Gyroscope

I got a vex gyro at worlds and I set up a code in RobotC but it wont work. I do not have cortex and I have looked around on the internet to find out how to get it to work but I can not seem to get the gyro to work. can any one help with this?

When you say that you cannot get it to work, you need to be more specific. What exactly is going wrong? What have you tried? What were your results? You should also post your code. The more information you provide, the more people here can help you.

I was actually wondering what the gyrosopes are capable of. Are they like very accurate?

I opened my teams Gyro yesterday, and from what i can tell is that it returns rotation in tenths of a degree so for an angle of 245.6 deg, it will output 2456. However, when you turn the robot on, the gryo does not read 0.0 deg, and you cant write a variable to it like you can with the encoders.

Something else I noticed, is when you turn slowly, the gyro is much more accurate, than when you make short abrupt movements. this concerns me, as our robot will not take 5 seconds to spin 360 deg.

hmm. what do you mean when you turn the robot on it doesn’t read 0. it doesn’t zero at the beginning of every match?

ok so im getting wierd readings from it, like it will start from 0 and go up to about 4000 and then start again and the robot will not be moving.
im thinking that my code is wrong but it looks like it should work

my code is

#pragma config(Sensor, in16,    Gyro,                sensorGyro)
#pragma config(Motor,  port1,           LeftD,         tmotorNormal, openLoop)
#pragma config(Motor,  port2,           RightD,        tmotorNormal, openLoop, reversed)
#pragma config(Motor,  port3,           RightL,        tmotorNormal, openLoop)
#pragma config(Motor,  port4,           LeftL,         tmotorNormal, openLoop, reversed)
#pragma config(Motor,  port5,           LeftC,         tmotorNormal, openLoop)
#pragma config(Motor,  port6,           RightC,        tmotorNormal, openLoop, reversed)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

task main ()
{
 SensorValue[Gyro] = 0;


    while (SensorValue[Gyro] < 90)
    {
      motor[LeftD] = -127;
      motor[RightD] = 127;
    }
  }

I don’t have a Gyro so have not been able to play with it yet, however, normally a gyroscope will not measure the angle of rotation directly but rather angular velocity (or is it change of angular velocity, I forget).

Read through this thread if you have not already done so it contains lots of good tips.

https://vexforum.com/t/vex-gyro/19027/1

oh I read that thread but it just confused me even more

Don’t feel bad, gyros in general can be tricky to use and, if vamfun’s findings are correct, RobotC v2.32 does not support it correctly yet. Vamfun posts some code in his blog that handles initialization and integration of the raw sensor data. Hopefully RobotC will include functionality to simplify this soon. Guess I need to order one and test for myself.

and now even more confused

Mark

I will try and post a simplified explanation in the next couple of days.

I dont think we are getting raw sensor data in robotC, because right now i have a demo on a robot where all it does is read the current value of the gyro out to an LCD Screen. and from what i can tell, integration isn’t necessary.

I don’t have a gyro so I’m at a disadvantage here, however, vamfun’s code is treating the gyro as a pot so he gets raw data. Perhaps Jesse from CMU can comment and give us some insight to whether V2.32 is supporting the gyro correctly and what the sampling rate etc. are.

What numbers do you see? does rotating the gyro by 90 deg change that number by 90 or some other amount?

So although it’s already been posted elsewhere that RobotC v2.32 does not yet correctly support the gyro, though I would do some experiments tonight. Although I do not have a gyro it is possible to simulate one by using a potentiometer just to see how RobotC is integrating the raw data. So I setup a pot on input 1 but told RobotC it was a gyro. The pot was set somewhere in the middle, the output was around 2V (btw, this was not a vex pot but a multi-turn precision one). Some test code was written just to show the SensorBias, SensorValue, SensorFullCount and SensorScale. The pot was then adjusted a small amount to simulate a slow rotation of the gyro, the SensorValue as expected started to change. A few observations.

  1. Although SensorFullCount reports 3600 as the maximum value, often the rollover count is somewhere around 2300.

  2. The gyro does not always init correctly, adding this …
    SensorType[in1] = sensorNone;
    SensorType[in1] = sensorGyro;

    seems to help.

  3. The default SensorScale is 260, a bit more coding to turn the angle back into deg/sec shows the angle to be underestimated with this value. Setting SensorScale as 135 seems to both correct this (if my calculations are correct) and also correct the rollover point ie. the SensorValue goes to 3599 and then back to 0.

So a possible initialization sequence for the gyro may be …

#pragma config(Sensor, in1,    gyro,                sensorGyro)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

task main()
{
    float  angle;

    // force gyro to reinitialize
    SensorType[in1] = sensorNone;
    SensorType[in1] = sensorGyro;
    // change sensor scale
    SensorScale[in1] = 135;
    
    // 2 second delay for init, may or may not be needed
    wait10Msec(200);
    
    while(true)
        {
        // Get gyro angle in degrees
        angle = SensorValue[in1] / 10.0;

        // do something with the angle ...


        wait1Msec(10);
        }
}

This is just a theory but if someone with a gyro want to try let us all know.

Since the initial value of the gyro is not always 0, from what i understand, I’m wondering if you can “set” the actual initial value as zero. What I mean by this is you can have the bot store the initial value to a variable, and every value thereafter is subtracted by that initial value.

Let’s say the gyro returned a value of “90” when it was actually at 0. You can do 90-90 to get 0. and then subtract 90 from every value the gyro returns afterwards. If the numbers get negative (because it’s 0->4000->0, if I’m not mistaken) multiplying by (-1) should give a proper value.

I hope my proposed “solution” isn’t too ridiculous, as currently I don’t have a gyro to experiment with.

I bought a gyro at worlds to experiment with. Since there was so little documentation I had to do a fair bit of external reading first. the solid state gyro measures a change only as it is moving. this means in order to determine your heading you need to integrate changes over time. Vamfan’s code is set up to do just that. The code samples the output of the gyro, converts the reading to a angular offset and then accumulates the reading into a variable representing current heading. a gyro naturally has some drift as well. this means that as it is sitting still it outputs a reading as if it is moving (called a bias). the first thing a gyro function needs to accomplish is to determine the bias, this then is used to correct the raw output of the sensor prior to conversion and accumulation. Vamfan reports the Robot C platform does not implement the gyro code correctly. I did not test that function. Since our team uses Easy C, the first thing I tried was the Easy C function but I did not get consistent results, or to be more precise the output was off by a significant amount while rotating the gyro back and forth through a fixed arc. In desperation I built a test rotation platform and attached a gyro and an optical shaft encoder (to have a reference for the rotational offset). I wrote a function in Easy C based upon the work Vamfan had posted. I found in Easy C that I still had a growing error in one rotational direction. Worse yet I saw this error in the Optical encoder output as well (after several rotations back and forth the encoder output would not return to zero when I returned to my starting location). So I switched to Robot C and using the same hardware repeated the tests. This time I could use the code Vamfan posted and just had to add code for the Optical shaft encoder. I found I got much better results. The optical shaft encoder portion gave me results consistent with what I had expected. The Gyro code Vamfan posted worked as he described the gyro would still ‘drift’ over time but for short periods of time (such as the 20 sec of autonomous) the error was still reasonably small.

In summary it appears neither Robot C nor Easy C included functions for the Gyro work as you might expect. but at least in Robot C you can implement your own.

You can implement a recurring function in Easy C which is similar to a task in Robot C, but it did not seem to yield solid results. - I may still have a logic error here?

If you write your own gyro function in Robot C (see Vamfan’s code) you can get reasonable results.

I need to do more testing with a robot ‘base’ as the amount of rotation measured will change based upon the location of the gyro and the pivot point, as long as your robot has essentially a single point of rotation for example spinning left wheels reverse and right wheels forward at the same time would have one pivot point vs just moving the right wheels would yield a different pivot point. Accounting for this difference might prove to be very challenging.

Good Luck and happy building! - Kevin

When I rotate the bot 90 degrees, the value increases 900 units. and when you get to 3600, it goes back to 0, indicating that it is reading out in tenths of a degree.

Well that sounds exactly right, I wonder why everyone is having issues, guess I have to send off my $40 to find out.

I posted in the robot c forums and Jesse responded there

here is the link to the thread:
http://robotc.net/forums/viewtopic.php?f=11&t=3382

I tested the function included with RobotC last night and found that while it seems to give reasonable responses some times it will also suddenly change values from 0.0 to a value of approximately 134.0 without moving the gyro. I’m sure an update is going to come out, not sure when, the code Vamfun posted works well though.

Cheers Kb