[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 post¹⁾.

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.

• Sensor values can be negative! Turning in one direction from the starting “north pole” will give a positive value; turning the other direction from the starting point will give negative readings.
• If the sensor is installed upside-down (on purpose or by accident), it will still operate with the same accuracy, except that the positive and negative directions (clockwise or counter-clockwise turning) will be reversed.

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.

1. In all testing and when a team is creating its programs, use the LCD screen every step of the way and print out as much data as possible while figuring out how to use this sensor. Teams will really be happier for it.
2. Watch the video below from Team 1826A from their 2017 STEM Educational Video Online Challenge entry about this sensor. While only 3 minutes long, it's full of incredibly useful stuff. For scaling one's component, pay close attention at time mark 2:20 to see the device that this team created to test their sensor; it's pretty cool, and not that complex. (They also demonstrate the effects of vibration on the sensor at this time.)

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).

• Teams need to create a very basic test program on their robot that clears any old sensor data, gets the analog data from the sensor, and prints it to the LCD screen.
• Place the robot on the competition field and line up a corner of the chassis as closely as possible with the corner of a field tile.
• Turn on the robot and let it sit perfectly still for 5 seconds. The LCD should read 0.
• Pick up the robot and turn it exactly 90 degrees so that another corner of the robot is lined up with the field tiles. Write down the number shown on the LCD.
• Do this 3 more times for 180 degrees, 270 degrees, and back to 360 degrees where it started. [In easyC the sensor count does not “loop around” to 0 after it turns 360 degrees; it keeps counting up forever if turned continuously in the same direction (like an Integrated Motor Encoder). In RobotC, the reading does reset to 0 after a full revolution.]

To calculate the scaling factor:

• Divide the first reading by 10 and then by 90 (since the reading is in tenths of a degree)
• Divide the second by 10 and 180
• Divide the third by 10 and 270
• Divide the 4th by 10 and 360; if the sensor did “loop around” to 0, add 3600 to the number on the LCD screen, then do the division.

Hopefully these resulting numbers will:

• all be reasonably close to 1.0 (in Team 1666's program, we ended up with 0.94), and
• all be reasonably close to each other.

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).

• Turn the robot off and on in between each of the following tests so that the gyro completely resets to 0.
• Drive around randomly, as in a match, for set periods of time, stop, and line the robot back up with the field tiles and check the gyro's value. How close to 0 is it?
• Drive back & forth in a straight line for 30 seconds and see what the drift is now.
• Spin slowly in place for 5 rotations. What is it now? How about 5 rotations in the other direction – is it the same? (Let's hope it is.)
• Let the robot sit in one place without driving it at all for a minute or 2; what happens?
• Do the above tests 5 times each; does the sensor result about the same drift each time?

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.