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:

  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.

Kenny Ramos Status Report 4.25.2020

This week was mostly spent on getting the last few particulars of physical assembly done. Tomorrow (Sunday 26 2020) will mostly be spent on getting data and video compiled for the upcoming presentation. As of Saturday 4/25/2020 at 9:16 pm the progress on each individual physical part is as follows:

  1. Small digikey bipolar motor driver/controller PCB (fully assembled, only needs to be plugged in [Rpi + motor + housed on physical mount]).
  2. Nema 17 unipolar motor driver and power supply (1 set [2 H-Bridges + 1 Power supply + heatsink] fully assembled] 2nd set is being debugged, I might attempt using replacement MOSFETs/BUCK converters to see if that gives better results)
  3. Wooden physical stand (each portion [1 ⅝’s wood door hinge assembly + polar scope + camera mounting slot] + [1 MDF declination axis mounting hinge] + [1 MDF turntable Right ascension mounting slot] individually assembled, once debugging is done it should be a matter of joining parts and wires)

On top of that a few visual aids have been set up for debugging and demonstration purposes:

  1. Arduino adc logger + matplotlib for plotting logged adc input over time.
  2. Simple led circuit for demonstrating test point connection to circuit ground for small digikey motor controller.
  3. As discussed previously a 10W-10Ohm resistor for measuring H-bridge current (currently being used for debugging)

 

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.

Kenny Ramos Status Report for 4.11.2020

System Changes:

The main changes done this week basically break down to design changes to accommodate parts trickling in over time. Most of this is adapting the previous eq aligning design to the new barn door tracker. After receiving the universal stepper motor couplers I should be able to assemble the top portion of the diagram above with the exception of the motors since I do not have the pcb’s yet and I would like to thoroughly test them before placing them into the mount. Some things to point out in the diagram below include:

  1. The polar scope is manually (by us, not the “user”) aligned parallel to the hinge joint adjacent to the scope.
  2. The compensator motor is attached to the declination base and the universal hub is attached to the carriage bolt.
  3. The motor is kept from spinning by two #4 threaded rods that are locked into the barn door tracker base by two #4 nuts each. As the cariage bolt actuates the motor is pulled along with it so spacing must be kept in mind and a hole of sufficient size must be bored in the declination base.
  4. The base below the main barn door tracker compensator is essentially the same design as the one previously done by Joy for the previous iteration of this project. Some adaptations have been made to fit the new requirements. (As discussed above).

Progress has also been done in adapting logging for the Arduino. Getting the logger right now outputs to csv in real-time via a python script.

Risks:

Unfortunately, the arrival of the incorrect board types set back demo-readiness a fair bit, hopefully once the new boards arrived the new design will be ready for it. So that’s a risk that we could face.