Comments (8)
You need to stop conflating Euler angles with gyroscope axes. The gyroscope axes are X, Y, and Z. The terms roll, pitch, and yaw cannot not be used to describe the gyroscope axes. You said in #16 that this is "a convention I've been using". You need to abandon this convention. It is incorrect and causing you confusion.
from fusion.
Thanks for getting back to me! I think we're on the same page. Gyroscope input is currently a struct with X, Y, and Z fields. In the code base, there's no indication of which Euler angle matches to which struct field.
I think this could be solved with one or more of these approaches:
-
Adding to the
FusionAhrsUpdate
doc comment the order to pass gyroscope measurements. (https://github.com/xioTechnologies/Fusion/blob/main/Fusion/FusionAhrs.c#L92) -
Modifying one of the examples to be more explicit. For example, replace this:
const FusionVector gyroscope = {0.0f, 0.0f, 0.0f}; // replace this with actual gyroscope data in degrees/s
with this:
// Replace `roll`, `pitch`, and `yaw` with actual gyroscope data in degrees/s.
const FusionVector gyroscope = {roll, pitch, yaw};
- Accept a FusionEuler struct instead of
FusionVector
for gyroscope inputs toFusionAhrsUpdate
.
from fusion.
You believe there is a problem because you have a fundamental misunderstanding of Euler angles. The solution is for you to correct this misunderstanding, not modify the library.
To repeat, "Pitch, roll, and yaw are Euler angles. These terms are not applicable to gyroscope measurements of angular velocity.", and "The terms roll, pitch, and yaw cannot not be used to describe the gyroscope axes.".
from fusion.
I understand that.
The order matters in terms of fusing the accel and gyro measurements. The API and docs are ambiguous about which order you pass gyro measurements into the vector struct thats fields are named X, Y, and Z
Thought experiment: Let's say I store my gyro reading euler angles as variables pitch
, roll
, and yaw
:
I run this to perform an attitude update:
const FusionVector gyroscope = {yaw, pitch, roll};
FusionAhrsUpdateNoMagnetometer(&ahrs, gyroscope, accelerometer, SAMPLE_PERIOD);
Should I expect accurate results?
What if I substitute this line:
const FusionVector gyroscope = {pitch, pitch, pitch};
This
const FusionVector gyroscope = {pitch, roll yaw};
Re your last line, in an attempt to clarify:
Pitch, roll, and yaw are Euler angles... The API uses the Vec {x, y, z}
type, not the EulerAngle
type for updating the algorithm, and gives no indication of in which order to pass the measurements. These must be consistent, or they will fuse incorrectly with the other terms.
from fusion.
Your diagram labels the gyroscope axes: X, Y, and Z. The gyroscope struct fields are: X, Y, and Z. There is no ambiguity.
I have said that Euler angles cannot be used to describe gyroscope measurements four times now, and you respond by using Euler angles to describe gyroscope measurements. I suggest that we end this discussion. You are welcome to open a new issue on a different topic if needed.
from fusion.
If you compare the diagram I posted and what you enter in the algorithm, I think you'll find the first 2 terms (X and Y) are not consistent with the code and examples here.
Order of gyro measurements mapping The FusionVector
type as used as a parameter to the update fns:
Per that diagram: X, Y, Z
Per how this algorithm is coded, as defined in the quaternion x vector operation: Y, X, Z. This is how it behaves upstream in the update functions.
I understand you are done with this discussion; I'm posting this for the benefit of others who might run into the same ambiguity.
from fusion.
Hi, the discussion makes more confusion. I would like to explain more simplified.
The measurement from gyroscope is regarding to the sensor frame, whilst Euler angles indicate the rotation from current sensor frame regarding to the reference frame. That's why x-io always emphasizes "Pitch, roll, and yaw are terms not applicable to gyroscope measurements of angular velocity".
In the Fusion algorithms, the reference frame is Earth frame by NWU convention.
If sensor frame setting by manufacture is not matched with NWU convention, see FusionAxesSwap functions in detail.
from fusion.
Fixed by #9
This was caused by mixing JPL and Hamilton conventions, which is a classic quaternion trap.
from fusion.
Related Issues (20)
- Guidance on tuning Fusion for "responsiveness" HOT 2
- Inferring gyroscope range HOT 3
- Roll and pitch relative to device, yaw relative to earth HOT 2
- Linear/earth acceleration very slow to catch up with movement HOT 3
- TEST data HOT 1
- Python "No code object available for imufusion" with Setup.py or pip install HOT 4
- Measurement convention for sensors other than x-imu HOT 3
- How to use the magnetometer data with different sampling frequency from the inertial sensors? HOT 1
- Gyroscope Offset Algorithm HOT 7
- Link to dissertation is broken HOT 1
- Q: Influence of motion and external acceleration HOT 3
- Very noisy Roll Pitch Yaw data HOT 5
- Recommended sampling rate? HOT 2
- yaw value changes while rotating on only roll or pitch axis. HOT 3
- 5 seconds delay in real-time operation (python) HOT 2
- Need some help setting up the algorithm. HOT 14
- Application Questions HOT 25
- Integration of GPS data to estimate position and velocity HOT 1
- Proper way of calling FusionAhrsUpdate with accel, gyro and mag all having different update rates HOT 2
- What is the difference between this algorithm and madwick gradient algorithm? Can it still be called gradient descent algorithm? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fusion.