Hardware Requirements

The following hardware requirements are to ensure that the default TurtleBot software runs without modification on the robot and to ensure accessory compatibility between TurtleBot compatible robots.

• The robot must have a rgbd camera with a base_link to camera_rgb_frame translation of [x:-0.087m, y:-0.0125m, z:0.287m], as specified in the turtlebot.xacro file in the turtlebot_description package.
• The top mounting surface of the robot must provide a hole grid pattern centered around the z-axis of the robot base_link that is identical to the 68-04541_TurtleBot_Plate_2 part found in the TurtleBot hardware documentation and shown in the figure below.
• The top mounting surface of the robot must be 0.2032m (8 inches) from rgbd camera mounting surface.
• The robot fits within a a circle 0.35m in diameter
• The robot must provide at least the following power buses:
  • 12V at 1.5A with a male Micro Fit 1x2 connector (Molex 43045-0209)
  • 5V at 500mA solderable connection (If connectorized use Micro Fit 2x1 connector (Molex 43650-0218) )
• Accurate Deadreckoning:
  • Drive pattern TODO with less than X inches offset and Y radians offset.

TurtleBot Mounting Surface.

Software Requirements

The TurtleBot stacks (turtlebot, turtlebot_viz, turtlebot_apps, turtlebot_arm) must run on the robot without user modification.

Distributors of TurtleBot Level 1 compatible robots should provide the following software and configuration files if they are different than the TurtleBot:

• A node which implements the TurtleBot Node Core ROS API listed below.
• Provide equivilant diagnostics with turtlebot_node [5]
• Provide turtlebot.launch file to replace turtlebot_bringup/upstart/turtlebot.launch
• If the RGBD sensor requires a breaker to turn on it will use "Breaker 0"
• If an attached arm requires a breaker to turn on it will use "Breaker 1"

TurtleBot Node Core API

Subscribed Topics

• cmd_vel (geometry_msgs/Twist)

  The desired velocity of the robot. The type of this message is determined by the drive_mode parameter. Default is geometry_msgs/Twist.

Published Topics

• odom (nav_msgs/Odometry)

  The odometry of the robot based on the gyro and sensor_state.

• imu/data (sensor_msgs/Imu)

  The angular velocity and integrated position of the gryo.

Expected Parameters

• ~cmd_vel_timeout (double, default: 0.6)

  If a new command isn't received within this many seconds, the base is stopped.

Hardware Requirements

• An RGBD sensor
• A mobile robot base
• A computer capable of running ROS and processing the RGBD sensor at full frame rate.
  • Note: most RGBD sensors require a full USB 2.0 bus to operate correctly, thus most computers will require 2 USB busses if USB periferals are expected to be used.
• Odometry is expected to be accurate within 1% after calibration in both linear and angular movement.

Software Requirements

• URDF description of the robot
• The origin of the base_link is at the rotation point of an in-place turn.
• The depth sensor should publish in the "camera" namespace
• The base moves based on geometry_msgs/Twist [10] on the "cmd_vel" topic
  • If the base is not holonomic, only the components of the command which are achievable should be executed.
• The base publishes nav_msgs/Odometry [11] on the "odom" topic
• REP 105 [2] compliant

Location Naming Conventions

Location names should be generic and have semantic meaning with respect to the robot hardware, below are examples of common location names:

• base
• torso
• head
• arm
  • shoulder
  • upper_arm
  • elbow
  • forearm
  • wrist
  • gripper

Sensor Naming Convetions

Whenever possible it is prefered to use the following convention naming for sensor topics/namespaces LOCATION_TYPE. For example:

• base_scan
• head_camera
• forearm_camera

Link, Joint, and Frame Naming Conventions

Whenever possible it is prefered to use the following convention naming for links and connecting joints LOCATION_DESCRIPTOR_TYPE. For example:

Common Joint Descriptors are:

• flex
• lift
• pan
• roll
• tilt

Examples are:

• arm_shoulder_pan_link, arm_shoulder_pan_joint
• head_tilt_link, head_tilt_joint
• forearm_link, elbow_flex_joint

Whenever possible it is prefered to use the following convention naming for links and sensors LOCATION_SENSOR_TYPE. For example:

• head_camera_rgb_link, head_camera_rgb_optical_frame

URDF

When providing an accessory or extension for a Level 1 or 2 TurtleBot compatable robot a URDF description of the extension should be provided which provides at least collision geometries and visualization meshes.