Interactive markers for teleoperation in ROS - Step-by-Step Execution

Concept Flow - Interactive markers for teleoperation

Start ROS Node

↓

Create Interactive Marker Server

↓

Define Marker Pose & Controls

↓

Insert Marker into Server

↓

Apply Changes to Server

↓

User Moves Marker in RViz

↓

Callback Triggered

↓

Update Robot Command Based on Marker

↓

Send Command to Robot

↓

Loop: Wait for Next User Interaction

The flow shows how a ROS node creates an interactive marker, listens for user moves, and sends commands to the robot accordingly.

Execution Sample

ROS

server = InteractiveMarkerServer("teleop_marker")
marker = InteractiveMarker()
marker.name = "move_marker"
server.insert(marker, feedback_cb)
server.applyChanges()

This code creates an interactive marker server, inserts a marker named 'move_marker', and sets a callback for user interaction.

Execution Table

Step	Action	Marker State	Callback Triggered	Robot Command Sent
1	Start ROS node and create server	No markers	No	No
2	Define marker pose and controls	Marker defined but not inserted	No	No
3	Insert marker into server	Marker 'move_marker' inserted	No	No
4	Apply changes to server	Marker visible in RViz	No	No
5	User moves marker in RViz	Marker pose updated	Yes	No
6	Callback processes feedback	Marker pose updated	Yes	Robot command calculated
7	Send command to robot	Marker pose updated	Yes	Command sent
8	Wait for next interaction	Marker pose stable	No	No

💡 Execution waits continuously for user interaction to update marker and send commands.

Variable Tracker

Variable	Start	After Step 3	After Step 5	After Step 7	Final
server	None	InteractiveMarkerServer instance	InteractiveMarkerServer instance	InteractiveMarkerServer instance	InteractiveMarkerServer instance
marker	Empty	Marker with name 'move_marker'	Marker pose updated by user	Marker pose updated by user	Marker pose updated by user
robot_command	None	None	None	Calculated from marker pose	Last sent command

Key Moments - 3 Insights

Why doesn't the robot command send immediately after inserting the marker?

Because the robot command is sent only after the user moves the marker and the callback processes the feedback, as shown in steps 5-7 of the execution_table.

What triggers the callback function in this flow?

The callback is triggered when the user moves the marker in RViz, updating its pose, as shown in step 5 of the execution_table.

Does the marker pose change automatically without user interaction?

No, the marker pose changes only when the user moves it in RViz, triggering the callback to update commands, as shown between steps 4 and 5.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the marker first visible in RViz?

A Step 3

B Step 5

C Step 4

D Step 2

💡 Hint

Check the 'Marker State' column for when the marker becomes visible.

According to variable_tracker, what is the state of 'robot_command' after step 5?

A Calculated from marker pose

B None

C Last sent command

D InteractiveMarkerServer instance

💡 Hint

Look at the 'robot_command' row and the column 'After Step 5'.

If the user never moves the marker, which steps in execution_table will never occur?

A Steps 5, 6, and 7

B Steps 1, 2, and 3

C Step 4 only

D All steps occur regardless

💡 Hint

User movement triggers callback and command sending in steps 5-7.

Concept Snapshot

Interactive markers let users move a marker in RViz.
A ROS node creates a marker server and inserts markers.
User moves trigger callbacks to update robot commands.
Commands are sent only after user interaction.
This enables teleoperation by moving markers visually.

Full Transcript

This visual execution trace shows how interactive markers work for teleoperation in ROS. First, a ROS node starts and creates an interactive marker server. Then, a marker named 'move_marker' is defined and inserted into the server. The marker becomes visible in RViz after applying changes. When the user moves the marker in RViz, a callback triggers to process the new pose. The callback calculates a robot command based on the marker's updated position and sends it to the robot. The system then waits for the next user interaction. Variables like the server instance, marker pose, and robot command update step-by-step as the process runs. Key moments clarify that commands only send after user moves and callbacks trigger only on interaction. The quiz questions help reinforce understanding of when markers appear, when commands are sent, and what triggers callbacks.

Practice

1. What is the main purpose of interactive markers in ROS teleoperation?

easy

A. To visually control robots by moving markers in 3D space

B. To write robot control code without any user input

C. To display static images of the robot status

D. To log robot sensor data for offline analysis

Solution

1. Step 1: Understand interactive markers role

   Interactive markers allow users to move and rotate markers in a 3D view to control robots easily.

2. Step 2: Compare options with purpose

   Only To visually control robots by moving markers in 3D space describes visual control via markers; others describe unrelated tasks.

3. Final Answer:

   To visually control robots by moving markers in 3D space -> Option A

4. Quick Check:

   Interactive markers = Visual robot control [OK]

Hint: Interactive markers let you move robot parts visually [OK]

Common Mistakes:

• Thinking markers are only for displaying data
• Confusing teleoperation with offline logging
• Assuming no user input is needed

2. Which ROS message type is commonly used to create an interactive marker for teleoperation?

easy

A. std_msgs/String

B. sensor_msgs/Image

C. geometry_msgs/Twist

D. visualization_msgs/InteractiveMarker

Solution

1. Step 1: Identify message type for interactive markers

   The message type visualization_msgs/InteractiveMarker is designed to define interactive markers in ROS.

2. Step 2: Eliminate unrelated message types

   sensor_msgs/Image is for images, geometry_msgs/Twist for velocity commands, std_msgs/String for text messages, so they don't create interactive markers.

3. Final Answer:

   visualization_msgs/InteractiveMarker -> Option D

4. Quick Check:

   Interactive marker message = visualization_msgs/InteractiveMarker [OK]

Hint: Interactive markers use visualization_msgs/InteractiveMarker type [OK]

Common Mistakes:

• Choosing geometry_msgs/Twist which is for velocity commands
• Confusing image or string messages with markers
• Not knowing ROS message types

3. Given this snippet handling interactive marker feedback in ROS:

void processFeedback(const visualization_msgs::InteractiveMarkerFeedbackConstPtr &feedback) {
  if (feedback->event_type == visualization_msgs::InteractiveMarkerFeedback::POSE_UPDATE) {
    geometry_msgs::Pose new_pose = feedback->pose;
    // Update robot command with new_pose
  }
}

What happens when the user moves the marker?

medium

A. The robot command updates with the marker's new pose

B. The marker resets to its original position

C. The feedback event_type is ignored

D. The robot stops moving immediately

Solution

1. Step 1: Analyze feedback event type

   The code checks if the event_type is POSE_UPDATE, which means the marker was moved or rotated.

2. Step 2: Understand the effect of POSE_UPDATE

   When POSE_UPDATE occurs, the new pose is extracted and used to update the robot command, so the robot moves accordingly.

3. Final Answer:

   The robot command updates with the marker's new pose -> Option A

4. Quick Check:

   POSE_UPDATE triggers robot command update [OK]

Hint: POSE_UPDATE means marker moved, update robot pose [OK]

Common Mistakes:

• Assuming marker resets automatically
• Ignoring the event_type check
• Thinking robot stops without command

4. You wrote this callback for interactive marker feedback but the robot does not move:

void feedbackCallback(const visualization_msgs::InteractiveMarkerFeedbackConstPtr &feedback) {
  if (feedback->event_type = visualization_msgs::InteractiveMarkerFeedback::POSE_UPDATE) {
    // update robot command
  }
}

What is the error?

medium

A. Missing return statement in the callback

B. Using assignment '=' instead of comparison '==' in the if condition

C. Incorrect message type for feedback parameter

D. Not publishing the updated robot command

Solution

1. Step 1: Check the if condition syntax

   The condition uses '=' which assigns a value instead of '==' which compares values.

2. Step 2: Understand effect of assignment in if

   Assignment always returns true, so the condition is always true but does not properly check event_type, causing logic errors.

3. Final Answer:

   Using assignment '=' instead of comparison '==' in the if condition -> Option B

4. Quick Check:

   Use '==' to compare event_type, not '=' [OK]

Hint: Use '==' to compare, '=' assigns value [OK]

Common Mistakes:

• Confusing '=' and '==' in conditions
• Assuming missing return causes no movement
• Ignoring need to publish commands

5. You want to create an interactive marker that allows the user to rotate a robot arm joint only around the Z axis. Which control type and orientation should you use in your marker setup?

hard

A. Use a BUTTON control with no orientation

B. Use a MOVE_PLANE control with orientation aligned to the X axis

C. Use a ROTATE_AXIS control with orientation set to align Z axis with the joint axis

D. Use a MOVE_AXIS control aligned to the Y axis

Solution

1. Step 1: Identify control type for rotation

   ROTATE_AXIS control allows rotation around a single axis, suitable for rotating a joint.

2. Step 2: Set orientation to align with joint axis

   To rotate around Z axis, set the control's orientation so its Z axis matches the joint's rotation axis.

3. Final Answer:

   Use a ROTATE_AXIS control with orientation set to align Z axis with the joint axis -> Option C

4. Quick Check:

   ROTATE_AXIS + Z orientation = rotate joint around Z [OK]

Hint: ROTATE_AXIS control with Z orientation rotates joint around Z [OK]

Common Mistakes:

• Using MOVE_PLANE which moves in a plane, not rotate
• Choosing BUTTON which is for clicks, not rotation
• Aligning control to wrong axis