I have an ICM20948 9DOF sensor. I have made a tilt-compensated compass, but I cannot understand why the pitch is negative when tilted up and positive when tilted down. Is this normal?
I have studied many different pitch and roll calculations, and most of them calculate pitch as follows: pitch = atan2(-ax, sqrt(ay * ay + az * az));
I know that the issue comes from the negative sign in front of ax, but why does everyone use this formula if it produces inverted pitch calculations?
If you watch this video (https://www.youtube.com/watch?v=7VW_XVbtu9k&t=666s) on YouTube, you will see that the person in the video has the same issue (even if he is not aware of it at the time). When he pitches up, he actually rolls, and when he rolls, the X-axis moves down, but the graph shows a negative value.
My question is: Should I use ax or -ax for tilt compensation?
Just off the top of my head and before any caffeine intake this morning, when one end is tilted up, isn't the other end by definition tilted down? Perhaps you are simply tilting up what the sensor regards as its back end, thereby tilting the front end down?
Based on the datasheet image and by double-checking the raw readings from the Serial console, when the X-axis moves down, the values are negative, and when it moves up the values are positive.The same applies to the Y-axis. Shouldn't the pitch also be positive when the X-axis moves up?
Ahh, okay. So X is positive when the "front end" tilts up. It's the pitch that goes negative. I think I've caught up now.
But like @DaveX, I'm having trouble reconciling the markings on the Adafruit board with the datasheet image. It looks like +Z would be down on the Adafruit board.
I think I definitely need some caffeine to make sense of this. I'm sure the accelerometer is fine, it's just my brain needs a jolt to get started...
I dont want to change it. I am just asking if this the correct reading i should be getting or i am calculating something wrong?
The tilt compensation works fine with this formula, i am just trying to understand why the pitch value is negative while it should be positive.
In fact the ICM-20948 has different axial orientations for the magnetometer and the accel/gyro. So those have to be reconciled in the code, before any AHRS or tilt-compensated compass can be expected to work properly. See below.
In the code I use, I invert both the magy and magz axes, and use the axial convention for the accel/gyro.
Then there is the issue that the direction of positive angle in navigational conventions is different from the mathematical convention chosen for atan2(). The sign conventions are NOT standardized across the board.
This aircraft scheme could be aligned with the magnetometer axes (X forward, Y right, Z down), make nose-up pitch a positive right-hand-rule rotation around Y, roll to the right positive RHR around X, and turn to the right positive RHR around Z.
I was struggling with this some months ago because almost no one ever mention that the mag axes have to be aligned with accel axes for the tilt compensation to work. Until i found a posts of yours that you mentioned that and also saw you AHRS code where you invert the signs of magY and magZ. That being said i thank you for your contribution!
My code already use the inverted magY and magZ and as i already wrote the tilt compensation works excellent.
Based on the other replies, as I understand, the negative value occurs because of the convention system used in relation with the accelerometer’s axes orientation. I know that i can use another convention or just invert the ax sign, but why almost every video/post/tutorial use this formula if it produces negative value when the nose is up?
Probably because the people posting those videos copied it from somewhere else, and/or don't care about such details. They just need something that looks like it works so they can finish making the video.
Much of the code you find on the web, especially Youtube and Instructables, doesn't work very well or conform to any recognizable standards, and projects you see done up on a breadboard are unlikely to work for long in a real-life application.
