SOFTWARE PROBLEM!!!! PLEASE HELP!!!

[RedHeadRobotics]

We are having trouble with our controls. We have tried many things. The software will lag and respond in two or more seconds. This problem is sporatic and we think that is has been fixed, but then it returns. We have kept the same setup and it still changes. We have checked the battery, made sure that the battery we used was new, freshly charged. Our software team even had us move where the wireless bridge was to see if it received code better (probably knew this wouldn't work because it does the same while tethered.)

Even more confusing is that the mechanisms delay more than the drive train. It is not just the pneumatic devices, motors also delay more than our drivetrain does even though they are connected in the same manner.

If Anyone has any ideas or suggestions, it would be great. Thank you!

[EthanMiller]

Depending on the programming language, there's different things that could cause it. What language are you using?

Also, look to see if you have any loops that may take a couple of seconds to complete.

[birkejf]

We are using LabView.

[Mark McLeod]

If you care to zip up the entire project and post it we can help diagnose code delays. Time is getting short...

Any messages on the Driver station Diagnostic screen?
Any lengthy "Watchdog not Feed" statuses showing up in the lower left corner box?
Any oddly behaving status lights?
Does the RSL have a consistent long-on/short-off blink sequence or is it disrupted?

[bronxbomber92]

Are you constantly running the camera and processing the images for ellipses. If you don't have this running quickly, that could drop your the speed pretty drastically, I suppose.

[nick1023]

Perhaps you have a "wait" somewhere?

If there is a "wait" anywhere in your teleop take it out. Each time the loop executes you will have to wait for that time to pass.

frcmastery.com has a state machine video that shows how to use timers properly inside a loop using a shift register and a tick count.

[lscime]

There are a couple of things that could be causing this. If you are getting "watchdogs" in the box at the bottom left corner of the driver station (where it usually says enabled or disabled) it is possible that you are running a loop (say for reading sensors) that has no time delay in it. This will cause the loop to run flat-out and result in lag-times. Also there can be pretty serious lag if you are running non-deployed code (i.e. you are running the code on your programming laptop and not the on cRIO alone). Try building your project and permanently deploying your code to the cRIO and see if the lag persists.

More information would be helpful in debugging your problem.

-Luke

[jawebste]

Hello from 2145
Our team is having the same problem with the delay between when we push a button/move an axis and when the motor moves. In our code we are trying to control 7 motors and two servos could there be a limit to what the digital side car and/or the cRIO can handle? We have built our project and deployed the code but the delay continues.

I am posting our code with the hope that some one can help us. This code is pre-update before last Saturday or Sunday, so right now we are redoing it on from the Robot Project Sample in the updated Labview, but I predict that we will still have a lag if some one can help us fix it on the old code we can probably use it to fix our new code.

When we enable teleop on the driver station it flashes between Teleop enabled and Watchdog Not Feed could the Watchdog have something to do with the lag?

[lscime]

The fluctuation between watchdog and telop enabled will certainly cause lag. After briefly looking at your code I don't see anything that is likely to cause a watchdog error. Although it appears that you have forgotten to close all of your devices (ie motors) in the "finish.vi." This may cause issues.

The best way to debug this kind of issue is to go back a couple of steps. For instance, did you start noticing the lag after writing a particular piece of code?

PS - the cRIO is incredibly powerful, it is highly unlikely you are taxing its processor (remember, it is designed to have all 8 slots filled with stuff).

-Luke

[pSYeNCe]

Team 2010 is also experiencing similar problems. We're getting a 1/2 to 1 second delay from moving the controls to a response. We don't have any loops other than the teleop.vi While loop that encompasses everything, so I think I'll try to time delay that a little bit and see what happens.

[lscime]

I'm sorry for any confusion. The telop loop does not need to be delayed as it requires a lot of processor time (in other words, it won't be running flat out). The vision loop similarly should be fine without a time delay. Loops that are reading sensor values etc. don't take much processor time and so do need to be delayed. Check the "periodic tasks.vi" for such loops. Also, make sure you have fully updated LabVIEW, the cRIO, and your Driver Station.

-Luke

[Robototes2412]

We use java and get a similar problem, try a reboot of the robot

[birkejf]

Thanks for everyone's advice. It was a mis-named variable and we were getting excessive watchdog error messages! We now know what to look for next time.

[flameout]

I'd like to add that we are having the same problem. It has sprung up since the last set of updates (LabVIEW and DS.)

It is vision related, since unplugging the camera will prevent the problem. It appears to be taking around 200 milliseconds per frame, and I think it is starving the teleop task.

This applies to all our code, including our "clean" project.

Does anyone have a clue? Thank you for any help.

[Mark McLeod]

Originally Posted by pSYeNCe

Team 2010 is also experiencing similar problems. We're getting a 1/2 to 1 second delay from moving the controls to a response. We don't have any loops other than the teleop.vi While loop that encompasses everything, so I think I'll try to time delay that a little bit and see what happens.

There shouldn't be a teleop While loop unless it is less than 1/50 sec.

Originally Posted by jawebste

Hello from 2145

Several of the Hook Motor Set Speed's are without a speed or motor reference. Of the three case statements for the Hook motor look at the False case on top, the False case in the middle, and the True case at the bottom. The pink wire needs to be wired across and the bottom speed needs a constant value.
I don't see anything else that would account for the delay you're seeing.