UP | HOME

MoveWhat? Activity

Introduction

  1. MoveIt 2 is a massive package, with many features, but it is still under heavy development
  2. To make our robot move, without using C++, we will need to do some detective work
  3. This guide is designed as a tutorial to introduce you to MoveIt and prepare your group for Homework 3

Preliminaries

  1. You should install the nupanda workspace and the interbotix workspace
    • Each of these workspaces provides a different robot that you will be working with

First Steps

  1. You can use either the franka or the px100 in this example
    • Using both will provide some extra comparisons when something inevitably goes wrong, helping you to narrow down whether the problem is robot-specific or more broadly related to moveit
  2. To start the franka robot ros2 launch franka_moveit_config moveit.launch.py robot_ip:=dont-care use_fake_hardware:=true
    • This will start a franka MoveIt setup, with the MoveIt GUI in rviz
    • Rather than connecting to the actual robot or a simulation, a mock controller is used that takes joint positions as inputs and returns fake joint states as sensor data
    • The mock controller provided by Franka does not work, which is part of why you are using a fork created by me.
  3. To start the px100 robot use ros2 launch interbotix_xsarm_moveit xsarm_moveit.launch.py robot_model:=px100 hardware_type:=fake
    • If you installed the interbotix workspace at the beginning of the quarter you will need to update the interbotix_ros_manipulators repository and rebuild

Rviz2

  1. There are two new Rviz widgets (which show up in the left-pane) that have been added by the setup when you run these launch files
    • PlanningScene, which keeps track of obstacles in the environment
    • MotionPlanning, which is a gui interface to move the robot
      • This is initally unchecked, check it to enable it. This provides a graphical interface for moving the robot
  2. In ROS 2 Humble, there will be an interactive marker displayed near the robot's end-effector that you can drag to set the target location for the motion plan
    • In ROS 2 Iron, both for the franka and the px100 this marker does not appear
    • I have yet tracked down the cause of this bug
    • You can still move to pre-selected positions or use the Joint panel to directly manipulate the joints
    • We will not be using the graphical planning features much, once we can control everything programmatically

Motion Plan

  1. When you enable the MotionPlanning Widget you should see
    1. An orange overlay on the robot. This represents the planning group, the collection of joints (and there associated links) that are currently being controlled
      • In the MotionPlanning GUI, under the Planning Tab, you can change the planning group to, for example, control the gripper instead of the arm
      • While you can plan a path for the gripper, you cannot execute it successfully without the robot, as there is currently no fake gripper state
        • There are multiple control modes for the gripper, all through the gripper action server, some of which are not position control (and hence are not part of moveit)
    2. An interactive marker, which can be dragged to move the arm to various positions
      • This marker controls the goal state, which is the target location of the robot's end-effector
      • As you drag the robot around, some of the links may turn red, which indicates a (possibly self) collision or otherwise invalid state
      • Try it! [Or Not since it does not work in ROS 2 Iron].
    3. There are also pre-set positions that can be moved to
      • It is also possible to plan from a goal state that is not the current location of the robot by setting the Start State
    4. In the Planning Tab, press plan to generate a motion plan
      • You should see an animation of the arm moving from start to goal
      • Press Execute to run the plan, and watch the arm move (Try It!)
      • If you press Plan & Execute you will se the robot start to move, with the plan happening slightly ahead of robot motion (Try It!)
      • You can change the speed of the motion by selecting Velocity Scaling and Accel Scaling
        • On the real robot be very careful with these, the robot can move fast!
      • There are also many options that are available for motion planning that are accessible via the gui

Joints

  1. The Joints tab allows you to plan to a specific joint configuration rather than an end-effector configuration
  2. Notice that if you move the marker at the end-effector, the joint states move as well indicating that inverse kinematics is happening here!
    • In other words, planning to an end-effector position means computing inverse kinematics to find the corresponding joint positions

Planning Scene

  1. Under the Scene Objects tab, you can manipulate obstacles in the environment
    1. Click the plus sign next to the word box to add a box into the scene
      • Move it to somewhere where the robot can potentially hit it
    2. Click "publish" to set the box as part of the planning scene
    3. It is also possible to attach objects to the end-effector (e.g., so that collision detection accounts for a grabbed object)
  2. With the scene set, drag the end-effector into the box
    • What happens? (The links that collide should turn red)
    • What happens if you click plan? (The plan will fail)
    • Check "collision-aware IK" and move the end-effector into the box and hold it
      • You should see the IK solver try to keep moving the joints to avoid the collision
        • If the end-effector is colliding with the box, no IK solution can succeed at avoiding it
        • But it is possible if another link is hitting the box (maybe another arm orienation does not have that same collision)

How It Works

  1. The Moveit Documentation provides an overview, particularly the Move Group diagram.
  2. Comments in the moveit_msgs packages explain how to use the ROS API for the /move_group node.
  3. Take a look at the rqt_graph (be sure to refresh)
    • The key node for planning is the /move_group node
  4. Run ros2 node info /move_group to see it's ROS API
    • You can of course get info on these interface with the ros2 command line ros2 service/action/topic and ros2 interface
    • The key actions here, however, are
      • /move_action, which is used to plan the path
      • /execute_trajectory, which does exactly what it sounds like
    • The key service is /compute_ik which computes the inverse kinematics
  5. If you use ros2 interface on the types (which you should do) you can learn how these actions work a bit more

The Plan

  1. Let's use our working interface to the move-group node (that is, Rviz) to help us better understand how the ROS API for the /move_group node works
    • Make sure the MotionPlanning panel in Rviz is selected and activated
  2. To be as thorough as possible we would want to capture all the data that rviz sends to the move_group node
    • That is, all move_group service servers, action servers, and subscriptions that rviz2 connects to
    • We can find these by comparing ros2 node info /move_group to ros2 node info /rviz2
  3. Capturing actions and services is not as straightforward as subscribing
    • We can use a hack where, prior to launching any moveit nodes we run our own node that provides the same service or action
      • The exact behavior of having duplicate services and a
      • This node will now receive the requests, even after we run the moveit node
      • The downside of this approach is that the /move_group node (as the second node started) will not receive the requests
      • We could always use remapping to insert a shim node where the server just forwards the request to the move_group
  4. While the above is the most thorough, we already know that most of the "action" is in the /move_action action
    • So the plan will be:
      • Write a node that creates an action server on the /move_action
      • Run that node
      • Run the moveit code
      • Perform actions in rviz
      • Print out the action request
      • Your library can then use this information as a model
  5. Create a new workspace, and a new package (called intercept), and a new node called move_what.
    • Run move_what, then launch the franka moveit code.
    • Use move_what to intercept services and and actions you think are relevant for planning, and print out the data
      • Some actions to try are:
        • /move_action
        • /execute_trajectory
      • Some services to try are:
        • /compute_ik
    • The /planning_scene topic is what gets published to when something is added to the planning scene
  6. By doing this you will learn how the move_it rviz plugin uses the move_group
    • Try to discover what sequence of events happens to plan a motion and then execute it
    • Try to discover the difference between Plan, Execute, and Plan & Execute
    • Try to discover what features of the planning message are used and which are not
  7. The goal of this exploration is to be able to call an action manually that causes a path to be planned and executed

Author: Matthew Elwin