[A note to readers who are using easyC. You may want to skip this sensor. Technically this sensor works in easyC, but this author's Team 1666 found it unusable, having spent ~20 hours coming to that conclusion. The communication of information from the sensor to the cortex was so slow as to be unusable. RobotC users on the VEX Forum are able to use this sensor effectively; there are few easyC users of this sensor to gather information from. (Wiki editors: add info here if available on easyC.)]
The gyro sensor is not like other VEX sensors, which are color-coordinated in red and white, with official VEX documentation. Instead, think of this sensor as a bare component that VEX commandeered for its product line. The official name for this sensor is the VEX Yaw Rate Gyroscope Sensor. It also differs from other VEX sensors in that there is no PDF instruction sheet—or any instructions on how to use it—on the VEX product page. What is linked on the product page is the STM Microelectronics LY3100ALH Datasheet, which is really only useful if one was building one of these components or taking one of these apart. Otherwise it is not useful for the VEX Robotics team.
First, the top is the side with the pins sticking out of it, and the 2 big holes are for screwing it onto the robot somewhere (more on that below). Connect this sensor to one of the analog ports on the cortex with the usual 3-wire extension cable; the black wire of the cable gets plugged into the pin that has a small “B” printed next to it on the component. If this cable is plugged in backward, nothing will happen. There is a teeny light on the component that indicates if it is getting power (labeled “PWR”, as shown in the photo above).
From here, in the most basic sense, the gyro like any other VEX sensor; the sensor gets initialized, information from the analog port is read by the team's program, that sensor value is assigned to a variable, and then something is done to the robot's functioning based on what the reading is.
The gyro is sensitive to vibration, a lot. So lots of vibration will cause the gyro to start “drifting” in its returned value; a lot of vibration will cause a lot of drift. And so will a little vibration over a long period of time while driving the robot.
The awesome **jpearman** from the VEX Forum did a series of tests on the sensor, mounting it in different places and noting the effects. First it was mounted on standoffs attached to the robot's frame, then he put some rubber couplers between the gyro and standoffs (acting as a cushion), which showed minor improvement. (This setup is shown in the image below from his Forum post; the rubber “stoppers” can be seen on top of the standoffs.) For the next test, he mounted the gyro on the highest part of the robot, away from the drive motors, and that showed significant improvement. See the full set of tests on the VEX Forum post1).
The caveat is that his tests were run with his robot propped on a box, so that the gyro would not change its value as a result of driving it around, but would only vary from the effects of the vibration. However, he said, this could not be exactly extrapolated to a robot driving around and he could not speculate as to those effects. A coach replied to his post and reported that his team's kids had a chassis-mounted gyro + mecanum wheels, and without special mounting, the drift was 20-50 degrees in 5 or 6 feet! They only added the rubber couplers under the gyro, and the drift was reduced to 3 degrees over the same distance. Rubber couplers appear to be a must-have when using a gyro sensor.
Another user suggested mounting the battery on top of rubber bumpers, screwing the gyro to the underside of a battery clip, and then turning it upside-down and clipping the gyro to the top side of the battery. The battery's mass would reduce small vibrations in addition to the work done by the couplers.
The sensor measures the degrees the robot has turned away from the “north pole” of where it was facing when it was turned on and one's program started running. The value the sensor returns is in tenths of a degree. So if it turns 60 degrees, the sensor would read 600.
The robot needs to sit perfectly still for several seconds when the gyro is started in order for it to calibrate itself to the big wide world. In competition programs, this gyro-initializing step is performed in the initialize (easyC) or pre-autonomous (RobotC) portion of the program, so it does this “I need to sit still so don't bother me” part when the team is standing around doing nothing anyway.
Every device is a little different, and none of them will return 6000 exactly when turned 60 degrees. So a team must figure out the scaling factor for its component before it can really use this thing. The good news is that the scaling factor is linear, so only one number/factor needs to be determined; it's not some crazy logarithmic or geometric thing that needs to be derived.
In Team 1666's use of this sensor, a less-sophisticated method was used to calculate the scaling factor, since it was already attached to the robot at the time. This procedure can be considered a more “quick and dirty” method for a Phase 1-type calibration (moving on to more precise “Phase-2” if needed).
To calculate the scaling factor:
Hopefully these resulting numbers will:
Then take a simple average of the 4 scaling numbers to get the final factor (0.94, in the case of Team 1666's component). Once a scaling factor is determined, the degrees the robot has actually moved from its “North pole” is represented by the following, which must be incorporated into the team's programming:
degreesTurned = sensorValue / 10 * scalingFactor
(and then truncate or round this to the nearest whole number)
According to the easyC help files, the sensor has a maximum rate of rotation between 80 and 300 degrees per second, so if the robot is spinning like a Tasmanian devil, it will probably give … misleading information.
As mentioned above, this is the biggie. The team in the video above obviously found a solution to drift, because they were able to aim their turret at the NbN net throughout the match after lots of driving around. Step 1 of reducing drift is reducing vibration, as stated above. The other is time; this sensor will definitely be easier to use in autonomous for a limited number of movements than in driver control with multiple turns and lots of movement for 1:45.
Teams need to first figure out what their sensor's drift IS, via testing and the trusty LCD screen. Line up the robot again to the corner of some field tiles & turn it on. Let it sit to orient itself; the LCD should read 0 (it will help if the LCD is programmed to display degreesTurned, unless one prefers thinking in terms or raw sensor output).
The point of all of this is that before trying to get really sophisticated with programming this sensor, a team has to have a really, really good understanding of the values it is outputting, and how those values need to be interpreted. Doing these types of tests, and figuring out if it is possible to compensate for the results programmatically or in the physical placement of the sensor will then reveal what a team will be able to use this sensor for. If the team can't figure out a way to compensate for drift after 20-30 seconds of driving no matter what programming or physical placement of the sensor is attempted, then the team might just be restricted to using it in autonomous mode, which has less opportunity for drift, since there's limited movement and autonomous is only 15 seconds, and is performed immediately after the sensor initializes. Be realistic.
There is hope; the last comment in this forum thread has this to say:
I am unsure what amount of drift others are experiencing, but I have had very good performances with very minimal (if any) drift with the gyroscopic sensor using the latest version (really, ever since version 3.x was released) of RobotC. Be sure to calibrate the sensor in the pre-autonomous portion of the Competition Template. You may also need to adjust the “SensorScale” such that the sensor's degree measurements are accurate. Information about calibrating the gyro and adjusting the SensorScale can be found here: http://robotc.net/blog/2011/10/13/programming-the-vex-gyro-in-robotc
This vamfun blog post from 2013 has some specific calculations that the author did concerning drift that more advanced readers may find helpful. This author cannot attest to its usefulness in 2017, as this methodology has not been independently tested or reported on. [Wiki editors, please add information here if available.]
In easyC, there is a parameter to set the “deadband,” or sensitivity level of the sensor. A lower sensitivity produces a smoother curve of output data; a higher sensitivity is more accurate, but the numbers are more jumpy. In RobotC, however, it does not appear that this is an attribute that the user sets, but also appears that it is not necessary, as RobotC handles noise automatically. Since this author has not used RobotC, first-hand information cannot be provided, but it's something a team should know about when configuring the sensor. [Wiki editors, please add RobotC content here.]
Some users—but not others—have reported that their gyro values are affected by electrical interference from nearby wiring or other components. It's another thing to keep in mind if a team is running into unexplainable problems; try mounting the component away from everything else and see if it makes a difference.
As shown in the video above and the forum quote above, some people have successfully integrated gyros into their robot lives. Other people are like the one in the quote below (pulled from this VEX forum thread), as well as this author, have not.
Unless you desperately need a gyro for something like position tracking, just use encoders. I have never had a gyro work either old or fresh out of the box.They are very finicky, and even with stuff like the QCC2 gyro lib, they still have noise and errors.
As mentioned at the start, now incoming information can be treated the same way as, say, potentiometer data being used to lift up an arm. If the robot is supposed to turn 90 degrees, as a very simple example, a while loop could be used:
desiredValue = round(90 * 10 * scalingFactor); actualValue = get(sensorValue); while (actualValue < desiredValue) { set chassis motors so robot turns; wait(100); actualValue = get(sensorValue); } set chassis motors to 0;
Since (a) Team's 1666 attempt to use this sensor in easyC turned into an epic fail, and (b) the team has not yet attempted to use it with RobotC, this author does not have programming specifics to add here. jpearman and lots of other thoughtful people have posted sample code in the VEX forum (and there is also sample code in the easyC and RobotC libraries). It is recommend that teams search for information in 2 different ways. (a) Google search on “VEX + gyro” or “VEX forum gyro”, etc.; and (b) go to the VEX forum and search all channels for the word “gyro.” These 2 methods will give some non-overlapping returns.
In addition, here is one helpful video from 2014 by Team 8756, that goes into specific details on how to program this sensor in RobotC, with screen-view/voice-over action. The gyro part of this video appears around 16:40.
Here's a link to a YouTube search of "VEX gyro" to point readers in the right direction for additional programming information.