Starting work on mcu-io-firmware

[Creative-Dhanush]

Picking up mcu-io-firmware from the RFC list.

This module is the safety-critical layer — motor control + sensor input + real-time obstacle response — so getting it right matters before anything else can build on top of it.

Plan:

• FreeRTOS on ESP32 first (prototyping), will port to STM32G473/Nucleo-G474RE to match spec

• Three tasks: motor PWM control, sensor polling (HC-SR04), and a safety task that force-stops the motor on obstacle detection

• Basic serial command interface as a stand-in for the future CPU↔MCU link

  Will share a demo video + code once working. Open to feedback on the serial protocol/task design before I go too far.

[makers-pet]

Hi Dhanush,

noted - thank you!

Related work FYI

• https://github.com/makerspet/oomwoo-install/tree/jazzy/contributions/xbattlax
• I’d like to work on io-mcu-firmware #38

[Creative-Dhanush]

Hardware components arriving in 1-2 days, will have a working demo + code up this week

[makers-pet]

Awesome, noted!

FYI, https://github.com/kaiaai/firmware has well-tested robot MCU firmware including wheel PIDs. Please feel free to point your LLM at it.

Vacuum I/O board with MCU and GPIO assignments (draft, not final) is here https://github.com/makerspet/oomwoo-io-board/blob/main/kicad/PDF/oomwoo-kicad.pdf

[Creative-Dhanush]

Started working on the MCU simulation using OOMWOO's own sim tools, will proceed with the hardware implementation once the simulation is completed and its accuracy has been verified.

[makers-pet]

Thank you for the update!

[Creative-Dhanush]

is Python fine for this or do you want it closer to how the real firmware will be written?

[makers-pet]

I'd recommend as close to real firmware as possible.

Generally speaking, in the age of LLM, the most value code/contribution is code that's not just written, but code that works (i.e. reviewed, tested, debugged).

[Creative-Dhanush]

I’m starting by implementing the MCU-style bumper-triggered emergency stop logic, where bumper sensor events immediately override motion commands and stop the robot for safety.

With this feature:
Robot moving forward
↓
Hits a wall
↓
Bumper topic publishes "pressed"
↓
MCU safety node detects it
↓
/cmd_vel = 0
↓
Robot stops instantly

[makers-pet]

Ok 👍

[Creative-Dhanush]

not sure how long the CPU watchdog timeout should be before MCU resets it, any rough
number in mind?

[makers-pet]

~5 minites. Enough for CPU to boot.

[Creative-Dhanush]

Is there a plan to keep the simulated MCU interfaces identical to the real firmware interfaces, so the same logic can be reused later with minimal changes?

[makers-pet]

No plan yet.

[Creative-Dhanush]

Implemented and tested Bumper Stop + Auto Recovery for the OOMWOO MCU simulation (C++ / ROS2) ### MCU Safety + Recovery (ROS2)

Current OOMWOO simulation:

Bumper Hit
↓
Bumper topics publish
↓
(No MCU reaction)
↓
Robot keeps pushing / gets stuck

Implemented MCU Gateway:

Bumper Hit
↓
MCU Gateway
↓
STOP Motors
↓
Backup
↓
Scan (/scan)
↓
Find Open Direction
↓
Rotate
↓
Resume Navigation

This adds an MCU-style safety and recovery layer on top of the existing simulation. For a robot vacuum, this is important because bumper collisions are common in homes, and without recovery the robot can remain stuck against furniture.

BumperStop_AutoRecovery.mp4