Vex IQ Gyro drifting issues

Programming Support VEXcode IQ Technical Support
#1

My team is currently using the Gyro and we’ve noticed that if left alone without touching it, the gyro drifts its value. For example, if we start the program and just print out the heading of the gyro, it starts and zero and just gradually increases its value. We’ve had issues where after a minute of driving, we turn the robot back to what we think is “0” heading, but the gyro reads 90+. Is there any recommended way to help with this drifting issue? We’ve noticed the drift isn’t as bad if we move the robot inside and the field is not elevated. We’ve tried to “calibrate” the gyro for 8 seconds, but there’s still a drift (but may not be as bad).

We’re currently using Vex IQ code blocks, but can switch if the API is more extensive for Vex code text. I looked at the c++ vex_gyro.h and saw that @jpearman wrote that class.

#2

Some drift is to be expected but if the gyro is calibrated at the start of the program (which happens by default if you have it as part of the Drivetrain) then that level of drift is by no means normal. Can you post your code?

1 Like
#3

The code is just basic to reproduce this. This is Code IQ Blocks, so When Started -> print Gyro heading and watch it increase

#4

Try calibrating it first. There should be a block for this under Sensing.

1 Like
#5

Thanks. We’re not using the drivetrain because the kids implemented for an X-Drive and Kiwi drive. Calibrating helps, but it the rate the gyro is changing gets worst when driving. In other words, if we don’t touch the robot after start, the drive is +2/100th every second, but if they drive around for a few seconds, then look at the gyro, the rate of change increases to around +30/100th every second and gets worst if they drive longer.

#6

You could possibly block small gyro inputs.

#7

You mean block small gyro inputs as in resetting the heading to 0? That doesn’t work because the program needs to know the exact heading where the robot is all the time.

#8

No. As in the way you threshold a controller. If the change in the heading is very small, don’t add anything. If it’s big enough, then add it in. No resetting required.

1 Like
#9

There’s no difference between blocks and C++, it all uses the same SDK. The gyro integration is inside the gyro sensor, so different programming environments should also make no difference.

Does the gyro drift if you just go to the devices screen and look at its value there ? Is the gyro away from any additional source of vibration, motors etc. ?

5 Likes
#10

That wouldn’t work for our application. We’re taking the value that is read from the gyro and performing math on it, then taking sine/cosine etc.

#11

Thanks. Yes, it’s closer to the motors. We can try to move it away from the motors.

#12

if you can try to move it to a low point of the robot, low points on the drive base tend to vibrate less becuase there is more support arround it

#13

Yes, but that’s a double edge sword. The motors are down low and would affect the gyro. We’ll need to play around with the location and make sure it’s secure

1 Like
#14

simple robotc implementation

task main() {

    float gyro = 0;

    float read = 0;
    float previous = 0;
    while (true) {       //main loop

        read = getGyroHeading(gyroSensor) - previous;

        if (read < 0.5) {

            gyro += read;

        }

        //do stuff

        previous = read;
    }
}

Also, those may not be the correct functions to use. I don’t really remember what exactly they were.

3 Likes
#15

Ah, ok. Thanks. I understand. The only problem is at one time when the kids were driving around for awhile, I saw it drift over 90 degrees, so even with this, it wouldn’t have helped

#16

You might be able to use a second one on top of the first one, and then average them out. The top one might need to be flipped to get better results.

4 Likes
#17

In my personal opinion, vex iq gyros are low quality and not worth the hours of research and frustration. I know it seams appealing to educators and students but if you don’t want every line in your code at motor speed 10, there are better options. A few things you can do are:
-make sure your drive motors actually spin at the same speed in device settings. different factory batches and levels of wear matter here
-use the tightest gears you have where it matters. worn gears have more give and cause inconsistencies
-make sure the shaft types are the same on both sides. For example, avoid having all metal on one side and plastic on the other
-use motor encoders and while loops on turns. we found that they work better than the typical turnRight/Left command
-use the straight edge of your robot to align against the wall by backing up for a set time. this serves as a kind of course correction for long auto sequences.

sincerely,
a person who has possibly the highest recorded squared away auto without sensors

8 Likes
#18

Do you have an example of using “Motor encoders and while loops on the turns” that you can share?

1 Like