Author: yuyis1

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.

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:

1. 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).
2. 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.
3. 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.

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.

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.

This week, I worked with Kenny to specify through-hole components suitable for driving the large NEMA-17 motors that were determined to be necessary for implementing the pan and tilt functions of our camera mount (see Team Status Report). Spinning out the PCB that was designed for this task earlier in the semester was found to be infeasible due to the risk of shipping delays impacting our ability to receive the boards from whichever manufacturer we decided to use (the boards would have needed to be manufactured overseas to keep costs low). We examined the possibility of simply ordering the motor drivers that were recommended on the motor supplier’s website (notably the Big Easy Driver on Sparkfun), but found them to be rated for far higher supply voltages than the motors were capable of handling.

First, we specified through-hole components for a 12V to 3V SMPS for powering the motors. We chose to use a LM2576T-ADJ/NOPB as the SMPS controller, and simply calculated the resistor feedback values for setting the output voltage to 3V. The inductor and capacitor values were kept to the recommended values in the datasheet. LtSpice was used to verify that the design would indeed produce the desired output voltage:

Then, I spec’d out through hole parts for implementing the actual H-bridges for controlling the motors (2 H-bridges per motor). IRFZ24N transistors and IR2302 gate drivers were selected, along with 24.9 Ohm gate resistors so that the driver circuit can tolerate up to 50 nH of parasitic inductance at the MOSFET gates (to reflect the implementation of the circuit on a breadboard). The gate drivers have built-in PWM and ENABLE inputs, so no additional logic was required past a single inverter for buffering the input of the 2nd gate driver. Because the gate driver ICs are synchronous, no special measures were required for generating dead time. High speed 1N4148 diodes were chosen to clamp the inductor voltages to the supply rails.

Verification was carried out in LtSpice:

Note that there are no spikes in the I(V1) waveform, indicating that the gate driver ICs are successfully mitigating shoot-through in the MOSFETs. Furthermore, the current through the inductor representing the motor coil falls rapidly to 0 when the ENABLE signal goes low, meaning that this functionality works in simulation.

There are voltage spikes at the motor coil during operation, but the flyback diodes successfully keep them within 1 diode drop of the supply rails. There’s also some ringing when the ENABLE signal goes low, but it eventually dies down to a steady-state.

Thus far, I believe I am on track for the 1st demo-in-lab, and the Gantt chart schedule. The first demo will consist of a slide show with simulation results for the motor controllers, and the layout for the motor controller PCB that was designed for the smaller compensator motor. Next week, I will first need to compile the slide show for the demo. Then, I will need to compile a Digikey cart for the final through hole components, and work with Kenny to ensure that we aren’t missing any mechanical components for the test-setup for our mount.