This code shows a steady gyro drift even as the robot is stationary
The value read out do not make sense
Is the Gyro class tested and functional?
Is there something wrong with the code as written here?
gyro = vex.Gyro(brain.three_wire_port.b)
sys.sleep(1.0)
while True:
print gyro.value()
sys.sleep(1.0)
output:
0.0
0.0
0.0
-0.099999
-0.099999
-0.199999
-0.199999
-0.199999
-0.199999
-0.299999
-0.299999
-0.399999
-0.399999
-0.5
-0.5
So far as I can tell, there’s nothing wrong with the code as you’ve written it (Other than not preserving your formatting). It looks like vibrations or movement are affecting your gyro while it is calibrating. All of the gyro integration is done by the legacy port interface chip. Programming solutions for V5 (VCS, RMS, PROS, etc.) all just ask that chip for information and parrot back what it reports.
Be very sure that nothing is shaking or moving your robot for a couple seconds after the program starts, as that is the primary cause of gyro drift on a stationary robot.
what does gyro.value() return? rad? Deg?
Also- once you stop rotating the robot the value() continues to change . Why would that be? Same gyro with prosv5 C++ gives predictable results.
0.0
0.0
0.0
0.0
0.299999
0.599999
1.399999
2.399999
3.699999
5.199998
6.899999
8.699996
10.699996
12.699996
14.899997
17.199996
19.599998
22.0
24.599998
27.199996
29.899993
32.59999
35.299987
38.199996
41.09999
44.199996
47.299987
There are docs. It defaults to degrees.
As for why PROS might return more stable results, they might be defaulting to calling the calibration method with a longer delay. Try putting this at the start of your program:
gyro.start_calibration(4)
sys.sleep(4)
while gyro.is_calibrating():
pass
and see if it improves.
thanks - much better
is there a lag in gyro reading and the current position of robot ? I am unable to stop the robot turn correctly but eventually the gyro catches up and gives a correct reading.
seem s like a ~350ms lag between the motion and the gyro read?
motor has inertia and does not stop abruptly; gyro may also have a log but does not seem significant
How are you monitoring the gyro value?
in a loop and when gyro shows (say) more than 90. In practice, we find that the robot has turned by ~110 deg and the final gyro reading with a sleep of 1s matches with that. As an experiment, I moved the motors quickly and then started to read the gyro with 10ms delays - it took roughly 350ms for the gyro reading to stabilize. I also printed the motor velocity along with the gyro reading. Even when the motor velocity is set to 0, still the decay of velocity took time ~350ms and the gyro stabilized when the velocity became zero
Right, but printed to where? E.g. Brain screen, controller screen, console over tether, console over wireless. I’m thinking it’s console over wireless, and what you’re seeing is messages being queued up in the buffer for the rather limited wireless communication rate. I’m pretty sure if you spaced the delays from 10ms to 50ms or so you would see reduced lag to the console.
the printout is on the debug console. I think the message remain queued up on the “brain.” With various delays starting at 10ms to 50ms - the total comes to between 340ms-370ms. When we set the target velocity to zero- it makes sense that it would take “sometime” before it is achieved even when decelerating. which means that you have to setup up a PID control if you want to use Gyro to rotate an exact amount. I wonder how they did it DriveTrain class- one big lookup table I suppose.
If you notice, the drivetrain class takes your wheel circumference and wheel separation as parameters. It then just does math with those values to compute the number of revolutions each wheel should rotate for the specified turn angle and does encoder moves to accomplish them.
You have to do this regardless of how console reporting works. The robot’s inertia doesn’t dissipate instantly, after all.