Introduction to Baxter and Sawyer

• Sawyer Wiki
• Baxter Wiki
• Baxter Hardware Specifications
• Sawyer Hardware Specifications

• The Baxter and Sawyer software is not released for noetic and in fact dates back to ROS indigo
• Some code, especially for baxter has to be patched to work.
  • Some code comes from forked repositories, with fixes to make it compile on Ubuntu 20.04 with noetic
  • The code is written in python 2. I have done my best to patch it to work with python3, however if you run into python issues let me know.
• We will create another workspace, similar to nuws but exclusively for the Baxter and Sawyer robots
  • You may wish to source this workspace from your .bashrc to have the packages accessible.

mkdir -p rethink_ws/src
cd rethink_ws/src
vcs import --input https://nu-msr.github.io/me495_site/rethink.rosinstall
cd ..
# Install dependencies, but ignore any errors
rosdep install --from-paths src --ignore-src -r -y 
catkin_make

1. You will connect to the robot via Ethernet. First, some one-time setup to install the profile

# Download the Network manager profile
curl -L https://nu-msr.github.io/me495_site/Rethink > /tmp/Rethink
sudo cp /tmp/Rethink /etc/NetworkManager/system-connections/Rethink
# Set the ownership and permissions
sudo chown root:root /etc/NetworkManager/system-connections/Rethink
sudo chmod 600 /etc/NetworkManager/system-connections/Rethink
# Reload network manager
sudo systemctl restart NetworkManager

# Append the IP address to your hosts file. This way you can resolve baxter.local and sawyer.local on your machine
echo "10.42.0.2 baxter.local" | sudo tee -a /etc/hosts
echo "10.42.0.2 sawyer.local" | sudo tee -a /etc/hosts

1. With the robot on and the ethernet cord plugged in, you can connect to the robot by doing
   • nmcli connection up Rethink
2. The IP address of the robot is 10.42.0.2 and your IP address is 10.42.0.1
   • You should be able to ping 10.42.0.2. If not, something is wrong.
   • You should also be able to ping sawyer.local and baxter.local
3. To have nodes on your computer connect to the remote rosmaster:
   • The ROS_MASTER_URI environment variable must be set to the robot's rosmaster uri: http://10.42.0.2:11311
     • This variable tells ROS nodes how to connect to rosmaster
   • The ROS_IP environment variable should be the ip address of your computer (10.42.0.1).
     • This variable tells rosmaster how to connect to your computer
   • The ROS_HOSTNAME environment variable should NOT be set unset ROS_HOSTNAME

   • Feel free to write a bash script that you can source to set these environment variables appropriately

     export ROS_MASTER_URI=http://10.42.0.2:11311
     export ROS_IP=10.42.0.1
     unset ROS_HOSTNAME
     

   • If you read Rethink's instructions, they provide a script that sets these variables for you. I don't like everything it does so I just use my own script.

1. Make sure you can ping 10.42.0.2, baxter.local and sawyer.local.

2. Set your environment variables:

   export ROS_MASTER_URI=http://10.42.0.2:11311
   export ROS_IP=10.42.0.1
   unset ROS_HOSTNAME
   

3. Source the rethink workspace: source rethink_ws/devel/setup.bash
4. When you run rosnode list you should see a bunch of nodes running on the baxter/sawyer
5. Echo joint states: rostopic echo /robot/joint_states
   • You should see joint states printed to the screen
6. Enable the robot
   • Baxter: rosrun baxter_tools enable_robot.py -e
   • Sawyer: rosrun intera_interface enable_robot.py -e
7. Disable the robot
   • Baxter: rosrun baxter_tools enable_robot.py -d
   • Sawyer: rosrun intera_interface enable_robot.py -d

• Baxter Physical Hardware
• Baxter SDK Wiki
• Foundations of Baxter gives a broad overview of the various Baxter programming possibilities
• Baxter SDK overview
• Baxter API Reference useful python API for controlling baxter
• Baxter ROS API Reference control baxter with ros messages and services
• Baxter Advanced Understanding (Not too advanced for you!)

• Sawyer Physical Hardware
• Sawyer SDK Wiki
• Sawyer SDK Overview
• Sawyer ROS API Reference
• Sawyer Python API

• Each robot has an internal URDF, with parameters that have been factory calibrated to account for manufacturing tolerances.
  • This URDF is stored in /robot_description in the parameter server.
• Generic URDFs are available:
  • For Baxter: baxter_description package (from the baxter_common git repo)
  • For Sawyer: sawyer_robot_package
• Two robot_state_publishers are used to publish the commanded and the real pose of the robot
  • See https://sdk.rethinkrobotics.com/wiki/URDF (Applies to Baxter and Sawyer)
  • The robots actually run a Mutable Robot State Publisher
    • When grippers are added, the URDF changes
    • The Mutable Robot State publisher subscribes to /robot/urdf and can have pieces of the URDF modified in real time.
• When using grippers, you should update the URDF to properly account for the gripper. We use electric grippers.
  • For Baxter: rethink_ee_description package in the baxter_common repository has URDF files for each gripper.
  • For Sawyer: intera_common contains the intera_tools_description package.
  • An example that adds a gripper to the baxter urdf can be found here.
    • This example is used on the Willen's Wing Baxter
    • The launch file calls a bash script which uses Rethink's send_urdf_fragment.py to update the urdf.
    • The gripper xacro file was adjusted to exactly match our gripper (see this commit)
  • When using MoveIt, you need to make sure your grippers are setup properly

• baxter.srdf.xacro / sawyer.srdf.xacro: Defines several "move groups", groups of joints that are controlled and planned for together. It requires several arguments to configure properly (for example, what grippers are installed)
  • The srdf must match the urdf being used by baxter=/=sawyer.
  • The urdf is changed using the mutable_robot_state_publisher depending on the status of its grippers.
  • If the urdf and srdf are not in sync, you will have the grippers constantly in collision with the last arm joint and be unable to motion plan (that is at least one negative affect)
• kinematics.yaml Provides options for the IK solvers. Both baxter and sawyer can use either IKFast or KDL but use KDL by default. To use a different solver, edit this file
• ompl_planning.yaml Options for the motion planner. Many of these parameters require looking at the OMPL source code to understand as they are not well documented.
  • The MoveIT setup assistant tweaks these parameters so it is also documented in its source code
  • Baxter uses RRT Connect
  • Sawyer's planner file also has good comments bout what the parameters do
    • it used the default SBL planner

• move_group.launch is the main launch file that includes many of the other launch files and eventually loads the configuration
• Do not expect the launch files to "just work".
  • You may be able to get them to work by passing the proper parameters
  • You may need to include these launch files in other launch files, or fork and modify them
• Gripper settings:
  • Your URDF and SRDF must match with respect to the gripper settings to handle collisions properly
  • For simulator, use arguments to xacro files, for real robots use the mutable_robot_state_publisher
• Look at the arguments to the launchfile and adjust them for your situation
• One common problem is that the gripper configuration is not correct.

• Baxter (and Sawyer) can compensate for the weight of grasped objects. For Baxter see here. For Sawyer, assume it works like Baxter and do your best; it is not documented as far as I know.

• Especially at first, you will want your trajectories to move slowly
• Editing joint_limits.yaml is an effective hack for quick debugging, but ultimately that file should reflect the true capabilities of the robot.
• There is a /move_group/trajectory_execution/execution_velocity_scaling that can be used to slow down a trajectory. It has been known not to work reliably however.
• Time Parameterization of your trajectory can be used to slow down the speed of the trajectory. Here is some python API documentation:
  • set_max_acceleration_scaling_factor
  • set_max_velocity_scaling_factor
  • retime_trajectory

• To use MoveIt with sawyer or baxter, you will want to have the Joint Trajectory Action Server running
• This server must be explicitly run
• It may interfere with normal commands, so you may need to start and stop this server as needed if you wish to use a combination of rethink's API and moveit in your project
• The Joint Trajectory Action Server is part of the sawyer/baxter packages

• It is a good idea to put some basic collision objects in your planning scene, such as the table
• The easiest way is to use moveit_commander.PlanningSceneInterface() in python.
  • You can use this class to attach objects to the gripper once they've been picked up
  • Thus, moveit can account for objects the robot is holding
• Baxter has demos for using the Asus xtion camera (with demo_xtion.launch) to find collisions in the environment
  • It is hopefully not to difficult to adjust for the RealSense, although we have xtion cameras as well

• MoveIt Has the ability to do grasping and pick and place.
• It is difficult to get this working and may or may not be worth the effort
• Recently released is a method that uses deep learning for planning grasps. Could be interesting

• For a Kinematic simulation rather than needing gazebo you can use the Fake Controller package
• This enables you to use moveit without a separate action server.
• The movement will follow trajectory exactly and no dynamics are involved
• You can use this in conjunction with rviz to visualize and debug your robot without gazebo when working on kinematic tasks.
• Baxter has demo_dummy.launch to help launch in this mode.

1. Is the joint_trajectory_action_server running?
2. Does the =SRDF and URDF match the actual robot
   • Grippers must be accounted for using the mutable_robot_state_publisher