-
Notifications
You must be signed in to change notification settings - Fork 13.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
accel and gyro calibration refactor and cleanup #14776
Conversation
On a high level this looks good and the right direction. I'll need to go through the details. A quicker and less intrusive solution would be to ensure everything gets advertised during serialized (driver) startup. |
I largely agree if I didn't already have this laying around, although I'm aware of some minor issues that we'd need to work on that front. I'm going to spend some time testing this across a range of boards. If it uncovers any surprises at all we can fall back to serialized driver registration + uorb advertise. Either way we need a solution immediately. |
4909fc8
to
b2092f0
Compare
Or both - #14784 |
So far everything checks out on a temperature calibration pixhawk (reported #14717) as well as basic calibration on fmu-v4 & fmu-v5. |
b2092f0
to
882a15d
Compare
882a15d
to
10132ae
Compare
This is ready for review and testing, but with #14784 merged this is no longer a v1.11 release blocker. |
@dagar any tips on how to review this or what I should focus on? |
Is the overall design clear? The general idea is to get to the point where sensor drivers do nothing more than publish raw data. Then things like calibrations are entirely applied downstream by the sensors module and we no longer need IOCTLs or character devices to directly push changes into each. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to do a review pass.
uint32[3] accel_device_ids | ||
float32[3] accel_offset_0 # accelerometer 0 XYZ offsets in the sensor frame in m/s/s | ||
float32[3] accel_offset_1 # accelerometer 1 XYZ offsets in the sensor frame in m/s/s | ||
float32[3] accel_offset_2 # accelerometer 2 XYZ offsets in the sensor frame in m/s/s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And no more accel scale calibration?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently in master if you have TC enabled the regular calibration is stored to TC parameters. The scale factor is stored directly (eg CAL_ACC0_XSCALE -> TC_A0_SCL_0). The offset (eg CAL_ACCx_XOFF) is applied by adjusting the TC coefficients (x0, y0, z0 terms).
The new idea is to basically keep them as separate as possible. Regular calibration (CAL_ACC*) is always there and operates the same way (on top of TC adjustment if available). Calibration code doesn't need to poke into TC parameters at all. This is important because in some cases the TC parameters are stored read only.
0fdc095
to
60a8414
Compare
2ec25f4
to
7bdb0ee
Compare
f285ece
to
5b6ceef
Compare
5b6ceef
to
9a7684d
Compare
Conflicts resolved and rebased on master. |
35325b1
to
c706097
Compare
- remove all remaining IOCTLs for accel and gyro - move accel/gyro calibration entirely to sensors module - calibration no longer needs to clear existing before starting - temperature calibration (TC) remove all scale (SCL) parameters - gyro and baro scale are completely unused - regular accel calibration scale can be used (CAL_ACC*_xSCALE)
c706097
to
8c23b7f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check my inline comment.
Also, the title says "(including important bug fix)". Is that still true? And if so should that fix go into the release?
for (unsigned s = 0; s < MAX_ACCEL_SENS; s++) { | ||
sensor_accel_s arp; | ||
|
||
if (accel_sub[s].update(&arp)) { | ||
// fetch optional thermal offset corrections in sensor/board frame | ||
Vector3f offset{0, 0, 0}; | ||
sensor_correction_sub.update(&sensor_correction); | ||
|
||
if (sensor_correction.timestamp > 0 && arp.device_id != 0) { | ||
for (uint8_t i = 0; i < MAX_ACCEL_SENS; i++) { | ||
if (sensor_correction.accel_device_ids[i] == arp.device_id) { | ||
switch (i) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you give i
and s
more descriptive names so it becomes clear? I'm still confused what should be i
and what s
. Also you loop both i
and s
from 0 to MAX_ACCEL_SENS
and I assume one of the two should be 3 for 3 axis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's looping through every available accel (sensor_accel) many times and accumulating the data. For each sample it loops through the current sensor_correction
(temperature_compensation) and removes the offset if available. Doing it in the loop like this is inefficient/lazy, but it's fine for a short run like this and minimizes state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
No, we can relax slightly. I'd still like to get this in soon. |
…calibration_cleanup
…calibration_cleanup
…calibration_cleanup
fce7dac
to
44d2f11
Compare
I've rebased to resolve the conflicts with the recent gyro calibration change (median filter) and tested this thoroughly comparing with master with and without temperature calibration. |
Problem
Currently in PX4 master each accel or gyro has a few requirements.
Unfortunately as the system evolved to this current state a number of implicit ordering assumptions around these interfaces slipped in. I only recently discovered real cases where this is violated.
Examples
We've mostly gotten away with this because typically all interfaces are created at the same time when starting the driver, but with the new drivers some (eg mpu6000) are performing longer more thorough reset procedures.
Solution
To solve this and clean up some legacy I've finished purging the accel and gyro character devices and IOCTLs. Then in all remaining usage of the uORB messages we don't allow any assumptions about ordering (always checking the device id field).
TODO:
Future Work