Teleop Lag

We have our teleop code programmed, and it works independently perfectly. However, when we use it with the Basic Robot Main.lvproj project we get a half second delay from when the driver moves a joystick to when the robot responds. We have thusfar been unable to remove this. Here’s some info that might help:

We are using LabView
Our Teleop Code is hardcoded directly into the “TeleOp Execute” case in Basic Robot Main.vi

We have to use this vi and project because at the competitions they will switch autonomous and teleoperated for us utilizing this code. Also, if you are not going to post a suggestion to solve this problem please do not post.

A very early version of the framework/firmware had this issue. Have you updated to the most recent version yet?

We had a similar teleop delay issue when we run in Deploy Mode.
We are using DS (1-22-09) and cRio (v11).

We found that right-clicking the Deploy setting and selecting “Build” then “Run as Startup” fixes the issue.

We have the three updates and the Rio has been imaged correctly, but we are still having these problems.

Well, what I found out was that even when your LabView was updated for FRC update #3, your old project still retains links to older updates. I remember nearly at the end before shipping that we were still using dependencies as old as before kickoff (early control system recipient) and so I had to create the whole 20~30 file LabView project from scratch. Granted, most of it was copy and pasting, but you may need to start from a new & fresh project and then re-image the cRio one more time.

Not sure if that’s it, but it doesn’t hurt to try

Can you characterize the delay any more?

The most likely thing that is causing this is having code in the teleop loop that causes it to finish late. A new teleop message arrives every 20ms, so you can’t really do much in there. Go ahead and time the amount of time spent in the loop or the time between subsequent iterations.

And if you plug in the serial cable, are there messages on the terminal that give an indication as to what is going on? The earlier issue with the lag, by the way had to do with too many print statements being sent out the serial port, so even a message that doesn’t sound bad may give info towards the lag.

Greg McKaskle

We have done more with meticulous probing and have isolated the source of the lag to JoystickCache.vi. You can reach it by going through the following VIs:
JoystickGetAxis.vi
JoystickGet.vi
JoystickCache.vi is there in JoystickGet.vi. We’ve tried to localize the source more within the program, but have been unable to figure out a way to make it work faster. Thanks for all your help so far.

we’ve had similar issues and it seems that the more open .vi’s slows the program down more and more. When you run as startup the computer is no longer linked and the delay issue usually goes away. Try just running the robot main.vi front panel and say vision processing.vi front panel.

-Alex

We ran into a similar problem during the build season, all our DS controls were delayed by around 1/2 second. If I remember correctly, we traced it the vision code. Our solution was to lower the priority on the vision processing to allow the robot code to have priority. I’ll have to check to be sure. One quick check would be to disable the vision processing and see if your problem goes away.

Mike

@Alex698:
Maybe you should have read the whole post… someone already said that and we have already tested that theory to no avail
@Mike Bortfeldt:
Same as above, we already traced it to a specific VI (JoystickCache.vi) located in between the while loop and the “Get,Set,Init” case structure
But thanks for trying :slight_smile:

P.S. I am another programmer on Xavier’s team

We have fixed this problem, copy-paste works wonders :slight_smile:

As in you started a new environment and cut and pasted all of your old code into the new?

I looked at the subVI in question, and I how the subVI you mentioned would cause a problem. Can you be more specific about copy/paste fixing the problem?

Greg McKaskle

To clarify what Sauce said, we opened a new environment on a new computer and rebuilt the code there, mostly using copy and paste from the old file, to see if that would work. It did.

My team had this problem too, and we fixed it by just copying and pasting the code… surprisingly, it worked!:confused: