Inspect, plot and record Axiom data

Inspect, plot and record Axiom data

The core build includes console monitors and a local Matplotlib plotter. These tools subscribe to the host driver's ROS topics; they do not open another USB/Wi-Fi connection or start firmware acquisition. Complete Install and connect and keep discovery running. Use the same sourced workspace, ROS domain and middleware in each terminal.

Copy complete topic paths from ros2 topic list -t –no-daemon or the board's devices.public_topics map. Placeholder variables below belong to the terminal where you set them. See standard messages and units before interpreting a field.

Console monitors

Run each continuous monitor in its own prepared terminal and stop it with Ctrl+C: 

# Load the core tools from the built workspace.
source scripts/setup_env.sh
# Select an actual sensor_msgs/Imu measurement topic.
IMU_TOPIC='PASTE_FULL_IMU_TOPIC_HERE'
# Print acceleration, gyro and an approximate received rate.
ros2 run axiom_debug_tools axiom_imu_monitor --ros-args -p topic:="$IMU_TOPIC"

# Select a scalar sensor_msgs/Range topic, not a multizone Image.
RANGE_TOPIC='PASTE_FULL_RANGE_TOPIC_HERE'
# Print range in metres and basic validity/rate information.
ros2 run axiom_debug_tools axiom_range_monitor --ros-args -p topic:="$RANGE_TOPIC"

For temperature and humidity: 

# Select the actual standard environmental outputs.
TEMP_TOPIC='PASTE_FULL_TEMPERATURE_TOPIC_HERE'
HUM_TOPIC='PASTE_FULL_HUMIDITY_TOPIC_HERE'
# Inspect temperature in Celsius and humidity displayed as percent RH.
ros2 run axiom_debug_tools axiom_env_monitor --ros-args \
  -p temp_topic:="$TEMP_TOPIC" -p hum_topic:="$HUM_TOPIC"

For another supported ROS message type: 

# Copy an actual full topic and its message type from discovery.
SENSOR_TOPIC='PASTE_FULL_SENSOR_TOPIC_HERE'
SENSOR_TYPE='PASTE_ROS_MESSAGE_TYPE_HERE'
# Print a generic JSON view and approximate received rate.
ros2 run axiom_debug_tools axiom_topic_sniff --ros-args \
  -p topic:="$SENSOR_TOPIC" -p type:="$SENSOR_TYPE"

Always pass the actual topics: monitor built-in defaults are example identities. IMU acceleration includes gravity and has no fused orientation. The gyro running average is a diagnostic, not an automatic calibration. Rates are observations of received messages and can vary with batching and host scheduling.

Plot without a browser

axiom_plotter uses Matplotlib and needs a graphical desktop on the ROS host. For a scalar range: 

# Select the actual scalar Range topic.
RANGE_TOPIC='PASTE_FULL_RANGE_TOPIC_HERE'
# Plot a rolling 60-second history using compatible best-effort sensor QoS.
ros2 run axiom_plotter dynamic_grapher \
  --topic-regex "^${RANGE_TOPIC}$" --sensor-qos \
  --qos-depth 200 --history-sec 60 --rate-hz 10

For an IMU component: 

# Select the actual IMU topic.
IMU_TOPIC='PASTE_FULL_IMU_TOPIC_HERE'
# Plot Z acceleration in m/s²; this includes the gravity component.
ros2 run axiom_plotter dynamic_grapher \
  --topic-regex "^${IMU_TOPIC}$" --field linear_acceleration.z --sensor-qos

The regex selects topics; –field selects a numeric message field. Use –sensor-qos for the driver's default best-effort measurement publishers. Display refresh is independent of sensor sampling and firmware packet delivery. History uses message stamps when available and receipt time otherwise; it does not synchronise board clocks. A launcher is also available as ros2 launch axiom_plotter plot_dynamic.launch.py, but its default /axiom/ filter must match your namespace. See the plotter options for other filters and limits.

For reusable browser layouts, use Foxglove dashboards.

Driver diagnostics, rates and configuration

# Select the full board namespace from the discovery inventory.
BOARD_NS='PASTE_DISCOVERED_BOARD_NAMESPACE_HERE'
# Inspect connection, freshness, queue loss and decode/command diagnostics.
ros2 topic echo "$BOARD_NS/diagnostics" diagnostic_msgs/msg/DiagnosticArray --once
# List startup settings; the driver parameters are read-only at runtime.
ros2 param list "$BOARD_NS/axiom_bridge_node"
# Read the configured measurement publisher reliability.
ros2 param get "$BOARD_NS/axiom_bridge_node" sensor_qos.reliability

Use services for runtime connection, acquisition and supported sample-rate changes. publish_data_subscription.rate_hz controls board delivery, not the sensor's output data rate. A FIFO can put several measurements in one packet, so ros2 topic hz can differ from packet frequency. Per-sensor configuration services such as commands/set_sample_rate only accept values advertised by that descriptor.

Measurement QoS defaults to best effort, depth 10. sensor_qos.overrides keys are exact relative topic paths; aliases use their own override or the default. A reliable subscriber cannot receive from a best-effort publisher. Command-topic inputs have their own reliable, volatile contract, explained in output topics.

Frame IDs identify coordinate frames; they do not rotate measurements or supply mounting transforms. Supply real mounting transforms through your robot URDF or measured TF configuration. IMU orientation is unavailable. Measurement stamps are estimated from device/poll timing; FIFO reconstruction and DeviceSample.time_quality help identify discontinuities but do not provide hardware clock synchronisation.

Record and replay measurements

rosbag2 records ROS topics and can replay them to the same consumers. A short IMU example, with the live driver acquiring: 

# Choose the actual measured IMU topic, not a command input.
IMU_TOPIC='PASTE_FULL_IMU_TOPIC_HERE'
# Choose a new writable output directory; this name must not already exist.
BAG_DIR="$HOME/axiom-imu-demo-$(date +%Y%m%d-%H%M%S)"
# Record until Ctrl+C, then wait for the recorder to finish writing.
ros2 bag record -o "$BAG_DIR" "$IMU_TOPIC"

After stopping the recorder: 

# Confirm the saved topic and nonzero message count.
ros2 bag info "$BAG_DIR"

Stop the live publisher or its acquisition before replaying on the same topic, so consumers receive one input source. Keep the viewer or processing subscriber available in the same ROS domain: 

# Replay the saved messages once at their recorded speed.
ros2 bag play "$BAG_DIR" --rate 1.0

Record sample when decoded values, validity and timing quality are needed. Include device_metadata, devices, raw/devjson, diagnostics and relevant TF topics when a recording must retain its decoder/profile and frame context. Late-joining recordings of retained metadata require suitable transient-local rosbag QoS overrides. Raw packets alone do not contain the decoder descriptor. Consult the driver recording contract and ROS recording QoS guide for that fuller setup.

For a managed recording/replay demonstration with shake detection and an independent robot face, use the movement teaching demo. Stop monitors/plots with Ctrl+C when finished; that alone does not stop the driver's acquisition.

Run software checks after an update

After a successful rebuild, the core tests can run without physical devices. Use an unused test domain, illustrated by 87, and omit the local board file for that command: 

# Run the core workspace tests using their simulated peers.
env -u AXIOM_ROS_BOARDS_FILE ROS_DOMAIN_ID=87 \
  colcon test --base-paths src --event-handlers console_direct+ \
  --return-code-on-test-failure
# Inspect failures and skips after the run.
colcon test-result --verbose

The environment override applies only to the test command. Software tests complement checking your own sensors and outputs; they do not establish physical calibration or actuator alignment. Continue with the ROS overview.

Task Runner