RM2025 Engineer Robot
Embedded Lead · System Integration
Built the coordinated control system for a 38 kg engineer robot, spanning a custom controller, dual main controllers, a 6-DoF arm, swerve chassis, lift, and vacuum mechanisms.
- System scope
- Dual controllers + custom input device across arm, swerve, lift, gimbal, and vacuum actuation
- Field result
- Hardware validation across training, matches, and All-Star tasks
- Deployment boundary
- Kinematics and compensation deployed; experiments labeled separately
- My role
- Embedded architecture, control, integration, and field support
Background
Built the coordinated control system for a 38 kg engineer robot, spanning a custom controller, dual main controllers, a 6-DoF arm, swerve chassis, lift, and vacuum mechanisms.
Delivered the three-node embedded architecture, arm and swerve control, vacuum handling, and full-robot protection, then exercised them in 2025 season and All-Star hardware tasks.
All numbers are scoped to 2025 hardware tasks: ~90% is an observational estimate, while 5.8 seconds is one All-Star task timing. Neither is a general performance guarantee.
My contribution
- Designed and maintained a three-node embedded architecture with clear input, vehicle-decision, and actuation boundaries.
- Implemented manipulator kinematics and joint control, swerve control, lift coordination, and vacuum actuation.
- Added homing, timeouts, speed/steering constraints, and observable states for full-robot integration.
- Worked with mechanical, vision, and operator teams to iterate task flows and troubleshoot under competition pressure.
- Technical environment
- STM32G473 / STM32G431 · FreeRTOS · FDCAN / Modbus RTU · 6-DoF Arm · Swerve Chassis · Kinematics · Vacuum System
Implementation
Input and status
The gimbal/arm controller collects VTM and custom-controller inputs, then reports state to the chassis controller through 0xBA frames.
Vehicle decisions
The chassis controller owns operating modes and interlocks, issuing coordinated 0xAA command frames to the arm side.
Redundant link
Modbus 485 is the primary inter-board link, with FDCAN3 retained as a backup path and both represented in timeout logic.
Actuation
A 6-DoF arm, four swerve modules, lift, gimbal, vacuum pumps, and valves are sequenced by explicit states.
0xBA state return → ← 0xAA commands · Modbus 485 primary / FDCAN3 backup
Deployment boundary
| Capability | Status | Evidence |
|---|---|---|
| Joint loops and gravity / static compensation | Deployed | Called by the field task path; compensation for joints two and three is enabled in output calculation. |
| Automatic inverse-kinematics target path | Tested, not shipped | The solver and experimental path exist, but the complete automatic IK path was not enabled for final tasks. |
| Arm workspace limiting | Tested, not shipped | The limiting function was implemented and tested; its formal task-path call remained disabled. |
| Dynamic rollover model | Abandoned / disabled | Not shipped; speed and steering constraints plus operating procedure managed the field risk. |
| Teleoperation force feedback | Abandoned / disabled | Removed from formal task modes because link rate and model fidelity were insufficient. |
Technical decisions
A deployable model over full inverse dynamics
- Context
- A full RNE model was highly sensitive to mass, center-of-mass, and friction parameters that were difficult to identify reliably during the season.
- Choice
- Kept kinematics and joint loops, while deploying testable gravity/static compensation and damping behavior instead of relying on the complete model.
- Delivered result
- The controller remained tunable across real mechanical error and payload variation.
Managing a 38 kg robot with explicit constraints
- Context
- The long arm created substantial inertia and center-of-mass shifts, while a dependable online rollover model was not available.
- Choice
- Used enabled speed and steering-rate constraints, homing, pose checks, and operating procedures; the disabled dynamic rollover model is not claimed as a deployed feature.
- Delivered result
- The robot completed tasks without rollover, with protections that could be inspected in code and pre-match checks.
Suction detection from available feedback
- Context
- The weight budget did not allow an independent pump and pressure sensor for every suction cup.
- Choice
- Used M3508 pump speed/current for the arm suction state and pressure feedback for storage suction cups.
- Delivered result
- Obtained useful suction observability without unacceptable hardware weight.
Dropping unreliable force feedback
- Context
- Link rate and model accuracy made experimental force feedback delayed and inconsistent.
- Choice
- Removed force feedback from competition operation and retained stable input mapping, compensation, and state cues.
- Delivered result
- Reduced oscillation and operator workload while keeping the published capability aligned with deployed code.
Debugging process
Why force feedback did not enter the field version
I experimented with returning model-estimated load and actuator state to the custom controller so the operator could feel arm loading.
Symptoms
- During fast motion, feedback lagged behind both vision and robot motion.
- Estimation error changed with pose and payload, preventing consistent operator expectations.
Investigation
- Separated control-cycle, inter-board update-rate, and model-parameter effects.
- Compared task repeatability with feedback enabled and disabled.
Root cause
Communication rate and model accuracy jointly limited feedback quality; more filtering could hide noise but could not create trustworthy haptics.
Fixes
- Removed force feedback from formal task modes.
- Retained verifiable gravity/static compensation, input mapping, and state cues.
- Made the boundary between experimental and deployed features explicit in code and documentation.
Validation & evidence
- Operators repeated storage, exchange, and driving tasks to confirm predictable motion.
- Pre-match checks verified communication, homing, vacuum, and chassis constraints.
LessonA more complete model is not automatically better engineering; if operators cannot trust the feedback, reducing scope is safer than adding algorithms.
Validation & evidence
- Verified joints, swerve, lift, and vacuum individually before multi-controller integration.
- Cross-checked function with task footage, first-person field video, and competition results rather than simulation alone.
- From my observations across season training and matches, ore storage/retrieval succeeded approximately 90% of the time. No per-attempt log was retained, so this is a scoped estimate rather than a formal measurement.
- No rollover occurred during the match tasks in which I participated; this is a season record, not a proof of safety for every pose.
- One Level-4 ore exchange at the RM2025 All-Star Game was timed at 5.8 seconds. It reflects the complete robot, mechanism, operator, and field workflow rather than one control algorithm.
All numbers are scoped to 2025 hardware tasks: ~90% is an observational estimate, while 5.8 seconds is one All-Star task timing. Neither is a general performance guarantee.