Diagnose ROS 2 Jazzy faults that reading the code cannot settle: QoS mismatch, sensor-mount and frame errors (REP 103/105), and odometry calibrated against CAD instead of the floor. Ships four runnable pass/fail checks.
Installs into .claude/skills of the current project.
Are you the author of Ros2 Troubleshooting?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/leehyunbin0131-ros2-troubleshooting)
---
name: ros2-troubleshooting
description: "Diagnose ROS 2 Jazzy faults that reading the code cannot settle: QoS mismatch, sensor-mount and frame errors (REP 103/105), and odometry calibrated against CAD instead of the floor. Ships four runnable pass/fail checks."
---
# ROS 2 troubleshooting
Most of this skill is scripts that turn a suspicion into an exit code. Run one
before reasoning about the symptom.
## Bundled checks
`scripts/` sits next to this file — resolve the path from this skill's own
directory, not the user's CWD. The variable `ROS2_SKILL_DIR` in the examples
represents the absolute directory of the loaded skill, set internally by the
agent based on discovery location (do not ask the user for this path).
This works with Claude Code and Codex, for project and user installations.
They are plain scripts: invoke with `python3` and a real path. There is no
package to `ros2 run`, and inventing one is a known failure mode. Exit code
**0 = PASS, 1 = FAIL, 2 = inconclusive/invalid request**. Tell the user the command you ran.
```bash
source /opt/ros/jazzy/setup.bash
ROS2_SKILL_DIR="/absolute/path/to/ros2-troubleshooting" # Set by agent to loaded skill directory.
python3 "${ROS2_SKILL_DIR}/scripts/check_qos_compat.py" --topic /scan
```
| Script | Answers |
| :--- | :--- |
| `check_qos_compat.py --topic /scan` | Why a healthy publisher delivers nothing to this subscriber |
| `check_tf_tree.py --sensors laser_frame,imu_link` | Does `map->odom->base_link` resolve? Prints sensor mount RPY for comparison with the hardware |
| `check_imu_gravity.py [--topic /imu/data]` | On a level robot, is measured gravity ~+9.81 on +Z in `--base base_link` after declared TF or with `--assume-aligned`? Requires ≥2 samples; RMS variation >1.5 m/s² (adjustable via `--max-variation`) returns inconclusive for motion, vibration or noise. Neither declared TF nor `--assume-aligned` proves physical stillness; yaw is not observable. Missing TF is inconclusive without `--assume-aligned` |
| `check_odom_direction.py [--topic /odom]` | Does odometry agree with the direction the robot physically moved |
`check_tf_tree.py` prints `VERIFY PHYSICALLY` for any ~180° roll or yaw **even
when that mounting is deliberate**. It asks for a comparison against the
hardware; it is not a verdict. Report it that way.
## References
Load the one the symptom points at.
- **`references/frames.md`** — REP 103/105 axis conventions, and the
misalignment symptoms that follow from getting them wrong. `CLAUDE.md` treats
this file as ground truth for any frame or TF question.
- **`references/runtime.md`** — what a QoS mismatch actually looks like on
Jazzy, the two other policies that fail the same way, and why `ros2 topic
echo` cannot detect any of them.
- **`references/calibration.md`** — correcting `diff_drive_controller` wheel
radius and separation against a tape measure, in the order that works. Read
when odometry is consistent but wrong by a ratio.
