status report – Team B1: Asterism

Team Status Update for May 2 2020

Now that we’re heading into the last week of the semester, the main risk to our project seems to be the lack of ready communication between the team member responsible for integrating the various components of our project and the rest of the team. This would have been tolerable earlier in the semester, but now it seriously threatens our ability to complete this project. As a contingency, we collected a cell phone number from the person in question, and will call him for status updates if he remains uncommunicative.

No changes to the overall system design or schedule have materialized, thankfully. We’d have pictures of the full project by now, if not for the aforementioned lack of communication. As a result, we’ll be showing the full project for the first time in the demo video due on May 4.

Yuyi Shen’s Status Report for May 2 2020

This week, I started preparing for the demo video due on May 4. This primarily consisted of setting up an OpenShot file for inserting our video and audio files:

I also set up the beginnings of a slide deck on slides.com (https://slides.com/yuyis/cmu_capstone_asterism) to serve as an initial part of the demo video:

I intend for this slide deck to be used to introduce the general project topic/design, electrical systems, and computer vision component before seguing into a recording by Kenny using our actual project. Recordings of this slide deck using OBS-studio will be stitched together with voice recordings and background music using the OpenShot instance shown earlier.

Next week, I’ll be working on the final report, and working with Kenny to get the demonstration setup and recorded. I think that’ll be all for capstone this semester.

Team Status Update for April 25 2020

The biggest risk right now is an incompatibility between the physical circuit and the software implementation in the final day of product implementation before the presentation is due. A difficulty in this aspect could prove to be a costly delay. This has been mitigated mostly by a good amount of software level verification from both Joy and Yuyi.

No changes in schedule have been made so far as the dominating factor this week is the presentation.

Yuyi Shen’s Status Report for April 25, 2020

This week, I spent most of my time advising Kenny on the assembly and testing of the mount electronics. Soldering the surface mount components proved to be unexpectedly challenging, and we had to get around multimeter reliability issues, inadequate desoldering equipment, and solder-related issues (Kenny had inadvertently ordered lead-free solder paste for use with the SMD components, which meant that he had to deal with the intrinsic difficulties of using lead-free vs. leaded solder as explained here: http://www.pcboardrework.com/difference-between-lead-and-lead-free-solder/). In addition to advising him on his difficulties, I also laid out procedures that he could apply to ensure the functionality of the mount electronics, ranging from the usage of the laser diodes intended for the test setup as makeshift current indicators for the mount’s unipolar motor driver PCB to the application of an ammeter (in conjunction with a large 10W resistor) for safely testing the NEMA 17 motor drivers’ H-bridges.

Given that the majority of my contribution is complete, I’m reasonably on schedule.

Tomorrow, we will conduct experiments to characterize the tradeoffs inherent in our design. These include the following:

The choice to use a custom PCB and circuit to implement the camera mount’s unipolar motor driver vs a typical UL2803 Darlington array. This tradeoff will mainly be evaluated by measuring the amount of current each device can supply to the mount’s unipolar stepper motor with a fixed supply voltage of 5V, and the temperature the transistors reach after 30 minutes of operation (as measured by infrared thermometer).
The decision to use a custom H-bridge circuit for driving our NEMA 17 stepper motors (used to implement panning and tilting of the camera mount) vs. a commercially available motor driver (such as the Easy Driver). This will be tested by measuring the H-bridge MOSFET temperatures after 30 minutes of powering 1 or 2 motor phases, and comparing their average to the temperature measurements listed on this site: http://www.schmalzhaus.com/EasyDriver/#Q14. A simple figure of merit will be calculated from the current each driver is able to supply, and the operating temperature.
We decided to implement our camera mount using a barn-door-style compensator to track the rotation of the starscape, instead of a more elaborate and accurate equatorial type mount. This style of mount usually experiences a form of tracking error called tangent error, which renders its usage impractical for exposures lasting longer than 5-10 minutes with a 50 mm lens. We intend to examine the degree to which our software-based compensation ameliorates this error by making progressively long exposures with a 56 mm lens with and without said compensation until star trails are visible on the image. The presence of star trails will be determined by comparing long exposures of the starscape with comparatively shorter ones, and measuring the relative sizes of the stars on the images.

Joy’s Status Update for 2020-04-25

I was able to verify that CV code compiles on the Pi and works with the motor controllers and libgphoto2 camera input. I wrote a GUI app (attached is a screenshot) for the motor controllers and fixed some bugs that my teammates pointed out to me. I haven’t integrated the CV code into the GUI app yet, so I am behind on that. Next week we have our final presentation, and the week after that we have the final demo, so I will spend next week working on those with my teammates, working on integrating the CV code into the GUI, and working on any last-minute software improvements.

Team Status Update for April 18 2020

The principal risk to the completion of the project at this late stage is the slowness with which assembly of the mount is proceeding. We also need to finish addressing the integration of the CV routines Joy has written with the mount hardware, such as the libgphoto2 interface to the mount camera. Given the remote nature of most of the remaining work, the only recourse seems to be the scheduling of more frequent status meetings until the dates of the in-lab demo and the final presentation. We’ve also created a Google document to list goals for each day of this final week.

No changes to the schedule or system design have been made.

Here’s a picture of a partially assembled motor controller PCB:

Feeding power to the 12V input of the buck converter that’s assembled on the bottom of the PCB causes the expected 5V to appear at the VDD pad, which is a promising result given the difficulty of soldering the SMD components. Tests of the remainder of the board (which composes the actual motor controller) should occur tomorrow afternoon at the latest.

Yuyi Shen’s Status Update for April 18 2020

This week, I mostly assisted Joy and Kenny with the integration of the mount electronics with the remainder of the mount. In Kenny’s case, this was just a matter of checking in on his progress with assembling the electronics (both on PCB and breadboard). In Joy’s case, this meant going over the meaning of the logic inputs of the unipolar and bipolar motor drivers, and the sequences in which they were supposed to be driven to effect a full-step sequence.

I also checked Joy’s motor driver code against the full-step sequences described online for bipolar and unipolar stepper motors, and wrote test cases in motor_driver/main.cpp. If all goes smoothly, main.cpp should cause one of the unipolar Digikey motors to rotate 3 times before reversing to the original position at 1 RPM, while setting one of the bipolar NEMA 17 motors to rotate at 60 RPM for a minute before turning off.

As a debugging aid, I also drew logic diagrams for the bipolar motor driver inputs that indicate the direction of current flow for different values of EN and PWM and labeled full-step sequence diagrams:

I felt that it was unnecessary to do the same for the unipolar motor driver, due to the lower complexity of the stepping sequence.

Thus far, I’m on track relative to the schedule. Next week, I need to start working on preparing materials for the demo video that cover my contribution to the project, while continuing to advise Kenny on the assembly and testing of the motor drivers. Since the vast majority of my tasks are complete, I will also spend some time working on the final report for the project.

Joy’s Status Update for 2020-04-18

This week I finished up the code for controlling the unipolar and bipolar stepper motors. It consists of two classes, one for controlling unipolar stepper motors and one for controlling bipolar stepper motors. The code I wrote uses std::thread to set the relevant GPIO pins in a loop so that multiple motors can be controlled at once. It also implements step-counting for tracking the number of revolutions taken. The GPIO library used was WiringPi. I found this article very helpful.

Next week, I will be working on checking that the CV code can run on the Pi, allowing the CV to use camera input, and hooking it up to motor control. I will also be working with Kenny to modify his polar alignment code from earlier in the semester to work with the rest of the system.

Joy’s Status Update for 2020-04-11

My tasks for the week:

Work on interface between motor controller board and Pi
UI fixes (e.g. selecting an object to track from live video) (not as important)
Automatic calibration for the compensator motor’s speed using CV (not as important)

What I have from this week:

Two squarewaves in quadrature from the GPIO pins of the Pi, at a much lower frequency than necessary for the PWM signals for motor control. (I don’t have an oscilloscope, although I might be able to hack something together with an Arduino, if I can find one) These are for the unipolar stepper motors for the compensator and test setup.

I lost some time trying to set up the Pi, and I’m also working on porting the code from the last few weeks to the Pi.

My progress: I’m behind on the motor controller interface. I expected to have more done.

Next week: More work on the motor controller interface.

Yuyi Shen’s Status Update for April 11, 2020

This week, I helped handle a handful of shipping/ordering mishaps. The PCBs that we had originally ordered were somehow mixed up with another team’s order, and Kenny ended up receiving a networking/audio controller board instead of the unipolar motor driver I had designed. Quinn re-ordered the motor controller PCBs, and they should arrive by the 17th.

In addition to dealing with the PCB mix-up, I had to revise our Digikey order for the NEMA 17 motor driver parts after reviewing simulation data of the motor driver power supply and the motor driver itself. After extending the transient simulation time for the motor driver power supply, I found that the SMPS’s inductor current oscillated between 0.6 and 6A, with an RMS average of 3.73A:

Since this was far beyond the current rating of the original inductor I’d specified for the SMPS, I asked Joe to cancel the original Digikey order, and changed the Digikey cart to use inductors that were rated for a maximum of 9A RMS. Since this maximum current would result in the maximum survivable temperature rise for the inductor (roughly 60 degrees C assuming the ambient temperature is 25C), I estimated that the newly selected inductor would experience temperatures of roughly 50C in operation. Kenny will need to be careful not to touch the SMPS inductors with his bare hands while the NEMA 17 motors are running, but they will otherwise be 35C below their maximum operating temperature.

Furthermore, a review of the transient currents through the motor driver core’s bootstrap diodes in LtSpice revealed that they experience regular spikes on the order of 1.5A and an inrush current in excess of 2.5A. Since their maximum current spike rating was 2A, I judged this to be potentially hazardous and switched them out for MBR360s, which are rated for 80A spikes. We were already ordering a handful of MBF360s for the motor driver SMPSs, so this wasn’t much of a load on the budget.

Lastly, I checked the power dissipation of the LM2576 regulator that I was planning on using for the motor driver SMPSs in simulation, and found that it would dissipate an average of 11W in steady state operation. Since the thermal resistance of the regulator’s package was specified to be 32.4 C/W, this would have resulted in a temperature rise of about 360 degrees Celsius if we ended up operating it without a heatsink. Obviously, this would have destroyed the device rather quickly. To prevent this, a heatsink with a natural thermal resistance of 3.8C/W was added to the original Digikey cart, in addition to a mounting kit with a mica insulator for the regulator tab. This thermal resistance is slightly less than half of the maximum required thermal resistance to keep the regulator at or below the maximum operating temperature of 125C (9.04 C/W), and should keep the regulator temperature down to 67C.

Lastly, I made sure to put in an order for 3 ULN2803 Darlington transistor arrays as a contingency in case the PCB re-order for the motor controller doesn’t get shipped to Kenny’s house in time for us to make the deadline for the demo.

Thus far, I am on track with my contributions to the project. Next week, I hope to consult with Kenny on the final construction of our camera mount’s electronics, and with Joy on the interface between the Raspberry Pi and the motor controllers.