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.

Team B1 Update for 4.11.2020

Risks:

One major risk we’ve come across recently is that of a mix-up occurring during the shipping or ordering of items we order from the course staff. This week, instead of receiving the unipolar motor driver that was expected, we got an audio controller PCB from OSHPark. After a few days of inquiries, it was found that the PCB we received was in fact associated with another team’s design, and the course staff decided to re-order the board design. As a contingency for the delay caused by this particular mix-up, it was decided to order a set of darlington transistor arrays from Sparkfun to serve as a potential (if less effective) replacement for the PCB. As a contingency for future mix-ups, we intend to investigate alternatives to required components that can be physically picked up at a store by the team member responsible for assembling our project hardware.

System Updates:

Our previous design made use of an external touch enabled display to provide user interfacing with our raspi. However, in an attempt to reduce project complexity as well as to provide a contingency in the case that the raspi is not powerful enough to both compute image-based compensation on top of a GUI and touch screen feedback we will be altering the design. In our new altered design we will be emplogin a standard user-end notebook as the system for our GUI. This notebook will then communicate with the rpi via usart interfacing (alternatively via ethernet connection) and will provide the raspi with necessary user feedback and vice versa.

The above Gantt chart reflects the decision to move away from the usage of an external display to interface with users. Notably, the task labeled “User Interface Specification” has been struck through, indicating that it is no longer relevant for the project.

Yuyi Shen’s Status Update for April 4 2020

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.

Team Status Update for April 4 2020

Risks:

With regards to the integration of the project components, the principal risk consists of coronavirus-induced shipping delays that could keep us from obtaining missing components on short notice. This is primarily being mitigated by having frequent discussions with one another (and especially Kenny) about parts that are missing or still in-transit.

Last week, we wrote about the increased distance between team members causing significant communication delays. This was addressed by first re-examining our regular meeting schedule, and updating it to reflect our present availabilities. Secondly, we set up a Google Form at https://forms.gle/HW3D9axC5a3YqB7x8 to serve as a rudimentary ticket system for team issues. Tickets are directed to a Google Spreadsheet within our Google Drive directory for later approval.

Changes to system:

This week, Kenny determined that the NEMA-17 400 step motors that we ordered earlier this semester are necessary to implement the panning and tilting functionality of our camera mount. This precludes the possibility of using the smaller 4096-step motors + pcbs that we ordered earlier. Because of the long shipping times associated with the cheaper manufacturers that we’d have to use to spin out the large PCBs that were designed earlier this semester for driving the NEMA-17 motors, we decided to have Kenny implement rudimentary H-bridges on a breadboard using through-hole components. Due to the timing with which orders are placed in this class, this change does not impact our schedule. Indeed, the new through-hole design has already been validated in SPICE simulation, and simply needs to be converted to a Digikey cart for ordering. The risks of implementing H-bridges on breadboard will be mitigated by using separate breadboards for each motor driver to avoid crosstalk, and a relatively large gate resistor was specified for the H-bridge MOSFETs to damp up to 50 nH of parasitic inductance at the FET gates (the circuit node that’s most sensitive to parasitic inductance). Note that this 50 nH corresponds to roughly 5 cm of wire (going by the classic approximation of 1 nH/mm for bond wires).

Changes to schedule:

The “assemble mount” task has been extended to Week 13 to allow for the arrival of the final mount components, while the laser array board layout task has been struck through to reflect our decision to have Kenny simply solder together through-hole components to implement the test setup’s laser drivers. Lastly, the User Interface board layout task has been revised to omit mentions of PCB layout, since the rudimentary UI can be implemented with switches on one of Kenny’s breadboards.

Joy’s Status Update for 2020-04-04

I hooked up the demo to the CV tracking and prototype panning and tilting by allowing output from the tracking algorithm to move the camera in the OpenGL model. The two virtual motors are controlled with a PID control loop. Code has been pushed to the s18-18400-b1-asterism repo.

Things I am behind on that I will catch up on next week:

  • Porting existing code to Raspbian
  • Figuring out how to communicate to the motor controller

Other things I will work on next week:

  • UI fixes (e.g. selecting an object to track from live video)
  • Automatic calibration for the compensator motor’s speed using CV