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