Autonomous runs during Teleop

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

Originally Posted by Ether

You didn't say what language you are using.
~

let me point you at:

Originally Posted by Zme

(mind you we used c++ for our robot)

Originally Posted by Ether

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

Originally Posted by Greg McKaskle

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.

Originally Posted by Zme

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]

Originally Posted by Zme

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]

Originally Posted by Ether

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.