Project 03 · Embedded robotics
Embedded Controller for an SO-101 Robot Arm
I am moving communication with all six servos from the laptop to an STM32 microcontroller running FreeRTOS. I completed PC-side setup and one-at-a-time ID assignment, and I am now validating the six reply packets.
- Role
- Solo embedded firmware build
- Controller
- NUCLEO-G474RE
- Configured diagnostic target
- 6 × STS3215 · USART1 at 1 Mbps
- Status
- Read-only telemetry work
At a glance
What the embedded controller handles today and what I need to validate next.
The problem
I am turning a six-servo SO-101 follower arm into a firmware project where the embedded controller owns communication, timing, motion execution, command checks, faults, and telemetry instead of relying on a laptop-first demo.
My contribution
I completed PC-side feedback bring-up and one-at-a-time servo ID assignment, configured the NUCLEO USART path, flashed an early UART ping build, and wrote the current FreeRTOS diagnostic task. I am now validating replies from all six servos before I introduce motion commands.
Current progress
The current diagnostic task sends one 14-byte broadcast request and treats the 84-byte response buffer as six assumed 14-byte servo replies. It prints each reply’s ID, error, position, speed, load, voltage, and temperature. I have not yet validated packet boundaries, headers, declared lengths, servo IDs, reply order, or checksums, so this is a parser prototype—not verified full-arm telemetry.
01 / Boundary
Move the real-time boundary onto the NUCLEO
I still use the laptop for setup, commands, logging, plotting, and tests. I am moving servo communication, timing, safety checks, and eventually motion execution onto the NUCLEO-G474RE so that the embedded controller—not the laptop—owns the real-time work.
02 / Early bring-up
Verify the board path before expanding the bus
I used the project-specific CubeMX configuration to establish the target and USART1 pin path, then flashed and verified an early single-servo UART ping build on the NUCLEO. I use these screenshots to document board-level bring-up—not a servo reply or the current six-servo path.
My current project uses separate transmit and receive pins, while the STS3215 servo chain shares one half-duplex data line. I have not yet documented the adapter or direction-control circuitry that connects them, so that physical interface is part of my next hardware validation milestone.
03 / Current source
The current path is read-only
My current firmware runs one blocking, read-only diagnostic task. It sends a broadcast status request to servo IDs 1–6 over USART1 at 1 Mbps, reads an expected 84-byte buffer as six assumed 14-byte replies, extracts the status fields, and sends readable diagnostics to the laptop over the NUCLEO’s 115,200-baud USB serial connection.
I wait 500 ms after each blocking exchange, so this is a bring-up diagnostic rather than a high-rate motion-control loop. The driver’s HAL_OK return value does not validate packet framing, order, length, servo ID, or checksum. Those checks and reliable full-arm telemetry are my next validation milestone, and I am keeping motion disabled until calibration, soft limits, command rejection, timeouts, fault handling, and controlled motion profiles are in place.
Live build status
Current status
- Done
PC bring-up
I verified serial feedback and assigned unique servo IDs one at a time.
- Now
STM32 telemetry
I am capturing one complete six-servo exchange. Before I treat the telemetry as reliable, I will validate packet boundaries, headers, declared lengths, servo IDs, reply order, and checksums.
- Next
Safety + motion
Next, I will add calibration storage, soft limits, command rejection, motion profiles, and fault handling.
- Next
Manipulation
I will validate repeated pickup before attempting the model-based bottle-flip trajectory.
Tools & technologies
- Embedded C
- STM32G4
- FreeRTOS
- UART
- STS3215
- CMake
- CubeMX