Hello,
Has anyone else encountered problems with the Vex Gyro?
I was trying it out with the Vex PIC Micro controller and it was giving me some weird readings, it was outputting around about 455 for a full 360 turn and I couldn’t figure out why it was outputting that, so I tried it with the RobotC Gyro test, it gave me a reading way different. Is there a problem with the Gyro and RobotC firmware? Its RobotC 2.32 (latest) with the latest driver, RobotC firmware and Master Firmware.
Can you post your code, to make it easier for me to follow along?
(I bought a gyro at Vex Worlds)
There is a bunch of discussion on DIY drones and Sparcfun that “Kalman filtering” is required to merge together 3d accelleration with 3d gyro measurements to get a true Inertial measurement unit. Someone has a nice youtube video also.
If a gryo provides “rate of rotation” value, you’ll have to integrate to go from rate to current position. To integrate, I thought about using a separate task (RobotC) or a “Timer Repeating Interrupt thingy” in EasyC.
I have also had some disappointing behavior with a gyro using Easy C for Cortex. I have not contacted tech support yet but plan to soon. I mounted the gyro on a turntable kit, but off center from the rotation axis.
I wait a second between init gyro and start gyro in my init code. I’m not sure how long they need to be ‘quiet’ on start up. I can rotate the gyro through small deflections back and forth, and the readings started at 0 most of the time and would vary by a couple hundred in either direction as I rotated the platform The readings do not consistently move up and down as I would expect rotating CW and CCW.
Does the gyro need to be positioned in a specific orientation relative to the point of rotation? I have mine mounted on a claw bracket just off center from the point of rotation.
I’m watching now and as the robot is sitting still the gyro reading is slowly increasing.
The issue of the gyro drifting is one that comes with all gyros. The better the gyro the less drift you’re going to get, but no matter what you’ll still have a small amount of change after the gyro comes to a stop. One simple way to deal with this is to not directly get the gyro value when you want to use the angle, but rather have another function that you call at the top of every loop through your code that checks the gyro value and if it has changed by more than some arbitrary limit add that change to a member variable that has a value for the supposed actual angle of the robot. This should in theory ignore the slow drift that occurs.
Unfortunately, I have not yet worked with the new gyro so that may not be the best way to go about it. I know with gyros on FRC robots you occasionally have to play with the sensitivity of the gyro, so I’d look for some function in Robot/Easy C that can alter the sensitivity of the gyro to a point where the drift is minimal and it is unnecessary to filter it. The gyro may also be reading a rate of rotation as jgraber said, and like he said you would then need to integrate that in order to get a usable angle if that is the case.
As for mounting the gyro, mounting it as close to the point of rotation as possible will provide the best values.
Ah, but the online help indicates the functions provided at least in Easy C do all that hard work for you. start the routine, wait a second or so for the Gyro to stabilize, and start getting headings from the sensor. The assumption I had is that as the sensor is rotated back and forth through some (fixed arc) the heading reported by the function (provided in Easy C) would go from 0 through some positive and negative values but come back to 0 (or close) when the device was returned the starting location.
Having done some research on how to do this with the sensor ‘raw’ output as you mentioned I agree this is not a trivial task, but the supplied block function for the gyro should have done the hard work for the average user. I am trying to find out how this sensor can provide useful information to a robot project. I’m not sure how to incorporate it yet, but would like to figure that out so I can develop some instruction on how to use it effectively. Just getting started, and wondering what others have found that have experimented with the sensor.
I am going to continue to experiment and will likely try Robot C to determine how the 2 IDE’s treat the subject.
I’ll share what I learn as I get good information.- Cheers Kb
You got me interested in trying the gyro I bought at Worlds too.
Here is my blog post Note: Vex gryo. It contains a RobotC process_gyro() task that works reasonably well. The RobotC 2.32 doesn’t seem to have a working gyro routine yet.
The key point is that Vex did not scale the 3 v chip to 5 volts as I expected. They chose to scale it to 4.5v to get an even 600 deg/s/v board scale factor. This means that all the gyro spec numbers have a .9 factor on them. Once I took that into account I got the correct outputs. E.G. the expected 50% A/D of 2048 cnts with zero rate now becomes 1843.
The gyro takes 7 seconds to init in easyC and it must be perfectly still to do so. (We chose 7 seconds to make sure the bias voltage is stable) The numbers returned are in tenths of a degree unscaled so you don’t have to use floats. 90.1 deg is 901, all gyros will drift a little and should be used in a mobile robot that can’t use a Potentiometer or a Encoder to determine angle.
If you are using it in competition I’d recommend putting the InitGyro inside Initialize so it can compute the BIAS before the match.
Thanks I can give it longer to init. Documentation is very scarce on this topic. I was referring to the Easy C help Page:
…Most Gyro’s take approximately 1 second to initialize, during which time the Gyro should remain completely motionless. This time is used to calculate the bias and zero point of rotation for the sensor. It is also important to note that each Gyro has a maximum rate of rotation (typically between 80 and 300 degrees per second). Exceeding this maximum rate will result in a loss of calibration. …
It would be great if that got updated as well in the future. - I won’t get to test till this weekend look for an update then. - Kb
1 second is typical and seems sufficient to me. See my updated blog post that reflects more recent discussions with Vex support. 7 seconds sure works but I would like to see the reasoning behind it.
Hi Everyone,
The ROBOTC team is currently improving support for the new Gyro in ROBOTC. Thanks for your patience as we do so - I’ll be sure to post here when we have an update to ROBOTC with the improved support.
Looks like your current gyro works ok except the scaling is off. I.E. 2304 A2D-> 360 degrees.
As a controls person, I really prefer not having the output constrained to [0, 360]. We generally use error signals in feedback loops and must take extra processing to remove the nonlinearity produced by the cyclic output.
Perhaps you would consider having alternate gyro processing outputs
Gyro360 which is [0,360] and
Gyro180 which is -180,180] for closed loop heading hold functions. Or maybe
Gyro… which is continuous - max int word, max int word] so one could command a turn that is over 360 if desired.
The latter two facilitate autonomous while loops that test on gyro angle for turning left and right. I have had emails from students that can turn left but have difficulty in figuring out how to turn right due to the nonlinearity.
Also, it would be nice to have an unbiased gyro rate output to use rather than just gyro angle. WPI libs often neglect this and if you want to use rate in feedbacks special processing is required. I. E. you have to differentiate gyro angle rather than use the direct measurement.
Thanks.