API Reference

Revision as of 20:22, 9 January 2017 by Swang (talk | contribs) (Robot)
Jump to: navigation , search

This page serves as a lookup reference for all the hardware and functionality for the SDK. The main interface of the SDK is via ROS Topics and Services, which you will find listed and described below along with other core information needed to interface with the robot.

ROS Topic API Reference

Python Code API

For the Robot Interface Python classes (built on top of the ROS API), please see the Code API Reference page.


Robot Movement Sensors+ I/O

Robot

Enable Robot

Be sure that you 'Enable' the robot before attempting to control any of the motors. The easiest method for controlling the robot is to use the enable_robot.py ROS executable found in the following example:Enable Robot Script

Robot State

/robot/state (intera_core_msgs/AssemblyState) Subscribe to the Robot State for the enabled and error state of the robot hardware itself. It also includes information on the EStop. The robot must be enabled (enabled: true) in order to move the robot. Use the Enable Robot Script, or the "Enable Robot Topic" below, to enable the robot. It is possible for the robot to have non-fatal errors, so error can be true while enabled is also true. For more complete information on robot state, see Robot State and EStop.

Enable Robot

/robot/set_super_enable (std_msgs/Bool) data: true to Enable robot motors; false to disable. You can check the Robot State Topic to see if the robot enabled properly or if it has an error.

Reset Robot State

/robot/set_super_reset (std_msgs/Empty) Publish an Empty message to reset the state after an error. A reset will clear all pre-existing errors and the state (it will disable).

Robot Description (URDF)

Sawyer automatically builds an appropriate URDF (Unified Robot Description Format) on boot and loads it onto the ROS Parameter Server, under the ROS parameter name /robot_description. From here, it is accessible by rviz, tf and other ROS utilities that use the URDF.

The Unified Robot Description Format (URDF) is the standard ROS XML representation of the robot model (kinematics, dynamics, sensors) describing Sawyer.

Sawyer generates his URDF dynamically on robot startup. This model is updated when any gripper is attached or detached, an object is 'grasped' or released and its mass is compensated for, and when new urdf segments are provided/commanded to the gripper plugins. As of SDK versions >= 1.0.0 Sawyer's internal robot model, is loaded to the parameter server on the topic /robot_description

The default URDF for Sawyer is available in the intera_common repository. The package sawyer_description contains the URDF and accompanying meshes.

Getting a Copy of the URDF from the parameter server

You can now get the current URDF describing your Sawyer.

From a properly initialized Sawyer environment, export the URDF from the /robot_description parameter on the ROS parameter server where it is stored, to a file of your choice (ex: sawyer_urdf.xml):

$ rosparam get -p /robot_description | tail -n +2 > sawyer_urdf.xml

The -p outputs the parameter using pretty print. The output urdf is piped through the tail command first to remove a dummy first line - an artifact of the pretty print.

Tip: You can check that you now have a proper URDF by running:

$ rosrun urdfdom check_urdf sawyer_urdf.xml

Robot State Publisher

The URDF is used by Sawyer's Robot State Publishers to create a tree of transforms (tfs). In fact, Sawyer has two of such publishers: robot_ref_publisher: publishes transforms that reflect the commanded robot state robot_state_publisher: publishes transforms that reflect the measured state of the robot

These robot publishers live internal to Sawyer and are accessible to the RSDK over ROS. The "ref" tfs are used by the robot internals, but you may find them useful to see where the robot will move at the next timestep. Otherwise, be sure to use the non-"ref" transforms if you're only interested in the Sawyer's current state.

Getting a Copy of the URDF Dynamically

Sawyer generates the URDF dynamically on initialization, based on the attached arm. In some cases, users may want to get the current URDF off the robot. From a working Sawyer RSDK environment, export the URDF from the /robot_description parameter on the ROS parameter server where it is stored, to a file of your choice (ex: sawyer_urdf.xml):

$ rosparam get -p /robot_description | tail -n +2 > sawyer_urdf.xml

The -p outputs the parameter using pretty print. The output urdf is piped through the tail command first to remove a dummy first line - an artifact of the pretty print.

Tip: You can check that you now have a proper URDF by running:

$ rosrun urdf_parser check_urdf sawyer_urdf.xml

If this doesn't work, you can just remove the tail command and use a text editor to manually remove the first few lines before the actual xml (all the lines before <?xml version="1.0" ?>).

    $ rosparam get -p /robot_description > sawyer_urdf.xml
    $ head sawyer_urdf.xml
    |  
      <?xml version="1.0" ?>  
      <!-- =================================================================================== -->  
      <!-- |    This document was autogenerated by xacro from sawyerp2.urdf.xacro            | -->  
    ...  
    $ gedit sawyer_urdf.xml &
    $ head sawyer_urdf.xml
      <?xml version="1.0" ?>  
      <!-- =================================================================================== -->  
      <!-- |    This document was autogenerated by xacro from sawyerp2.urdf.xacro            | -->  
    ...

Movement

Joints

Sawyer has 7 joints (DoF) in arm and one more joint in its head (side-to-side panning). The control for the head is done separately from the arm; however, you can read the current joint states (position, velocity, and effort) for all the joints on arm and head by subscribing to one topic: /robot/joint_states (sensor_msgs-JointState) where the units for the position of a joint are in (rad), the units of velocity are in (rad/s) and the units of effort in each joint is in (Nm).

The following sections cover the individual joint sensing and control in more detail:

Cartesian Endpoint

Published at 100 Hz, the endpoint state topic provides the current Cartesian Position, Velocity and Effort at the endpoint for either limb.

The following sections covered the endpoint state and IK Solver in more detail:

Gripper (End-Effector)

Before using an End-Effector, or Gripper, you must first send the calibration command. You can check whether the gripper has been calibrated yet by echoing on the gripper state topic for that hand. Once calibrated, gripper can be controlled using the simplified command_grip and command_release topics, or using the more direct command_set topic. For more information on using the gripper, see the Gripper Example Program.

The following sections cover the gripper configuration, gripper state and simple gripper control in more detail:

Sensors+

Sensors

Multiple sensors are included inside of the Sawyer Robot.

Cameras

You can access Sawyer's hand camera and the head camera using the standard ROS image types and image_transport mechanism. You can use the ROS Services to open, close, and configure each of the cameras. See the link below for more info:

Head Display Screen

Images can be displayed on Sawyer's LCD screen by publishing the image data. For detailed info regarding the head display, please see:

Inputs and Outputs

Navigators

There are two Navigators on Sawyer's body: one on side of the body and one on the arm. Each Navigator is comprised of three push buttons, one of which is also an indexing scroll wheel, and one set of white LED light.

Component IDs:
head_navigator, right_navigator

Cuff Buttons

There are two buttons and one touch sensor in the cuff of the hand. The state of each button is published in a DigitalIOState message under its own topic (DigitalIOState constants: PRESSED==1, UNPRESSED==0).

Lights

The head LEDs at the top of Sawyer's head, and navigator LEDs are inside of navigator.

See followed link for more info: