Baxter Research Robot. Introductory Training

Transcription

1 Baxter Research Robot Introductory Training

2 CONTENTS 1. Hardware Set Up Physical Hardware Connections Booting Networking End-Effectors 2. Wiki/Github/Community Forums 3. Baxter Research Robot SDK ROS Overview Catkin RSDK Metapackage Working with Packages 4. ROS Environment Sourcing the Environment Using the Environment 5. Basic Tools Enable Untuck Running Nodes Prebuilt Examples MoveIt MoveIt Wrapper

3 CONTENTS CONT. 6. API API URDF Addressing Arms Addressing Other Sensors 8. Maintenance Calibration Update Robot Update Workstation NTP FSM Filters 7. Diagnostics Log Files Robot Monitor 9. Example A simple Example Application

4 HARDWARE

5 Hardware Setup Pedestal Mounting Levelling Table Mounting Connections Power Mains v at 50Hz AC auto detecting power supply Emergency Stop The Emergency Stop must be connected to use the robot The Emergency Stop disables all actuators, but the PC remains powered Network RJ45 network lead, to router Recommended network configuration uses a Router with DHCP/DNS Airline psi, ~ bar, filtered and oil/moisture free 6mm Push Fit connectors

6 Booting Startup Press power button Wait for the green halo, when the halo is green Baxter is fully booted and ready to use Networking Recommended Network Setup Using a router with DHCP/DNS Shutdown Press power button Baxter will then shutdown Ensure arms are in a safe position Troubleshooting Demo Mode or Field Service Menu (FSM) appears on screen (covered in detail later) Disable FSM (consult FSM instructions for details) Reboot Verify Hostname Resolution across the Network $ ping <baxtershostname> $ ping <workstationhostname> $ avahi-browse -a -r

7 End Effectors Can be fitted at any time Powered Unpowered Use HEX key provided in kit Refer to the instructions in the End Effector Kit or on the wiki. Best Practice Mount the Electric Parallel Gripper before connecting the interface cable

8 WIKI / GITHUB / RESOURCES

9 Github/RSDK Community Wiki Setup Guides Tutorials Help/Troubleshooting guides Showcases of Research Projects / Papers Github Code Repository API Raising Issues Google Group Direct responses from Rethink Engineers and also the wider community Active Robots /call we are here to help

10 WIKI

11 GITHUB

12 FORUM

13 BAXTER RESEARCH ROBOT SOFTWARE DEVELOPMENT KIT

14 ROS Overview Robot Operating System Widely used robot middleware Libraries and tools designed for robot applications Hardware abstraction Device drivers Libraries Visualisers Message parsing Package management and much more ROS is licensed under an open source, BSD licence Allows integration of non-ros libraries ROS Structure File System Packages Each sub-library can be its own package For your application you may create one package or multiples Metapackages A collection of packages that co-exist, the Baxter RSDK is a metapackage Package Manifests (package.xml) Provides metadata about a package name version description licence information dependencies Message Types Defined Data Structures for package and node cross communication Service Types Service is a request and response defined by a pair of messages

15 Catkin Workspaces Catkin Catkin is ROS s build system Combines CMake macros and Python Scripts to direct the Make on your source Provides a portable package system to allow release of packages Compliant with File System Hierarchy (FHS), a standard directory layout for organising files on Unix-like systems workspace_folder/ src/ CMakeLists.txt package_1/ CMakeLists.txt package.xml... package_n/ CMakeLists.txt package.xml -- WORKSPACE -- SOURCE SPACE -- 'Toplevel' CMake file, provided by catkin -- CMakeLists.txt file for package_1 -- Package manifest for package_1 -- CMakeLists.txt file for package_n -- Package manifest for package_n

16 RSDK Folder ~/baxter-rsdk/rsdk100 Is a catkin workspace Contains CmakeLists.txt with build information for making the workspace and the source contained in it $ catkin_make $ catkin_make install This has already been done for your preinstalled workstations Contains a series of packages that make up the RSDK metapackage baxter_common baxter_interface baxter_tools baxter_examples

17 Creating a New Package $ cd ~/baxter-rsdk/rsdk100/src $ catkin_create_pkg research_project rsdk100/ src/ CMakeLists.txt research_project/ CMakeLists.txt package.xml... baxter_interface/ CMakeLists.txt package.xml -- CMakeLists.txt file for our new package -- Package manifest for our new package -- CMakeLists.txt file for baxter_interface -- Package manifest for baxter_interface ~/baxter-rsdk/rsdk070/src/research_project/src - Place your code here

18 C++ $../research_project/src - Place source files in src directory $ cd ~/baxter-rsdk/rsdk100 $ catkin_make This will make any unmade packages in the workspace It will also generate the build and devel directories and their contents You may need to edit your CMakeLists.txt and package.xml depending on what your package does or depends upon $../research_project/src Python Place source files in src directory Make sure you change the permissions to allow execution You may need to edit your CMakeLists.txt and package.xml depending on what your package does or depends upon. Run your node Run your node

19 ROS ENVIRONMENT

20 ROS Computation Graph Nodes Nodes are processes that perform computation ROS is designed to be modular at a fine-grained scale A robot control system usually comprises many nodes Joint feedback Joint control Inverse Kinematics A ROS node is written with the use of a ROS client library, such as roscpp or rospy Master Provides name registration and lookup to the rest of the Computation Graph Without the Master, nodes would not be able to find each other, exchange messages, or invoke services Provides the Parameter Server for central control of key parameters Nodes connect to other nodes directly; the Master only provides lookup information similar to a DNS server Messages Data structure for node-node communication Topics Messages can be published to a Topic A node could publish its data to a Topic One or more nodes can then subscribe to that Topic This allows multiple nodes to access information such as sensor data without having to make requests to the sensor Node. Services If request/response communication is needed Comprises two messages Request Response Bags A format for saving and replaying ROS messages Used for logging sensor data Can be replayed and fed to Nodes for testing

21 ROS Environment Sourcing the ROS environment $ cd ~/baxter-rsdk/rsdk100 ;./baxter.sh baxter_hostname="baxter_hostname.local your_hostname="my_computer.local ros_version="groovy Terminal This Terminal now has access to: all ROS nodes/libraries bi-directional communication between workstation and robot Run the majority of ROS based applications from terminals like this.

22 Using a ROS terminal Basic Tools $ rosrun <package> <executable> <optional arguments> Examples: $ rosrun baxter_tools enable_robot.py -e #(-e:enable -d:disable -s:status -r:reset -h:help) $ rosrun baxter_tools tuck_arms.py -u #(-u:untuck -t:tuck -h:help) $ rosparam $ roslaunch <package> <launchfile>.launch

23 Examples $ rosrun baxter_examples joint_position_keyboard.py $ roslaunch baxter_examples joint_position_joystick.launch joystick:=<joystick_type> $ rosrun baxter_examples joint_recorder.py -f <filename> $ rosrun baxter_examples joint_position_file_playback.py -f <filename> $ rosrun baxter_examples joint_torque_springs.py -l right $ rosrun baxter_examples joint_velocity_puppet.py -l right $ rosrun baxter_tools camera_control.py -l $ rosrun baxter_tools camera_control.py -c left_hand_camera $ rosrun baxter_tools camera_control.py -c right_hand_camera $ rosrun baxter_tools camera_control.py -c head_camera $ rosrun baxter_tools camera_control.py -o left_hand_camera -r 1280x800 $ rosrun image_view image_view image:=/cameras/left_hand_camera/image $ rosrun baxter_examples xdisplay_image.py --file=`rospack find baxter_examples`/share/images/baxterworking.png

24 MoveIt Visualisation Environment and planning framework for Baxter Uses URDF file generated by Baxter Kinematics Inverse Kinematics Forward Kinematics Jacobian Trajectory Planning OMPL (Open Motion Planning Library) SBPL (Search Based Planning Library) CHOMP (Covariant Hamiltonian Optimization and Motion Planning) IKFast Environment Representation Collision Checking Environment mapping Robot Representation Constraint evaluation Sensor output visualisation Has a C++ and Python wrappers to allow you to address all its functions programmatically

25 Planning Groups SRDF (Semantic Robot Description Format) compliments the URDF and specifies joint groups for motion planning both_arms left_arm right_arm left_arm left_s0 left_s1 left_e0 left_e1 left_w0 left_w1 left_w2 left_hand left_endpoint right_arm right_s0 right_s1 right_e0 right_e1 right_w0 right_w1 right_w2 right_hand right_endpoint left_hand left_gripper right_hand right_gripper You can view the SRDF at any time: $ rosed baxter_moveit_config baxter.srdf

26 Run MoveIt Verify that the robot is enabled $ rosrun baxter_tools enable_robot.py e Start the joint trajectory controller $ rosrun baxter_interface trajectory_controller.py In another RSDK terminal, Launch the rviz MoveIt! Plugin $ roslaunch baxter_moveit_config demo_baxter.launch Drag Baxters arms in the GUI to the desired cartesian position and RPY/quaternion orientation Planning Tab Plan and Execute

27 Environment Representation We will now create a scene object in a text file to be imported into our environment. # Copy in the following scene describing a pillar pillar * pillar 1 box # Save and exit. Scene Objects Tab Import from Text Context Tab Publish Current Scene Drag Baxters arms in the GUI to the desired cartesian position and RPY/quaternion orientation Planning Tab Plan and Execute

28 Wrapping MoveIt Functionality Into Your Project C++ #include <moveit/move_group_interface/move_group.h> interface_1_1movegroup.html Python from moveit_commander import MoveGroupCommander

29 Gazebo is the ROS simulation environment Open Source Developed by the OSRF (Open Source Robotics Foundation) Baxter Configuration Models are limited to Baxter owners No limit on number of installations / licensing Give a whole class the simulator for project / homework development Use the same code on the simulator as on the robot Gazebo Simulation Use the simulator as a test-bed for early development of control solutions that may be unstable./baxter.sh sim roslaunch baxter_gazebo baxter_world.launch

30 API

31 API URDF Baxter automatically builds an appropriate URDF (Unified Robot Description Format) on boot and loads it onto the ROS Parameter Server /robot_description From here, it is accessible by rviz, tf and other ROS utilities that use the URDF $ rosparam get -p /robot_description tail -n +2 > baxter_urdf.xml

32 ADDRESSING ARMS

33 Limb class, from limb.py in baxter_interface Addressing Arms joint_names(self): joint_angle(self, joint): joint_angles(self): joint_velocity(self, joint): joint_velocities(self): joint_effort(self, joint): joint_efforts(self): endpoint_pose(self): endpoint_velocity(self): endpoint_effort(self): set_command_timeout(self, timeout): exit_control_mode(self, timeout=0.2): set_joint_position_speed(self, speed): set_joint_positions(self, positions): set_joint_velocities(self, velocities): set_joint_torques(self, torques): move_to_neutral(self, timeout=15.0): move_to_joint_positions(self, positions, timeout=15.0): There are similar classes for each subsystem, which allows you to both read and write to the ROS topics for that subsystem

34 Using the functions from the Limb class Sending Joint Angles To An Arms move_to_joint_positions(self, positions, timeout=15.0): baxter_interface.limb('right').move_to_joint_positions({ 'right_s0': 0.0, 'right_s1': 0.0, 'right_e0': 0.0, 'right_e1': 0.0, 'right_w0': 0.0, 'right_w1': 0.0, 'right_w2': 0.0 }) Angles are in Radians Parsing in a Dict where each joint label has a corresponding float

35 Again using functions from the Limb class Reading Joint Angles From An Arms baxter_interface.limb('right').joint_angles() {'right_s0': , 'right_s1': , 'right_w0': 0.0, 'right_w1': , 'right_w2': , 'right_e0': , 'right_e1': } Formatted as a dict and internally addressable by joint name If you only need a specific joint then you can use: joint_angle(self, joint):

36 End Effector Control A class to address the end-effectors is also available in the Gripper class command(self, cmd, block=false, test=lambda: True, timeout=0.0, args=none): valid_parameters_text(self): valid_parameters(self): set_parameters(self, parameters=none, defaults=false): reset(self, block=true, timeout=2.0): reboot(self, timeout=5.0, delay_check=0.1): clear_calibration(self, block=true, timeout=2.0): calibrate(self, block=true, timeout=5.0): stop(self, block=true, timeout=5.0): command_position(self, position, block=false, timeout=5.0): command_suction(self, block=false, timeout=5.0): set_velocity(self, velocity): set_moving_force(self, force): set_holding_force(self, force): set_dead_band(self, dead_band): set_vacuum_threshold(self, threshold): set_blow_off(self, blow_off): open(self, block=false, timeout=5.0): close(self, block=false, timeout=5.0): parameters(self): calibrated(self):

37 End Effector Control A class to address the end-effectors is also available in the Gripper class ready(self): moving(self): gripping(self): missed(self): error(self): position(self): force(self): vacuum_sensor(self): vacuum(self): blowing(self): sucking(self): has_force(self): has_position(self): type(self): hardware_id(self): hardware_version(self): firmware_version(self):

38 Other Inputs/Outputs Analog I/O IR Range Sensor Class from: analog_io.py Component IDs from: baxter_interface.analog_io.analogio('right_hand_range').state() Digital I/O Buttons Class from: digital_io.py Component IDs from: baxter_interface.digital_io.digitalio('right_lower_button').state Poll this for inputs Lights Class from: digital_io.py Component IDs from: baxter_interface.digital_io.digitalio('right_itb_light_inner').set_output(false) Poll this for inputs Camera Class from: camera.py Component IDs from: baxter_interface.cameracontroller('right_hand_camera').close() baxter_interface.cameracontroller('right_hand_camera').open() baxter_interface.cameracontroller('right_hand_camera').resolution = (960,600)

39 Other Inputs/Outputs Screen Displaying Images on the Screen rosrun baxter_examples xdisplay_image.py --file=`rospack find baxter_examples`/share/images/baxterworking.png Displaying Video to the Screen Create a publisher as part of the callback function for the video subscriber Rospy.Publisher('/robot/xdisplay',Image).publish(data) Camera Simple Camera View Rather than creating a subscriber to the camera topic and a library such as opencv to convert and view the camera feed you can use the ros tool $ rosrun image_view image_view image:=/cameras/right_hand_camera/image

40 DIAGNOSTICS

41 Log Files Log Files Connecting to Baxters FTP server and retrieving all logs $ wget -r ftp://<robothostname>.local/ Zip them for uploading $ tar cvzf ftp_logs_baxter_<uni.dept>_<date>.tar.gz <RobotHostname>.local/ g_files Robot Monitor Useful for viewing data and diagnostics Displays diagnostics_agg topics messages that are published by diagnostic_aggregator $ rosrun rqt_robot_monitor rqt_robot_monitor./ -- hlr-log -- EndEffectorUpdater.log -- eth-jfiload.log -- eth-jfiload.log.1.gz -- hlr -- 2a6faef2-977b-11e2-b03d-90b11c94fb4e -- master.log -- roslaunch-tuftsbaxter-4160.log -- rosout-1-stdout.log `-- rosout.log -- plugin_manager_18590_ log -- plugin_manager_20566_ log -- rethink_repeaters.log `-- xdisplay.log -- rethink.log -- robot_config.log -- robot_config.status `-- root `-- sys-log -- Xorg.0.log -- auth.log -- daemon.log -- kernel.log -- messages.log -- overcfg `-- overcfg log -- portage -- rc.log -- syslog.log `-- user.log

42 MAINTENANCE

43 Calibration Calibrate The full "factory" calibration moves the arms to different poses and uses knowledge of the robot mass (with no gripper or payload) as ground truth torque to correct errors in the torque modeling. As an example, if there was a linear model of torque vs. angle, the model's slope and y-intercept would be adjusted (i.e. offset or bias) accordingly. Recommended to be carried out monthly, or following significant travel/position change (assuming daily use) Remove End-Effectors/Payloads $ rosrun baxter_tools calibrate_arm.py --calibrate right Reboot Baxter after calibrate and before post-calibration use

44 Tare Tare The "simple" calibration for each arm. Tare is done by putting the robot in a known location and reseting the offset torques so that the output is an expected value. Ideally, this would be accomplished with a reliable value of zero torque, but since it's difficult to obtain zero torque on all joints (impossible on some), a known position with known non-zero torques is chosen. Because of the way Baxter's large bend joints are constructed, their torque readings can be distorted by the presence off-axis torques about a certain axis. We refer to this as "crosstalk". In the case of the s1 joint, this effect is large enough that it is beneficial to actively compensate for it. We do this by modelling the torque reading distortion as a function of off-axis torque, and then subtracting the predicted "crosstalk" from s1's torque reading during operation. Because Baxter's s1 joint must support relatively high gravitational loads, a pair of springs provides an anti-gravity torque to assist the motor. Because of the way these springs are manufactured, the torque supplied is a function not only of the s1 joint position but also of the recent history of s1 joint position, and that function can vary from spring to spring. In order to provide good position and torque control as well as good extrinsic torque sensing, the torque contribution from the s1 springs must be allowed for. The joint torque sensors can change over time so that torque readings are uniformly offset from the correct values. To address this, at the end of the "tare" process, the arm is moved to a pose with known torques due to gravity and torque readings are taken. The torque sensor calibrations are adjusted to compensate for any offset. The s1 joint is excluded from this correction. Recommended to be carried out weekly, or following significant travel/position change (assuming daily use) Remove End-Effectors/Payloads $ rosrun baxter_tools tare.py --tare right Reboot Baxter after tare and before post-tare use

45 SDK update is released Your organisation Point of Contact receives notice (though you likely knew it was coming long before, from forum, github etc) Update Robot Find UUID of the update $ rosrun baxter_tools update_robot.py l Version UUID e db- 11e3-bae4-e0cb4e8bae9f Download update from Rethinks FTP server (details in above ) Unzip Copy to FAT32 formatted USB Flash Drive Ensure they are in the root directory Safely Eject your flash drive :) Run the Update, parsing the UUID $ rosrun baxter_tools update_robot.py -u e db-11e3-bae4-e0cb4e8bae9f Baxter will Reboot Confirm the New Software Version $ rosparam get /rethink/software_version Boot Baxter, Initialise ROS terminal Ensure you are at the correct version for your update to update FROM, updates are incremental, don't skip releases $ rosparam get /rethink/software_version date

46 Create a new Catkin workspace $ mkdir -p ~/baxter-rsdk/rsdk<version>/src $ cd ~/baxter-rsdk/rsdk<version>/src Update Workstation Clone the new repository $ wstool init. $ wstool merge $ wstool update $ cd.. Source ROS setup $ source /opt/ros/groovy/setup.bash Build and Install catkin_make catkin_make install

47 Use the baxter.sh script for proper environment setup $ cp src/baxter/baxter.sh. Update Workstation Edit the baxter.sh script, modifying the 'baxter_hostname' and 'your_ip' OR 'your_hostname' variables: - baxter_hostname="baxter_hostname.local - your_hostname="my_computer.local - ros_version="groovy Initialize your sdk environment $./baxter.sh

48 NTP Baxter uses the Network Time Protocol (NTP) to set its internal clock Reference Time mismatch between Robot and Workstation can lead to issues Transforms Trajectory Planning Makes reading logs difficult If connected to the internet (ie your router has its uplink port connected to your main network) Update internal clock on bootup Correct small discrepancies as a service during running Check if you have a time mismatch via $ ntpdate -q <robot_address> server , stratum 2, offset , delay Oct 18:32:31 ntpdate[7238]: adjust time server offset sec

49 FSM Field Service Menu (FSM) Accessed by connecting a USB keyboard directly to Baxter Press Alt-ff during bootup Hardware Tests Basic functionality tests for hardware subsystems Use these to verify hardware is working Useful as a first step in case of issues Low Level Config Edit Hostname (recommended to leave it as default) Set static IP Edit Timezone View MAC Address Filters 2 PC air filters, one each side of lower torso Recommend cleaning filters every 6 months Assuming an industrial environment To remove/refit filter 2mm hex key Remove 2 screws Clean Filter Refit filter Torque screws to 0.3Nm Demo Mode

50 Gravity Compensation Springs Periodically (approximately annually) you may need to grease the Gravity Compensation Springs Use a grease such as: Mobilith SHC 221 or Lubriplate DS-ES Full instructions for the greasing procedure are available on the wiki

51 HANDS ON EXAMPLE

52 Example Application Create a package within our catkin workspace $ cd ~/baxter-rsdk/rsdk100/src $ catkin_create_pkg trainingexample Create some code in the src folder We will use python for simplicity in this example Create an empty file with a.py extension training.py Change the file permissions to allow execution [Make, if using C++] Run the node $ rosrun trainingexample training.py See the results on the robot Example will address: Sensors Cameras Including Image Processing Limb Movement By Joint Angle By Inverse Kinematics Integration of External Libraries Using Services

53 Questions?