MoveIt Arm Software

Written by Meshva.

Motivation : to coordinate how the arm should move

• given a starting and target position, we should be able to create a plan of how the arm should move to follow that trajectory

• Thus, we need to plan how the arm should move and follow that plan. 

https://moveit.ros.org/documentation/concepts/ 

Move Group (ie. Planning group)

• Motion planning is in the context of some robot components

• We have to pass in an URDF of the arm to MoveIt

  • See uwrt_mars_rover_arm_urdf

  • Note: we should make our arm model more accurate by replacing all the files in meshes by the real CAD files (right now, we approximate the arm design with rectangles)

Motion Planning (ie. Planning Pipeline)

• There are different motion planners with different use cases. MoveIt can use a planner by passing it as a plugin, some common ones include:

  • OMPL planners (default) : is a library of different planners (more info)

    • It will eventually find a solution if it exists, but cannot confirm that a plan doesn’t exist. That is why we must specify a maximum planning time to try and find a solution before giving up.

    • It cannot avoid obstacles in the surroundings, but if a plan results in a collision, it will keep trying again

    • The default configuration is ompl_planning.yaml

  • CHOMP : first generates a naive plan and then adjusts it to avoid collisions in the surroundings

  • … and more!

• For now, we use OMPL, since we do not have a way of creating a planning scene of all the obstacles in our surroundings

• Motion Plan Request

  • Can specify a target pose in joint space or using cartesian coordinates (x, y, z, yaw, pitch, roll of the end effector)

• Motion Plan Result

  • Outputs a trajectory

    • Uses information about maximum acceleration/ velocities of each joint (joint_limits.yaml)

  • Is of type trajectory_msgs/JointTrajectory joint_trajectory, which specifies (for each joint) a series of waypoints

    • Each waypoint contains the acceleration, velocity, position, effort, and time from the start

Trajectory Following

• Specify the controllers that should be used to follow the trajectory in moveit_controllers.yaml 

• We must load and start a Joint Trajectory Controller, which will start a FollowJointTrajectory action server

  • MoveIt will send messages to this action server, which will allow it to communicate with the controller specified

Next Steps

• Right now, we follow the trajectory using RViz

  • We created an action server that uses what MoveIt exposes to create a motion plan and start executing it by publishing to the FollowJointTrajectory action server

  • Decided to use an action so that once the trajectory has started, we can still cancel it, for emergencies

  • We claim that we reached our destination once all of our joint positions are within some tolerance

  • We can launch this by using move_group.launch.py

• To use with the physical arm, create a new hardware interface

  • Specify the controllers you must use (moveit_controllers.yaml) & modify the launch file

  • The uwrt_mars_rover_arm_hw package already exists. Once we start integrating the proper motor controllers and protocols (such as CAN), we need to populate this hardware interface, similar to the drivetrain hardware interface.