Carrier board update

[BotshareAI]

Technical specification / Terms of Reference 

Project: OpenAMR modular motherboard for Mobile Dual-Arm Robot
Version: 1.1
Date: November 1, 2025
Author: Botshare Robotics Lab

1. Project overview

Design a modular motherboard platform for a mobile robot with dual robotic arms and integrated perception, suitable for DIY prototyping, education, and future upgrades.

The motherboard must:

• Handle power distribution and safety (Power Node)

• Manage real-time control of motors and sensors (MC Node)

• Support high-level computing and perception (Main Node)
  
  

Design should be modular, simple, and upgradeable (e.g., Main Node: Raspberry Pi and NVIDIA Jetson extendable; MC Node: Teensy4.0, Power node: Teensy4.0).

2. System architecture

Three logical nodes:

Node	Function	Key components	Interfaces
Power Node	Power distribution, safety, E-STOP	Teensy4.0, MCP2515 CAN controller, MCP2551 CAN transceiver, relays, fuses, DC-DC modules, inrush current limit, etc	CAN (to MC/Main), digital GPIO (relay control, buttons)
MC Node	Real-time motor/sensor control	Teensy 4.0, motor drivers, encoders, IMU	SPI (encoders), I²C (IMU), CAN (backbone), RS-485 optional
Main Node	High-level computation & perception	Raspberry Pi 5 (simple SLAM and navigation tasks), NVIDIA Jetson extension (CV, ML tasks), USB-connected perception modules	USB3 (cameras/peripherals), CAN (backbone), Ethernet (ROS2), GPIO/UART; future M.2/mini-PCIe upgrade footprint reserved

Communication and buses: CAN backbone for control nodes, USB for perception peripherals, SPI/I²C for sensors, RS-485 optional, Ethernet for networking.

3. Power node specifications

Platform: Teensy4.0 + MCP2515 + MCP2551 CAN transceiver

Functions:

• Relay control for motor rails, lift, and robotic arms

• Monitoring of voltage/current on all rails

• Dual physical E-STOP buttons to cut high-current rails

• Power-on/off sequencing

• Charging management
  
  

Power Rails:

• Digital electronics rail: 5V/3.3V (RPi, Teensy 4.0, etc)

• Digital electronics rail: 12V (NVIDIA, etc)

• Motor rail: 24V

• Lift rail: 24V

• Arm motors Rail: 24V

• Auxiliary rail: 12V (features, additional functions)
  
  

Modules and best practices:

• Use off-the-shelf relay breakout modules, fuse holders, DC-DC converters

• Keep Teensy 4.0 optically isolated from high-current lines
  SPI interface for MCP2515 CAN controller; CAN transceiver to bus

• Ensure proper termination (120 Ω resistors) on CAN bus

4. MC Node specifications (real-time control)

• Platform: Teensy 4.0

• Functions: Motor control, encoder/IMU reading, real-time safety logic

• Interfaces: SPI (encoders), I²C (IMU), CAN (backbone), RS-485 optional

• Best practices: Hardware watchdog, twisted-pair CAN, isolated grounds, modular headers for arms and sensors

5. Main node specifications (high-level computing and perception)

• Platform: Raspberry Pi 5 (USB-connected perception)

• Functions: Navigation, ROS2, perception, HMI

• Interfaces: USB3 (cameras/peripherals), CAN (control backbone), Ethernet (ROS2), GPIO/UART

• Best practices: Shielded cables, heatsink/fan provision for future GPU, easy replacement/upgrade

6. Communication topology

• CAN backbone: Power Node ↔ MC Node ↔ Main Node

• USB3: Cameras/perception modules connected to Main Node now

• SPI/I²C: Sensors on MC Node

• RS-485: Optional peripherals

• Ethernet: Main Node ROS2 networking

7. PCB and mechanical guidelines

• PCB layers: 2-layer, DIY-friendly

• Power traces: Wide copper pours for motor rails, logic traces separate

• Connectors: Screw terminals for power, headers for sensors and modules

• Module placement: Off-board heavy modules (DC-DC, relays) mounted to chassis; Teensy and MC Node boards on standoffs

• Upgrade provision: Reserved area/headers for future M.2/mini-PCIe on Main Node

8. Software and integration

• Power Node: Teensy 4.0 firmware (relay control, CAN messages)

• MC Node: Teensy firmware (motor/encoder/IMU control), CAN comms

• Main Node: Raspberry Pi ROS2 stack, USB perception modules, optional Jetson upgrade later

• Safety: Hardware E-STOP overrides all other nodes

9. Design principles

• DIY-accessible: Simple boards, two-layer PCB, off-the-shelf modules

• Modular & upgradeable: Teensy + MCP2515 now; upgrade to Teensy later; USB now, M.2/PCIe later

• Safe: Dual E-STOP, fuses, relays, isolated power rails

• Educational: Open hardware philosophy, clear documentation, easy assembly

• Future-proof: Upgrade paths for perception modules and MC Node controllers

Old carrier board project files for reference and ToR in Google docs format

[BotshareAI]

Community suggestions for OpenAMR Carrier Board (from LinkedIn discussion)

1. 96Boards Spirit

What it is:
An open hardware spec by Linaro defining board size, connectors, and I/O standards for SBCs and mezzanines.

Why it’s useful:

• Enables drop-in mezzanines (camera, comms, sensors)
• Simplifies vendor integration and community extensions

How to align:

• Include a 96Boards-style low-speed header (GPIO, I²C, I²S, UART; shift to 3.3 V)
• Expose MIPI CSI via a high-speed connector (partial lanes acceptable)
• Match hole pattern and keep-outs for mezzanines

Note:
96Boards often uses 1.8 V logic—plan for level shifting.

---

2. OSHW / OSHWA alignment

What it is:
Publishing hardware design files and documentation under open-source licenses, optionally certified by OSHWA.

Why it matters:

• Legal clarity and easier reuse
• Builds trust and supports grant eligibility

How to align:

• Use CERN-OHL-S (share-alike) or CERN-OHL-P (permissive)
• Publish source CAD, verified BOMs, fab notes, and assembly/test guides
• Maintain a known-issues document

---

3. Enabling Standards (Connectors, Rails, Pinouts)

Goal:
Define a minimal, stable, vendor-neutral baseline (“Robot Carrier v1”).

Proposal:

• Power: 24 V (motors), 12 V (perception), 5 V (logic), 3.3 V (I/O)
• Control: CAN-FD (required), RS-485 (optional)
• Sensing: 2× I²C, 1× SPI, 2× UART, 5× GPIO (5 V-tolerant)
• Perception: 2× CSI (MIPI), 2× USB 3.x, 1× GbE (PoE-PD optional)
• Expansion: M.2 Key-E/M, 96Boards LS/HS headers
• Mechanical: standard hole pattern and clear silkscreen labels

Deliverables:
4–6 page Interface Spec (PDF) + KiCad connector library.

---

4. Developer Ecosystem and Community

Purpose:
Build a sustainable contributor base and attract partners.

How to align:

• Maintain a public roadmap and labeled GitHub issues
• Provide reference mezzanines (e.g., CAN-FD with isolated power)
• Apply for OSHWA certification and announce in relevant forums

---

5. Design win

Meaning:
External teams adopt the board/spec in their work.

To encourage adoption:

• Keep the spec concise and stable
• Offer a starter kit (carrier + mezzanine + ROS 2 bring-up)
• Publish acceptance tests (CAN loopback, CSI demo, Nav2)
• Release Gerbers and verified BOMs (≥2 vendors per part)

---

Proposed next steps for OpenAMR

• Publish Robot Carrier v1 mini-spec (power, buses, pinouts, mechanicals)
• Add 96Boards LS/HS headers with level shifting and keep-outs
• Release Rev A carrier (RPi 5 base, Jetson optional) with CAN-FD, RS-485, dual CSI, GbE, USB 3.x, and M.2-E
• Provide a mezzanine reference (isolated dual CAN-FD + relay outputs)
• OSHWA-certify and publish complete CAD/BOM/docs
• Run a GitHub RFC (2–3 weeks) and finalize v1
• Secure a first adopter and document their bring-up

[BotshareAI]

Future OpenAMR RTC (Real-Time Controller) architecture should support modular multi-controller scalability instead of assuming a single monolithic controller for the entire robot.

Current RTC development is mainly focused on the mobile platform itself:

• Differential drive control
• Motor drivers
• Encoders
• IMU
• Low-level odometry
• Safety signals
• Battery/power monitoring
• Mobile platform sensors

However, future OpenAMR variants may include:

• Dual robotic arms
• Lift/elevator mechanisms
• Tool changers
• Additional upper-body sensors
• Functional I/O modules
• LED/status systems
• Auxiliary actuators
• Safety interlocks
• Additional real-time peripherals

For such systems, a single RTC may become difficult to maintain, wire, scale, and debug. Therefore, the architecture should support synchronized multi-RTC operation.

Recommended architecture:

• SBC (ROS 2 computer) acts as the central high-level coordinator:

  • Navigation
  • Planning
  • Perception
  • Task execution
  • Arm coordination
  • UI/diagnostics

• RTC add submodules #1 → mobile platform controller:

  • Wheel motors
  • Encoders
  • IMU
  • Safety systems
  • Odometry
  • Base sensors

• RTC #2 → upper-body controller:

  • Lift mechanism
  • Upper-body sensors
  • LEDs/status indicators
  • Tool I/O
  • Auxiliary actuators
  • Safety interlocks
  • Peripheral management

Robotic arms themselves should preferably keep their own dedicated controllers/drivers and communicate with the SBC via CAN/CAN-FD, EtherCAT, Ethernet, or vendor SDK interfaces. The RTC should coordinate the robot body around the arms rather than directly replacing dedicated arm controllers.

Important design goal:
The RTC PCB should be designed as a reusable modular controller platform, configurable for different roles instead of creating fully separate boards.

For example:

• Same PCB design
• Different firmware/configuration
• Addressable/synchronized multi-board operation

Recommended hardware interfaces/features for future scalability:

• CAN/CAN-FD
• RS485
• Ethernet or micro-ROS support
• Encoder inputs
• PWM outputs
• Digital I/O
• Safety inputs
• Power monitoring
• Expansion connectors
• Board addressing/configuration support

The power module can remain centralized in the mobile base, while sensor/control modules become extendable and stackable depending on robot configuration.

This architecture would allow OpenAMR to scale from:

• Simple AMR base
  to:
• Lift-enabled robots
• Single-arm systems
• Dual-arm mobile manipulators
• Tool-changing robots
• Industrial service robots
• Research platforms with custom modules

Main long-term goal:
Create a reusable, scalable, modular RTC ecosystem for future OpenAMR robot variants while keeping deterministic low-level control separated from high-level ROS 2 computation.

[BotshareAI]

OpenAMRobot STM32 Firmware Development

We are currently preparing the first firmware architecture for OpenAMRobot using STM32-based controllers.

Main goals:

• industrial-grade motor control integration
• encoder feedback
• safety IO
• communication bridge with ROS2
• modular firmware architecture
• hardware abstraction
• support for future industrial deployments

The goal is to separate:

• high-level ROS2 software
• low-level real-time firmware responsibilities

Future planned areas:

• CAN bus
• RS485
• safety layer
• watchdog systems
• battery management
• industrial communication interfaces

Embedded and firmware contributors are welcome.

[BotshareAI]

OpenAMRobot - Full System Electrical & Firmware Architecture

Dual-Arm Mobile Manipulator with Perception Module

Industrial-Grade, Open-Source, Cost-Optimized - Final Technical Requirements

Status: Final draft for team reference and community replication
Target application: SME manufacturing and warehousing (indoor and light outdoor use)
Design philosophy: every choice targets the minimum complexity necessary and sufficient to reach an industrial-grade safety and reliability bar, while staying affordable and buildable by a small team or an outside community contributor. Proven off-the-shelf modules and components are preferred over custom-designed subsystems everywhere they exist; custom design effort is reserved for the parts that genuinely need it (main power safety path, the three control MCUs).

---

1. What "Industrial-Grade" Means Here, and How Commercial Vendors Do It

Commercial mobile-manipulator and AMR vendors (MiR, ABB, KUKA, OMRON) converge on a consistent pattern, formalized in ISO 3691-4 (mobile robot safety) and RIA R15.08 (industrial mobile robots carrying a manipulator - our exact "Type C" configuration):

• The mobile base has its own independent, hardware-based safety system (E-STOP, bumpers/safety edges, signal lights) that does not depend on the navigation computer or any single microcontroller being alive and correct.
• Collaborative arms are sourced with their own certified control box handling joint control and force limiting (ISO/TS 15066) - integrators wire into the arm's safety I/O rather than re-implementing that logic.
• A general-purpose compute layer runs navigation, perception, and task planning, and is treated as replaceable hardware, isolated from the safety-critical logic beneath it.
• Every commercial platform surveyed includes: safety laser scanner and/or perimeter bumper/safety edge, redundant E-STOP, visible status light, audible movement warning, and automated charging.

This document follows that same layered pattern, scaled to what a small team can design, source, and debug without certification infrastructure, while explicitly deferring the highest-cost/highest-certification items (safety-rated scanners, wireless E-STOP, formal safety-PLC certification) to a later hardening stage.

---

2. System Topology

Four physical electronics assemblies, plus vendor-supplied arm control boxes treated as external equipment:

                                   ┌────────────────────────────────────────┐
                                   │  Main Compute Layer (Raspberry Pi 5)    │
                                   │  ROS 2, navigation, task planning       │
                                   │  + CAN-FD interfaces (Section 5)        │
                                   │  + LTE module (Section 7)               │
                                   │  + GNSS module (Section 7)              │
                                   └───────────────┬─────────────────────────┘
                                                    │
                        ┌───────────────────────────┼───────────────────────────┐
                        │ GbE / USB3                 │ CAN-FD (two segments)      │ Ethernet/TCP
              ┌─────────▼──────────┐        ┌─────────▼───────────┐       ┌──────────▼─────────┐
              │ Perception Module  │        │ Power / Mobile /    │       │ Arm control box(es)│
              │ (NVIDIA Jetson-    │        │ Upper-Body layers    │       │ (vendor-native,    │
              │  class add-on,     │        │ (Sections 3–4–5)     │       │  own safety system)│
              │  network-attached) │        └───────────────────────┘       └─────────────────────┘
              └────────────────────┘

Hardwired safety loop (independent of every bus above):
  [E-STOP Button 1]──┐                                          ┌──[Perimeter Safety Edge]
  [E-STOP Button 2]──┼── Dual relay channels (energize-to-run) ──┤
  [Arm Safety I/O]────┘                                          └──[Stack Light + Buzzer — status OUTPUT, not part of the safety input loop]

---

3. Layer 1 - Power Distribution (Wireless Charging + Dual-Battery Hot-Swap)

3.1 Charging: Wireless, Not Contact-Based

Decision: no physical charging contacts. Charging is inductive, via a dock-mounted transmitter pad and a chassis-mounted receiver coil.

Selected reference product: TZBot WCM-300 (Zhejiang Tongzhu Technology)

• Output: 28.8 V, 7 A, 300 W, wireless transmission efficiency ≥85%.
• Air gap tolerance: 0–50 mm; positional tolerance: ±30 mm on both X and Y axis — this is the mechanical/navigation-precision budget the docking behavior needs to hit, not tighter.
• 2.4 GHz communication link between transmitter and receiver for autonomous position confirmation and charge handshake — no separate data cable needed between dock and robot.
• IP65-rated on both transmitter and receiver — suitable for warehouse floors and light outdoor exposure.
• A matching 24V/20Ah battery+BMS pack is available from the same supplier line, usable as a reference sizing point even if the project sources its own pack.

Developer requirement: the chassis-mounted receiver coil output feeds the battery charge input exactly as a wired charger would - from the BMS's perspective, wireless charging is simply "the charger is present," no BMS redesign required. The docking behavior (approach, align within ±30 mm, hold position) is a navigation/software requirement, not an electronics one, and should be documented as such in openamrobot-docs.

3.2 Hot-Swap: Dual-Battery, OR-ing Architecture

Rather than a single battery pack with a single power path (which forces a full shutdown to change batteries), the platform uses two battery bays, each independently fused and BMS-protected, combined through an ideal-diode OR-ing stage onto a common bus - the same pattern already proven on the wearable data-collection kit (Discussion #17), applied here to the mobile base:

Battery A ── Fuse ── BMS ── Ideal-diode / OR-ing module ──┐
                                                            ├── Common DC bus ── Supercap hold-up ── Distribution/regulation
Battery B ── Fuse ── BMS ── Ideal-diode / OR-ing module ──┘

• Ideal-diode / OR-ing controller (e.g. an LTC4412-class controller, or a ready-made "power OR-ing" module - off-the-shelf modules exist and are the preferred implementation per the modular-electronics rule in Section 8): each battery bay feeds the common bus through its own OR-ing stage, so either bay can supply the system, or both simultaneously, with no reverse current between packs.
• Supercapacitor hold-up bank on the common bus: bridges the brief transition when one pack is physically removed for a hands-on swap, so the Main Compute and MCUs never brown out during a swap. Sized for a few seconds of full-system draw - enough to cover a physical pack change, not intended as a runtime energy source.
• Operational modes this enables: (a) charge Bay A wirelessly at the dock while Bay B powers the robot, then swap roles; (b) physically hot-swap either bay by hand at any time without powering down, using the supercap bridge; (c) both bays can be topped up wirelessly in sequence if only one wireless receiver/dock is fitted.
• BMS interface: prioritize a battery pack whose BMS exposes a native CAN output (per the CAN-everywhere rule, Section 5); fall back to SMBus/UART only if the selected BMS has no CAN option.

3.3 Fusing and Protection

• Main fuse per battery bay, immediately after the battery connector, ahead of the BMS.
• Per-rail fuses downstream of the common bus (motor 24V, auxiliary 24V, 12V, 5V logic), socketed for field replacement.
• Reverse-polarity protection (ideal-diode controller or Schottky diode) on each battery input, independent of the BMS.
• Inrush/soft-start (NTC thermistor or MOSFET soft-start) ahead of the main bulk capacitance.
• TVS diodes on all external harness connections (E-STOP wiring, BMS communication lines, sense lines).

3.4 Dual E-STOP Subsystem (self-built, hardwired - unchanged principle)

• Two independent, normally-closed mushroom E-STOP push-buttons, each driving its own independent relay, wired into the main power disconnect path such that either button alone cuts power to the motor/actuator rails.
• The two channels are electrically independent from button through relay contact - no shared wiring, connector pin, or PCB trace between them.
• Relays are energize-to-run / de-energize-to-stop, so loss of all onboard power leaves the system in the safe (de-energized) state by default.
• The relay disconnect path carries motor/actuator power directly and does not route through any microcontroller or firmware.
• Each relay has a spare auxiliary contact wired out to the power-monitoring MCU for diagnostic monitoring only - read-only, no firmware path can actuate the main contacts.
• A third independent NC channel from a perimeter safety edge (pressure-sensitive contact strip around the base) feeds the same relay logic as a peer of the two buttons, not a separate subsystem.
• Flyback/snubber network across each relay coil; contact ratings include ≥1.5× margin over maximum rail current/voltage.

3.5 Status Indicators (output side, not part of the safety loop)

• Stack light (addressable-LED module, single data line) showing run/fault/charging state.
• Audible buzzer, active especially during motion (and specifically reversing), consistent with standard AMR practice.
• Driven by the power-monitoring MCU or Main Compute - whichever owns the aggregated system state machine - never gating or being gated by the E-STOP loop itself.

3.6 Power-Monitoring MCU

• STM32G0-class part, physically on the power distribution board.
• Role: monitor rail voltage/current, poll BMS status (both bays), read E-STOP/safety-edge diagnostic contacts (read-only), sequence pre-charge/soft-start, drive status indicators, publish telemetry over CAN.
• No electrical or firmware path to actuate the E-STOP relays - this MCU cannot open or close the safety-critical contacts under any circumstance, by design.
• Isolated CAN-FD transceiver (e.g. ISO1042-class), since this node crosses the battery/logic ground-domain boundary.

3.7 Firmware Requirements (Power-Monitoring MCU)

• IWDG hardware watchdog, fed only by a monitor routine confirming all critical polling tasks (BMS ×2, rail sensing, E-STOP diagnostics) executed within their expected period.
• CAN heartbeat loss does not itself cut power (hard safety doesn't depend on this MCU) but is logged and reported once communication resumes.
• Startup self-test: verify relay auxiliary contacts read as expected, current/voltage sensing returns plausible values, both BMS units respond, before reporting READY.
• Manual-reset interlock: transition out of FAULT/SAFE_STATE requires an explicit operator action (dedicated reset input or command) — never an automatic clear when the fault condition disappears.
• Continuous rolling diagnostic log (not fault-triggered only) - key telemetry retained on a rolling basis in flash/EEPROM, in addition to a detailed fault-triggered snapshot, so intermittent issues can be diagnosed after the fact.
• State machine: INIT → SELF_TEST → READY → RUNNING → WARNING → FAULT → SAFE_STATE, published on every heartbeat frame.
• No dynamic memory allocation in any safety- or monitoring-relevant code path.

---

4. Layer 2 - Mobile-Platform RTC

MCU: STM32G4 (G474). HRTIM and CORDIC hardware accelerators give hard-real-time motor/encoder control with headroom to spare; built-in FDCAN removes the need for an external CAN controller; a right-sized, cost-appropriate part for a board replicated on every unit.

Interface	Connects to	Medium/Connector	Notes
Wheel motor drivers	Motor driver stage	CAN if the selected driver supports it (prioritize CAN-capable drivers when sourcing); otherwise PWM + direction with hardware encoder feedback
Wheel encoders	Encoder modules	Quadrature (A/B/Z), differential signaling for longer cable runs	Direct GPIO/timer input, not bussed
IMU	Onboard module	SPI	Off-the-shelf breakout module on header (Section 8)
Ultrasonic sensors	Sensor ring	I²C (multiplexed) or trigger/echo per sensor datasheet
Bumper switches	Mechanical/microswitch	Digital GPIO, normally-closed (fail-safe: wiring fault reads as "triggered")
IR proximity sensors	Sensor modules	Analog or digital GPIO
Temperature sensors	Motor/driver thermal monitoring	I²C or analog thermistor + ADC
Upstream link	Main Compute	CAN

Firmware:

• Real-time control loop (encoder/motor) runs as a timer-triggered ISR, never inside the RTOS scheduler.
• FreeRTOS handles CAN comms, telemetry, and non-time-critical sensor polling.
• Static allocation only in the control-loop path.
• Same watchdog stack as the Power-Monitoring MCU: IWDG + task-level heartbeat check + CAN heartbeat timeout (loss of Main Compute heartbeat beyond ~200 ms → autonomous transition to zero-torque/brake, without waiting for the Main Compute).
• Same state-machine convention and rolling diagnostic log requirement as Section 3.7.

---

5. Layer 3 - Upper-Body Controller

Kept as a separate physical board and firmware image from the Mobile-Platform RTC, because the upper body's sensor mix (force/pressure, an additional IMU, lift encoder, tool I/O) and its gateway role toward the arm control boxes are enough independent complexity to justify it.

MCU: STM32H7 (H743, or the dual-core H745 if the workload benefits from splitting deterministic I/O from gateway logic on separate cores).

Interface	Connects to	Medium/Connector	Notes
Lift motor driver	Lift actuator driver stage	CAN preferred, same reasoning as wheel drivers
Lift encoder	Lift mechanism	Quadrature or absolute encoder (SSI/BiSS if precision position needed)
Upper-body IMU	Onboard module	SPI	Off-the-shelf breakout on header
Pressure/force sensors	Load cells or force sensors at tool/lift interface	Digital load-cell amplifier (HX711-class) or analog + onboard ADC
Tool I/O	Gripper, pneumatic valves, end-effector sensors	Digital I/O, opto-isolated where the tool circuit is a different voltage domain
Arm control box(es)	Vendor arm controller	Ethernet/TCP (vendor-native protocol) — explicit exception to the CAN-everywhere rule, since collaborative arm vendors standardize on Ethernet	Host this on the Upper-Body Controller if it has an Ethernet PHY, or pass through the Main Compute's network port — pick one and document it, don't split the responsibility
Arm safety I/O	Arm control box's safety-rated I/O connector	Hardwired into the same E-STOP loop as Section 3.4	Diagnostic-only monitoring here, no override authority
Upstream link	Main Compute	CAN

Arm integration principle: arms are sourced with their own vendor control box handling joint-level real-time control and (for collaborative-class arms) certified force limiting. The Upper-Body Controller's role toward the arms is supervisory — start/stop, mode selection, status/fault feedback, and safety-I/O tie-in — never re-implementing joint control or force limiting.

Firmware: same watchdog stack, state-machine convention, and rolling diagnostic log requirement as Sections 3.7/4. If using the dual-core H745, dedicate the M4 core to the lift control loop and time-critical I/O, and the M7 core to the arm-gateway/logic workload, communicating between them via message queue rather than shared state.

---

6. Layer 4 - Main Compute

• Raspberry Pi 5 as the baseline "brain": ROS 2, navigation, task planning, fleet/UI connectivity.
• Perception module (NVIDIA Jetson-class) as a network-attached add-on over GbE/USB3, running its own ROS 2 node(s) - this keeps the main carrier SBC-agnostic instead of requiring a custom multi-footprint carrier.
• Hosts the Ethernet/TCP link to arm control boxes if that responsibility isn't delegated to the Upper-Body Controller.
• Bridges the two CAN-FD bus segments (Section 5 of the bus architecture below) at the software/ROS 2 level, keeping the two bus fault domains physically separate.

---

7. Communication Backbone

7.1 CAN-FD as the Default Interface

Rule: if a subsystem (motor driver, BMS, sensor module) offers a CAN or CAN-FD interface, use it in preference to any other interface. This applies to wheel motor drivers, the lift motor driver, both battery BMS units, and any future actuator driver.

Two physical bus segments, not one flat bus, so a fault in one area cannot degrade the other:

Bus	Nodes	Bitrate
CAN-A ("Base Bus")	Main Compute (gateway), Power-Monitoring MCU, Mobile-Platform RTC, wheel motor driver(s)	500 kbit/s arbitration / 2 Mbit/s data phase
CAN-B ("Upper Bus")	Main Compute (gateway), Upper-Body Controller, lift motor driver	500 kbit/s arbitration / 2 Mbit/s data phase

• Termination: 120 Ω at each physical end of each segment only - not at every node.
• Transceivers: isolated CAN-FD transceiver (ISO1042-class) required at any node crossing a ground-domain boundary (Power-Monitoring MCU, Main Compute gateway).
• Connectors: locking 4-pin connector (JST-GH class or equivalent) for every CAN drop - no bare headers on a CAN-carrying connector. Pinout: CAN_H, CAN_L, GND, +5V (optional bus power).
• Node addressing: fixed CAN ID ranges at compile time, defined once as shared constants in openamrobot-comm:

Node	Bus	ID range
Main Compute (gateway)	A & B	0x000–0x00F
Power-Monitoring MCU	A	0x010–0x01F
Mobile-Platform RTC	A	0x020–0x03F
Wheel motor driver(s)	A	0x040–0x05F
Upper-Body Controller	B	0x060–0x07F
Lift motor driver	B	0x080–0x08F

• Frame integrity: every published frame includes a sequence counter and CRC beyond the CAN-level CRC.
• Main Compute CAN interface: the Raspberry Pi 5 has no native CAN — use two MCP2518FD-based CAN-FD HATs/modules over SPI, exposed to Linux/ROS 2 via standard socketcan. This is a well-documented, widely reproduced approach in the RPi/ROS 2 community, keeping the Main Compute standard and off-the-shelf.

7.2 Cellular Connectivity (LTE)

Purpose: onboard internet independent of site Wi-Fi, for remote monitoring, telemetry, and fleet management in environments where Wi-Fi coverage can't be assumed.

• Recommended part family: Quectel EC25-series (or equivalent EC2x/EG2x-class) LTE Cat-4 module - widely used and well-supported in Linux (appears as a standard USB modem).
• Mini-PCIe or M.2 module on a small header-mounted carrier board, connected over USB 2.0.
• Standard nano-SIM slot accessible without full enclosure disassembly.
• External LTE antenna via SMA or u.FL pigtail.
• Dedicated, well-decoupled 3.8–4.2 V supply rail with adequate local bulk capacitance to absorb transmit-burst current draw without affecting the 5V logic rail — do not share this regulator with sensitive analog circuitry.
• Wi-Fi remains the primary link when available; LTE is the automatic fallback.

7.3 GNSS (Outdoor Localization)

Purpose: outdoor localization support for yard, loading-dock, or outdoor-adjacent operation, beyond indoor SLAM/AprilTag-based navigation.

• Recommended part family: u-blox NEO-M9N-class (or M8N-class) multi-constellation GNSS receiver module - standard in open-source robotics, well-supported in ROS 2.
• UART (preferred) or USB to the Main Compute.
• Active GNSS antenna, mounted with unobstructed sky view, away from motor/driver EMI sources.
• Feeds ROS 2 navigation as a standard NavSatFix source, fused with wheel odometry/IMU (e.g. via robot_localization) for outdoor localization, while indoor operation continues on the platform's existing SLAM/AprilTag methods.

7.4 Time Synchronization

Main Compute and perception add-on synchronize clocks via NTP/chrony over their shared network link; each MCU node's CAN telemetry carries a local monotonic counter (the existing sequence-counter field) translated to wall-clock time by the Main Compute. Hardware-level PTP triggering across camera/LiDAR/IMU is deferred to a later hardening stage.

---

8. Modular Electronics: Headers, Not Solder

Rule: wherever a proven, off-the-shelf breakout module exists for a function, use it via a pin-header/socket on the main PCB rather than soldering the equivalent chip directly. Rationale for an open-source project: contributors can replace/repair a failed module without reflow equipment, anyone reproducing the project can source modules individually, and the small per-unit cost premium buys a large reduction in build difficulty and repair friction.

Function	Module-based approach
IMU (all three nodes)	Off-the-shelf breakout (e.g. BNO055 or MPU6050-class), socketed
GNSS	u-blox NEO-M9N breakout module
LTE	Quectel EC25-class module on its own carrier, header-connected
Current sensing	ACS712/INA219-class breakout module
CAN transceiver	Isolated SN65HVD230/TCAN-class breakout, socketed onto each MCU board's CAN header
Load-cell/force amplifier	HX711-class breakout module
Battery OR-ing stage	Ready-made ideal-diode/power-OR-ing module (Section 3.2) rather than a custom-laid-out equivalent
Buzzer	Off-the-shelf active buzzer module
Status light	Addressable LED module (WS2812-class), single data line
Auxiliary DC-DC conversion	Off-the-shelf buck/boost modules for low-current auxiliary rails (5V logic, 12V aux)

Exceptions (remain custom-designed): the main power distribution stage (fusing, E-STOP relays, main rail regulation) and the three STM32 MCU boards themselves - these are the safety- and performance-critical parts where a generic module would not meet the requirements already specified above. Every custom board should still expose standard pin-header sockets for every module listed, rather than hardwiring modules with fixed point-to-point cabling.

---

9. Bill of Materials (representative part families - final SKUs confirmed at procurement)

Category	Item	Example part/family	Interface	Qty
Compute	Main Compute SBC	Raspberry Pi 5	—	1
Compute	Perception add-on	NVIDIA Jetson Orin Nano-class	GbE/USB3	1
Compute	CAN-FD interface	MCP2518FD-based SPI CAN-FD HAT/module	SPI	2
MCU	Power-Monitoring MCU	STM32G0 (G071/G0B1)	—	1
MCU	Mobile-Platform RTC	STM32G4 (G474)	—	1
MCU	Upper-Body Controller	STM32H7 (H743/H745)	—	1
Charging	Wireless charger set	TZBot WCM-300 (transmitter + receiver)	Inductive, 2.4 GHz handshake	1 set
Power	Battery packs	2× packs (main + hot-swap bay), CAN-capable BMS preferred	CAN/SMBus	2
Power	Ideal-diode/OR-ing modules	LTC4412-class or equivalent ready-made module	—	2 (one per bay)
Power	Supercapacitor hold-up bank	Sized for full-system draw over a few seconds	—	1
Power	Hot-swap/eFuse per rail	TPS2596-class or fuse + module equivalent	—	per rail
Power	E-STOP buttons	Mushroom-head NC push-button	—	2
Power	E-STOP relays	Industrial relay, silver-alloy contacts, energize-to-run	—	2
Power	Perimeter safety edge	Rubber contact-strip safety edge, NC output	—	1 set (perimeter length)
Sensing	IMU breakout (×3 nodes)	BNO055/MPU6050-class module	SPI/I²C	3
Sensing	Wheel encoders	Quadrature encoder module	Digital	per wheel
Sensing	Ultrasonic sensors	Standard trigger/echo or I²C module	I²C/GPIO	per ring position
Sensing	Bumper switches	Microswitch, NC	GPIO	per contact point
Sensing	Load cell amplifier	HX711-class module	Digital	as needed
Sensing	Current sense modules	ACS712/INA219-class module	Analog/I²C	per monitored rail
Sensing	GNSS module + antenna	u-blox NEO-M9N + active antenna	UART/USB	1
Connectivity	LTE module + carrier + antenna	Quectel EC25-class	USB	1
Comms	CAN transceiver modules	Isolated SN65HVD230/TCAN-class breakout	Header	1 per MCU node
Indicators	Status light	Addressable LED module (WS2812-class)	GPIO	1
Indicators	Buzzer	Active buzzer module	GPIO	1
Actuation	Wheel motor drivers	CAN-capable BLDC/servo driver	CAN-A	per drive wheel
Actuation	Lift motor driver	CAN-capable driver	CAN-B	1
Actuation	Arm(s)	Vendor collaborative arm + control box	Ethernet/TCP + safety I/O	per arm
Enclosure	Electronics enclosure	IP54-rated enclosure/box (IP65 already covered on the wireless charger itself)	—	per compartment

---

10. Developer Checklists

Electronics

• Every CAN drop uses a locking 4-pin connector — no bare headers on any CAN-carrying connector.
• Bus termination resistors placed only at the two physical ends of each CAN segment.
• Isolated CAN transceiver at every ground-domain-crossing node (Power-Monitoring MCU, Main Compute gateway).
• E-STOP loop wiring physically routed and connectorized separately from all bus cabling.
• Both battery bays' OR-ing modules verified to prevent any reverse current path between packs.
• Supercap hold-up bank sized and tested against an actual hot-swap event (measure bus voltage sag during a live pack removal).
• LTE module's power rail decoupled from analog/sensor rails; confirm with a transmit-burst load test.
• GNSS antenna placement reviewed for sky visibility and separation from motor/driver EMI sources.
• Every custom PCB includes a hardware-revision ID (resistor divider or small EEPROM) readable by its MCU.
• Every board's schematic and connector pinout documented in openamrobot-docs before layout is finalized.
• Docking mechanical/navigation design confirmed against the WCM-300's ±30mm / 0–50mm alignment tolerance.

Firmware

• CAN node ID ranges defined as shared constants in openamrobot-comm, not hardcoded per repo.
• Every published CAN-FD frame includes a sequence counter and CRC beyond the CAN-level CRC.
• Every node implements the shared state machine and reports it on every heartbeat frame.
• Every node implements the layered watchdog stack (IWDG + task-level heartbeat + CAN heartbeat timeout).
• Manual-reset interlock implemented — no automatic clear of FAULT/SAFE_STATE.
• Rolling diagnostic log implemented on every node, in addition to fault-triggered snapshots.
• LTE/GNSS integration lives at the ROS 2 node level on the Main Compute — no STM32 firmware changes required for connectivity features.
• Arm-gateway code runs in a task/process separate from any real-time control loop, communicating via message queue rather than shared state.

---

11. Staged Roadmap

Stage	Scope
This build	Wireless charging (TZBot WCM-300), dual-battery hot-swap with OR-ing + supercap hold-up, hardwired dual E-STOP + perimeter safety edge, three-MCU CAN-FD architecture (STM32G0/G4/H7), LTE + GNSS connectivity, module-based sensor breakouts, vendor arm integration via Ethernet + safety-I/O tie-in, IP54 enclosure target
Hardening (post-MVP)	Safety-rated laser scanner, wireless E-STOP remote, load/weight sensing, hardware-level sensor time sync (PTP), formal AMR safety certification path (ISO 3691-4 / RIA R15.08) if pursuing regulated deployment
Scale-up	Fleet management integration, multiple perception modules, additional arm/tool variants

This is the complete reference for the platform's electronics and firmware at this stage - every interface, protocol, connector class, and part family needed to start detailed schematic design and firmware implementation is specified above.