The open-source robotics stack, explained

There is no single open-source robotics stack. There is a set of layers maintained by different communities, each with its own release cycle and assumptions.

That is a strength until two layers disagree about time, coordinates, message types, or who owns the hardware.

Ask which layer owns each job and what contract connects it to the next layer. A framework ranking will not answer either question.

ROS 2 connects processes and people

ROS 2 supplies the graph, message types, discovery, command-line tools, launch system, and a large package ecosystem.

Use it to connect sensing, estimation, planning, control, visualization, logging, and hardware drivers.

ROS 2 does not decide your control law, choose your planner, or make a bad message contract safe. It gives those components a common way to communicate.

Its core abstractions are deliberately small:

• Nodes own a unit of computation.
• Topics carry ongoing streams.
• Services handle short request-response operations.
• Actions represent cancellable work with feedback.
• Parameters hold runtime configuration.

The hard part is deciding which abstraction fits. A camera frame belongs on a topic. "Calibrate now" may be a service. "Navigate to this pose" is usually an action.

Simulation owns physics before hardware can

A simulator gives your software a world, sensors, actuators, and time.

Gazebo works naturally with ROS 2 and supports complete robot worlds. It is useful for integration tests, navigation, sensors, and multi-component demos.

MuJoCo focuses on fast, accurate rigid-body dynamics and contact. It is common in control and robot-learning work.

They overlap, but they are not interchangeable in every project.

Choose Gazebo when the ROS 2 integration and world ecosystem carry the project. Choose MuJoCo when contact-rich dynamics, control, or fast policy rollouts dominate.

Do not claim "sim to real" because the robot moved in both places. Record which physical properties were modeled, measured, randomized, or ignored.

Robot descriptions are shared contracts

A robot description names links, joints, geometry, limits, sensors, and frames.

URDF is common in ROS systems. Xacro adds reusable macros. SRDF adds semantic information used by MoveIt. MuJoCo uses MJCF, while Gazebo also uses SDF.

Conversion can save time, but every format carries concepts the others may not express exactly.

Keep one source of truth where possible. Add validation that catches missing limits, duplicate names, invalid inertia, and frame changes.

Visual geometry can be forgiving. Collision geometry and inertial values cannot. A beautiful mesh with poor mass properties creates a persuasive but dishonest simulation.

ros2_control owns the hardware boundary

ros2_control separates controller logic from hardware-specific read and write operations.

A hardware interface exposes state and command interfaces. A controller manager updates controllers. Controllers consume state and produce commands.

The same controller can then target simulated or physical hardware if both expose compatible interfaces.

That sentence contains the benefit and the trap. Compatible names and types do not guarantee compatible timing, delay, noise, saturation, or failure behavior.

Test update rates. Reject stale commands. Apply limits at the lowest sensible layer. Make emergency behavior independent of a healthy network path.

The hardware boundary should be narrow enough to inspect and strict enough to distrust upstream code.

MoveIt owns arm motion planning

MoveIt brings kinematics, collision checking, motion planning, scene management, and execution together for manipulators.

It can answer a demanding question: how can the arm reach a goal while respecting joints, obstacles, and the current scene?

It cannot rescue a bad calibration or an incorrect frame tree. Planning errors often begin as state-estimation errors.

Start with a known robot in simulation. Inspect the planning scene. Request a pose. Visualize the path. Then add one obstacle and verify that the path changes.

When you connect hardware, compare the commanded trajectory with measured joint states. A successful planner request is not proof that the arm followed safely.

Navigation needs a similar division of labor

Mobile robots need mapping, localization, global planning, local control, and recovery.

ROS 2's navigation ecosystem packages these jobs, but the boundaries still matter.

A global planner works on a larger map. A local controller responds to nearby constraints. Localization estimates pose. Recovery behavior handles states where ordinary progress stops.

Do not hide every failure behind a retry. A robot that repeatedly replans into the same blocked corridor needs a different state transition, not more optimism.

The Fanout system design path is relevant here because robot software is distributed software with motors attached. Timeouts, ownership, backpressure, and degraded modes still decide behavior.

LeRobot adds data and learned policies

LeRobot provides open datasets, models, policy implementations, robot interfaces, and training tools in PyTorch.

It is useful when a task is easier to demonstrate than to specify as a classical controller.

The data loop matters more than the model menu:

1. Teleoperate the robot and record observations plus actions.
2. Inspect timing, dropped frames, calibration, and task coverage.
3. Train a policy against a fixed dataset split.
4. Evaluate in simulation or a guarded hardware setup.
5. Add failure cases to the next collection round.

Robot-learning datasets include physical history. A camera moved by two centimeters can change the distribution. Record configuration beside the episodes.

Open hardware makes the stack inspectable

Open software is easier to test when the mechanical drawings, bill of materials, firmware, and calibration process are also available.

Low-cost arms are useful because a learner can inspect the full path from an action tensor to a motor command.

Check more than the repository license. Ask whether replacement parts are available, whether calibration is documented, and whether the design has an active maintainer community.

An open CAD file without tolerances or assembly instructions may still leave most of the hardware effectively closed.

Infrastructure becomes part of the robot

Robotics projects collect bags, videos, checkpoints, container images, and calibration files. They also depend on machines with different GPUs and device access.

Use containers for repeatable user-space dependencies, but keep device drivers and real-time assumptions visible.

Use Git for source and small configuration. Use an artifact store for datasets and models. Record hashes so an evaluation can name the exact code, data, and checkpoint.

The AI homelab guide covers remote compute, worktrees, secrets, storage, and recovery when one laptop is no longer enough.

A small stack for a first serious project

For a mobile robot, start with ROS 2, Gazebo, ros2_control, RViz, bags, and a navigation package.

For an arm, start with ROS 2, MoveIt, ros2_control, Gazebo or MuJoCo, and a camera calibration tool.

For imitation learning, add LeRobot only after teleoperation and recording are stable.

Keep the system observable:

• Log software versions and launch parameters.
• Record message rates and latency.
• Preserve calibration with the run.
• Store a short failure clip and the matching messages.
• Test one component without launching the entire graph.

The stack should make a failure easier to localize. If adding a framework makes ownership less clear, its integration cost is higher than its install command suggests.

Fanout's robotics roadmap provides an order for learning these layers. Build one vertical slice before widening the stack.