> 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/simulation/technology-baseline.md).

# Technology Baseline and Version Policy

CAREC maintains **one supported simulation baseline** so contributors, CI and future hardware integration do not drift into incompatible ROS/Gazebo combinations.

## Supported baseline

| Layer               | CAREC baseline                     | Responsibility                                                           |
| ------------------- | ---------------------------------- | ------------------------------------------------------------------------ |
| Host OS             | Ubuntu 24.04 LTS (Noble)           | Native Linux and CI reference                                            |
| Middleware          | ROS 2 Jazzy Jalisco                | Inter-process communication, TF, parameters, lifecycle and robotics APIs |
| Primary simulator   | Gazebo Harmonic LTS                | Physics, worlds, collisions and simulated sensors                        |
| Navigation          | Nav2 for Jazzy                     | Planning, control, costmaps, recovery and navigation orchestration       |
| Mapping             | SLAM Toolbox                       | 2D SLAM and map generation                                               |
| Visualization       | RViz2                              | Robot, TF, map, path and sensor inspection                               |
| Control             | `ros2_control` + `gz_ros2_control` | Shared controller interfaces across simulation and future hardware       |
| Simulator bridge    | `ros_gz`                           | ROS 2/Gazebo message and service integration                             |
| Build               | `colcon`, `rosdep`, `vcstool`      | Workspace build and dependency management                                |
| Languages           | C++ and Python                     | Production ROS nodes, algorithms, utilities and tests                    |
| Containers          | Dev Container / Docker             | Reproducible contributor and CI environment                              |
| Source/CI           | Git, GitHub, GitHub Actions        | Collaboration, reviews and automated verification                        |
| Advanced simulation | NVIDIA Isaac Sim                   | Phase-2 high-fidelity perception, synthetic data and GPU/AI experiments  |
| Asset creation      | Blender                            | Optional 3D model/world asset preparation                                |

## Primary vs advanced simulator

**Gazebo Harmonic is the CAREC baseline simulator.** Every core wheelchair model, control interface, safety behavior and navigation regression must be testable here.

**NVIDIA Isaac Sim is complementary, not a replacement baseline.** Use it later when photorealistic perception, synthetic datasets, domain randomization, GPU-heavy sensor simulation or AI evaluation provides a measurable benefit. Core CAREC development must not require every volunteer to own an RTX workstation.

## Why this combination

ROS 2 provides the modular robotics architecture. Gazebo provides deterministic-enough physics and sensor simulation for everyday engineering. `ros2_control` creates a boundary that can later connect the same higher-level software to physical drive hardware. Nav2 and SLAM Toolbox prevent CAREC from rebuilding mature navigation infrastructure while still allowing CAREC-specific accessible planning and safety behavior to be developed around them.

## Version policy

Jazzy packages target Ubuntu 24.04, and Gazebo Harmonic is the supported simulator pairing. CAREC should not mix Gazebo Classic, older Ignition-era package conventions or arbitrary newer Gazebo releases into the standard contributor path.

{% hint style="info" %}
Newer ROS 2, Gazebo, Nav2 or simulator releases may be evaluated on an experimental CI lane. They become supported only after the complete regression suite passes and this baseline is deliberately updated.
{% endhint %}

## Pinning rules

* Pin the container base image by digest for releases.
* Record ROS distribution, Gazebo release, source commit, world version, parameter bundle, random seed and test-image digest in reproducible runs.
* Keep one dependency manifest for local development and CI.
* Rebuild the reference environment on a scheduled cadence and execute the full simulation suite before adoption.
* Never repair a broken build by adding an undocumented package interactively.
* Do not merge a dependency upgrade solely because it works on one contributor's computer.

## Upgrade gate

A baseline upgrade requires:

1. a documented change proposal;
2. a clean build from the supported base environment;
3. deterministic smoke-test completion;
4. navigation regression comparison;
5. safety-scenario regression comparison;
6. performance/resource comparison;
7. known-issue and migration notes;
8. rollback path;
9. maintainer approval.

The goal is not to use the newest package immediately. The goal is to keep CAREC reproducible, reviewable and safe while still providing an explicit path to newer technology.


---

# 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/simulation/technology-baseline.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.
