|
| 1 | +# Raspberry Pi 4/5 4GB Runtime Plan |
| 2 | + |
| 3 | +This document sketches the first runtime path for running OOMWOO onboard on a |
| 4 | +Raspberry Pi 4/5 or CM4/CM5-class module with 4 GB RAM, then measuring how far |
| 5 | +the stack can be reduced toward a 2 GB target. |
| 6 | + |
| 7 | +The desktop Docker image remains useful for development and simulation. This |
| 8 | +runtime profile is for the robot computer: ROS2, SLAM, Nav2, LiDAR, high-level |
| 9 | +behavior, and a serial link to an MCU that owns motors, sensors, battery/charging |
| 10 | +supervision, watchdogs, and safety reactions. |
| 11 | + |
| 12 | +## Goals |
| 13 | + |
| 14 | +- Keep SLAM and navigation onboard for the consumer vacuum profile. |
| 15 | +- Start with a Pi 4/5 or CM4/CM5 4 GB runtime baseline. |
| 16 | +- Avoid Gazebo, desktop GUI tools, and development-only packages on the robot. |
| 17 | +- Add a simulated CPU-MCU serial interface until the real I/O board is ready. |
| 18 | +- Measure RSS/PSS/CPU before attempting 2 GB optimization. |
| 19 | +- Try ROS2 composition and launch/process layout before adding new language |
| 20 | + dependencies. |
| 21 | +- Keep Rust/rclrs as an optional later experiment for selected memory-heavy or |
| 22 | + latency-sensitive nodes. |
| 23 | + |
| 24 | +## Non-Goals For This First Scaffold |
| 25 | + |
| 26 | +- It does not replace the desktop Docker development image. |
| 27 | +- It does not provide a final production image. |
| 28 | +- It does not choose the final MCU firmware protocol. |
| 29 | +- It does not attempt Kilted, Lyrical, or Rolling yet. |
| 30 | +- It does not provide a costed hardware BOM; that belongs with the PCB design. |
| 31 | + |
| 32 | +## Runtime Package Direction |
| 33 | + |
| 34 | +Install ROS2 Jazzy from Debian packages, but prefer `ros-jazzy-ros-base` plus the |
| 35 | +robot packages that are actually needed: |
| 36 | + |
| 37 | +- Nav2 and Nav2 bringup |
| 38 | +- slam_toolbox |
| 39 | +- robot_state_publisher and xacro |
| 40 | +- robot_localization |
| 41 | +- tf2 tools used by launch/runtime |
| 42 | +- ros2_control and controllers when hardware interfaces need them |
| 43 | +- Fast DDS RMW, matching the current development image direction |
| 44 | +- Python serial tooling for the simulated MCU link |
| 45 | + |
| 46 | +Avoid in the first runtime profile: |
| 47 | + |
| 48 | +- `ros-jazzy-desktop` |
| 49 | +- Gazebo / ros_gz packages |
| 50 | +- GUI joint-state tools |
| 51 | +- simulation worlds |
| 52 | +- unrelated robot model packages |
| 53 | +- telemetry or web UI pieces until a runtime measurement requires them |
| 54 | + |
| 55 | +## Simulated CPU-MCU Serial Link |
| 56 | + |
| 57 | +Until the OOMWOO I/O board firmware exists, run: |
| 58 | + |
| 59 | +```bash |
| 60 | +python3 ubuntu/tools/oomwoo_sim_mcu_serial.py --link /tmp/oomwoo-mcu-serial |
| 61 | +``` |
| 62 | + |
| 63 | +The tool creates a pseudo-terminal symlink such as: |
| 64 | + |
| 65 | +```text |
| 66 | +/tmp/oomwoo-mcu-serial |
| 67 | +``` |
| 68 | + |
| 69 | +ROS2 bridge code can open that path as if it were the MCU serial device. The |
| 70 | +simulator emits newline-delimited JSON heartbeat/sensor frames and accepts simple |
| 71 | +command lines, replying with acknowledgements. |
| 72 | + |
| 73 | +This keeps the CPU-MCU contract testable while the real STM32G070 firmware and |
| 74 | +custom serial protocol are still being designed. |
| 75 | + |
| 76 | +## First Install Script |
| 77 | + |
| 78 | +The first scaffold is: |
| 79 | + |
| 80 | +```bash |
| 81 | +ubuntu/install_oomwoo_runtime_jazzy.sh |
| 82 | +``` |
| 83 | + |
| 84 | +It is intentionally conservative: |
| 85 | + |
| 86 | +- installs ROS2 Jazzy runtime packages |
| 87 | +- creates `~/oomwoo_runtime_ws` |
| 88 | +- clones a minimal set of OOMWOO/Kaia.ai runtime repositories |
| 89 | +- optionally builds the workspace |
| 90 | +- installs the simulated MCU serial tool to `~/.local/bin` |
| 91 | +- writes a runtime environment snippet to `~/.bashrc` |
| 92 | + |
| 93 | +Run: |
| 94 | + |
| 95 | +```bash |
| 96 | +bash ubuntu/install_oomwoo_runtime_jazzy.sh |
| 97 | +``` |
| 98 | + |
| 99 | +Use `--skip-build` when iterating on the script or testing package selection. |
| 100 | + |
| 101 | +## Measurement Plan |
| 102 | + |
| 103 | +After the runtime install works on a 4 GB board: |
| 104 | + |
| 105 | +1. Boot cleanly and record baseline memory after login. |
| 106 | +2. Source ROS2 and the runtime workspace. |
| 107 | +3. Start the simulated MCU serial tool. |
| 108 | +4. Launch the minimal OOMWOO runtime graph. |
| 109 | +5. Record RSS/PSS/CPU for idle. |
| 110 | +6. Run SLAM with 5 Hz LiDAR input and no scan dropping. |
| 111 | +7. Run navigation on a known map. |
| 112 | +8. Repeat after ROS2 composition/process-layout changes. |
| 113 | +9. Only then decide whether a C++ or Rust/rclrs port is justified. |
| 114 | + |
| 115 | +The related benchmark scaffold lives in: |
| 116 | + |
| 117 | +```text |
| 118 | +makerspet/oomwoo/contributions/compute-benchmark |
| 119 | +``` |
| 120 | + |
| 121 | +## Path Toward 2 GB |
| 122 | + |
| 123 | +The 2 GB target should be treated as an optimization target, not an assumption. |
| 124 | + |
| 125 | +Suggested order: |
| 126 | + |
| 127 | +1. Remove development/simulation packages from the runtime image. |
| 128 | +2. Measure the Python/C++ baseline. |
| 129 | +3. Try ROS2 composition where supported. |
| 130 | +4. Reduce launch/process count. |
| 131 | +5. Remove unused web/telemetry/UI pieces from the onboard profile. |
| 132 | +6. Consider C++ ports for memory-heavy custom nodes. |
| 133 | +7. Consider Rust/rclrs ports only after the Jazzy setup is reproducible. |
| 134 | + |
| 135 | +## Future Branches |
| 136 | + |
| 137 | +The maintainer mentioned interest in Kilted, Lyrical, and Rolling branches. A |
| 138 | +good later contribution is to parameterize this script or create branch-specific |
| 139 | +variants once the Jazzy runtime profile is validated. |
0 commit comments