ladislas/feature/ahrs fusion #1245
Conversation
ladislas
commented
Jan 10, 2023
ladislas
commented
- ♻️ (CoreIMU): Return g intead of mg
- ✨ (spikes): Add spike imu_kit_fusion
File comparision analysis report🔖 Info
Click to show memory sections📝 SummaryClick to show summary
🗺️ Map files diff outputClick to show diff list
|
File comparision analysis report🔖 Info
Click to show memory sections📝 SummaryClick to show summary
🗺️ Map files diff outputClick to show diff list
|
Codecov Report
@@ Coverage Diff @@
## develop #1245 +/- ##
========================================
Coverage 98.70% 98.70%
========================================
Files 147 147
Lines 3788 3788
========================================
Hits 3739 3739
Misses 49 49 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
ladislas
force-pushed
the
ladislas/feature/ahrs-fusion
branch
4 times, most recently
from
dca2820
to
3f25929
Compare
ladislas
force-pushed
the
ladislas/feature/ahrs-fusion
branch
from
3f25929
to
9df5409
Compare
Version comparison
|
ladislas
force-pushed
the
ladislas/feature/ahrs-fusion
branch
2 times, most recently
from
07509e6
to
5d93e18
Compare
ladislas
force-pushed
the
ladislas/feature/ahrs-fusion
branch
3 times, most recently
from
d2abe92
to
1398594
Compare
spikes/lk_sensors_imu_lsm6dsox_fusion_calibration/CMakeLists.txt
Outdated
Show resolved
Hide resolved
| const FusionAhrsSettings settings = { | ||
| .gain = 0.5F, | ||
| .accelerationRejection = 10.0F, | ||
| .magneticRejection = 0.0F, | ||
| .rejectionTimeout = static_cast<unsigned int>(5 * kODR_HZ), // ? # of samples in 5 seconds | ||
| }; |
There was a problem hiding this comment.
This answer to my previous question. Seems those parameters to have an influence on results or this is insignificant compared to calibration for instance ?
There was a problem hiding this comment.
they don't work on the same things.
calibration is the first thing that you need. working with uncalibrated values is like working with no values at all.
Once you have calibrated values, you can improve the results better.
| @@ -0,0 +1,143 @@ | |||
| // Leka - LekaOS | |||
There was a problem hiding this comment.
Sometimes, the spike does not logs anything. Is it logs itself or the computation that clog the output? In second case, that might impact performance of robot, especially for reinforcers.
There was a problem hiding this comment.
Are there "CPU usage" measurement to compare with the other method?
There was a problem hiding this comment.
Sometimes, the spike does not logs anything. Is it logs itself or the computation that clog the output?
it's an issue with the LSM6DSOX and it happened before using Fusion -- I'm still trying to understand what is happening.
In second case, that might impact performance of robot, especially for reinforcers.
I don't know, but I'm pretty confident it won't change anything as the computation is very fast
Are there "CPU usage" measurement to compare with the other method?
no, as you know we don't have that.
but at 104Hz for the ODR, the computation was happening is less than 1ms, so no worries there.
As for performance and efficiency, see:
| const auto q_w = quaternion.element.w; | ||
| const auto q_x = quaternion.element.x; | ||
| const auto q_y = quaternion.element.y; | ||
| const auto q_z = quaternion.element.z; |
There was a problem hiding this comment.
Since quaternion are hard to read and interpret, I don't think it is necessary to expose them.
There was a problem hiding this comment.
in IMUKit, I agree, they won't be exposed.
for this spike, they are necessary because they are sent to the x-IMU3 software for calibration. It's important to have the low level data.
as of "hard to read and interpret", they are mathematical constructs invented especially to make reasoning about 3D rotations easier.
People mostly want Yaw/Pitch/Roll but as soon as you start looking under the hood, you need quaternions
An amazing explanation by Ben Eater https://eater.net/quaternions
| // ? Apply calibration offsets | ||
| gyroscope = | ||
| FusionCalibrationInertial(gyroscope, FUSION_IDENTITY_MATRIX, FUSION_VECTOR_ONES, gyroscopeOffset); | ||
| accelerometer = FusionCalibrationInertial(accelerometer, FUSION_IDENTITY_MATRIX, FUSION_VECTOR_ONES, | ||
| accelerometerOffset); | ||
|
|
||
| // ? Update gyroscope offset correction algorithm | ||
| gyroscope = FusionOffsetUpdate(&global_offset, gyroscope); |
There was a problem hiding this comment.
I read the documentation and examples from github Fusion, but I still don't understand the difference between FusionCalibrationInertial and FusionOffsetUpdate.
There was a problem hiding this comment.
-
FusionCalibrationInertial- see https://github.com/xioTechnologies/Fusion#sensor-calibration - it's just a calibration function, you apply offset to the raw values to have the correct ones. The offset values are calculated before running the application. -
FusionOffsetUpdate- see https://github.com/xioTechnologies/Fusion#gyroscope-offset-correction-algorithm - this is an inflight calibration algorithm: it senses when the device is stationary and fine tunes the offsets of the gyroscope
ladislas
force-pushed
the
ladislas/feature/ahrs-fusion
branch
from
2085966
to
4464654
Compare
ladislas
force-pushed
the
ladislas/feature/ahrs-fusion
branch
from
4464654
to
574ee02
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
