Changed all 'NED board' references to 'FRD body'. Also cleaned up mix… #16339
Conversation
…ing of m/s/s and m/s^2 to use the latter. Corrected m/s/s to Pascals. Plus minor typos. There are still some messages that needs to be looked at for correct reference frame: 'vehicle_rates_setpoint.msg' and 'vehicle_attitude_setpoint.msg. Also made some minor cosmetic clean ups.
bresch
added
the
Documentation 📑
Co-authored-by: Mathieu Bresciani <brescianimathieu@gmail.com>
Co-authored-by: Mathieu Bresciani <brescianimathieu@gmail.com>
|
Good catch! Shall be included now. |
There was a problem hiding this comment.
I went through it in details and there was still a bit of confusion (due to my comment in the issue).
To make it clear:
- all the
sensor_*are in the "autopilot hardware frame" (called "board"). This is not necessarily the frame of the MEMS itself. - all the
vehicle_*are in the vehicle body frame
For example:
The data of an accelerometer is sampled, rotated in the board frame (i.e.:autopilot hardware, e.g.: Pixhawk) and published as sensor_accel. Then the calibrations and estimated bias are applied and the result is rotated in body frame and re-published as vehicle_imu and potentially in sensors_combined (if it has the highest priority).
|
Makes sense. Good work! Perhaps it is a good idea to define and list the coordinate systems in the documentation for completeness. I have not really managed to find anything in the documentation other than the mentioning of NED and FRD systems here: https://dev.px4.io/v1.11/en/contribute/notation.html Note that FRD in the documentation refers to the vehicle front axis etc. i.e. rather easy to misconcive mentioning of 'body' and 'board' in the RTPS message comments. Also, to me 'board' is somewhat vague as it might refer to the complete flight controller, or just the sensor board of the Cube if you are using such flight controller. Perhaps obvious to some people, but if you have whatever diagnosis a psychiatrist would label me with, it keeps you awake at night :) |
| int16[32] x # acceleration in the NED X board axis in m/s/s | ||
| int16[32] y # acceleration in the NED Y board axis in m/s/s | ||
| int16[32] z # acceleration in the NED Z board axis in m/s/s | ||
| int16[32] x # acceleration in the FRD board frame X-axis in m/s^2 |
There was a problem hiding this comment.
To add to the confusion these FIFO messages are the raw data that we get out of an IMU's FIFO. They're in the sensor frame and the data is raw 16 bit integers, typically with UINT16_MAX corresponding to the configured max range (eg 16 G accelerometer). That's why the message carries a rotation and scale factor.
There was a problem hiding this comment.
Ouch, so they're not always in the same frame as sensor_accel ?
…ing of m/s/s and m/s^2 to use the latter. Corrected m/s/s to Pascals. Plus minor typos. There are still some messages that needs to be looked at for correct reference frame: 'vehicle_rates_setpoint.msg' and 'vehicle_attitude_setpoint.msg. Also made some minor cosmetic clean ups.
Solves: #16328
Note: This PR replaces PR #16337