Robot arm motion planning in ROS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output of this ROS node controlling a robot arm?

Consider a ROS node that publishes joint angles to move a robot arm to a predefined pose. What will be the final joint state published?

ROS

import rospy
from sensor_msgs.msg import JointState

def publish_joint_state():
    rospy.init_node('arm_mover')
    pub = rospy.Publisher('/joint_states', JointState, queue_size=10)
    rate = rospy.Rate(10)
    joint_state = JointState()
    joint_state.name = ['joint1', 'joint2', 'joint3']
    joint_state.position = [0.5, 1.0, -0.5]
    for _ in range(5):
        joint_state.header.stamp = rospy.Time.now()
        pub.publish(joint_state)
        rate.sleep()

if __name__ == '__main__':
    publish_joint_state()

A The node publishes joint states with positions [0.5, 1.0, -0.5] five times at 10 Hz.

B The node publishes joint states with positions [0.0, 0.0, 0.0] once and then stops.

C The node throws a runtime error because the publisher is not initialized properly.

D The node publishes joint states with positions [0.5, 1.0, -0.5] only once and then exits.

💡 Hint

Look at the loop and the rate at which publishing happens.

The code initializes a ROS node and publishes the joint state with the specified positions five times at 10 Hz before exiting.

📝 Syntax

intermediate

Which option correctly initializes a MoveIt! MoveGroupInterface for a robot arm?

You want to control a robot arm using MoveIt! in ROS. Which code snippet correctly initializes the MoveGroupInterface in Python?

A move_group = moveit_commander.MoveGroup('arm')

B move_group = MoveGroupInterface('arm')

C move_group = moveit_commander.MoveGroupCommander('arm')

D move_group = moveit_commander.MoveGroupCommander()

💡 Hint

Check the exact class name and required argument for MoveGroupCommander.

The correct class is MoveGroupCommander and it requires the group name as a string argument.

🔧 Debug

advanced

Why does this ROS motion planning script fail to move the robot arm?

This script sets a target pose but the robot arm does not move. What is the likely cause?

ROS

import moveit_commander
import rospy
from geometry_msgs.msg import Pose

rospy.init_node('move_arm')
move_group = moveit_commander.MoveGroupCommander('arm')
pose_target = Pose()
pose_target.position.x = 0.4
pose_target.position.y = 0.1
pose_target.position.z = 0.4
pose_target.orientation.w = 1.0
move_group.set_pose_target(pose_target)
move_group.go()

A The move_group.go() method is called without wait=True, so the motion is asynchronous and not executed.

B The script does not call move_group.stop() after move_group.go(), causing the arm to not execute the plan.

C The node is not spinning, so callbacks are not processed and the arm does not move.

D The pose_target is missing orientation x, y, z values, causing an incomplete pose.

💡 Hint

Check if the pose target is fully defined for orientation.

The orientation quaternion must have all components set; missing x, y, z defaults to zero but should be explicitly set for clarity.

❓ state_output

advanced

What is the final joint state after executing this MoveIt! plan?

Given this code snippet that plans and executes a motion, what will be the final joint positions?

ROS

import moveit_commander
import rospy

rospy.init_node('move_arm')
move_group = moveit_commander.MoveGroupCommander('arm')
joint_goal = move_group.get_current_joint_values()
joint_goal[0] += 0.5
move_group.go(joint_goal, wait=True)
move_group.stop()
final_joints = move_group.get_current_joint_values()

A final_joints remain unchanged because move_group.go() was called without wait=True.

B final_joints[0] is approximately original + 0.5, others unchanged.

C final_joints are all zeros because the plan resets joints.

D final_joints contain random values due to missing synchronization.

💡 Hint

The code modifies only the first joint and waits for execution.

The first joint is incremented by 0.5 and the motion is executed synchronously, so final joints reflect this change.

🧠 Conceptual

expert

Which factor most affects the success of robot arm motion planning in cluttered environments?

When planning robot arm motions in a cluttered workspace, which factor is most critical to ensure a collision-free path?

A The accuracy and update rate of the robot's environment perception and obstacle representation.

B The number of joints the robot arm has.

C The speed at which the robot arm moves during execution.

D The color of the robot arm in the visualization tool.

💡 Hint

Think about what helps the planner avoid obstacles effectively.

Accurate and timely perception of obstacles allows the planner to generate safe paths avoiding collisions.

Practice

1. What is the main purpose of robot arm motion planning in ROS?

easy

A. To control the robot's camera settings

B. To calculate safe and smooth paths for the robot arm to move

C. To manage network communication between robots

D. To store sensor data from the robot arm

Solution

1. Step 1: Understand the role of motion planning

   Motion planning calculates paths that avoid obstacles and ensure smooth movement.

2. Step 2: Identify the correct purpose among options

   Only To calculate safe and smooth paths for the robot arm to move describes calculating safe and smooth paths for the robot arm.

3. Final Answer:

   To calculate safe and smooth paths for the robot arm to move -> Option B

4. Quick Check:

   Motion planning = safe, smooth paths [OK]

Hint: Motion planning means planning safe arm movements [OK]

Common Mistakes:

• Confusing motion planning with sensor data handling
• Thinking motion planning controls cameras
• Mixing motion planning with network communication

2. Which of the following is the correct way to create a MoveGroupInterface object for a robot arm named "manipulator" in ROS C++?

easy

A. MoveGroupInterface move_group("robot_arm");

B. MoveGroupInterface move_group = new MoveGroupInterface("manipulator");

C. move_group = MoveGroupInterface("manipulator");

D. moveit::planning_interface::MoveGroupInterface move_group("manipulator");

Solution

1. Step 1: Recall correct MoveGroupInterface syntax

   In ROS C++, the MoveGroupInterface is created with the namespace and constructor: moveit::planning_interface::MoveGroupInterface move_group("group_name");

2. Step 2: Check each option for syntax and group name

   moveit::planning_interface::MoveGroupInterface move_group("manipulator"); uses correct syntax and the correct group name "manipulator". MoveGroupInterface move_group = new MoveGroupInterface("manipulator"); uses incorrect new keyword and assignment. move_group = MoveGroupInterface("manipulator"); lacks type declaration. MoveGroupInterface move_group("robot_arm"); uses wrong group name.

3. Final Answer:

   moveit::planning_interface::MoveGroupInterface move_group("manipulator"); -> Option D

4. Quick Check:

   Correct constructor syntax = moveit::planning_interface::MoveGroupInterface move_group("manipulator"); [OK]

Hint: Use full type and constructor with group name in quotes [OK]

Common Mistakes:

• Using 'new' keyword incorrectly in C++
• Omitting type declaration
• Using wrong group name string

3. Given the following ROS C++ code snippet, what will be the output if planning succeeds?

moveit::planning_interface::MoveGroupInterface move_group("manipulator");
auto success = (move_group.plan(plan) == moveit::planning_interface::MoveItErrorCode::SUCCESS);
if (success) {
  std::cout << "Plan found!" << std::endl;
} else {
  std::cout << "Plan failed." << std::endl;
}

medium

A. Plan found!

B. Plan failed.

C. Compilation error

D. No output

Solution

1. Step 1: Understand the plan() return value check

   The plan() function returns a MoveItErrorCode. Comparing it to SUCCESS means success is true if planning worked.

2. Step 2: Analyze the if condition and output

   If success is true, the code prints "Plan found!"; otherwise, "Plan failed.". Since planning succeeds, output is "Plan found!".

3. Final Answer:

   Plan found! -> Option A

4. Quick Check:

   Plan success prints "Plan found!" [OK]

Hint: Success means plan() returns SUCCESS code [OK]

Common Mistakes:

• Confusing success condition logic
• Assuming plan() returns bool directly
• Ignoring MoveItErrorCode enum comparison

4. Identify the error in this ROS C++ code snippet for robot arm motion planning:

moveit::planning_interface::MoveGroupInterface move_group("manipulator");
move_group.setPoseTarget(target_pose);
move_group.plan(plan);
move_group.execute(plan);

medium

A. Missing check if plan was successful before execute

B. Incorrect method name: should be setTargetPose

C. execute() does not accept a plan argument

D. Missing initialization of MoveGroupInterface

Solution

1. Step 1: Review the planning and execution sequence

   The code sets a target, plans, then executes without checking if planning succeeded.

2. Step 2: Identify the missing safety check

   Best practice is to verify plan success before calling execute to avoid errors or unsafe moves.

3. Final Answer:

   Missing check if plan was successful before execute -> Option A

4. Quick Check:

   Always verify plan success before execute [OK]

Hint: Always check plan success before executing [OK]

Common Mistakes:

• Assuming plan always succeeds
• Confusing method names
• Ignoring return values from plan()

5. You want to plan a motion for a robot arm to reach a target pose but avoid a newly added obstacle in the environment. Which ROS framework feature should you use to update the planning scene before planning?

hard

A. Use RViz to manually move the robot arm

B. Directly modify the MoveGroupInterface target pose to avoid obstacle

C. Use PlanningSceneInterface to add the obstacle and update the scene

D. Restart the ROS node to reload the environment

Solution

1. Step 1: Understand how obstacles affect planning

   Obstacles must be added to the planning scene so the planner knows to avoid them.

2. Step 2: Identify the correct tool to update the planning scene

   PlanningSceneInterface allows adding/removing objects in the environment for planning awareness.

3. Step 3: Evaluate other options

   Modifying target pose doesn't update obstacles. Restarting node is inefficient. RViz manual moves don't affect planning scene programmatically.

4. Final Answer:

   Use PlanningSceneInterface to add the obstacle and update the scene -> Option C

5. Quick Check:

   Update planning scene with PlanningSceneInterface [OK]

Hint: Add obstacles via PlanningSceneInterface before planning [OK]

Common Mistakes:

• Trying to avoid obstacles by changing target pose only
• Restarting nodes unnecessarily
• Using RViz manual moves instead of programmatic updates