Gyro angle in simulation vs reality?

[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