LabVIEW & autonomous "remembers" old values?

Technical NI LabVIEW
#1

In our autonomous code we have a stacked sequence that does various things. For example one of our first frames lifts the robot’s arm and the next goes forward a predetermined amount of encoder clicks.

While testing the code we experienced some (erratic) odd behaviour. Occasionally, when we start autonomous mode, the robot will start two sequences at once, i.e. start lifting and start driving. So far we haven’t been able to pin down exactly when this happens, but my personal hypothesis is that it does this when we stop the earlier autonomous runs early (start autonomous, hit disable, start autonomous again).

A mentor from a nearby team mentioned, in passing, that he thought it was a “feature” of labVIEW where it “remembered” the old values that things held before. Besides this clue we are completely at a loss. We’ve tried building over USB and unplugging the cable, building twice in a row, building and using “run as startup” all to no avail.

Does anyone have any idea on what might be happening?

#2

The “Autonomous Independent” is run in a different way from all the other team-edited VIs. It is started by a special LabVIEW function when Autonomous mode begins, and it is stopped by a special LabVIEW function when Autonomous mode ends. If you just disable and re-enable without leaving Autonomous, the first run is not stopped, and if conditions are right a second copy can end up running at the same time. But that really shouldn’t happen, and I don’t think it’s what is going on in your case. What is probably happening is that your encoders are not starting at zero when you run Autonomous a second time, and that’s confusing your sequencing.

If you’re going to cancel Autonomous without proceeding to Teleop, I think your best option for making things work properly is just to reset the roboRIO before running Autonomous again. You can do that remotely from the Driver Station.

#3

We are actually resetting all the encoders first thing. What you said first sounds like it (at least in what it does).

#4

Autonomous is indeed launched specially. When the robot transitions to Auto, it will “run” your autonomous independent VI. I put it in quotes because it is literally calling the Run method and is very much like pressing the run button.

The reason it does this is really for what happens at the end of auto. When the period ends, it calls the Abort method, which is pretty much like hitting the Stop/Abort button next to the run. It does this because that allows you to write your code without worrying so much about how it stops and transitions to tele.

So, what Alan says is theoretically possible. LV can clone and run as many reentrant VIs as you have memory for, but Auto isn’t reentrant, and I have not seen this, and I think that if anything like this happens, it is because the abort has been blocked waiting for a DLL or some other system call that has hung. At that point I think you’d see lots more symptoms than described.

If you run the code in the debugger, without build/deploy, you can open the auto window and actually see from the buttons what is going on. I believe that when you hit disable, you will see auto VI stop. Please inform me/support if it doesn’t.

So what is happening?

Here is another way that the auto->disable->auto transition can have the side-effects you describe. When a robot is disabled, the servos, motor controllers, pneumatics, and other output values are simply ignored. They aren’t zeroed or magically reset. If your auto makes assumptions about their initial state, that mean that the outputs are simply reenabled to their most recent state.

Example:
Two motors A and B are using during auto. First A is run for 5 seconds and stopped, then B is run for 8 seconds and stopped. You run auto and see this pattern work. Yay.

Then you run auto again and abort when B is running. You now enable the robot for auto again. All outputs are enabled, A and B will both run for five seconds, then A will stop. B will run for 8 more and stop.

This wasn’t what you intended, but unless auto specifies what to do with B, it gets to do whatever it wants, or rather whatever state it was left in, until you tell it otherwise, which doesn’t happen for 5 seconds.

So that is my theory as to what is happening. It won’t actually happen in a match because the boot up puts things in a known state. But practicing and testing can cause some very confusing results. The easiest way to avoid this is to stop Robot Main and restart. This will close and reopen all outputs, and I believe should give reliable state and is quicker than restarting the runtime or rebooting the controller.

And of course, if you write your Auto to put all your outputs into an initial state, that is a good approach too.

Greg McKaskle

#5

It sounds like you are using Local or global variables. If this is true then one of them is probably not getting initialized properly. The is the trouble with using these. If you post your code I could look through it and give you some suggestions.

#6

We are using global variables, yes. But they are all set to zero in robot global and the only place they are ever changed is autonomous. Does that cover what you meant by “initialization”?

I can post some code later, if you want.

#7

Wow, thanks Greg, that was very well explained! I might just set some initial values. Simple, easy and reliable.

#8