3-wheeled mobile manipulator (18-DoF arm) - onboard computation architecture

Scope: a practical, vendor-neutral onboard compute + control architecture for a 3-wheeled base with a single 18-DoF manipulator arm. Sensor suite similar to legged/humanoid stacks (RGB-D + LiDAR + IMU), but with reduced actuator and controller counts. Target all-up mass: 30 lb (13.6 kg).

Table of contents

1) Workloads and timing (what drives the architecture)
2) Recommended layered compute/control architecture
3) Compute node sizing (what is "enough" for a 30 lb robot)
4) Actuators and control buses (reduced counts, but still non-trivial)
5) Sensor suite (similar types, fewer devices)
6) Software stack (ROS 2-centric, typical)
7) Open-source software and open-weights model options
8) Power, wiring, and safety (keep it boring and robust)
9) Rough weight + power budget (30 lb target)
10) References (starting points)

Executive summary

Usually 1 main computer is enough (unlike humanoids): runs ROS 2, perception, mapping, planning, MoveIt 2, UI/teleop, logging.
Still use a low-level controller for deterministic motor control + safety interlocks (base traction, E-stop chain, power supervision).
Arm DoF is the complexity driver: 18 joints typically imply a bus of smart servos (RS-485/CAN) or a distributed drive network.
Keep the control boundaries clean: high-level compute produces motion targets; embedded controllers close fast loops and implement fail-safe behavior.

1) Workloads and timing (what drives the architecture)

Base motion control: odometry + velocity control loop typically 50-400 Hz; motor current loops are inside drives.
Arm motion control: joint servo loop often 100-500 Hz (depends on actuator and bus). Trajectory generation and collision checking can be slower (10-100 Hz).
Perception: RGB-D + optional additional cameras (5-30 Hz), LiDAR (5-20 Hz), IMU (100-1000 Hz).
Planning: Nav2 (navigation), MoveIt 2 (manipulation), task logic (behavior trees/state machines), often bursty CPU usage.

2) Recommended layered compute/control architecture

                     +-----------------------------------+
                     | High-level compute ("Robot PC")   |
Sensors -> drivers ->| - ROS 2 graph (perception/nav/man) |--> Wi-Fi/Ethernet
(RGB-D/LiDAR/IMU)    | - SLAM, Nav2, MoveIt 2             |    (teleop/cloud)
                     | - UI, logging, orchestration       |
                     +------------------+----------------+
                                        |
                                        | command + state (non-hard-RT)
                                        v
                     +-----------------------------------+
                     | Low-level control + safety MCU     |
                     | - base motor control (50-400 Hz)   |
                     | - watchdogs, E-stop, power OK      |
                     | - timestamps/filters for sensors   |
                     +------------------+----------------+
                                        |
                                        | motor/servo buses
                 +----------------------+------------------------+
                 |                                               |
                 v                                               v
      +---------------------+                         +---------------------+
      | Base drive modules  |                         | Arm joint modules   |
      | (2-3 motors + enc)  |                         | (18 smart servos or |
      | - drive internal    |                         |  drives)            |
      +---------------------+                         +---------------------+

Note: if the arm uses smart servos (DYNAMIXEL-class) you may skip the separate low-level arm controller - the main computer can talk directly to the servo bus - but you still want an independent safety/power chain for a real robot.

3) Compute node sizing (what is "enough" for a 30 lb robot)

3.1 Main computer (recommended: 1 unit)

Option A (common): NVIDIA Jetson Orin NX/Nano class for onboard vision/inference + ROS 2.
Option B: small x86_64 PC (NUC/industrial mini PC) if your stack is CPU-heavy (SLAM + planning + logging) and you do not need heavy GPU inference.
Storage: NVMe SSD (logging + datasets) - plan for sustained writes.
Networking: 1GbE internal for sensors (LiDAR, cameras), Wi-Fi for teleop.

3.2 Low-level controller (recommended: 1 unit)

MCU class: STM32 / similar (or a small embedded Linux SBC if needed).
Roles:
- base motor control loop + encoder capture
- watchdog (if command stream stops - brake/disable outputs)
- hardware safety IO (E-stop, bumpers, power-good)
- optional sensor timestamping/fusion for odom
Integration: micro-ROS is a common ROS 2 pattern for MCU integration, but plain serial/CAN protocols are also fine.

4) Actuators and control buses (reduced counts, but still non-trivial)

4.1 Actuator count (typical)

Subsystem	Qty	Notes
Arm joints	18	18 DoF (including wrist/hand). These are the primary servo nodes.
Base drive motors	2-3	Common: 2 driven wheels + 1 passive caster (2 motors). If truly 3-wheel drive (omni/kiwi), then 3 motors.
Optional gripper/hand extras	0-? (already included)	If the 18 DoF includes the hand, nothing extra; otherwise add a small actuator budget.

4.2 Common bus options for an 18-DoF arm

Smart servo daisy-chain (RS-485 / TTL / CAN depending on vendor): simplest wiring, moderate update rates, internal motor control loops.
CAN/CAN-FD: robust and common in mobile robotics; good for moderate-rate joint state and commands.
EtherCAT: best if you need very tight synchronization, high update rates, and/or mixed drive vendors; more complex but very capable.

5) Sensor suite (similar types, fewer devices)

For a wheeled mobile manipulator, you typically keep the same sensor classes as larger robots, but use fewer instances:

Sensor	Qty (typical)	Purpose	Notes
RGB-D camera (front)	1	obstacle detection, manipulation perception, mapping support	Mount high enough for near-ground occlusions.
2D LiDAR (or 3D LiDAR)	1	navigation + mapping	2D is often sufficient indoors; 3D helps with clutter and manipulation scenes.
IMU	1	state estimation / dead-reckoning support	Mount rigidly on the base; avoid vibration.
Wheel encoders	2-3	odometry	Usually integrated in motor/drive.
Arm joint position sensors	18	manipulator state	Usually integrated in each smart servo/drive.
Force/torque sensing	0-1	compliance, contact detection, grasp robustness	Optional but very valuable for real manipulation.
Bump sensors / contact switches	2-6	safety + docking	Simple, cheap safety improvement.

6) Software stack (ROS 2-centric, typical)

ROS 2 as the integration framework.
Nav2 for base navigation (mapping/localization + planners + recovery behaviors).
MoveIt 2 for arm planning and execution (plus a driver bridge to your servos/drives).
ros2_control for a standard hardware abstraction layer (especially useful if you swap arms/drives).
SLAM: depends on sensors (2D LiDAR SLAM, visual-inertial, or RGB-D SLAM).

7) Open-source software and open-weights model options

These are commonly used building blocks for wheeled mobile manipulators. Verify realtime/safety needs and controller limits before running on hardware.

Software components (3+ options per major component)

Component	Open-source options
Robot middleware / messaging	ROS 2 (rclcpp/rclpy + DDS) YARP LCM
Base navigation stack (planning + recovery)	Nav2 (behavior tree navigator) TEB local planner (ROS ecosystem; where supported) SMAC planners (Nav2 family: Hybrid-A*, etc.)
SLAM / mapping / localization	slam_toolbox (2D SLAM) Cartographer (2D/3D) RTAB-Map (visual/RGB-D SLAM)
Base control (velocity -> wheels/odometry)	ros2_control diff_drive_controller ros2_control mecanum_drive_controller / omni-style controllers (if applicable) Custom ros2_control controller plugin (common for 3-wheel kinematics)
Arm control + trajectory execution	ros2_control JointTrajectoryController MoveIt Servo (jogging/servoing) Dynamixel SDK + ROS 2 drivers (if using smart servos)
Manipulation motion planning	MoveIt 2 Tesseract Drake (IK + trajectory optimization)
Trajectory generation / time-parameterization	Ruckig (online trajectory generation) TOPPRA (time-optimal path parameterization) MoveIt time-parameterization modules
3D perception primitives (point clouds, voxel maps)	PCL (Point Cloud Library) Open3D OctoMap
Motor control firmware (common in small robots)	VESC firmware (BLDC controllers) ODrive firmware moteus (mjbots) firmware
Power management (battery/BMS)	foxBMS 2 Libre Solar BMS DIYBMS
Logging + visualization + debugging	rosbag2 (MCAP/SQLite) RViz2 + rqt PlotJuggler
Simulation	Gazebo MuJoCo Webots PyBullet

Open-weights models (examples)

Use	Open-weights options
Object detection	YOLOv5 torchvision Faster R-CNN / Mask R-CNN weights DETR weights
Text-prompted / open-vocabulary detection	GroundingDINO OWL-ViT CLIP (as a building block for retrieval/classification)
Segmentation	SAM DeepLabv3 Mask R-CNN
Depth / pose / scene understanding	MiDaS / DPT (depth) Depth Anything (depth) MMPose models (human pose, where useful)
Speech-to-text	Whisper Vosk/Kaldi models Mozilla TTS/Piper style pipelines (STT/TTS stack varies)
Language / VLM for task planning / tool use (note: licenses vary)	Qwen2.5 / Qwen2-VL LLaVA Mistral

8) Power, wiring, and safety (keep it boring and robust)

8.1 Suggested power architecture

Single main battery bus sized for drive + arm peak current.
Dedicated DC-DC rails for compute and sensors (12 V / 5 V) to isolate noise from motors/servos.
E-stop chain that can remove power or assert STO/disable lines to drives.

8.2 Suggested safety behaviors

Watchdog: if velocity/trajectory commands stop - base stops; arm goes to hold/relax mode depending on risk.
Soft limits: joint position and velocity limits enforced in firmware and in the ROS layer.
Current/thermal limiting: especially on arm joints (small robots can still hurt people).

9) Rough weight + power budget (30 lb target)

Order-of-magnitude placeholders to sanity-check feasibility early. Replace with your actual parts.

9.1 Weight budget (target: 30 lb / 13.6 kg)

Subsystem	Target mass	Notes
Base chassis + wheels + drive train	10-12 lb (4.5-5.5 kg)	Frame, wheels/caster, gearboxes, mounting plates.
Arm structure + cabling	4-6 lb (1.8-2.7 kg)	Links, brackets, harnessing.
Arm actuators (18)	6-10 lb (2.7-4.5 kg)	Depends heavily on servo class.
Battery + BMS + enclosure	3-6 lb (1.4-2.7 kg)	Capacity vs runtime trade-off.
Compute + networking	1.5-3 lb (0.7-1.4 kg)	Jetson/x86 + SSD + cooling.
Sensors	1-2.5 lb (0.5-1.1 kg)	RGB-D + LiDAR + IMU + mounts.
Power distribution + wiring + safety	1-2.5 lb (0.5-1.1 kg)	DC-DCs, fuses, E-stop, connectors.
Margin	2-4 lb (0.9-1.8 kg)	Fasteners, covers, rework allowance.

9.2 Power budget (very rough)

Subsystem	Typical (W)	Peak (W)	Notes
Main compute	15-60	80-120	Depends on Jetson power mode / x86 load.
Sensors	10-30	40	LiDAR + RGB-D + networking.
Base drive	30-150	300-600	Floor, payload, acceleration.
Arm servos (18)	30-200	400-1000	Biggest spikes during fast motion or stalls.

Reality check: even a 30 lb robot can hit large electrical peaks. Size wiring/fuses/contactors for worst-case, not average.

10) References (starting points)

Related document: Humanoid robotics - typical onboard computation architecture
ROS 2 design documentation: https://design.ros2.org/
Nav2 documentation: https://navigation.ros.org/
MoveIt 2 documentation: https://moveit.picknik.ai/
micro-ROS overview (ROS 2 to MCUs): https://micro.ros.org/
Linux SocketCAN docs: https://docs.kernel.org/networking/can.html
EtherCAT Technology Group - overview: https://www.ethercat.org/en/technology.html
TurtleBot3 overview (reference mobile robot architecture patterns): https://emanual.robotis.com/docs/en/platform/turtlebot3/overview/
Husarion ROSbot (open-source mobile base patterns): https://husarion.com/

File generated for: /home/marc/documents/Robot-Project/