RobotnixAcademy

Unit 13 · lab

Lab: Choose and Verify the Right ROS 2 Interaction Model

This lab closes Unit 6 by putting topics, services, actions, and parameters side by side.

You will not build four separate toy exercises. You will inspect one example of each interaction model, record the evidence it produces, deliberately trigger two failure cases, and then justify which ROS primitive best fits four robot requirements.

Your final artifact is a ROS Interaction Selection Record.

Choose your lane

Reader lane

Use the deterministic Week 13 terminal.

The service response, Fibonacci action, and parameter state are fixed lesson evidence. They do not execute DDS calls, change a real ROS node, or control hardware.

Local Jazzy lane

If you have a local ROS 2 Jazzy environment with services, actions, or parameters you are authorized to inspect, you may use local evidence instead.

Your local names and interfaces will differ. Label them local ROS 2 evidence and preserve the same reasoning structure.

Guided example: classify the requirement before touching the CLI

Requirement:

The motor guard continuously publishes its current warning state so dashboards and recorders can observe changes.

Candidate models:

topic
service
action
parameter

A topic fits best because the data is an asynchronous changing state that may have multiple consumers.

A service would require every consumer to poll.

An action adds unnecessary goal lifecycle.

A parameter would turn telemetry into configuration.

The important step happened before the command line: the requirement identified the interaction semantics.

Use that same reasoning throughout the lab.

Part 1: Establish the service contract

Source Jazzy:

source /opt/ros/jazzy/setup.bash

Then run:

ros2 service list -t
ros2 service type /motor_guard/reset_fault
ros2 interface show std_srvs/srv/Trigger

Record:

service: /motor_guard/reset_fault
type: std_srvs/srv/Trigger
request fields: none
response fields: bool success, string message

Explain why Trigger fits an operation that needs no request data but returns a success status and message.

Part 2: Call the service

Run:

ros2 service call \
  /motor_guard/reset_fault \
  std_srvs/srv/Trigger \
  '{}'

Record the deterministic response:

success=True
message='deterministic fault latch cleared'

Write the strongest supported conclusion.

Then write one claim the response does not establish about physical hardware.

Part 3: Preserve a missing-service failure

Try the deliberately unavailable name:

ros2 service call \
  /motor_guard/emergency_stop \
  std_srvs/srv/Trigger \
  '{}'

Preserve the failure exactly.

Do not write:

The emergency stop is broken.

Write:

/motor_guard/emergency_stop was not available in the deterministic Week 13 service graph.

Then list two possible explanations a real system would require you to investigate before diagnosing a failure.

Part 4: Inspect the action contract

Run:

ros2 action list -t
ros2 action info /fibonacci
ros2 interface show \
  example_interfaces/action/Fibonacci

Record:

action: /fibonacci
type: example_interfaces/action/Fibonacci
goal field: int32 order
result field: int32[] sequence
feedback field: int32[] partial_sequence

State explicitly that this is a generic standard action mechanism example, not a robot-motion API.

Part 5: Send a goal and preserve the lifecycle

Run:

ros2 action send_goal \
  /fibonacci \
  example_interfaces/action/Fibonacci \
  '{order: 5}' \
  --feedback

Your record must preserve these stages separately:

Goal acceptance

Record the accepted goal evidence.

Feedback

Record at least two partial_sequence updates.

Final status

Record:

SUCCEEDED

Result

Record:

[0, 1, 1, 2, 3]

Then explain why goal acceptance is not the same event as goal success.

Part 6: Translate the action mechanics into a robot requirement

Requirement:

Dock the robot. The operation may take up to one minute. Show progress and allow the operator to abort.

Do not claim /fibonacci can dock a robot.

Instead, explain why the action interaction model fits this requirement:

  • goal;
  • progress feedback;
  • long-running execution;
  • cancellation;
  • final result.

Name one physical-safety question that a docking action implementation would still need to answer beyond the ROS protocol.

Part 7: Inspect the parameter contract

Run:

ros2 param list /motor_guard
ros2 param describe \
  /motor_guard \
  caution_distance_m
ros2 param get \
  /motor_guard \
  caution_distance_m

Record:

parameter: caution_distance_m
type: double
description: movement caution distance in meters
constraint: 0.10..5.00 m in the deterministic node
initial value: 0.5

Label this configuration evidence.

Part 8: Change the parameter and verify the result

Run:

ros2 param set \
  /motor_guard \
  caution_distance_m \
  0.75

Then:

ros2 param get \
  /motor_guard \
  caution_distance_m

Record all three pieces:

before: 0.5
set response: successful
after: 0.75

Explain why the second get matters.

A set response tells you the request was accepted. Reading the parameter again verifies the node's reported configuration state.

Part 9: Trigger a rejected parameter update

Run:

ros2 param set \
  /motor_guard \
  caution_distance_m \
  -1.0

Preserve the rejection.

Then run:

ros2 param get \
  /motor_guard \
  caution_distance_m

The value should remain:

0.75

Your evidence record should show that the invalid request did not replace the last accepted configuration state.

Connect this reasoning to the Java validation work from Unit 4.

Part 10: Bring the Week 12 topic evidence back into the comparison

Use your Topic Communication Evidence Dossier for:

/scan
sensor_msgs/msg/LaserScan
BEST_EFFORT QoS
approximately 10 Hz supplied receiving rate

Do not rerun the entire Week 12 lab.

Use the record as the topic example in your final interaction comparison.

Part 11: Build the four-way comparison

Create a table with these rows:

/scan
/motor_guard/reset_fault
/fibonacci
/motor_guard caution_distance_m

and these columns:

  • interaction model;
  • who initiates;
  • data/lifecycle shape;
  • CLI evidence used;
  • one failure state;
  • one claim still outside the ROS evidence.

Your explanations should make the differences visible without relying only on the words topic/service/action/parameter.

Part 12: Design four robot interactions

For each requirement, choose the best ROS model and defend it.

A. Front lidar telemetry

Publish scans continuously for obstacle processing and visualization.

B. Clear one software fault latch

One request, one fast success/message response.

C. Dock the robot

Long-running goal, progress, cancellation, final result.

D. Configure caution distance

Node-owned double value that may be changed within an allowed range.

For each design, include:

  • selected model;
  • one rejected alternative;
  • one runtime evidence command;
  • one failure state;
  • one hardware or Java/WPILib claim not established by that ROS evidence.

Part 13: Red-team one bad architecture

A teammate proposes:

Use parameters for scans, a service for docking, and an action to read the caution distance because actions are more powerful.

Repair all three decisions.

Your explanation must use interaction semantics, not style preferences.

Final ROS Interaction Selection Record

Your artifact must contain:

Service evidence

  • name/type/interface;
  • successful Trigger response;
  • missing-service failure;
  • evidence boundary.

Action evidence

  • name/type/interface;
  • accepted goal;
  • feedback;
  • final status/result;
  • robot-task transfer explanation.

Parameter evidence

  • list/description;
  • 0.5 → 0.75 accepted change;
  • -1.0 rejected change;
  • verified final state;
  • behavior boundary.

Topic evidence reference

Summarize the Week 12 /scan evidence without pretending it was produced by the Week 13 service/action/parameter terminal.

Interaction design matrix

Defend the model selected for the four robot requirements.

Rejected alternatives

For at least two requirements, explain why another ROS model would produce worse semantics.

Success criteria

Your record is complete when another student can answer:

  • Why is /scan a topic instead of a service?
  • What does the Trigger service response actually prove?
  • Why does docking fit an action better than a service?
  • What is the difference between action goal acceptance, feedback, and final result?
  • Why is caution_distance_m configuration rather than telemetry?
  • What happened after the valid and invalid parameter set requests?
  • Which interactions were real robot-domain examples and which action was only a generic mechanism demonstration?
  • Which physical or Java/WPILib claims remain outside the ROS runtime evidence?

The goal is to leave Unit 6 able to look at a robot requirement and choose a ROS interaction model for a reason, not because one command happened to be easier to remember.