RM2025-Core Embedded Platform
Embedded Team Lead · Core Maintainer
Maintained the shared embedded platform used by seven robots, standardizing drivers, communication, control, and math interfaces while helping a team of about ten engineers work within clear boundaries.
- Platform scope
- 7 RoboMaster robots
- Collaboration
- ~10-person embedded team
- Maintenance evidence
- 141 unique commits; 114 in develop
- Knowledge transfer
- ~10 training sessions on drivers, RTOS, and debugging
Background
Maintained the shared embedded platform used by seven robots, standardizing drivers, communication, control, and math interfaces while helping a team of about ten engineers work within clear boundaries.
The platform supported the full 2025 fleet. Repository history contains 141 unique commits by wilsonooo09, 114 of which are in current develop; these numbers indicate maintenance scale, not sole authorship or quality.
The 141 / 114 figures come from local author and branch-history counts. They indicate maintenance scale only; the platform was collaborative work.
My contribution
- Maintained shared driver, communication, control, and math infrastructure with consistent interfaces.
- Split team work, reviewed pull requests, and handled fleet-wide regressions and urgent field fixes.
- Delivered about ten training sessions covering STM32, FreeRTOS, communication, control, and debugging.
- Improved observability with SystemView, Tracealyzer, error counters, and per-channel timeout states.
- Technical environment
- STM32 · FreeRTOS · FDCAN / UART / SPI · DMA Receive-to-Idle · PID / Filters · SystemView / Tracealyzer · Git Review
Implementation
Drivers
GPIO, PWM, CAN, UART, SPI, timers, and DMA isolate board- and HAL-specific differences.
Communication
Motor, referee, VTM, vision, and inter-board protocols share parsing, validation, timeout, and status interfaces.
Control & Math
PID, filters, ramps, kinematics, and common math utilities avoid repeated implementations across robots.
Application boundary
The shared library exposes reviewed capabilities while robot-specific task states remain in each application.
Technical decisions
Shared interfaces before robot-specific exceptions
- Context
- Seven robots had different hardware and tasks; adding every exception to drivers would turn each change into a fleet-wide regression risk.
- Choice
- Exposed device capability, validity, and timeout through stable interfaces and kept robot policy in application code.
- Delivered result
- The same drivers remained reusable and reviews could focus on actual boundary changes.
Observability as a shared capability
- Context
- Many field failures occurred only under load or disconnection, where breakpoints were insufficient.
- Choice
- Added communication counters, per-input validity, timeouts, and RTOS trace tooling.
- Delivered result
- Failures could be localized to protocol, transport, or application state instead of being labeled generic serial instability.
Debugging process
Supporting old and new VTM serial protocols
A new referee system introduced a new video-transmission module. The shared driver had to support both serial protocols without regressing existing robots.
Symptoms
- Some new-protocol frames failed validation and keyboard/mouse or remote-control input dropped intermittently.
- Old-protocol regression exposed length, bit-field, and buffer differences.
- After disconnect, the application could still read the last valid keyboard state.
Investigation
- Instrumented receive paths by header, CmdID, length, CRC8, and CRC16.
- Checked structure bit-fields and alignment against actual DMA Receive-to-Idle lengths.
- Reviewed the fix sequence to locate buffer-clear timing and old-protocol regressions.
Root cause
The protocols differed in headers, command IDs, lengths, and field layout. Early handling mixed validity with buffer lifetime, allowing invalid frames or stale disconnected input to reach applications.
Fixes
- Separated parsing by protocol header, CmdID, and length with complete CRC8/CRC16 validation.
- Corrected bit-fields, structure alignment, buffer sizes, and DMA buffer-clear timing.
- Added receive, UART-error, and CRC-error counters.
- Tracked remote, keyboard/mouse, and VTM state with independent timeout/valid flags and cleared unavailable input.
Validation & evidence
- Regressed input, disconnect, reconnect, and malformed frames on both old and new modules.
- Observed state continuity and counters on real robot tasks until the compatibility driver was stable.
LessonProtocol compatibility is more than another parser branch: frame validation, buffer lifetime, and disconnect semantics must form one coherent interface.
Validation & evidence
- The shared platform went through cross-robot integration and hardware regression across seven distinct robots during the season.
- Both VTM generations passed input, disconnect, and recovery regression; no packet-loss metric was saved, so none is claimed.
- Commit counts are maintenance-scale evidence only and do not erase team contribution.
The 141 / 114 figures come from local author and branch-history counts. They indicate maintenance scale only; the platform was collaborative work.