Category: Crystal’s Status Reports

This week was quite eventful. I fried one of our pwm expanders which was a critical part of our project. To fix this there were 4 possible solutions: connect 10 servos to the stm and 6 to the raspberry pi and use UART signaling to initiate servo motor movement (all servos would not be able to move at once, give up on 6 of them and only drive 26 servo motor, use an arduino to drive the remaining servo motors, or use an Arduino Mega. Originally, I borrowed an Arduino Mega from Roboclub, but their Mega was broken and the I2C did not work. We had to borrow one from Justin from Techspark. I had to rewrite the STM code on to the Arduino. We are on track to finish because we have to. Next week we hope to finish everything (duh).

This week I cut hundreds of dowels. I still need to cut more when the other dowels come in. This week I also successfully wrote the firmware to control 3 servo motors on the PWM expanders and 2 stepper motors. I was originally having issues with the PWM expander, but the issue was that I forgot to plug it into a power source. When I first flashed the code onto the STM, the stepper motor twitched. This was due to the step pulses being too fast. I then added the stepper motor code but the stepper motors just did not spin. I tried to debug this by unplugging the I2C PWM expander, but the stepper motor started twitching again. This was because with no I2C devices connected, the I2C reader was failing and was blocking for a short period of time. This made the stepping loop slower, allowing the motor to spin. When I reduced the timeout, the stepper pulses became fast again, causing the motor to twitch. So increasing the I2C blocking period was just slowed down the CPU to make the stepping speed possible. The second stepper motor also initially used illegal GPIO pins.
I am on schedule, but I am concerned about the ability to incorporate the reset actuators because that depends on when they come in. We also have not ordered all of the dowels yet because we need to wait for them to restock.
Next week I hope to write the firmware for the second PWM expander and write the button powered interrupt that will trigger the reset.

To accomplish my task, I needed to know how to use the CubeIDE, know how servo motors worked, and understand the ability / limitations of different microcontrollers. I practiced reading data sheets and how to internet search to acquire this knowledge.

 

This week I started working on incorporating the PWM expanders and big stepper motor driver. Previously the servo motors were directly plugged into the GPIO pins of the STM. This would not have been efficient because a single STM does not have enough ports to directly connect 32 servo motors, so we had to buy 2 PWM expanders. Similarly, our stepper motors were previously run on A4988 stepper motor drivers, which did not have enough current to support the weight of our carriage holding 32 servos and gantry belt. I slightly moved the schedule around by working on incorporating these components first instead of programming an interrupt for the rest mechanism. I am still on track. Next week I hope to have all 32 servos working on the PWM expanders and the stepper motors on the heavy duty driver.

This week I was able to somewhat concurrently run 4 servo motors and then sequentially run the stepper motor that powers the gantry. I am saying somewhat concurrently because timer 2 on the STM only has 3 usable channels. This leaves one of the servo motors running on a different timer, causing it to run out of sync with the other servos. I am investigating how to sync these two timers. While writing the stepper motor driver, I realized we never considered a stepper motor driver in our design. Given that our stepper motor will need to support the weight of the actuator carriage and 32 servo motors, I decided to purchase a heavy duty stepper motor driver. I also wrote a function that can convert the calculated depth to an angle the servo can rotate to. We also decided to use dowels as our pins. We tried hand sawing and using a miter saw to cut the dowels. The miter saw didn’t give a clean cut, so we will be hand-sawing for now. However we will try other saws.

I am on schedule. Hopefully, the pwm expanders will come in this week, so I can implement actuation with the pwm expanders.

This week I worked on the firmware of this project. I designed the architecture of the firmware by creating 4 schedulable tasks: the UART message, actuator movement, gantry movement, and reseting. I am on schedule. Next week I hope to be able to have the firmware working with at least 2 actuators, a gantry motor (since the other one didn’t come in), and actual UART messages with the actuator heights.

I am currently trying to drive 4 servo motors. I was originally using 18349 code as a base, but was unsuccessful. I decided to pivot to using STM32CubeIDE projects because there are more resources on how to debug and approach common projects like driving servo motors. As I was trying to drive the servos, one of the servo motors had damaged wires due to strain and was therefore unusable. Setting up the CubeIDE was a bit of a challenge at first. The program was unable to detect my ST Link Server, and therefore unable to connect to my STM32. To fix this, I had to redownload the latest version of the CubeIDE. I was able to drive 3 servos! If I had a 4th servo, I am confident I will be able to drive it too.
I am now on schedule and next week I hope I can help with the physical assembly of the project.

This week I started getting the STM32 setup by configuring the timers and GPIO pins to generate a PWM signal. This has not been successful yet, but I will verify the setup by output putting the PWM signal to an LED.

I am slightly behind on schedule due to workload from other classes. I will put in extra hours this weekend to get the LED to vary in brightness with duty cycle, demonstrating the PWM signal.
Next week I hope to be able to have 4 servos moving in parallel.

So far, I’ve worked on shaping the project by carefully identifying the right components and mechanisms to make it feasible. I started by analyzing the cost and scalability issues of giving each pin its own actuator, realizing that this would exceed our $600 budget, so I explored alternatives like row-based actuation and column scanning. This week I listed different position based actuator parts we could use and narrowed it down to a few. On the electronics side, I mapped out how to divide responsibilities between a Raspberry Pi (for real-time depth capture and heightmap processing) and an STM32 (for deterministic actuator control), since the Pi can’t handle precise timing and the STM32 can’t handle heavy vision workloads. I also investigated specific ways to test latency, weighing options like software timestamps versus high-speed video, to ensure I can measure each subsystem’s delay as well as the full end-to-end pipeline.