Lab: Prove What `/scan` Is Doing Without Overclaiming the Robot

Lab: Prove What /scan Is Doing Without Overclaiming the Robot

This lab continues the exact graph from Week 11.

You already know that /sensor_bridge publishes /scan and /motor_guard subscribes to it in the supplied graph. Now you will inspect the topic itself: type, endpoints, one LaserScan message, receiving rate, and QoS.

You will also create a deliberate QoS mismatch, preserve the failure, and then change only the inspection subscriber's reliability request to restore compatibility.

Your final artifact is a Topic Communication Evidence Dossier.

Choose your lane

Reader lane

Use the deterministic Week 12 terminal below.

xterm.js terminal simulation

Inspect a ROS 2 topic, message, rate, and QoS

Continue the Week 11 graph by inspecting /scan type, endpoints, one supplied LaserScan message, receiving-rate evidence, and a deliberate QoS reliability mismatch.

This is a controlled command simulator. It does not execute Java, ROS 2, shell commands, or network requests on your device.

Commands worth trying

• source /opt/ros/jazzy/setup.bash
• ros2 topic list -t
• ros2 topic info /scan
• ros2 topic info /scan --verbose
• ros2 interface show sensor_msgs/msg/LaserScan
• ros2 topic echo /scan --once
• ros2 topic hz /scan
• ros2 topic echo /scan --qos-reliability reliable --once
• ros2 topic echo /scan --qos-reliability best_effort --once

The endpoint profiles, LaserScan sample, rate record, and QoS failure are fixed lesson evidence. No DDS network, lidar, or physical robot is connected.

Local Jazzy lane

If you have a local ROS 2 Jazzy system with a topic you are authorized to inspect, you may use local evidence instead.

Your names, types, rates, and QoS profiles may differ from the Robotnix case. Label them local ROS 2 evidence and do not force your local system to match the reader-lane architecture.

Guided example: a topic name is only the beginning

Suppose:

ros2 topic list -t

shows:

/scan [sensor_msgs/msg/LaserScan]

What do you know?

You know /scan is visible in the inspected graph and is associated with the sensor_msgs/msg/LaserScan type.

What do you not know yet?

You do not know:

• how many publishers exist;
• how many subscriptions exist;
• which nodes own the endpoints;
• whether their QoS policies are compatible;
• whether any message is currently being received;
• whether the stream rate matches the requirement;
• whether the values come from physical hardware.

The rest of the lab collects those layers one by one.

Part 1: Verify the topic identity

Source Jazzy in the reader lane:

source /opt/ros/jazzy/setup.bash

Then run:

ros2 topic list -t
ros2 topic type /scan

Record:

topic: /scan
type: sensor_msgs/msg/LaserScan

Do not copy only the topic name. The type is part of the communication contract.

Part 2: Record endpoint counts

Run:

ros2 topic info /scan

Reader-lane result:

Type: sensor_msgs/msg/LaserScan
Publisher count: 1
Subscription count: 1

Add these values to your dossier.

Then write one sentence explaining why endpoint counts are not message counts.

Part 3: Identify endpoint owners and QoS

Run:

ros2 topic info /scan --verbose

Record the publisher endpoint:

node: /sensor_bridge
endpoint: publisher
reliability: BEST_EFFORT
durability: VOLATILE
history: KEEP_LAST
depth: 5

Record the subscription endpoint:

node: /motor_guard
endpoint: subscription
reliability: BEST_EFFORT
durability: VOLATILE
history: KEEP_LAST
depth: 5

Explain why these profiles are compatible in the supplied case.

Part 4: Read the LaserScan contract

Run:

ros2 interface show sensor_msgs/msg/LaserScan

In your dossier, define the role of:

• header;
• angle_min;
• angle_increment;
• scan_time;
• range_min;
• range_max;
• ranges;
• intensities.

Do not paste the field list without explanation.

Part 5: Inspect one message

Run:

ros2 topic echo /scan --once

Record at least:

frame_id
scan_time
range_min
range_max
ranges

For the reader lane, calculate:

• number of range entries;
• minimum range value;
• index of the minimum;
• approximate angle of that index using angle_min + index × angle_increment.

The supplied array is:

[1.20, 0.82, 0.48, 0.73, 1.40]

Do not describe the minimum as a real obstacle distance. Label it as a value in the supplied deterministic LaserScan message.

Part 6: Measure the supplied receiving rate

Run:

ros2 topic hz /scan

Reader-lane result:

average rate: 10.000
min: 0.099s max: 0.101s std dev: 0.0005s window: 10

Record the average rate and the observation-window size.

Then calculate the approximate average period:

period = 1 / frequency

For 10 Hz, the result is approximately:

0.10 s

Compare that with the supplied message's scan_time.

State that agreement is part of the supplied case and does not prove a permanent rate.

Part 7: Break the QoS compatibility on purpose

Keep the supplied best-effort publisher unchanged.

Request a reliable inspection subscription:

ros2 topic echo /scan \
  --qos-reliability reliable \
  --once

Record the incompatibility result.

Your dossier must identify:

publisher offer: BEST_EFFORT
subscriber request: RELIABLE
compatibility: no
incompatible policy: RELIABILITY

Do not call the publisher "bad." It is offering the profile defined for this sensor-data case.

Part 8: Repair only the inspection subscriber

Now run:

ros2 topic echo /scan \
  --qos-reliability best_effort \
  --once

The supplied message becomes available again.

Record exactly what changed:

subscription reliability request changed from RELIABLE to BEST_EFFORT

and what did not change:

topic name unchanged
message type unchanged
publisher QoS unchanged

That is a clean communication repair.

Part 9: Build a layered evidence table

Create this structure in your dossier:

Add a final row of your own for a hardware claim the topic evidence cannot establish.

Part 10: Compare with Week 9 Java evidence without merging runtimes

Your Week 9 Java test may have shown:

ObstacleGuard strict 0.50 m boundary test: PASSED

The Week 12 supplied scan contains a minimum value:

0.48 m

Do not write:

The Java guard processed the ROS scan and stopped the robot.

No Java-to-ROS integration path has been demonstrated.

Instead write two separate facts and name the missing integration evidence.

Part 11: Write the final Topic Communication Evidence Dossier

Your artifact must contain:

Topic identity

• /scan;
• sensor_msgs/msg/LaserScan.

Endpoint inventory

• publisher count;
• subscription count;
• publisher node;
• subscriber node.

QoS profiles

• reliability;
• durability;
• history;
• depth for both endpoints.

Message contract

Explain the key LaserScan fields in your own words.

One message

Annotate the supplied message and calculate the minimum range/index/angle.

Stream evidence

Record the supplied receiving rate and observation window.

Deliberate QoS failure

Preserve the reliable-subscriber incompatibility.

QoS repair

Preserve the best-effort subscriber result and state exactly what changed.

Evidence boundary

Name at least five facts the dossier does not establish, including:

• physical lidar accuracy;
• Java/WPILib consumption of /scan;
• /motor_guard algorithm correctness;
• /cmd_vel contents;
• motor or wheel response.

Success criteria

Your dossier is complete when another student can answer:

• What is /scan's message type?
• Which nodes own the supplied endpoints?
• What QoS profile does each endpoint use?
• Why is the default supplied pair compatible?
• Why does a reliable inspection subscription fail against the supplied publisher?
• What fields make a LaserScan message interpretable?
• What did the one supplied message contain?
• What did the rate observation establish?
• What changed in the QoS repair?
• Which robot-behavior claims remain outside the evidence?

The goal is not to prove that /scan is healthy with one command. It is to build a communication case strong enough that each conclusion can be traced to the command that supports it.