Gyro angle in simulation vs reality?

[GuyM142]

The gyro in the simulation gives angles between -180 to 180 and when it reaches 180 it goes to -180.
Is it like this in real life gyros?
It makes it hard to make the simulation robot turn 180 degrees or more

[Chris Hibner]

See this post: http://www.chiefdelphi.com/forums/sh...6&postcount=18

There are also some other great posts in that thread on this topic.

Here's the thread: http://www.chiefdelphi.com/forums/sh....php?p=1182626

[GuyM142]

Originally Posted by Chris Hibner

See this post: http://www.chiefdelphi.com/forums/sh...6&postcount=18

There are also some other great posts in that thread on this topic.

Here's the thread: http://www.chiefdelphi.com/forums/sh....php?p=1182626

Ok, I understand now how to solve it.
Is it like this in the KIT gyro too?

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

[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?

[GuyM142]

Originally Posted by 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.

That's the vi I'm using, but it works differently in the simulator.
I think that the cRIO version of it would work the way I want to.

What I'm trying to accomplish is a vi which turns X degrees (rather than the shortest way to a certain angle), it doesn't even matter in which direction because I get stuck whenever the (current angle + degrees to rotate) is bigger than 180 or smaller than -180.
(The problem is the same for "rotate the shortest way to angle X, but leave it for now)
I hope I've explained it well

[Greg McKaskle]

The WPILiib VIs should behave the same for a simulated, analog, and digital gyro. The conventions of the simulator were quite different and had to be manipulated in order to fit into WPILib, and it seems like you've discovered a bug.

If you select the gyro VI in your code and choose Edit>>Create SubVI, it will wrap the WPILib version in a simple subVI. Try to modify it to make the simulated one behave the same as real-world, then use that instead until the bug gets fixed.

Greg McKaskle

[GuyM142]

Originally Posted by Greg McKaskle

The WPILiib VIs should behave the same for a simulated, analog, and digital gyro. The conventions of the simulator were quite different and had to be manipulated in order to fit into WPILib, and it seems like you've discovered a bug.

If you select the gyro VI in your code and choose Edit>>Create SubVI, it will wrap the WPILib version in a simple subVI. Try to modify it to make the simulated one behave the same as real-world, then use that instead until the bug gets fixed.

Greg McKaskle

I can't really change the code inside the gyro VI, I get to a level where I need to enter a password in order to make changes to the VI.
But i noticed that the angle value is coming from a a Honeywell Compass reference.
I don't get it.. why would the VI called gyro and inside it'll be a compass?
The gyro output really does behave like a compass would.

[Joe Ross]

Originally Posted by GuyM142

I can't really change the code inside the gyro VI, I get to a level where I need to enter a password in order to make changes to the VI.

Greg's suggestion was to make your own VI that looked for a rollover from 180 to -180, and when that happened, add 360 to the gyro output. If you kept a running total of gyro rollovers, this would work forever. This doesn't require any changes to the simulation.

Originally Posted by GuyM142

But i noticed that the angle value is coming from a a Honeywell Compass reference.
I don't get it.. why would the VI called gyro and inside it'll be a compass?
The gyro output really does behave like a compass would.

The trick in simulation is to make something that isn't real work "close enough" to something that is real. In this case, most teams are interested in the angle from the gyro. Rather then spend thousands of dollars to make a computer model of a gyro, they used a compass that was already implemented, and produced very similar data. As you noted, it is different in the rollover, however that is easily compensated for.

[Ether]

Here's a possible implementation of Joe's suggestion.

// initialization:
alpha=Go=getGyroReading();  // range -180 to +180

// iteration:
G=getGyroReading();
d=G-Go;
Go=G;
if (d>180) d-=360;
else if (d<-180) d+=360;
alpha+=d; // alpha is the continuous angle reading you've been asking for

[GuyM142]

Originally Posted by Ether

Here's a possible implementation of Joe's suggestion.

// initialization:
alpha=Go=getGyroReading();  // range -180 to +180

// iteration:
G=getGyroReading();
d=G-Go;
Go=G;
if (d>180) d-=360;
else if (d<-180) d+=360;
alpha+=d; // alpha is the continuous angle reading you've been asking for

Thank you! that's what I was looking for.
My goal was to make the simulated gyro work like a real FRC gyro for new programmers training.
I've attached my implementation (this is in periodic tasks)

[Ether]

At runtime if the result of the comparison circled in green is TRUE, does the LABview-generated code still perform the computations circled in red?

[Greg McKaskle]

There are two types of data flow diagrams, pull and push.

The pull type works from the answer backwards. It determines what it needs in order to compute the result and back propagates to the next layer of what it needs to know. Therefore, it doesn't need to calculate the red value.

The push type executes the other way around. It starts with what it knows and pushes it to the downstream areas until it has produced the result.

Because LV diagrams contain as much I/O as they do, it was decided to use the push model. This means that side-effects such as I/O in the red area will happen even if the results are not used. If you wish to avoid the red calculations, the technique is to use the switch/case statement.

The other way to determine this ...

When a LV diagram executes, it executes all nodes it contains exactly once. That requires both red and green to execute. The case/switch simply decides not to execute one of its diagrams. The for loop, by contrast, executes its diagram N times. Hope that helps.

Greg McKaskle