Teleop transition issues, Labview

Team 2062 is having a problem where after hybrid period executes then the first frame of teleop executes but then the code gets hung up and does not continue. We had 2 NI CSA’s look at our code and they could not find anything or help us. After the matches we talked to the FTA who said that the robot was communicating throughout the match but the robot received the signal from the FMS to turn to teleop but this did not reflect in our code (see log file attached). We put in some debugging to see where the robot got hung up and the code would work randomly half of the time. We serialized the code to prevent a race condition which the CSA said could be the problem but that did not fix the problem. The diagnostic lights on the jaguars using CAN are solid orange (good signal, neutral speed) and the diagnostic lights on the jaguars using PWM are slow falshing orange (bad PWM signal). We changed our program to send a message to the driver station each iteration of the teleop program and this verified that we go through only one frame of teleop.

CD Post.zip (3.51 MB)


CD Post.zip (3.51 MB)

Whoa, that’s a lot of stuff going on in Teleop. I don’t see any reason for it to hang, though.

I notice that Robot Main has been modified. That’s often a recipe for unexpected weirdness, but it doesn’t seem to have anything in it that’ll break things. I do wonder why you didn’t just put that vision-receiving code in the Periodic Tasks vi, instead of doing clever background startup and shutdown processing.

Using the Practice mode on the Driver Station in your pits and turning on Highlight Execution (the little lightbulb) while running the code from LabVIEW you may be able to see what VI may be getting stuck (unfortunately it’s possible that the issue won’t crop up with highlight execution enabled).

You should also check the Diagnostics tab and NetConsole to make sure no errors are being reported.

I saw another team with similar sounding issues, but I just received their code and don’t have a cRIO. Their workaround was to end their teleop loop at fourteen seconds.

I hope to get to the bottom of it late next week.

Greg Mckaskle

Thanks for the help everyone. We ended up rewriting our code and sending the old code off to NI to have it looked at. We never really had a chance to get the old code working at this regional but we’ll try to get it working for Wisconsin.

To follow up with what’s been said already…

We tried this, but unfortunately we could only reproduce the problem with built code (as opposed to just deployed). We added user messages to almost every bit of our code, which actually made the problem a little bit better, happening about half the time. When it did happen though, it was inconsistent as to where in the code it happened.

We ended up rewriting our whole teleop and autonomous code on Thursday night before our Qualification matches, and it preformed reasonably well (with a lot of between-matches scrum). By our second match in Qualifications we had gotten it back up to almost where it was.

The whole building issue is key here, as it could most likely be a bug that’s been lurking in our codebase for a long time, as we never really tested our build code with a practice match. This lack of testing is something we have noticed and are taking steps to improve.

We had this same problem at our regional, and we traced the problem to our CANJaguar GetStatus. When we had that vi running, the code would freeze running that VI when we would transition between auton and teleop. After we removed this, the code worked again.