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.
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Most of this skill is scripts that turn a suspicion into an exit code. Run one before reasoning about the symptom.
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.
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.
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.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Implement or change ROS 2 Jazzy packages, nodes, interfaces, launch files and configuration in a colcon workspace. Use for building and validating a development change, including tests that report success without running. For a live QoS, TF, IMU or odometry fault, use ros2-troubleshooting.
The English summary is being prepared. Showing the original description.
micro-ROS: agent, rclc client API, micro_ros_setup, custom transports, static memory.
The English summary is being prepared. Showing the original description.