Our inertial sensor will randomly swap directions. Normally turning clockwise increases the value and turning counterclockwise decreases the value. However, sometimes, with no apparent cause, this will swap and turning clockwise will decrease the value while counterclockwise will increase the value. As you can probably imagine this causes a variety of issues within our autons and programming skills. Is the sensor faulty or is there something we can change in the code?
How did you mount your sensor? Which side points up?
From what I understand when IMU starts up it detects which way is up and then computes quaternions with angles in all directions.
Could it be that you are tilting it causing it to think its up orientation changed?
I haven’t played with it yet but shouldn’t it increase CCW and decrease CW, right hand rule?
It’s mounted on the bottom of a 1x5 C-channel upside down. The C-channel is mounted via 4 rubber cortex mounts. It’s possible that mounting it upright could fix this issue, I’ll try that.
Can you post the code? I might know how to fix the problem. If you are you using the .heading(degrees) method try .rotation(degrees) instead. This is because .heading(degrees) returns a value from 0 to 360, while .rotation(degrees) can go above 360 and below 0. Also make sure you are on VexOS 1.0.9
Is it known if there is IMU filtering with sensor outputs? Obviously advanced dynamic systems and statistical predictions such as the Kalman filter wouldn’t exist, but is there quaternion complimentary tilt correction or any complimentary corrective filters for noise and bias?
We would rather not post the code since it’s really advanced and unique. We are using heading, but we actually created our own code that makes the heading work as rotation. Unfortunately the issue isn’t related to the counts resetting at those values, but is that the direction of the value is swapped.
These quotes give some insights on the way Inertial Sensor processes measurements:
Also, IMU diagnostics example: V5 internal sensor Code
It is hard to say what is going on without more detailed debugging information. I would start by opening IMU dashboard and observing all available numbers as you manually rotate the robot.
2 Likes
My team just had this same exact issue. IMU worked fine for days. Mounted right side up with the connector facing towards the back of robot. Calibrating before each run. Using yaw() parameter and turns that are way within the -180/+180 range. Until today spinning robot clockwise showed positive values (0 to 180), CCW showed negatives. Today this reversed, where turning robot CW shows negative numbers and CCW positive. After a long freak-out session from my programmer we displayed all output from IMU on brain screen and observed this bizarre phenomenon. We reversed things in code but then the IMU decided to go back to normal. The only events that happened today were possibly hitting the IMU with a cube (by accident). Then we unplugged it and plugged a spare IMU to compare. Replugged the crazy IMU and things reversed again, but not sure if total coincidence. It’s definitely a real thing and a programmer’s nightmare.
Our issue completely disappeared once we flipped the sensor to be upright. In fact it’s mounted the exact same way as you describe and no longer has any issues 
1 Like
Strange. Our issue is gone as well but in the back of our heads there is that looming thought that it DID happen and it MIGHT happen again, at the wrong time, aka at States where autonomous turn PIDs just go nuts and robot starts uncontrollably shaking. The other annoying issue is that we completely went through a huge pile of anxiety and panic attacks and did not do cool head research. We did notice the flip and frantically unplugged and re-plugged everything, but did not record every single parameter to figure out what happened. Is it that the yaw() class is just badly computing somewhere inside VexOS (we use the RobotMesh Python API, maybe that has something to do with it), is it that the whole IMU thought its world flipped upside down, we just don’t know. I also owe our programmer an apology because after checking that the IMU calibrates, stays within the usual minimal drift, responds to rotation (took a while to realize rotation is negative) and that the motors spin ok and the standard normal everyday routine thing we do nowadays - CHECK FOR BURNT PORTS, I insisted that it is the PID code that got messed up (because let’s face it, it’s always the programmer’s fault), but I was wrong - there, I said it.
1 Like