API review

Proposer: John Hsu

Present at review:

Gil
Tim
Wim
Ioan
Nate
Rosen

Proposal

An attempt at organizing high level symbolic description of the robot model, application oriented description and configuration of the robot model.

Additional high level robot model descriptions are to be added as URDF extensions.
Change <transmission> and <gazebo> tags to <extension type="gazebo"> and <extension type="transmission">
- * NOTE: In COLLADA the extra type describes the semantics of the data, while the technique describes the format of the data. So instead of "gazebo", find a better type name for the physics data gazebo is specifically using.
Is it necessary to move/reorganize any of the parameters in sbpl_arm_planner/config/*.cfg upstream into an urdf extension? Are there overlaps with <extra type="*"> as proposed on the OpenRave COLLADA page?
Mapping <extra type="manipulator"> into an URDF extension?
- <frame_origin>, <frame_tip> / <translate> <rotate>
- <gripper_axis> / <closingdirection>
- <iksolver> / <free_axis> / <axis>, <stepsize>
How do we handle multiple collision meshes in ROS?
- Mapping <extra type="collision"> into an URDF extension?
Decide what additional sensor information is needed for calibration per tikcet #4611. Below are tags proposed on the OpenRave COLLADA page.
- <extra type="base_pinhole_camera">
  - <image_width> <image_height> <intrinsic> <measurement_time> <distortion>
- <extra type="base_stereo_camera">
  - <instance_sensor> <rectification>
- <extra type="base_laser2d">
  - <angle_min> <angle_max> <range_min> <range_max> <angle_increment> <time_increment> <measurement_time>
- <extra type="base_imu">
  - <measurement_time> <rotation_covariance> <angular_velocity_covariance> <linear_acceleration_covariance>
- <extra type="base_odometry">
  - <measurement_time> <target>
Proposal of a new dynamic_robot_description_manager
- maintains XML string of robot urdf and extensions on the parameter server
- provides services and latched topics to retrieve XML string of robot urdf and extensions
  - get_robot_description
- provides interfaces for updating the robot description
  - update_robot_description

Question / concerns / comments

Enter your thoughts on the API and any questions / concerns you have here. Please sign your name. Anything you want to address in the API review should be marked down here before the start of the meeting.

Rosen

* Official support for putting COLLADA files on parameter server? pr2.dae is 5.7Mb, so would have to compress?

* Possible to export calibrated COLLADA dae file to /etc/ros along with URDF?

* Holding list of link pairs where self-collisions can be ignored (part of "collision" tag)

Sometimes robot links close to each other can self collide due to mesh imprecisions, even though robot can safely get into that state.
Some links will never collide (head and casters). Having this information can reduce self-collision time (important for planning).

Here is an example of what the PR2 COLLADA file looks like with manipulator, sensor, and ignore_link_pair tags pr2-beta-static-collada.tgz

Ioan

How about retrieving the robot description with the resource retriever, if it gets large?
I think the <extra> tag is useful for certain things like <gazebo> or even transmissions. However, for multiple collision meshes I would say they need to be specified in the same format as already done -- simply allow more instances of the same tag.
For the semantics component, I would suggest there are a set of pre-defined part names that have special meaning. For instance, the part called arm (which can exist multiple times in the same robot) is something for which inverse kinematics can be done. We could have other parts such as base, which could have properties such as omni-directional. This would allow defining parameters that are useful for kinematics, collision checking, planning in a more specific way. Perhaps we could use the <extra> for properties of these parts?
- ```
<component name="left arm" type="arm">
  <property joints="list of joints in the arm" />
  <property links="list of links in the arm" />
  <property end-effector="link name" />
  <property ik="..." />
</component>

<component name="my wheels" type="base">
  <property joints="list of joints in the base" />
  <property links="list of links in the base" />
  <property mobility="translation|omnidirectional|floating|legged" />
</component>
```

Tim F.

COLLADA FBX

Josh F.

Collada comes up as a topic every couple years in a game-industry forum I frequent, and the trends over the last few years have been:

2006 -- this could be promising, but I'm going to hold off until it gains real industry traction 2008 -- this is kinda cool, this FCollada thing (from Feeling Software) makes parsing/saving really easy 2010 -- welp, Collada's basically dead. I'm going to either a) write my own exporter or b) use FBX.

Also, Collada was never meant to be the thing you use directly in your engine, rather it was meant as an interchange format.

John

Additional robot model descriptions other than <link> and <joint> are to be added as URDF extensions.
- Not as extensions, but as completely separate XML blocks specific to individual applications.
Change <transmission> and <gazebo> tags to <extension type="gazebo"> and <extension type="transmission">
- Rather than making <transmission> and <gazebo> URDF extensions, move them outside of <robot>
  - Maintain separately in separate packages (outside of pr2_description.
  - Put <transmission> under <transmissions> or <actuators>
  - Put <gazebo> under a general tag such as <simulator_gazebo> or <simulation>
Is it necessary...
Mapping...

How do we handle multiple collision meshes in ROS?

Define consistent XML tags for additioanl robot meshes, for example:

<self_collision_mesh>
  <link name="l_forearm_roll_link"/>
  <origin xyz="0 0 0" rpy="0 0 0"/>
  <geometry>
    <mesh file="robot.mesh"/>
  </geometry>
</self_collision_mesh>

Decide what additional sensor information is needed for calibration per tikcet #4611. Below are tags proposed on the OpenRave COLLADA page.
- For each sensor, specify a way to access them via ROS namespaces, for example:
```
<sensor name="sensor_01">
  <link name="l_forearm_cam_optical_frame"/>
  <ros ns="l_forearm_cam"/>
</sensor>
```
Proposal of a new dynamic_robot_description_manager
- maintains XML string of robot urdf and extensions on the parameter server
- provides services and latched topics to retrieve/update XML string of robot urdf (with extensions)
  - get_robot_description
- provides interfaces for updating the robot description
  - update_robot_description

Meeting Notes

Come up with a common planning specific robot description format, then consider upgrading components into URDF if necessary.
- Gil will send links to multiple YAML configuration file locations for planning specific applications and try to consolidate.
W.R.T. addition of alternative meshes such as self collision mesh, convex decomposed meshes, etc.
- As a first step, the additional mesh formats can live in a planning specific description file, and if necessary, propose and review porting of the new mesh elements into URDF in the future.
Rosen's final comment: Should we export PR2 COLLADA and place it on the parameter server? This could potentially be taken care of by a robot description manager. TBD.

Conclusion

Package status change mark change manifest)

$/!\$ Action items that need to be taken.
Major issues that need to be resolved