> For the complete documentation index, see [llms.txt](https://carec.gitbook.io/carec-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://carec.gitbook.io/carec-docs/documentation/architecture/adr-0009-stable-carec-ros-interfaces.md).

# ADR-0009 — Stable CAREC ROS Interfaces

**Status:** Accepted\
**Date:** 2026-09-01\
**Accepted:** 2026-09-01

## Decision

CAREC uses one non-bypassable ROS 2 motion path:

`User Input / Autonomy -> User Intent or Proposed Velocity -> Independent Safety Supervisor -> Safety-Approved Velocity -> Simulator`

Only the independent safety supervisor may publish the final motion command consumed by the simulator. Any future physical platform adapter must use the same final safety-approved motion boundary and requires a separate hardware-phase review.

## Required interfaces

* **User intent** — operator-requested motion or stop intent with source identity, timestamp, and freshness.
* **Proposed velocity** — teleoperation/shared-control/navigation motion before safety authorization.
* **Safety-approved velocity** — bounded final motion accepted by the simulator or future approved platform adapter.
* **Emergency stop / reset** — explicit latched stop and controlled reset; reset never resumes motion by itself.
* **Sensor health** — explicit `HEALTHY`, `STALE`, `UNAVAILABLE`, and `INVALID` states.
* **Localization health** — explicit health independently from pose data.
* **Safety intervention reason** — machine-readable reason whenever proposed motion is changed or rejected.
* **Platform profile identity** — identifies digital platform configuration without implying physical certification.

## Frames, units, and time

CAREC follows ROS mobile-robot conventions using `map -> odom -> base_link -> sensor frames`. Linear motion uses meters per second and angular motion uses radians per second. ROS time and `/clock` are used for simulation; freshness timeouts are explicit and configuration-controlled.

Missing, stale, invalid, non-finite, or otherwise unsafe inputs must not silently continue motion. When a fresh valid safe command cannot be established, the final commanded motion is zero.

## Safety invariant

> Only the independent safety supervisor may produce the motion command accepted by the simulator or a future approved physical platform adapter.

Acceptance of this ADR is not physical-wheelchair safety certification and does not authorize physical wheelchair control.

## Acceptance record

The ADR was technically reviewed against GitHub Issue #17 and the simulation-first CAREC architecture on 2026-09-01. No interface-contract gaps were identified.

Issue #17 originally requested two independent reviewer approvals. On 2026-09-01 the project owner removed that repository branch-rule gate and explicitly directed the project to proceed. PR #45 was then merged by owner decision. This governance override is recorded explicitly rather than represented as independent approvals that did not occur.

Future changes to this safety boundary should return to independent review whenever reviewers are available.

## Consequences

Issue #20 may now proceed with the ROS 2 autonomy workspace scaffold. Teleoperation, navigation, shared control, fault injection, localization health, collision monitoring, and evaluation tooling must preserve this accepted interface boundary.

## Related

* GitHub Issue #17 — completed
* GitHub PR #45 — merged
* GitHub Issue #20 — ROS 2 autonomy workspace scaffold
* ADR-0004 — Motor-Control Interface
* ADR-0008 — Communication Architecture


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://carec.gitbook.io/carec-docs/documentation/architecture/adr-0009-stable-carec-ros-interfaces.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.