Review InertialUnit with respect to REP 145

[omichel]

trafficstars

We should review our InertialUnit implementation and interface with respect to REP-0145, Conventions for IMU Sensor Drivers and corresponding PR.

[ygoumaz]

After reading the REP in question and putting it in perspective with the sensors available in Webots here is what I think is the best to do in our case:

• [x] Implementing a PROTO representing a real IMU product combining several key sensors would allow the user to access a generic IMU that directly combines the essential sensors. This has already been started in PR #5168, with the implementation of the MPU-9250. However, the product datasheet does not mention an overlay for attitude output (roll, pitch, yaw). So I suggest not to add an InertialUnit in this PROTO. MPU-9250 PROTO would contain only accelerometer, magnetometer and gyroscope. In addition, the REP clearly states that the attitude output is optional on the IMUs.
• [x] The documentation of the InertialUnit must be updated to clearly indicate that it is a device allowing to obtain the attitude of the robot. It must also be clearly specified that this data is the ground truth and not the result of the combination of several sensors. It makes life easier for the user who does not want to use a library or a sensor fusion algorithm to combine the data from an IMU and calculate the attitude. EDIT: this is achieved in #5234.
• [x] The sample world named inertial_unit.wbt can be left as it is. It might be interesting to add a new sample world which could be titled imu.wbt which would use the MPU-9250 to compute the attitude (by merging its sensor data) and indicate the difference with the exact values provided by the InertialUnit. I feel that separating the example world for the InertialUnit with the one that highlights the fusion of sensors makes sense. But this is an open question and it is always possible to simply add the attitude calculation part to the existing world. EDIT: this is achieved in #5256.