Gyro angle in simulation vs reality?

[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

[Ether]

Originally Posted by Greg McKaskle

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.

Thanks for the informative post Greg.

Applying the above at face value as a general principle: if the portion circled in red was made into a separate diagram, then would that diagram not be executed if the portion in green evaluated to TRUE?

I suspect the answer is that it would still be executed, and the reason is that the green decision is in parallel with the red computation, whereas with the case/switch the diagrams are in series downstream. If that wording is awkward/incorrect, what's the proper way to articulate this distinction, in LABview-speak?

One more thing: wouldn't it be reasonably straightforward for the code generator to recognize these T/F decisions, and generate conditional code like the case/switch does? Or would that effectively mean abandoning the push model?

[Greg McKaskle]

Let me elaborate on the statement I made about node and diagram execution. I don't remember why, but had to cut that short.

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.

Completing the thought ...

The for loop and case/switch are nodes. They must execute exactly once. Normal nodes such as + represent a closed operation. There is no sub diagram to schedule for execution. The control structures in LV that bring additional scheduling structure to the language are the loop, switch, sequence, and subVI. Each of these executes by scheduling one or more subDiagrams in a structured fashion. This is the same as how a procedural language structure such a loop or case will manipulate the execution of its "body" expression.

So to be more exact, the case/switch is a node and must execute exactly once for each execution of its owning diagram. It performs conditional execution by scheduling one diagram and ignoring the rest. A loop only contains one diagram, and it performs repetition by scheduling it multiple times. A sequence contains N diagrams and enforces sequencing by scheduling then in sequence. A subVI doesn't look much like a flow structure, but it acts to coordinate the execution of the calling and called diagrams so that they behave as a procedure call.

While LV supports, promotes, and promises parallelism, it can't change the fundamental characteristics of the CPU(s) it runs on. Code such as you've drawn, with simple operators do not benefit from parallelism. They are synchronous atomic operations and one of the optimizations LV makes is actually to serialize that code to avoid scheduling overhead. The "clumping" algorithm's job is to identify when to use the parallelism expressed in your diagram and when to arbitrarily serialize it to improve performance.

The compiler does eliminate code and move code around to eliminate unnecessary operations. It has to be careful that the code is functional and has no side-effects. Also, realtime users would often prefer that we calculate both and not introduce jitter in the calculation.

Greg McKaskle

[Ether]

Question for experienced veteran LabVIEW gurus:

Do you tend to prefer one method over the other, and why?

[ProgrammerJoe]

Quick Question, but I'm messing around with the Robot Simulation Model Builder and I didn't notice a Gyro option under sensors. Is the Gyroscope inherent within the FRC Frame or does it need to be imported within the Model Library?

[Joe Ross]

Originally Posted by ProgrammerJoe

Quick Question, but I'm messing around with the Robot Simulation Model Builder and I didn't notice a Gyro option under sensors. Is the Gyroscope inherent within the FRC Frame or does it need to be imported within the Model Library?

It's built into the frame as described here: https://decibel.ni.com/content/docs/DOC-26300