Architecture
OpenAMRobot separates implementation, contracts, releases, durable documentation and governance so each concern has one owner while the complete platform remains understandable from this knowledge hub.
Layers
| Layer | Owner |
|---|---|
| Mobile-base ROS 2 software | openamr-platform-sw |
| Mobile-base firmware | openamr-platform-fw |
| Mobile-base hardware | openamr-platform-hw |
| Operator interface | openamrobot-ui |
| Shared ROS 2 contracts | openamrobot-interfaces |
| Communication boundary | openamrobot-comm |
| Upper-body components | Upper-body overview |
| Release coordination | openamrobot-release and openamrobot-manifest |
| Governance and contribution | openAMRobot/.github |
| Learning and durable conceptual documentation | openamrobot-docs |
Ownership rule
Implementation-sensitive source, exact versions and machine-readable contracts stay with the component that owns them. Shared contracts stay in interface or communication repositories. Cross-repository compatibility is captured by the manifest and release repositories.
This site remains the self-contained learning layer: it explains what those elements mean, how they work together, how to choose among them and how to complete and verify a robot task.
See the Documentation Standard and complete repository ecosystem.
Safety boundary
No single repository proves that an assembled robot is safe. Integrators must validate the complete configured system, including mechanical, electrical, firmware, software, communication and operator-control behavior. See Working safely.