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.