[Documentation] [TitleIndex] [WordIndex

API review

Proposer: Blaise Gassend

Present at review:

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:

Two questions remain in my mind:

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)



2024-03-23 12:38