Autonomous runs during Teleop

[garrettg]

Our team's robot will run in teleop just fine, and autonomous will work just fine too, but then it won't go back to teleop. It will say it's in teleop, but it is still moving like in autonomous. So, in the practice match on the DS, autonomous runs fine, then autonomous period ends and teleop period begins, but the driver has no control over the robot because it is still running in autonomous.

I am using autonomous independant, and all i changed in Begin.vi is replacing iteritive with independant.

Any ideas on why this is happening, and/or how to fix it?
Great appreciation in advance.

[airnate]

Any chance you can share code, either screen shots or actual VIs?

[Greg McKaskle]

If this is reproducible, PM me and I'd like to determine what the issue is.

Greg McKaskle

[ideasrule]

This may be a complete red herring, but I noticed in Java that an infinite loop in autonomous will continue running if teleop is enabled after autonomous is enabled.

[Greg McKaskle]

I've seen teams place calls to their autonomous code other places in the framework. I don't know why this happened, they either did it accidentally or thought it was better that way. Anyway, again, either post here or PM and we'll arrange to email.

Greg McKaskle

[Ether]

Using the LabVIEW framework, if autonomous independent exceeds 15 seconds, will it continue to execute when FMS changes to teleop?

Our LabVIEW programmer tells me "No", but I thought I recalled seeing something in the documentation warning that the answer is "Yes". Maybe I was reading the Java or C++ documents.


~

[jhersh]

Using the LabVIEW framework, if autonomous independent exceeds 15 seconds, will it continue to execute when FMS changes to teleop?

Our LabVIEW programmer tells me "No", but I thought I recalled seeing something in the documentation warning that the answer is "Yes". Maybe I was reading the Java or C++ documents.

If you are running Autonomous Independent, the LabVIEW framework will stop your autonomous VI when the autonomous period ends, even if it's not done. I do not believe that Java or C++ will do this for you (when using the "SimpleRobot" framework).

[Greg McKaskle]

LV will abort the VI that imlements auto independent. If the VI calls into a .out that never returns, then it cannot be aborted, but it is unlikely that is happening.

Greg McKaskle

[garrettg]

Sorry about taking so long, but here's my autonomous.
It still stays in autonomous, but if I keep both the photosensor and the limit switch for the kicker returning true, it will go to teleop. Largest case strucure true will run once in autonomous, then once in teleop before finally relenquishing control to teleop. The best I can tell is it gets stuck in a loop, finishes early, and repeats autonomous again. Any ideas?

kickerlimit is a limit switch for the kicker, true means it's ready to kick
solenoid push true will kick
solenoid pull true will wind kicker
laser is a photosensor to tell if a ball is present
switcha and b are part of a 3-way switch for autonomous selection

Hope this is enough information.

[Ether]

Using the LabVIEW framework, if autonomous independent exceeds 15 seconds, will it continue to execute when FMS changes to teleop?

Our LabVIEW programmer tells me "No", but I thought I recalled seeing something in the documentation warning that the answer is "Yes". Maybe I was reading the Java or C++ documents.


Aha. I found it while sorting through a pile of papers:

"The Autonomous method will not quit running until it exits, so it will continue to run through the TeleOp period unless it finishes by the end of the Autonomous period."

The above excerpt is from Page 15 of a document dated 15 Sep 2008 in section "Built-in Robot Classes". I don't have the doc title or the link. I believe it may be the WPI Library tutorial.

Note: The LabVIEW Framework is different, or so I am told. It will abort the Autonomous independent when the 15 seconds expires.


~

[garrettg]

I got the problem resolved right after qualification matches today (I know, it's late) and the problem was it was hanging in a while loop, and it didn't want to kick out. With the help of Matt from team 2619, we added a tick count, and used that to kill the while loops. Now, if executed just right, autonomous will not give the user control for (up to) the first 8-ish seconds, but the team is OK with that for right now. Too bad chain keeps popping off and our wheel brackets are bending... :p

[Zme]

since i was mentioned i thought i should write in and describe what we did for teams that could be having a similar issue

in the beginning of the autonomous independent (before any loops) we got the tick count (in ms) and added 14500 to it, then inside of each loop it would get the tick count and compare it to that, if it was greater than it then the exit condition became true and it went on with the show, the extra 8 seconds there is being used up by the setup they used for autonomous (they have some wait commands in there and it has to cycle through all of the iterations before it will exit.)

It is a really roundabout way of doing things thought, any chance that for next year the labview side of things could get a IsOperatorControl() function so that it could be used to exit out of the loops if it switches over to teleop? i know it has saved our team more than once with runaway code

[Racer26]

I know the C++ flavour of WPILib has IsAutonomous() and IsOperatorControl()... theres no LabVIEW equivalent?

[Zme]

not one that i can easily find (mind you we used c++ for our robot)

there are some that we can find but the issue is that they require inputs to work correctly which means that they need constantly updated inputs which can be tricky with the autonomous independent because it is only called once

[Ether]

since i was mentioned i thought i should write in and describe what we did for teams that could be having a similar issue

in the beginning of the autonomous independent (before any loops) we got the tick count (in ms) and added 14500 to it, then inside of each loop it would get the tick count and compare it to that, if it was greater than it then the exit condition became true and it went on with the show, the extra 8 seconds there is being used up by the setup they used for autonomous (they have some wait commands in there and it has to cycle through all of the iterations before it will exit.)

It is a really roundabout way of doing things thought, any chance that for next year the labview side of things could get a IsOperatorControl() function so that it could be used to exit out of the loops if it switches over to teleop? i know it has saved our team more than once with runaway code

You didn't say what language you are using.

As mentioned earlier in this thread, the LabVIEW framework automatically terminates autonomous independent when teleop is commanded.

Since you are adding code to exit from autonomous when time is up, I assume you are using C or Java.

If such is the case, why don't you break out of the code immediately when the tick count reaches the target, rather than letting the code "cycle through all of the iterations before it will exit" ?


~

[Greg McKaskle]

Sorry it took me so long to look at the attached code. The Autonomous Independent VI that was attached is fine. That tells me that the problem is elsewhere.

The original framework sets the autonomous type in Begin along with assigning the VI reference to the Autonomous Independent VI. The framework will then launch that reference on the first packet of autonomous, and will abort it on the first non-auto.

My explanation is still that other changes have been made to the framework so that it is not really controlling things. If you attach the rest of the project, I can tell you why it is happening. If you want to debug it yourself, start by looking in Begin and see what type of auto you are using. Then look to see what VI reference you are attaching. Next using either Find or the hierarchy window, determine if you are explicitly calling the Autonomous Independent VI. On a lark, you might want to open the Auto Iterative and look to see that is the code actually being run, or if it has been modified to call the Independent VI.

As for the IsAutonomous() functions, they are easily added based on the MatchInfo data around in RobotMain and passed into Tele and AutoIterative. Since the data about the match is passed in as a parameter and the Independent style of auto doesn't need such functions, they were never written.

Greg McKaskle

[Zme]

You didn't say what language you are using.
~
let me point you at:
(mind you we used c++ for our robot)

As mentioned earlier in this thread, the LabVIEW framework automatically terminates autonomous independent when teleop is commanded.

not always, with the iPirates' code it seemed like it was getting stuck in a while loop that was inside of the autonomous independent vi

As for the IsAutonomous() functions, they are easily added based on the MatchInfo data around in RobotMain and passed into Tele and AutoIterative. Since the data about the match is passed in as a parameter and the Independent style of auto doesn't need such functions, they were never written.

what seemed to be happening was the program was waiting for a set of conditions to be met before it could exit. if this is indeed the case, which from my understanding in not necessarily true, a function like this would make it easier to debug.

and either way, while it is not necessary, in my opinion it would be nice to have something simple that queried the field and returned what mode the match was in, hopefully something that did not need any inputs so it wouldn't be based off of old data

[Ether]

Originally Posted by Ether
As mentioned earlier in this thread, the LabVIEW framework automatically terminates autonomous independent when teleop is commanded.



not really, no,
as the iPirates can tell you, it will not exit if it is caught in a loop inside of the autonomous section and switching it to teleop at that point will only cause more issues


Greg, is this true ? I have told our programmers, who are working to add autonomous now, that they don't need to add code to terminate after 15 seconds... so I need a firm answer here.


~

[Greg McKaskle]

If that were true, the Stop/Abort button in LV must have never worked either. Pretty sure it does.

It will break out of a loop, a nested loop, and any code LV generates that has cooperative multitasking code compiled into it. If the code calls into a .out which doesn't return, or manages to generate a loop without the cooperative code (I don't know of a way to do this), then Abort will not work. LV stops short of killing threads to abort as this tends to lock up or leak system resources, so it will not preemptively abort these exceptional cases.

In short, I'll believe it when I see it. Please post the rest of the project and I'll be happy to give another explanation of the symptoms being seen.

Greg McKaskle

[Zme]

I think at this point it boils down to, should it exit? yes
will labview make it exit? it should, it works in other cases so again yes
did it exit? no.

I have seen in at least 2 maybe 3 different teams where autonomous did not exit because of a logic error in a loop for example on 3114 it was set up so that a loop in the autonomous would only exit if the watchdog was still alive, if it wasn't then they just sat there the entire time doing nothing


my advice, (which if you have $5 might get you a cheap cup of coffee), is to test the heck out of it, if you are trying to kick 3 balls test what happens if you only kick 2 and then try to switch. if it doesn't try adding code for timing on it, if nothing else it is a failsafe so if something does go wrong you are not dead in the water.

[Greg McKaskle]

Again, I'll happily investigate this and give an explanation if I can be given the rest of the code. Until then, I call voodoo.

I've worked on the LV team for 19.9 years. Anything is possible, but I've never seen the Abort method fail except in the cases I mentioned. It is possible that there is a bug in the framework, but my money is a bug in how the framework is being used. I'd like to look at the code to get to the bottom of it.

Telling people that LV cannot break out of a while loop, and that they need to add code to their loop in order for the autonomous to work is counter-productive. It is like telling people that the earth is flat or that drafts cause colds. If you have a VI that will not Abort, please send it to me, otherwise, perhaps your advice is doing more harm than good.

Greg McKaskle

[Zme]

while i find that partially offensive i will choose to ignore it,

i did not say "you need to do this" what i was after was more of a "if you have this problem you can try this"

i understand that you know the language and how things work with it a lot better than i do now and a lot better than i probably ever will but please, next time before you go taking my head off for advice given and please realize that it is simply that, advice, i gave it because it fixed the issue that this thread discussed, not because i thought i knew something better than the people that work with it.

now, with that being said if i in any way insulted you please forgive me, it was not my intention, in the future i will be sure to only give my opinion on things when it is asked of me

[Ether]

in the future i will be sure to only give my opinion on things when it is asked of me

Please don't do that. If you have something constructive to say, please say it. We all benefit from the ensuing dialog.

Greg is understandably frustrated because he wants to get to the bottom of this but he needs to see the mis-behaving project in order to analyze it to figure out what is going on. I would VERY much like to see that happen. How about it, Team 1528? Do us a favor and send your project to Greg for analysis.

~


~

[Greg McKaskle]

I wasn't trying to take off any heads or be offensive. We've all formed a model of how things work based on observations, only to later discover that those models sometimes need to be adjusted.

In post #17, you were giving some pretty strong advice which I would rather people did not follow. In fact it caused others concern and they asked for clarification from me.

Until I can look at the VI, I cannot explain everything, but I can say that it is very unlikely that Abort didn't work. There is no good reason to worry about loops in the auto independent code. In fact it was written the way it is to expressly allow loops.

Again, I know you were trying to help, and in most cases I wouldn't jump in so strongly. But, if we have to get into a tug-of-war as to whose advice to follow, I have to hold my ground. I want to see the evidence -- I want to look at the code -- before I'll buy into the conclusions presented.

Greg McKaskle

[Zme]

in rereading that post i have to agree with you there and have edited it to better reflect what my thoughts were on the issue, i apologize for any misunderstanding

Matthew

[Greg McKaskle]

Awesome. Hopefully we can get to the bottom of this soon.

Greg McKaskle

[garrettg]

What matt (zme) had our team do is currently having it work, and that's all I could ever hope for, and THANK YOU. As for posting the entire code with the errors before, I currently do NOT have a copy of it, BUT a former member MIGHT have it, and I will be able to get it to you from him tomorrow at our meeting (multiple people having backups is better than 1 person). If he does not have it, then I will post our current working code, which I believe is only different than the non-working autonomous one is the autonomous. (worded strangley, so here I try in smaller words) I think the working vs non- are same in every way but autonomous.
Hopefully this can be resolved for next year or find a way were I screwed something else up elsewhere.

Thanks everyone for showing all this enthousiasm (sorry for spelling) shown in this thread.

[Ether]

What matt (zme) had our team do is currently having it work, and that's all I could ever hope for, and THANK YOU. As for posting the entire code with the errors before, I currently do NOT have a copy of it

May I politely suggest that there IS more to be hoped for - much more? There is so much that could be learned from your experience. And after all, isn't that what FRC is about?


~

[Zme]

May I politely suggest that there IS more to be hoped for - much more? There is so much that could be learned from your experience. And after all, isn't that what FRC is about?


~

I wholeheartedly agree

[garrettg]

This should be the code in it's broken entirety. Enjoy.

[Ether]

This should be the code in it's broken entirety. Enjoy.

OK Greg, the ball's in your court :-)


~

[Vikesrock]

Next using either Find or the hierarchy window, determine if you are explicitly calling the Autonomous Independent VI.

Greg McKaskle

As you predicted, this is the issue. You can see in the attached code posted above that the call from Robot Main that is typically to Autonomous Iterative has been replaced with a call to Autonomous Independent.

For any others having this problem this is a good first thing to check. To use Autonomous Independent, the only thing you have to do is make sure that the enum at the top of Begin.VI is set to Independent and then place your code inside the existing Autonomous Independent VI accessed from the Project Explorer.

[Ether]

As you predicted, this is the issue. You can see in the attached code posted above that the call from Robot Main that is typically to Autonomous Iterative has been replaced with a call to Autonomous Independent.

For any others having this problem this is a good first thing to check. To use Autonomous Independent, the only thing you have to do is make sure that the enum at the top of Begin.VI is set to Independent and then place your code inside the existing Autonomous Independent VI accessed from the Project Explorer.

Hi Kevin,

Do you know if there's a document somewhere which clearly explains this? If so, I want to make sure our programmers go read it thoroughly. They're working on autonomous now.

Thanks.

~

[garrettg]

So I should replace auto indep in robot main with the iteritive VI, and then that code should work?

[Zme]

that, and from what it sounds like, make sure that the begin.vi states that you are using the autonomous independent function instead of iteritive. this seems a little counter intuitive to me but if it works then it would save people a lot of time.

please try it and let us know how it goes

[Vikesrock]

So I should replace auto indep in robot main with the iteritive VI, and then that code should work?

Greg could tell you with more certainty than I can, but yes that is what appears to be wrong with the code. The Autonomous Independent VI is called from inside the Get Competition Mode VI by the default code when the mode in Begin is set to Independent and is aborted by the same VI when the mode is switched away from Autonomous.

Because your call was separate it was not being aborted by the Get Competition Mode VI.

Ether,
I will look around and see if this is spelled out in any documentation I have at the moment or not. I learned a lot of this through reading the comments that are in the default code and poking around inside some of the VIs such as the Get Competition Mode VI.

[garrettg]

Our robot is currently out of the bag for the next hour and 45 minutes, so I will test this adjustment when build gets build problems out of the way (I might not get to try this today, but should be able to try tomorrow).

Edit: I was able to test it today, and the change of having Iteritive in Robot Main got Independent to kick out on time. I don't understand why though. Anyone mind explaining in the clearest way possible why Iteritive needs to run if you want Independent? All help given is greatly appreciated, and I doubt I'm the only one to have changed Robot Main like this.

[Greg McKaskle]

I just got home from work and looked at the code. To fix the auto that won't stop, delete the call from the Robot Main. It is not necessary to call the iterative there as it is an empty template anyway.

Begin VI is still set for using Independent, and the AutoIndependent VI is the one that it will call and abort.

I'll post again with more explanation of what the framework does, why this behaved the way it did, and where the docs are.

Good Luck with your auto.
Greg McKaskle

[Greg McKaskle]

There are tutorials on NI.com/first and on the LVMastery.com sites. I'll admit that I didn't write them, and I haven't watched all of them for correctness, but they should show how to write the autonomous that works.

The other documentation on the framework is in the code itself. The green comment to the left of the loop in RobotMain states

Robot Main implements the framework and scheduler for your robotics program.

It should not be necessary to modify the framework. You should be able to implement your code within the following VIs. ...


As usual, more documentation can be added, especially once we know what the misunderstandings are. Actually, no final decision yet, but we may look at some simplifications while we are at it. The initial framework was a widely cast net, intended to support many different programming styles and abilities. Now that we've seen what most teams prefer to use, I think it can be vastly simplified.

Back on topic, the auto was supported in two ways, independent and iterative. Iterative is basically the same as TeleOp -- called for each packet, expected to complete in under 20ms, and no easy support of sequences or repetitive code. Independent, on the other hand, is called once asynchronously, is automatically aborted when auto is over, making it east to do sequences and repetitive tasks. The way Iterative is called is pretty obvious, a subVI call for each packet. Independent is less obvious. In Begin, a VI reference is designated as being the AutoIndependent VI reference. Then the Get Mode VI in the Robot Main loop will automatically run the referenced VI when auto begins and abort it when the period completes. The syntax for calling and aborting was intentionally hidden in part because it is complicated by the different state transitions of the DS, and partly to prevent it form becoming broken by curious programmers.

By adding a subVI call to Auto Independent, the Run method will return an error. It is a little complicated, but VIs have a number of states they can be in (Broken, Idle, Active, Running, Reserved, Suspended, and I'm sure more that I can't remember off the top of my head) which define the operations that are valid on the VI. Run only works on Idle VIs. SubVIs are Reserved by their caller, so are not runnable because the are callable. Anyway, For that reason, I'm pretty sure the VI refnum was invalid so that Abort also failed. To be more sure what the value of the refnum was from the failed Run, I'll need to run that app.

Anyway, if there are any more questions or any more things to learn from this, fire away.
Greg McKaskle

[Madification]

Our bot is definately doing the same thing but I'm Build and Chairman's team so I have no idea what you're talking about lol I'll get our programmer to look at this.

[Greg McKaskle]

If you can't find the issue, post code to this thread. There are lots of people willing to help.

Greg McKaskle