Large amounts of gyro drift

[Aero]

I'm trying to use the KOP Gyro to control our orientation during auton, but the angle is drifting a lot without the robot moving.
This makes our robot drive in curves, and not in straight lines.
We're not doing anything funky programming-wise, the drift is observable with barebones code

from wpilib import SampleRobot, run, Gyro, Timer, SmartDashboard
class GyroTest(SampleRobot):
	def robotInit(self):
		self.gyro = Gyro(0)
	
	def disabled(self):
		while self.isDisabled():
			SmartDashboard.putNumber('Gyro', self.gyro.getAngle())
			Timer.delay(0.01)

if __name__ == "__main__":
	run(GyroTest)

The gyro starts at 0 (as it should) and without the robot moving, slowly starts creeping at a rate of about -1 degree / 5 seconds.

Any ideas? We've already checked our gyro's pwm cable.

[Ben Wolsieffer]

Are you letting the gyro calibrate correctly? You need to make sure the robot does not move at all during the calibration process, which occurs when you construct the gyro object and takes 5 seconds.

[Aero]

Yep, robot is totally still for calibration.

[lark95]

we had some really bad problems with this. Turned out that the signal wire to the gyro was going right by a cim, and speed controller. The RF noise was just enough to get the gyro to drift. We replaced the signal cable with a shielded one and all our problems were gone.
Hope this helps

[SousVide]

Gyros drift naturally overtime. Numerous ways to deal with this: You can re-zero constantly; you can assume drift overtime and compensate in your code; you can combine data with an accelerometer and/or magnet heading.

See "Drift" here:
http://www.phidgets.com/docs/Gyroscope_Primer

and here:
http://www.instructables.com/id/Guid...Arduino-inclu/

[Joe Johnson]

I have no financial interest in AndyMark or Kauai Labs but we are using the navX MXP Robotics Navigation Sensor and we LOVE it.

I was a complete skeptic when the coding team insisted that we could do Field Centric driving using our Wild Swerve modules. But after looking into it, asking a real roboticist that I am lucky enough to work with, and, most importantly, after seeing it work on Rover (Overclocked's fall "Practice Project"), I am a complete and total fanboy.

The navX MXP is amazing. If you are not using it, you should be.

It takes the literal "rocket science" technology from InvenSence IMU and puts it in an beautiful and well behaved (and Open Source/Open Hardware) wrapper.

IT IS AMAZING.

If you are using a gyro and you're not using a navX, I think you're missing the boat.

Free advice, worth every penny.

Dr. Joe J.

P.S. They claim 1 degree per minute drift. Again, I was skeptical but I think actually, in most cases, they do better than that. We will often practice for 20 minutes and stop because the motors are hot or the battery is dead not because we need to rezero the gyro. YMMV but that is our experience.

[virtuald]

We're using python + KOP gyro, and it works fine for me.

I've had issues with gyros in past years drifting too much... I think it's just something that's particular to some gyros.

Make sure you're actually using the same gyro that the WPILib is expecting you to use. If the volts per g parameter is wrong, then you'll get behavior similar to what you're describing.

[SuperBK]

Here is some calibration code I found here on Chielf Delphi. It basically involves adjusting the sensitivity with the gyro sitting still so that it doesn't change. It seems to help, although I don't know how accurate it was after changing the sensitivity.

	void CalibrateGyro()
	{
		// gyro should be out of cal mode by now,
		// try to find and set best sensitivity

		float fAngle;

		for(int uLoop = 0; uLoop < 10; uLoop++)
		{
			float fAngleSensitivity = Gyro::kDefaultVoltsPerDegreePerSecond;
			bool bLastAdjustmentWasIncrease;

			// reset the accumulator, stop a while and see if we drifted

			gyro.Reset();
			// taskDelay(sysClkRateGet() / 4);
			Wait(.001);

			fAngle = gyro.GetAngle();

			if(fAngle > 0.0)
			{
				fAngleSensitivity -= 0.0001;
				bLastAdjustmentWasIncrease = false;
			}
			else
			{
				fAngleSensitivity += 0.0001;
				bLastAdjustmentWasIncrease = true;
			}

			gyro.SetSensitivity(fAngleSensitivity);

			if((fAngleSensitivity > 0.0) && (bLastAdjustmentWasIncrease == false))
			{
				// we were adjusting up then went down a step - good enough
				break;
			}
			else if ((fAngleSensitivity < 0.0) && (bLastAdjustmentWasIncrease == true))
			{
				// we were adjusting down then went up a step - good enough
				break;
			}

			if((fAngleSensitivity >= (Gyro::kDefaultVoltsPerDegreePerSecond + 0.0008)) ||
					(fAngleSensitivity <= (Gyro::kDefaultVoltsPerDegreePerSecond - 0.0008)))
			{
				// the next number would be outside any reasonable value according to the datasheet
				break;
			}
		}

		gyro.Reset();
	}

[Ether]

Originally Posted by Joe Johnson

We will often practice for 20 minutes and stop because ... the battery is dead.

How "dead" do you let the batteries get during practice?

[washide]

We had similar drift issues and the most important things to do are:

1) ensuring a stable, secure, level mounting of the gyro
2) making certain that the gyro is perfectly still when it's being calibrated (as was already mentioned).

We were drifting around 1-3 degrees per second before mounting the gyro properly. Afterward, we had a drift of maybe 5 degrees after driving for a couple of minutes.

[Joe Johnson]

Originally Posted by Ether

How "dead" do you let the batteries get during practice?

How dead do our batteries get? I'm sure to be honest. The Coding Team has figured out a way to have our laptop play a sound "Low Power" sound when our battery voltage gets too low and then we change our battery. It seems to be working so I haven't looked into the voltage that they've picked.

Our robot for this year's game is not a huge current hog. We have 14 motors yes, but the Gripper & Pusher motors are off literally 95% of the time, the three arm motors and the lift motor are nearly perfectly counter balanced and the three wheels are never scrubbing because they are always pointed in the direction of travel with respect to the ground (thanks to the awesome programming of Paul, Michael, & Owen -- you guys are rock stars!). The motors that get hottest, believe it or not, are the three swerve motors.

Don't know if that answers your question, but that's all I've got...

Dr. Joe J.

[Ether]

Originally Posted by Joe Johnson

...our laptop play a sound "Low Power" sound when our battery voltage gets too low and then we change our battery.

Thanks for that clarification Joe.

I didn't want rookie readers to be left with the impression that you drain the batteries until the robot stops working.

Deep discharging is enemy #1 of lead acid batteries.

[slibert]

Originally Posted by Joe Johnson

... P.S. They claim 1 degree per minute drift. Again, I was skeptical but I think actually, in most cases, they do better than that. We will often practice for 20 minutes and stop because the motors are hot or the battery is dead not because we need to rezero the gyro. YMMV but that is our experience.

The navX MXP static yaw drift (e.g., when the navX MXP is still, and the ambient temperature is constant) averages just below 0.25 degrees/hour. This yields a very respectable 15 degrees of drift/hour when not moving - comparable to the ADXRS453. Our goal is to under-promise and over-deliver.

[Bacon8er]

Triple check that the analog port you are plugged into matches what port the software is looking at. A slowly changing input value is exactly what you would see on an open-circuited analog input channel.

[Jean Tenca]

Originally Posted by Joe Johnson

...we are using the navX MXP Robotics Navigation Sensor and we LOVE it.

I honestly wish this had been our experience. We bought two and have been experiencing problems with them across both competition and practice robots all season (it appears that the something gets hosed and the gyro only sends 0's instead of actual values). We've gone back to the KOP gyro while we investigate the problem.