Tag: Yuyi Shen’s status report

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.

This week, I designed and laid out for a unipolar stepper controller board for the MIKROE-1530 stepper motor, which we’re switching to due to its lower power requirements. Although ready-made drivers do in fact exist for this stepper motor, the more common ones rely on BJTs to switch current through the motor windings, which have relatively high Vce,sat values. As a result, the decision was made to specify a controller board with low Rds,on MOSFETs (IRLR6225TRPBF) to bring the board’s power dissipation to a minimum.

Because of the relatively low complexity of unipolar motor drivers, the design process was fairly simple, with the exception of the selection of gate resistor values for the motor driver MOSFETs for limiting the degree to which the current waveforms through adjacent motor phases overlap. This overlap manifests as periodic spikes in the current from the power supply, and needs to be kept to a minimum to avoid overloading whichever module is supplying power to the motor. LtSpice simulation was performed with the below testbench to determine the impact of the gate resistor on the supply current spikes (graphed below):

The magnitude of the spike (measured using the steady-state supply current of 185 mA as a reference) was found to be inversely proportional to the gate resistor value:

Ultimately, a gate resistor value of 475 Ohms was selected to keep the supply current within 5% of the steady-state value. The logic gates for providing the motor controller’s ENABLE functionality and hardwiring the motor’s full-step sequence were included in the simulation to model the impact of their propagation delays on the supply current spikes. After this was finalized, high-speed 1N4148 diodes were added in shunt with the MOSFET body diodes to serve as flyback diodes and a transient simulation was performed to confirm that the voltages at the MOSFET drains did not rise beyond the 20V limit for the MOSFETs:

Because the current spikes through the flyback diodes do not exceed 92 mA in magnitude while the diodes themselves are rated for 2 A of surge current, this design is fine.

Unfortunately, due to a connection error during the layout, a revision had to be performed after the Google Form for the board order was submitted. The updated board order is linked here: https://oshpark.com/shared_projects/ezthQ1TM

The layout for the new motor controller board is shown here:

All IO pads on the board are surface mount, and so will require some skill from Kenny during assembly. Each logic input and the board outputs are equipped with either test points for debugging the board’s control inputs or current sensing resistors for measuring the board’s output current so that my SPICE simulations can be validated.

In addition to working on the motor controller for the mount, I also advised Kenny on the design of rudimentary constant-current drivers for the test setup’s laser diodes. To lower the strain on our budget and avoid the lead time associated with PCB fabrication, we chose to have Kenny solder together through-hole components in air for these drivers.

At present, I am on track with respect to our current schedule. Next week, I plan on going over the mount’s user interface with the others and designing a board based on their recommendations to serve as an electro-mechanical interface to the mount for the user. Thus far, we’ve been planning to use this interface board to permit the manual operation of the camera mount’s stepper motors and the selection of targets for object tracking.

This week, I placed the finishing touches on the high power motor controller board. This mostly consisted of adding charge reservoir capacitors to decouple the H-bridges locally so that the voltage at the H-bridges won’t droop during operation. I also tidied up the PCB silkscreen so that the component designators are easily visible:

On JLPCB, the design should cost roughly $28.50, with an additional $17.55 for DHL shipping for 5 units. Thus far, shipping to the US with the aforementioned courier has not been impacted. With an estimated build time of 3 days, a shipping time of 4 business days, and a delay of 3 days (due to Coronavirus), we can get our designs done with a lead time of 10 days, which is still reasonable.

Due to changes in the scope of our project due to Coronavirus precautions, I’ve begun investigating the possibility of using a smaller 4096 step stepper motor (MIKROE-1530) for driving our project’s barn door compensator. This motor takes 5V (which would require a redesign of the primary SMPS), but only consumes 0.1 A per phase. Using IRLR6225TRPBF MOSFETs means that the static power consumption is less than a milliwatt, allowing the omission of area-intensive drain pads that would ordinarily be used for heat dissipation. The electrical complexity of the gate drivers also drops due to the motor being unipolar, allowing the usage of simple buffers (LM5114BMFX/S7003094) instead of proper half-bridge gate drivers like the LM5109B. Overall, changing over to this motor will allow the resultant motor controller board to be much smaller, giving us more headroom in the budget since the US-based PCB manufacturer we were planning to use as a backup in the case of further Coronavirus-based shipping restrictions charges by the square inch. Assuming that we fix a rotation rate of 1 RPM for this motor for the barn door compensator, the motor controller board will need to support 68 steps per second (which is well within the capabilities of an Arduino’s ADC to detect and record for debugging purposes).

Next week, I intend to consult with the faculty on the feasibility of performing the PCB fabrication through JLPCB in light of potential shipping restrictions. If it is possible, then I will perform a design review of the motor controller with Dr. Mukherjee and have the board ordered to Kenny’s location for assembly. As a contingency, I will proceed with the design and layout of a motor controller for the new 4096 step motor with the goal of keeping total PCB area below 4 square inches ($20 dollars on OSHpark).

This week, I resolved the shoot-through issues that the motor controller board was experiencing. This was mainly done by increasing the value of the H-bridge gate resistors until the MOSFET turn-on times were significantly longer than the turn-off times, generating dead-time in which neither MOSFET on a single side of an H-bridge is on. An acceptable shoot-through current spike specification was calculated by assuming that the shoot-through current was relatively constant for the duration of the spike (which was roughly 1 us in transient simulation), and relating the resultant flow of charge to a drop in the voltage of the H-bridge power supply output capacitors. By setting this maximal voltage drop to 0.03 V (so that the output capacitors retained 99% of the nominal output voltage after a shoot-through spike), I calculated that a maximum shoot-through current of 1.2 A for 1 us was satisfactory for the motor controller design. This maximum shoot-through current specification was found to correspond to a gate resistor value of 4152 Ohms in simulation. Setting the gate resistor to 4.22 kOhms (the nearest available value in Digikey) produced the following waveforms:

As can be seen from the pink waveform in the bottom-most plot, this value of gate resistor results in a shoot-through current spike of 2.251 A. From the waveforms of the hi-side and lo-side MOSFET gate voltages shown in the upper-most plot, we can see that the turn-on time (the red waveform) is much longer than the turn-off time (shown in the sharp edge of the blue waveform). Therefore, the circuit is operating properly for this value of gate-resistor.

Re-simulating for the circuit propagation delay, we find that the tplh of the PWM input is now 1.127 ms, while the tphl is 1.1 ms. Since this is much less than the period with which we plan to switch the motors, the gate resistors clearly do not overly impact circuit performance.

After making this refinement to the motor controller circuit, I generated a preliminary layout on PCB:

The 8V and 3V supply modules were pasted in from their respective layout files, while the remainder of the board was laid out in accordance with http://www.ti.com/lit/an/slva959a/slva959a.pdf. All that’s left is to place additional charge-storage capacitors at the power nodes. Here’s the updated schematic: schematic

I’m slightly behind schedule on this. I was supposed to complete the layout process earlier in the week, but ended up taking longer than expected. However, assuming that we follow the current schedule, all that’s left is to make the aforementioned revisions and perform a design review before ordering the board.

I’m uncertain as to what I should aim to complete next week. CMU’s recent move to remote instruction in light of the recent pandemic means that there will be substantial changes to the plan for capstone moving forward, and it’s unclear if there’ll still be a project component to this class.

This week, I worked on generating a preliminary layout for the motor controller board in KiCad. To accomplish this, I finished specifying and laying out an 8V LDO-based supply for the motor controller ICs:

It’s laid out in standard-cell format so that it can be easily dropped into the final motor controller board. We came up with an initial BOM for this supply for the design report, but I ended up revising it to better reflect the requirements stated in the voltage regulator’s datasheet: https://www.digikey.com/short/z8pr24. The revised BOM simply includes two large I/O capacitors, so there isn’t much of a change to the budget. The specific IC is the LK112M80TR (rated for 150 mA of output current). Fortunately, the low quiescent current draw of the motor driver ICs (22.8 mA in total for each controller board) means that we don’t need to include thermal considerations during layout design. It takes a 23.5 C temperature rise to produce a 1dB degradation of supply voltage rejection for this particular regulator (the key spec for a LDO), and it’s incredibly difficult to produce that with only 91 mW of quiescent power consumption.

I’ve also produced a PDF of the tentative full schematic for the motor controller: KiCad Schematic

At the moment, the layout of the motor controller board is being held up by the unwieldy footprints of the MOSFETs. Each MOSFET drain requires a 28 mm by 28 mm copper square to keep their temperatures below ~35 C during operation, resulting in this horrid thing:

It doesn’t help that the MOSFET drains are on one side of the package while the sources and gates are on the other, since drains and sources need to be connected in a H-bridge. I’ve gotten around this thus far by using one MOSFET in each IC (the ICs have 2 MOSFETs each) for individual half-bridges, but it requires excessive distance between the MOSFET gates and gate drivers (terrible for minimizing H-bridge ringing).

Luckily, there haven’t been any issues with copy-pasting the standard cells for the power supplies into the full motor controller KiCad project. I was initially worried when I figured out that it’s not possible to directly copy-paste between KiCad instances, but it turns out that EESchema allows users to append schematics, while the standalone version of PCBnew allows for appending layouts.

I’ve also run a new simulation of the H-bridge, with diodes placed at the MOSFET gates to speed up turn-off times and hopefully prevent shoot-through:

Unfortunately, simply placing the diodes there does little to prevent shoot-through, as can be seen in this simulation of the power supply current (the blue waveform) as the H-bridge is switched:

Clearly, there are immense current spikes exceeding 45A in amplitude as the motor controller PWM input is turned on and off. Simulating for the gate voltages of the hi and low-side MOSFETs on the “left” side of the H-bridge confirms that these spikes are caused by shoot-through:

The voltage at the MOSFET gates (the top set of waveforms) is high for both hi-side and lo-side MOSFETs for a short amount of time, causing the MOSFETs to short the supply to ground temporarily.

I’m behind by a week. I resolved to complete the motor controller board by the first half of this week, but was delayed by a series of unfortunate events (design report due on Monday, design review for another class, and an Open House event for prospective grad students). To catch up, I’ll need to resolve the shoot-through issues in simulation (hopefully through simply finding a circuit to copy-paste). Then, I’ll need to wrestle with the MOSFET footprints and find a way to position them so as to avoid adding extreme amounts of parasitic inductance into the gate driver traces. Lastly, I’ll need to talk with Kenny about what the circuitry for the test-setup should look like (so that he can do the actual design by himself, and perform sanity checks against our general expectations).

Next week, I hope to complete the layout for the motor controller board, and meet with one of the professors to perform a design review (probably in the latter half of the week). Given the challenges that this part of the project has posed thus far, I think that’s the most I can hope for.

I estimate that I’m 1 week behind on the user interface board design and the layout for the motor controller board. I was also meant to start working on the test setup with Kenny, but he’s been bogged down with the mechanical portion of the project. This isn’t entirely unexpected, as I’ve been gone for almost half the week for a graduate student recruitment event. That, and course logistics have taken up a great deal of time (i.e. preparing for the design review presentation and the design report).

This week, I’ve only managed to setup my layout software with component symbols and footprints in preparation for laying out the motor driver board. Motor driver layout is precarious at best, so I’ve spent most of my time reading up on board design guidelines so that we don’t waste time re-spinning a board. I’ve also compiled a Digikey cart for the driver board: https://www.digikey.com/short/zq07q2 as a price estimate. Disregarding the cost of the PCB, the components for a single unit cost $18.91. This high price point is mainly due to the MOSFET gate drivers and H-bridge FETs, so it’s difficult to ameliorate.

To get back on track next week, I’ll first need to work with my team to get the design report done ASAP. Then, I’ll need to finalize the layout for the motor driver board and 8V power supply in the first half of next week so that we can send the orders out. In the remainder of the week, I’ll work with Kenny on the circuitry and layout for the equatorial mount’s test setup. The layout for the user interface board can be pushed back to Spring Break, since there hasn’t been much progress on the software component of the project.