segbot_description: define ROS frames of reference for each Arduino sensor

[jack-oquin]

To do point cloud conversion for navigation, we must define a ROS frame of reference for each sensor, giving its location and orientation relative to the sensor plate or the robot base.

[piyushk]

We were doing a transformation by hand in this script: https://github.com/utexas-bwi/code_store/blob/master/jose/sonar_test/src/sonar_listener.cpp

I would prefer to aggregate all 5 sonars and the 2 IRs before publishing the pointcloud, and define a single frame of reference for the sensor board.

[jack-oquin]

My current prototype sensor_ranges_driver aggregates the sensors by publishing an array of sensor_msgs/Range ROS messages.

That is a good fit for this application, and it seems better to use a standard message. Eventually, the navigation stack should accept those messages directly. Meanwhile, the poiint cloud generation can be generic, like laser_filters.

The messy details have to go somewhere, but it need not be segbot_description. I can put them in a YAML file and publish the transforms in my driver.

How will it work in simulation?

[jack-oquin]

For testing, my current implementation uses the tf2_ros static transform publisher in the arduino.launch. Note that this is not as bad as it looks, because tf2 supports static transforms published on a latched /tf_static topic, so the publisher only publishes once then waits in ROS spin() until someone needs to read it, all of which is handled automatically by roscpp.

We should probably switch to using tf2_ros for all our static transforms.

Each sensor has its own frame: "sonar0", "sonar1", "sonar2", "sonar3", "sonar4", "cliff0" and "cliff1". They are all transformed into the "sensor_base" frame, which is the location of the center front screw hole on the base plate holding the sensors and the Arduino.

I still need to figure out how all this should work in simulation. I believe the "sensor_base" should be represented explicitly in the URDF. We will also need to handle tf_prefix, which I currently ignore.