ROS 2 Lyrical Luth · Lesson 82 of 86

Building a manipulator stack

Project: arm description, ros2_control, trajectory controller and motion planning.

Estimated time · 120–180 min

Learning goals

What you will understand

Explain building a manipulator stack in your own words
Use it in a small robotics example
Verify the result instead of assuming it worked

Understand the idea first

The mental model

A manipulator stack has a URDF with joint limits and inertia, a ros2_control hardware interface (or a mock), joint_state_broadcaster and a joint_trajectory_controller, and a motion planner such as MoveIt 2 that finds collision-free trajectories. MoveIt needs the robot description, a semantic description (SRDF) with planning groups, and kinematics settings.

Bring it up in steps: the model in RViz2, the mock hardware and controllers, then MoveIt planning with the interactive marker, and finally a C++ program that plans to a pose and executes it. Test with the simulated arm before hardware, always with velocity scaling at 10–20% first.

Guided lesson

Work through these steps

1.
Source the ROS 2 Lyrical environment in a fresh terminal.
2.
Read the building a manipulator stack example and identify what each line does.
3.
Build only the affected package, source the workspace overlay, and run the example.
4.
Inspect the result from a second terminal with the ros2 CLI or RViz2 and compare it with the expected result.

Worked example

Read it before you run it

ros2 launch arm_bringup arm.launch.py use_mock:=true
# Start the arm with mock hardware and controllers.
ros2 control list_controllers
# Confirm joint_state_broadcaster and arm_controller are active.
ros2 launch arm_moveit_config move_group.launch.py
# Start MoveIt's planning node.
ros2 action list | grep -E 'move_action|follow_joint_trajectory'
# Check the planning and execution actions exist.
ros2 run arm_examples plan_to_pose
# Run a program that plans and executes to a target pose.

What the example is doing

1.The ros2 commands query the running graph; they do not prove that a node's internal behavior is correct.
2.Build from the workspace root, then source install/setup.bash so the shell can discover the new package.
3.Use a second sourced terminal to inspect nodes and interfaces while the example runs.

Watch it run · Robot arm

See what this code does

The terminal types this lesson's practice solution and runs it. The scene shows the kind of robot behaviour that code drives. It plays by itself and loops.

Practice code

Now type it yourself

Copy the starter into your ROS 2 package, replace every TODO, then build with colcon build and run it from a sourced terminal.

# TODO: list the controllers of the controller manager to check they are active

Expected output

arm_controller and joint_state_broadcaster are active

Stuck? Show the full solution (try it yourself first)

ros2 control list_controllers

Expected result

How you know it worked

ROS_DISTRO is lyrical in every terminal used for the exercise.
The complete package from the exercise builds and the expected graph entity appears in a second terminal.

Practical exercise

Apply the lesson

Build a 3-joint arm with mock hardware, configure MoveIt, plan a motion around a box obstacle, and execute it with 20% velocity scaling. Record planning time and path length.

Before you continue

ROS_DISTRO reports lyrical in every terminal you used
The example builds and runs without errors
You checked the result with a ros2 command, RViz2 or a test, not just by reading the code

If something goes wrong

ros2 cannot find a package or executable.

Source /opt/ros/lyrical/setup.bash, build from the workspace root, then source install/setup.bash in that terminal.

Nodes run but cannot discover each other.

Confirm both terminals use Lyrical, the same ROS_DOMAIN_ID, and compatible network/discovery settings.