I’d like to work on io-mcu-firmware

[JPHutchins]

So excited to find this! I've been so frustrated with my robot vacs and I wanted to make my own, but it is definitely not a one person job 🤣

I'd love to work on MCU, control systems, serial protocols, and peripheral driver stuff. I'm hoping that the chosen software stack -- Arduino, freeRTOS -- can be revisited, so that we arrive at the best long term solution as early as possible.

LMK how to proceed, thanks!
JPH

[makers-pet]

Hi JP, glad to hear you'd like to make your own vacuum!
I have 6 robot vacuums in my family, each of them with their own frustrating hangups - so, I'd like to build one too that I can hack/fix!

How to proceed - here are some comments off the top of my head.

I'd love to hear your recommendations.

• MCU firmware contributions live under the mcu-io-firmware RFC (request for contributions). You are most welcome to create PRs, for example contributions/mcu-io-firmware/JPHutchins/<README.md, files, etc.> I'd suggest self-hosting your development under github.com/JPHutchins and creating PRs containing a README.md with a link to your self-hosted repo, description/instructions, a brief status (what works, what's TODO)
• https://github.com/makerspet/oomwoo-io-firmware/ is the firmware home placeholder. The intention is that it would host "a version" of firmware - not required to be used - but that builds, works, host reference hardware include files, a place to start with tutorials.
• As far as I understand, you come from Zephyr and SMP MCU firmware professional world. FYI, my Claude is super excited to see your post, says you are celebrity! I'm not a MCU professional, but I did design VLSI ICs with embedded MCU.

"Arduino, freeRTOS -- can be revisited" - in short, yes. That said, there are a few considerations. Here is how (I hope) this can work.

• There is no "requirement" to use Arduino. If you'd like to use Zephyr, please do by all means.
• We don't have to choose "the one" firmware framework. All frameworks should be welcome. Over time makers/users will gravitate to the best framework (stable, up-to-date, best features, supported and so on). So, there should be no tension about which framework to choose.
• To support multiple firmware framework alternatives, I'd like to make the code modular - publish hardware include files, algorithm implementations (say, sensor initialization, configuration, data acquisition, motor control PID - including tested, recommended settings). Each firmware framework imports those include files, builds and runs. As far as MCU-CPU communication, the Linux CPU would have a matching MCU communication module that subscribes + publishes to a standardized TODO API ROS2 topics.
• why I'd like to support Arduino - Arduino is hackable, comes with 30M active user community and nearly infinite learning resources. Having firmware run Zephyr only would make the robot hackable to you and a small number of firmware professionals.
• FYI, here is reverse engineering of MCU-CPU serial protocol in a consumer vacuum cleaner robot https://github.com/codetiger/VacuumRobot with the CPU-side component reimplemented https://github.com/codetiger/VacuumTiger/tree/main/sangam-io. That vacuum does run LiDAR, but the vacuum's hardware platform is old, maybe 10 years old.
• this repo has the I/O board schematic https://github.com/makerspet/oomwoo-io-board. The I/O board has sensors, motor drivers, MCU, battery charging, power tree, connectors accepting a Raspberry Pi CM4/CM5 compute module (both CM4 and CM5 supported), camera connectors and so on.
• firmware specs: MCU firmware overarching concern is safety. Anything happens - the robot must stop or back off or shut down all motors or battery charging (action depends on particular case). For example, a brush gets caught in something - stop all motors. The battery gets hot during charging - stop charging. The front bumper is hit - stop. Cliff sensor triggered - stop (maybe also back off a bit).
  • max reaction delays must be guaranteed
  • MCU acts as CPU's watchdog; if CPU crashes - MCU resets it
  • assume the product (with its firmware) has to pass CE safety certification

Ilia

[JPHutchins]

Thanks for that background!

The schematics still show G070 https://github.com/makerspet/oomwoo-io-board and I saw G473 discussed. I wonder if G474 can be considered since it has a Nucleo which makes early development easier: https://estore.st.com/en/nucleo-g474re-cpn.html

Anyway, I'd like the build system to support multiple MCU and peripheral part combinations, so perhaps it's OK to prototype on 474 as long as the 473 migration is derisked early.

I'd like to encourage routing SWD (missing right now, I think, meaning we rely on ST's bootloader ROM and no debugging is possible) and UART to a 9-pin cortex-M connector. A realtime system like this will benefit from host-side debugging without MCU halts, and it's nice to have the option for MCU halts as well.

Yes, I have experience with Zephyr, FreeRTOS, FOC, STM32 and related, but for this I am interested in using embassy. It will provide the concurrent DMA-backed ADCs with tiny CPU and RAM overhead.

Agreed with the sentiment about Arduino, but everything I do is in a fully reproducible build system, backed by GitHub actions, so I would expect contributors to have a very short time going from clone -> build -> flash. Faster than Arduino.

[makers-pet]

Once the PCB engineer sends me the updated schematic with STM32G473VCT6 I will check it in.

"UART to a 9-pin cortex-M connector" - good catch, I will have this added.

"routing SWD" - good catch, I will have that added as well. Thank you.

"G474 can be considered" - I'd love to, if it were available on JLCPCB (or elsewhere consigned) in stock, under $3, 80+ GPIO including 20+ analog, no BGA. We can still change schematic in the next few days.

• So far STM32G473VCT6 seems far cheaper and better than STM32 alternatives.
• my personal preference is Nations N32G455VEL7 used in Roborock G10S Pro. It has all the GPIO I need, several times more flash, SRAM vs STM32G473VCT6, all GPIOs I need, a solid toolchain - and costs half of STM32G473VCT6. But my Claude says "go with STM32" because of community and English documentation.
• FYI, here are MCUs used commonly in consumer vacuums
• hopefully we can use NUCLEO-G474RE and run code on G473 without changes. I doubt the 474 high-res timer will be needed. The robots I've built never needed such high precision.

[makers-pet]

Update - I've checked, SWD is present, J21 sheet MCU-STM32, including reset. UART - J23 has spares.

[JPHutchins]

Can you link me to the schematics? I only found this one so far and I see G0: https://github.com/makerspet/oomwoo-io-board/blob/main/kicad/PDF/oomwoo-kicad.pdf

[makers-pet]

That link is correct - and the MCU has been updated to STM32G473VCT6.

[JPHutchins]

Hi, I am still seeing G070 on the output - perhaps just the PDF needs to be updated?

[makers-pet]

My mistake. I've uploaded the latest schematic version, with STM32G473VCT6.

[Pyrobrick]

AFAIK, there’s an Arduino Core/compat layer for Zephyr that lets Arduino-style sketches run on top of Zephyr. It’s a pragmatic middle ground: you get Zephyr’s cross-MCU drivers and RTOS features while keeping Arduino hackability, though a few low-level/register-touching libraries may need tweaks. You also gain Zephyr’s tooling, workflow and automation benefits, which should help long-term maintainability as Zephyr becomes increasingly dominant in the MCU space.