Skip to main content
When something misbehaves, SSH into MARS and work through the layers: overall status → hardware → logs → skills → raw ROS2. The innate CLI covers the first four without touching ROS2 directly.
Prefer the browser? The web app’s Logging page shows the robot’s entire console — every node and process, structured, filterable, and live — with no SSH, and it’s a complete superset of /rosout. Reach for this terminal guide when you need the CLI, tmux, or raw ROS 2 tools.

​
1) Get the lay of the land

Running innate with no arguments prints the status dashboard: OS version, mode, ROS/DDS status, and a quick command reference. Start here — it often answers “is the stack even running?” immediately.

​
2) Check the hardware

Runs hardware diagnostics across servos, PCB, lidar, cameras, and speaker. If a component fails here, no amount of software debugging will help — fix the hardware issue first (see Troubleshooting).

​
3) Read the logs

Attaches to the tmux session where every ROS node runs, one pane per node. Look for red error text, stack traces, or panes stuck in a restart loop.

​
4) Test skills in isolation

When an agent misbehaves, bypass it and trigger the skill directly:
If the skill works when run directly, the problem is in the agent (prompt, skill list, inputs) — not the skill.

​
5) Drop down to ROS2

For anything the CLI doesn’t surface, use the ROS2 CLI directly:
See Topics, Services, and Actions for the full interface reference.

​
6) Restart and rebuild

innate build is smart: if nodes aren’t running it just builds, and if the build fails it leaves nodes stopped rather than restarting a broken stack.
For every command and flag, see the Innate CLI Reference. For hardware/runtime issue patterns, see Troubleshooting. For visualization workflows (RViz and Foxglove Bridge), see ROS2 Overview.