API review

Proposer: Blaise Gassend

Present at review:

• List reviewers

Why this API

I would like to solidify what it means to be an IMU in ROS. This is prompted by the fact that wiimote is an IMU, and currently we can't make wiimote and imu_node have the same interface because wiimote can't depend on imu_node due to stack dependencies.

The following proposal has two changes compared with current practice:

• Imu data is sent on imu/data instead of imu_data. This is to be consistent with the other topics and services.

• imu/is_calibrated has been changed from a service call into a latched topic, since latched topics now exist.

Two questions remain in my mind:

• What is the right message for the imu/is_calibrated topic? We could have a sensor_msgs/calibration message, but since this is just a boolean, it might be nice to push this into something more general such as ???/BooleanStatus that could work for any latched topic that reports some state of a node as a boolean.

• Should the imu/calibrate service be allowed to return an error? An IMU could be reasonably expected to detect if there is non-uniform motion of the IMU during calibration, and decide to reject that calibration, possibly after retrying a few times. It isn't clear, however, that the node calling calibrate would know how to handle that error.

Beyond the ROS API below, is there anything else that we should standardize at this time?

Proposed API

In ROS, IMU devices are expected to have the following standard interface:

Topics

* imu/data (sensor_msgs/Imu) : Streams the data from the IMU.

* imu/is_calibrated (???/???) : A latched topic that reports wether the IMU is calibrated.

Services

* imu/calibrate (std_srvs/Empty) : A service call that causes the IMU to calibrate itself. The service call returns when calibration is complete.

Parameters

* ~autocalibrate (bool) : Indicates if the IMU should calibrate as soon as it is started up.

Remapping

* Remapping "imu" will remap the whole "imu" subtree.

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.

Comments by Andreas:

1. One could enrich the is_calibrated request by having the IMU service return either -1 if calibration has not happened, or a time duration, which indicates how long it's been since calibration was last done.This allows the client node to ask for re-calibration if drift rate is known.

2. I feel that the return of an error condition to calibration requests would be important. Yes, the client might not be able to do anything, but other nodes can communicate with the human operator. The Wiinode currently does check the standard deviation during calibration and could return an error when readings exceed 2*stdev.

3. Command line args: the only other *might* be the frequency of publishing. Maybe that's not in the spirit of the architecture. But one could imagine a very high sample rate IMU for which one might wish to limit the multicast frequency of ROS messages.

Meeting agenda

To be filled out by proposer based on comments gathered during API review period

Conclusion

Stack status change mark change manifest)

• Action items that need to be taken.

• Major issues that need to be resolved

---