Evaluate Rust and MCU split to reduce OOMWOO compute requirements
Author: xbattlaxCreated Jul 6, 2026Updated Sep 8, 2026
LabelsDiscussion
Issue draft: Evaluate Rust and MCU split to reduce OOMWOO compute requirements
Context
OOMWOO currently targets Raspberry Pi 5 for the MVP compute module, while the architecture still leaves open the question of "onboard ROS2 vs micro-ROS on an MCU for the base controller".
Before the software stack grows, we should decide whether Rust can help reduce CPU/RAM needs, and whether a split architecture could eventually let OOMWOO run on cheaper or lower-power compute than Raspberry Pi 5.
This issue is not a proposal to rewrite OOMWOO in Rust. It is a proposal to benchmark where language/runtime choices and MCU offload actually change the hardware tier.
Short hypothesis
Rust may help for small always-on custom nodes by removing Python runtime overhead and improving memory safety, but it probably will not by itself move the full MVP from Raspberry Pi 5 to a much smaller board if SLAM/Nav2 remain the dominant CPU/RAM users.
The cost goal should be explicit: Rust is only a BOM reducer if it lets OOMWOO move to a cheaper RAM/compute tier, avoid high-RAM Raspberry Pi 5 variants, or remove enough Linux-side responsibility that a smaller SBC plus MCU becomes viable. Otherwise it is mainly an engineering-quality choice, not a hardware-cost reduction.
For a real compute reduction, the more promising direction is likely:
- SBC: ROS2, Nav2, SLAM, LiDAR processing, maps, high-level behavior
- MCU: motors, encoders, bumper/cliff/wheel-drop, e-stop, low-level safety, watchdogs, deterministic base control
Rust can still be useful in this architecture for selected host-side nodes, and possibly for MCU firmware if the project chooses an embedded Rust stack. However, micro-ROS itself is C/rclc-first today.
Why this matters
If OOMWOO can run reliably on lower-cost/lower-power compute, the project gets:
- lower BOM cost
- lower battery draw and heat
- more headroom for future app-layer features
- smaller mechanical/thermal requirements
- better real-time behavior for safety and base-control loops
But the wrong optimization could increase contributor friction without reducing the actual hardware requirement.
Cost reduction angle
The practical question is not "is Rust faster than Python?" but "does the architecture let us buy, power, cool, and package cheaper compute per robot?"
Snapshot from official product pages, plus one EU reseller example, checked or provided on 2026-07-06:
| Hardware path | Cost signal | OOMWOO implication |
|---|---|---|
| High-RAM Raspberry Pi 5 | Raspberry Pi lists the 16 GB Pi 5 at $305; an EU reseller example from Elektor France lists the 16 GB board at EUR 144.95 incl. VAT, but out of stock. Pi 5 also recommends 5V/5A USB-C power and performs best with active cooling. | Treat high-RAM Pi 5 as a cost ceiling, not the default target. Avoiding high-RAM Pi 5 SKUs is a concrete savings goal, and price/stock must be recorded at benchmark time. |
| Lower-RAM Pi 5 / Raspberry Pi 4 | Pi 4 starts at $35 and offers 1/2/4/8 GB RAM variants with a 15W USB-C supply recommendation. | If measurements show OOMWOO can fit in 2-4 GB with headroom, the cost impact is much stronger than a small per-node optimization. |
| Compute Module 4 | CM4 starts as low as $41.25 and has 1/2/4/8 GB RAM options, but requires a carrier-board design. | Potentially attractive for a productized robot, but prototype savings can disappear once carrier board, connectors, and integration time are counted. |
| Raspberry Pi Zero 2 W | $15 board, 1 GHz quad-core Cortex-A53, 512 MB RAM. | Too small for full Nav2/SLAM unless the product scope changes, but useful as a bridge/lightweight side computer benchmark. |
| MCU + lower SBC | ESP32-S3-class MCU: dual-core 240 MHz, 512 KB SRAM, Wi-Fi/BLE, many GPIO/peripherals. | Strong candidate for motors, encoders, bumpers, cliff sensors, e-stop, watchdogs, and deterministic base control; not a replacement for onboard Nav2/SLAM. |
Cost should be measured as total compute BOM, not board price alone:
- SBC/module price at measurement time
- regional price and stock status, because reseller availability can be the difference between theoretical and real robot cost
- power supply/regulation requirement
- cooling requirement
- storage requirement
- carrier board or HAT requirement
- MCU/module, level shifting, cabling, and connector cost
- integration and maintenance cost from adding firmware, Rust, or micro-ROS
Useful cost-reduction hypotheses to test:
- Rust-only optimization: saves memory on always-on custom ROS2 nodes; may matter only if several Python nodes are replaced and the whole stack fits a lower RAM tier.
- MCU offload: likely stronger BOM impact because it can remove real-time control and safety I/O from Linux, simplify SBC responsibilities, and make a lower compute tier more realistic.
- Mapping/navigation split: if MVP allows first-map generation on a dev machine and only navigation on the robot, onboard compute may drop significantly. This changes the product promise and should be explicit.
- High-RAM avoidance: the clearest cost target is not "Rust everywhere"; it is "avoid needing 8-16 GB Raspberry Pi 5-class compute for the robot."
Cost success criteria:
- Worth it: measured OOMWOO workloads move from high-RAM Pi 5 to lower-RAM Pi 5, Pi 4/CM4, or lower-SBC-plus-MCU with enough RAM/CPU/thermal headroom.
- Worth it: MCU offload reduces Linux timing/safety risk and allows a cheaper SBC without hurting navigation reliability.
- Not worth it: Rust adds tooling/onboarding complexity but SLAM/Nav2 still force the same high-end SBC tier.
- Not worth it: CM4/MCU integration saves board cost but increases carrier-board or firmware maintenance cost enough to erase the robot-level savings.
Compute-sensitive workloads
| Workload | Likely compute pressure | Language/runtime likely to matter? | Notes |
|---|---|---|---|
| Gazebo simulation | Very high, dev-only | No | Not part of onboard robot compute. |
| SLAM / mapping | High | Low/medium | Mostly determined by algorithm, map size, LiDAR rate, and existing SLAM implementation. |
| Nav2 planning/control | Medium/high | Low/medium | Mostly C++ already; tuning matters more than rewriting custom glue. |
| LiDAR driver/filtering | Medium | Medium | Rust/C++ may help if custom processing grows. |
| Base motor control | Real-time sensitive | High if on SBC; better moved to MCU | MCU offload likely gives more benefit than host language choice. |
| Recovery/safety state machine | Low CPU, always-on | Medium/high | Good Rust candidate: small, safety-sensitive, latency/jitter-sensitive. |
| Job orchestration/status | Low CPU, always-on | Medium | Rust may reduce resident memory vs Python. |
| Home Assistant/app bridge | Low/medium | Medium | Depends on protocol stack; Rust could be efficient, but ecosystem matters. |
Hardware tiers to evaluate
| Tier | Example | Fit for full MVP? | What must be true |
|---|---|---|---|
| Current target | Raspberry Pi 5 | Yes, expected | Enough for ROS2 + Nav2 + SLAM with headroom. |
| Lower SBC | Raspberry Pi 4 / CM4 | Plausible | Need measured SLAM/Nav2 performance and memory under OOMWOO maps. |
| Very small Linux SBC | Raspberry Pi Zero 2 W | Unlikely for full Nav2/SLAM | Could run simple bridge/control, but 512 MB RAM is likely tight for full ROS2 navigation. |
| MCU + SBC split | ESP32-S3 / STM32 + Pi class SBC | Strong candidate | MCU handles real-time I/O/safety; SBC handles planning/mapping. |
| MCU-only | ESP32-S3 / STM32-class | Not for MVP Nav2/SLAM | Only viable for non-ROS/simple vacuum behavior or as low-level controller. |
Options to compare
| Option | What changes | Expected benefit | Main risk |
|---|---|---|---|
| Keep Python/C++ ROS2 nodes | Use rclpy for glue, rclcpp/Nav2 for core robotics | Fastest development, strongest ROS2 contributor familiarity | Python always-on nodes may cost RAM and latency jitter. |
| Rust for selected ROS2 nodes | Reimplement small custom nodes using rclrs |
Lower memory than Python, no Python runtime, stronger type/memory safety | rclrs is still rapidly evolving and has no stability guarantees; Jazzy setup is not yet as simple as rclpy/rclcpp. |
| C++ for selected performance nodes | Use rclcpp for custom performance-sensitive nodes | Mature ROS2 support, best Nav2 integration | More memory-safety risk than Rust; slower iteration than Python. |
| micro-ROS MCU base controller | Move low-level motors/sensors/safety to MCU | Better timing, less SBC responsibility, clearer safety boundary | micro-ROS is C/rclc-first; adds firmware and transport complexity. |
| Rust MCU firmware + ROS bridge | Use embedded Rust for MCU, bridge to ROS2 on SBC | Memory safety on MCU, explicit protocol | Not micro-ROS-native unless additional bridge work is done. |
| rmw_zenoh experiment | Keep languages, test Zenoh RMW | May help discovery/network behavior, especially multi-host | Does not directly reduce SLAM/Nav2 CPU. |
Preliminary measurement
As a quick local reference, the current Python oomwoo_recovery_safety node from
PR #17 was started in the OOMWOO Jazzy Docker container and inspected after
roughly 8 seconds idle:
RSS: ~53.7 MB
VSZ: ~616.9 MB
Process: python3This is only an indicative measurement. It includes Python, rclpy, ROS2 runtime overhead, and container environment effects. It should be repeated with:
- same machine
- same ROS domain/RMW
- warm and cold starts
- event burst load
- multiple samples
- Rust/C++ equivalents
Still, it gives a useful baseline: if several always-on Python nodes each cost tens of MB RSS, replacing only selected nodes may matter on 1 GB / 2 GB systems, even if it does not solve SLAM/Nav2 compute by itself.
Proposed benchmark plan
Phase 1: Baseline inventory
Run the current OOMWOO sim stack and record:
- process list
- RSS/PSS where available
- CPU while idle
- CPU during mapping
- CPU during navigation
- CPU during recovery event bursts
- startup time
- message latency from bumper event to
/cmd_vel
Targets:
- Raspberry Pi 5, if available
- Raspberry Pi 4 / CM4, if available
- x86/ARM dev machine as reference only
Phase 2: Language comparison for a small always-on node
Use oomwoo_recovery_safety as the benchmark because it is small, bounded, and
safety-relevant.
Implement/compare:
- Python/rclpy baseline
- Rust/rclrs equivalent
- C++/rclcpp equivalent, optional but useful as mature ROS2 baseline
Metrics:
- RSS/PSS
- CPU idle
- CPU during 100/1000 trigger events
- p50/p95/p99 event-to-command latency
- p50/p95/p99 status publication latency
- cold-start time
- binary/package size
- build complexity
- contributor setup complexity
Phase 3: MCU split experiment
Model low-level base controller responsibilities:
- wheel velocity command
- encoder odometry publication
- bumper/cliff/wheel-drop/e-stop publication
- watchdog: stop motors if host commands go stale
- local safety: e-stop and cliff stop must not depend on Linux scheduling
Compare:
- SBC-only base controller
- micro-ROS MCU base controller
- custom MCU protocol + ROS2 bridge
Metrics:
- host CPU/RAM reduction
- command latency and jitter
- odometry rate stability
- behavior during host crash or ROS graph restart
- firmware complexity
- recovery from serial/transport loss
Decision criteria
Rust should be adopted for selected OOMWOO modules if it shows at least one of:
- materially lower RSS for always-on nodes compared with Python
- materially lower p95/p99 trigger latency or jitter
- simpler safety-critical state handling
- acceptable ROS2 Jazzy build reproducibility
- low contributor friction after templates/docs are added
Rust should not become the default if:
- Nav2/SLAM dominate CPU/RAM enough that custom-node language choice does not change the compute tier
rclrssetup makes onboarding significantly harder- a mature C++ node or micro-ROS/C firmware solves the same problem with less project risk
Recommended near-term decision
- Keep Python acceptable for prototypes and high-level glue.
- Keep C++/Nav2 as the default for mature navigation/performance-critical ROS2 integration.
- Start a Rust experiment only for one small, always-on, safety-adjacent node:
recovery-safety. - Treat MCU base-control split as the main path for reducing SBC requirements.
- Do not aim for MCU-only OOMWOO while Nav2/SLAM are in scope.
Concrete next action
Create a compute-benchmark contribution that contains:
- a script to launch one node and capture RSS/CPU/startup latency
- a Python baseline for
oomwoo_recovery_safety - a Rust/rclrs prototype with the same topic surface
- a small BOM sheet for each hardware tier, including board/module, power, cooling, storage, carrier/HAT, and MCU add-ons
- a short decision record after measurements
Open questions
- What is the minimum acceptable target: Pi 5 only, Pi 4/CM4, or Pi Zero-class?
- Should the MVP require onboard SLAM, or can first-map generation run with a stronger dev machine while the robot runs navigation later?
- What is the expected map size and LiDAR update rate for the MVP demo?
- Should low-level safety be allowed to depend on Linux/ROS2 at all?
- Would maintainers accept Rust dependencies in the OOMWOO dev image?
- Should firmware be micro-ROS C/rclc, embedded Rust, or a minimal custom serial protocol with a ROS2 bridge?
References
- OOMWOO architecture: Raspberry Pi 5 is the MVP compute target; onboard ROS2 vs micro-ROS MCU base control is still an open question.
- Raspberry Pi 5 official specs: Broadcom BCM2712 quad-core Arm Cortex-A76 at 2.4 GHz, LPDDR4X RAM variants up to 16 GB, 16 GB model listed at $305, 5V/5A USB-C power recommendation, and active-cooling recommendation under heavier use. https://www.raspberrypi.com/products/raspberry-pi-5/
- Elektor France Raspberry Pi 5 16 GB reseller example: contributor-provided snapshot on 2026-07-06 listed the board at EUR 144.95 incl. VAT and out of stock, illustrating why regional street price and availability should be recorded during benchmark/BOM work. https://www.elektor.fr/products/raspberry-pi-5-16-gb-ram?src=raspberrypi
- Raspberry Pi 4 official specs: starts at $35, RAM variants up to 8 GB, and 15W USB-C power recommendation. https://www.raspberrypi.com/products/raspberry-pi-4-model-b/
- Raspberry Pi Zero 2 W official specs: 1 GHz quad-core Arm Cortex-A53 and 512 MB SDRAM; official page describes it as a $15 computer. https://www.raspberrypi.com/products/raspberry-pi-zero-2-w/
- Raspberry Pi Compute Module 4 official specs: starts as low as $41.25, Broadcom BCM2711 quad-core Cortex-A72 at 1.5 GHz, 1/2/4/8 GB RAM options, and eMMC/Lite storage options. https://www.raspberrypi.com/products/compute-module-4/
- Espressif ESP32-S3 official specs: dual-core Xtensa LX7 MCU at 240 MHz, 512 KB internal SRAM, Wi-Fi/BLE, 45 GPIOs, and peripheral support. https://www.espressif.com/en/products/socs/esp32-s3
ros2-rust/rclrs: Rust ROS2 client library with publishers, subscriptions, services, actions, QoS, parameters, logging, graph queries, timers, and executors; README notes that the client library is still rapidly evolving and has no stability guarantees. https://github.com/ros2-rust/ros2_rust- micro-ROS: MCU-optimized rcl/rclc API in C; supports ROS concepts on MCUs, static memory pools, serial/UDP/Wi-Fi transports, and FreeRTOS/Zephyr/NuttX. https://micro.ros.org/docs/overview/features/
rmw_zenoh: ROS2 RMW implementation based on Zenoh; useful for communication/discovery experiments, not a direct SLAM/Nav2 compute reducer. https://github.com/ros2/rmw_zenoh
Source: makerspet/oomwoo