Gyro angle in simulation vs reality?

[GuyM142]

Originally Posted by billbo911

The gyro is not the issue. The issue is how the code is interpreting and displaying the data that sensor is sending to it. For all intents, any gyro running this particular could would behave the same way.

If you want the values to continue to increase/decrease, then the code must be written that way.

The gyro is just a sensor. What the code does is take the sensors output an converts it into something useable.

Ok, so for my needs continuous increase/decrease would be the best "convertion" of the gyro volts readings.
Now, the default code is giving me +/-180 degrees range and I can't change it so I'll have to use it that way.
I'd like to have a vi that gets X degrees as an input and moves the robot X degrees CW, can I have some help with that?
If my current Angle is 90 and I want to move 100 degrees CW, I should end up at -170.. I don't know how to get to that.

[billbo911]

I'm not sure which example you are using, but here is what I found.
If you open LV and click on "Support". Then select Find FRC Examples, you will find a Gyro example under the Analog folder.

The Get Angle vi returns two things: The current angle relative to where the robot started, and the current angular rate of rotation.

If you use the "Get Angle" output, I believe you will find what you are looking for.
See the attached image.

[Ether]

Originally Posted by GuyM142

Ok, so for my needs continuous increase/decrease would be the best "convertion" of the gyro volts readings.

Would you mind sharing with us what you are trying to accomplish and how you determined that a continuous increase/decrease sensor output would be best?

Now, the default code is giving me +/-180 degrees range...

Interesting. In Java, the gyro angle is returned as a continuous increase/decrease from the starting value:

    /**
     * Return the actual angle in degrees that the robot is currently facing.
     *
     * The angle is based on the current accumulator value corrected by the oversampling rate, the
     * gyro type and the A/D calibration values.
     * The angle is continuous, that is can go beyond 360 degrees. This make algorithms that wouldn't
     * want to see a discontinuity in the gyro output as it sweeps past 0 on the second time around.
     *
     * @return the current heading of the robot in degrees. This heading is based on integration
     * of the returned rate from the gyro.
     */

I'd like to have a vi that gets X degrees as an input and moves the robot X degrees CW

Is there a reason you always want to rotate the robot clockwise? In other words, if "X" is 359 degrees wouldn't it be better to rotate the robot 1 degree counter-clockwise?