EV3 robots can use a Gyro sensor to determine the direction the robot is heading.

The initial conditions are important. The sensor needs to be still and then the sensor reset.

However, once in a while the Gyro returns values that drift over time.

What can be done to handle Gyro drift?

Step one would be to remove the drift using the

  • Hardware fix: unplug the gyro sensor, make sure the robot is still, and then plug in the sensor.
  • Software fix: Gyro Drift Simple Fix which should only need to be run once. Gyro Drift Simple Fix

However, I'm aware of several FLL teams using this fix and even then, once in a while the robot goes crazy, because the Gyro sensor has acquired a drift.

Applying the Simple Fix at the start of every run does not seem to fix it every time.

Is there a way to handle this?


There are two options that I can think of.

  1. Do the "hardware" fix before every run of the robot to reboot the sensor along with the "software" fix to zero it.

  2. Don't use the Angle reading at all. To calibrate the sensor, sample the rate (d/s) 10 times or so and take the average to get the "at rest" rate offset and store it in a variable. Subtract this variable from the rate returned by the sensor to get the actual rate. Integrate the rate over time to calculate the angle. (I haven't actually attempted this myself, but this is how you use, for example, the HiTechnic Gyro sensor since it does not provide an angle).

|improve this answer|||||
  • At least 1. can be done by FLL teams. 2. can also be done, but . . . wow is that complicated. How many samples per second? Does it fix the problem? It is better than "Don't use the Gyro sensor." which is my current recommendation. I was hoping for something less complicated. I'm going to give this a day to see if there is another option. – dfrevert Dec 22 '15 at 23:33

My team put their software fix in a loop with a small wait that cycles until the d/s = 0, then reset it to 0. Here's a simplified version: Gyro calibrate loop

It works like a charm. We don't mess with the hardware reset anymore. Combined with a heading variable, a turn my block, and a few drive my blocks they can program a maze run in minutes.

FWIW: They output their angle and rate to the display so they can monitor it even when not connected to a computer. They're working on checking the number of loops and total time it takes to optimize. Your team may need to play with the wait time a bit to get the best results.

|improve this answer|||||

The Gyro is a tricky sensor to use, but at yesterday's FLL competition in Elk River, at least 5 teams had worked out the issues to their satisfaction. I'm revealing their answers here. It is unfair to those teams, since their research does represent a significant advantage over other teams. That said, none of their solutions were complete. Each team had some part of the answer, but none had everything.

One team, not one of the 5, had given up on using the gyro in the belief that it could not be place close to the rechargeable battery pack because the gyro sensor would get too hot. I hadn't heard that before and have no idea if it has any basis in fact.

Almost all of the teams used the "Simple Gyro Fix" mentioned in the original question. They varied in whether they paused before, during, and after each step.

Two teams had tests to avoid leaving home base with a "drifting" gyro. One waited 10 seconds to see if the drift was still less than 2 degrees. Another ran the robot through a routine that cause the robot to twitch if it was drifting. No twitching meant it was ok.

A different set of two teams added a double reset of the gyro. This reset being the reset of the Gyro angle to 0. One of those teams said they had followed the advice of some site on the internet. That team also added a 1 second wait before and after the double reset. The first to "still" the robot; the second to ensure the zeroing of the gyro angle had been taken.

One team had a set of MyBlocks that turned based on either the rotation sensors or the gyro sensor. It allowed them to retreat from using the gyro sensor if they needed to. They had gone to the trouble because of the bad reputation of the Gyro sensor. In front of the judges, they used the gyro. It worked. Clearly, they had worried a lot and then figured out how to use it.

The teams differed in how they turned. Some pivoted, some spinned, and some accepted any motion.

One team used the gyro to go straight, sort of a proportional line follower with a gyro sensor instead of light sensor. They did not use it for turns.

None of the teams did the work of recording the drifting episodes to a file. None of the teams displayed a warning as a sound, a blinking light, or a message on the LCD panel before the robot left the home base. None of the teams switch automagically to the rotation sensors when the gyro is known to be drifting.

None of the teams used #2 of the accepted answer.

|improve this answer|||||
  • An additional suggestion from a team judged a couple weeks ago. They did their best to isolate the robot from vibration during the brick's boot up time. They started by demanding everyone keep their hands off the table, but found that less effective than placing the robot on the floor. – dfrevert Dec 14 '17 at 0:59

The most reliable way I've found to quickly reset the gyro is simply unplug it & plug it into a different input port, then unplug it & plug it back into it's port. Just unplugging & plugging it into the same port doesn't always work for me.

My software always has a 1 sec delay as the first step, and then software reset of the gyro. This is so after pressing the button on the brick to run the program I have a sec to remove my hand & the bot settles perfectly still, then the gyro resets itself to zero before any motors start to run.

Just this last weekend I started using the gyro to run perfectly forward & it works like a charm, but I haven't experimented how long until it's off by a degree, etc.

|improve this answer|||||

Your Answer

