Aug 2024 — Aug 2025Shared embedded platform for the team

RM2025-Core Embedded Platform

Embedded Team Lead · Core Maintainer

Maintained drivers and communication interfaces on the team’s existing shared firmware, handling protocol compatibility, motor-driver fixes, code review, and onboarding for seven robots.

Scope
Drivers, communication, and shared interfaces
Used by
7 robots
Team role
~10 members · PR review and training
The HKUST ENTERPRIZE embedded team.
The HKUST ENTERPRIZE embedded team.

Background

Robots shared device drivers, protocols, and control utilities. The library combines work from multiple seasons and contributors, while robot-specific tasks remain in application projects.

As team lead and maintainer, I implemented selected driver and protocol changes and reviewed and integrated teammates’ work.

My contribution

  • Adapted old/new video-transmission protocols and corrected decoding layout, buffer sizing, and writes from invalid keyboard/mouse input.
  • Fixed reversed motor output and CAN-channel initialization, and maintained motor interfaces and MCU configuration.
  • Updated dependencies including FreeRTOS and SystemView and maintained project templates; assigned work, reviewed PRs, and handled field issues.
  • Designed and delivered about ten training sessions on peripheral communication, motor control, and FreeRTOS.
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.

System relationship schematic
New / old VTM serial bytesTwo headers and field layouts
DMA Receive-to-IdleBuffer handling by actual receive length
Header / CmdID / lengthCRC8 + CRC16
Protocol-specific decodeBit-field and structure alignment
Per-channel validityRemote / keyboard / VTM time out separately; stale input is cleared

Technical decisions

Separate shared drivers from robot tasks

Context
The same device interfaces serve robots with different tasks.
Choice
Maintain device and communication interfaces in the shared library, leaving task-specific state machines in applications.

Maintain callers alongside interface changes

Context
Motor interfaces, MCU settings, and dependency updates affect existing projects.
Choice
Update configuration templates, build lists, and affected drivers together, integrating changes through PR review.

Problem & changes

Protocol compatibility and invalid input handling

The new season’s video-transmission hardware changed its communication format. I adapted the existing driver and worked with teammates on receive and parsing fixes.

Fixes

  • My changes covered field layout, receive-buffer sizing, transmit/receive handling, and conditions for accepting keyboard/mouse input.
  • Teammates also fixed receive logic, including buffer-clear timing; I reviewed and integrated their changes.
  • The resulting implementation tracks input validity, clears timed-out input, and prevents invalid fields from being written back.

Validation & field records

  1. Development and integration established communication with old and new modules, with changes addressing data layout, receive handling, and input validity.
  2. The library supported the team’s 2025 robots, with integration carried out by each robot’s project members.

Public references