Is it possible to use 2 gyros and then find the average angle degree? If so could someone send the code for VCS Vex C++
I believe someone got an innovative award for that. Check out this video.
It is both possible and legal. In C++ in the initialization area, just drop down another gyro in graphics, or add another initialization statement adding the second gyro if you are C++ Pro.
There’s a saying: a man with two watches never knows what time it is.
Is the same thing true for two gyros - you never truly know where you are? Would having two just cause confusion. I’m scratching my head at how useful having two gyros would be. Can someone explain the perceived benefits?
1 Like
@Gear Geeks I’m not sure if I can explain this in the best way possible, but here’s my take on the issue:
The VEX gyro from what I hear is pretty bad - it can do the bare minimum of returning a rotation value, but there a lot of things that can affect is accuracy, vibration, drifting (which varies by each sensor).
Let’s say you’ve got 1 gyroscope on your robot. You are attempting to turn 90 degrees. When you do so, the gyroscope is off by say, +5 degrees. Its returning 95 instead of 90.
Now let’s add another to the previous situation. This time its off by -3 degrees. Its returning 87 instead of 90. If you take the average between the values of the 2 sensors, you get 91 degrees, which is much closer to your desired value.
1 Like
That’s great if they are both off by a small amount. But, if they are off by that small of an amount, you wouldn’t really need two gyros.
The time when you would need two gyros is when one goes way off - but in that case, averaging the output would not really increase accuracy to an acceptable level. What is really needed is a way to detect when a gyro output is way out of school and disregard it. Because if you want to go 90 degrees and one gyro reads 92 and the other one goes haywire and reads 456, averaging them really doesn’t help get you to where you want to be.
1 Like
At that point you would probably want to incorporate a data filter to get rid of noisy values that are generated because of error. Have some sort of tolerance and when receiving data, see if its outside of your tolerance, and act accordingly.
One of our teams last year used 3 gyros to make get some pretty accurate readings. They basically did the averaging method I just explained and some method to filter out out-of-domain values.
1 Like
That makes a lot of sense.
1 Like
So would it just be ((Gyro1)-(Gyro2)/2)? And you would subtract because one reads negative?
You could do that and it will work well for small drift errors, but if error from one of the gyros suddenly jumps then it is not going to help.
The root of the problem is that actual Gyro reports angular velocity measurement (how fast the robot is rotating) and not the true heading angle. The heading is estimated in (vex) software by integrating measured rotation rate over time. If every once in a while you get erroneous measurement, the errors will accumulate and averaging two separate gyro estimates will have a lot of the error as well.
The right way to fix this is to filter the raw measurements of the rotation rate and throw out erroneous values before they have a chance to spoil the estimated heading value. This is how it is done in QCC2 gyro library:
https://vexforum.com/t/qcc2-gyro-and-pid-control-code/29292/1
If you have two gyros this will easily take care of any error sources that are independent and affect only one gyroscope at a time (like electrical and thermal noise). You want to throw out bad rotation rate measurements before averaging them and sending result into integration routine.
However, if the error source is going to affect both gyros - for example, robot violently bumps into a wall, then you will need to throw out measurements from both gyros (when they are far away from the expected range) and rely on the integration algorithm to coast over the time periods with bad measurements, using the last known estimated value of the robot’s rotation rate.
Still, if your robot bumps into a wall at high speed and rapidly changes heading angle, while measurements from both gyros will read garbage, you are going to lose good heading estimate anyways. At this point you need to either reset your true heading estimate assuming robot gets aligned by the wall, or avoid bumping hard into the wall in the first place by using ultrasonic sensor and slow down as you approach the field perimeter.
1 Like