Joystick Delay

[andres20perez]

There is a delay between the joystick controls and the motors. When we move the joystick is takes about 3 seconds for the motors to respond. We have seen delays like this in the past but this year they are much worse. There isn't much of a delay between the joystick and the speed controller lights because they react almost instantaneously. Are there any teams experiencing this issue and how can we solve this problem?

[Greg McKaskle]

I'd first try turning down the camera rate and size. Also check to see that the DS CPU is not loaded down by another program and check the cRIO CPU usage. Both are shown on the Charts tab.

Please let us know what you find.

Greg McKaskle

[Gmercer]

Check your functions to make sure you don't have any delays in your functions without a conditional statement. I had a similar issue in that a shoot function was called in the same loop to check if i hit a certain button and would fire a frisbee. Turns out i had used Timer.delay(.5) before even checking if i hit the button that would fire the frisbee, causing a .5 second lag. simple things like this can sometimes slip by.

[Secretspy97]

try adding a wait of 10 milliseconds to each class/VI.

[Greg McKaskle]

When used like that, wait statements are like duct tape for programmers.

You may want to understand why those delays were needed, which ones were really needed. Also, with no comments, someone will happen upon that and wonder why it is there. "Why did someone put duct tape right there, and what will happen if I remove it?"

Greg McKaskle

[andres20perez]

We've reduced the delay to less than a second. We cleaned up code and got rid of functions we didn't think we needed.
The cRIO CPU usage is around 70%
Is it normal to have a small delay like that or should we fix up our code further.

[Greg McKaskle]

The delay should be far less than a second.

Greg McKaskle

[BitTwiddler]

Are there large time delays in teleop.vi? If so, move those tasks down into the periodic tasks.vi where they belong. Teleop needs to run as fast as it can to keep up with the data packets coming from the Driver Station. Use Global variables to pass values between teleop and periodic tasks.

[apalrd]

My advice is to ALWAYS write the code without any waits other than while-throttling waits.

Basically, your code design should always assume that any function call must return as fast as possible. This includes thinking about code efficienty, excessive function calls, calculating the same thing multiple times, Wait statements, Wait On Interrupt, waiting for events to return, etc. should all be done through state-machines and not actually blocking.

Our code currently runs in a 10ms RT look with very deterministic timing (average jitter is 10us or so) with no missed periods at under 50% CPU load. The speed limit is the radio packets which are sent at 50hz (we should get new HMI data every other loop, but we still can process new sensor data every 10ms).

[stingray27]

Make sure you don't have any open motor or sensor refnums. We have noticed that when we open a motor port that doesn't actually exist hardware wise, our code slows down TREMENDOUSLY and also triggers some watchdog issues. This has been a problem until we started using disable diagrams (Labview) to toggle working/unworking code when switching between the competition robot and practice robot

[bhsrobotics1671]

If you are using CAN, make sure that you are not referencing any CAN IDs that do not exist on the CAN network. You will receive time-out errors and while the code is timing-out, you will receive lag in the controls.

Happens to us almost every year when we go to test new code before we have all of the components wired up or program for jaguars that we never end up using.

[Ether]

Originally Posted by apalrd

My advice is to ALWAYS write the code without any waits other than while-throttling waits.

What is a "while-throttling wait"? I Googled it and got zero hits.

[Greg McKaskle]

I interpreted Andrew's terminology to refer to the wait that limits the desired speed of the loop/task. For example, if a loop contains an unconditional wait of 100ms in parallel with other code, you've guaranteed that it will never run over 10Hz regardless of what is placed in it. As mentioned in other papers, this is nit a great way to express that you want it to run at exactly 10Hz, but it is often used for that as well.

Greg McKaskle

[Alan Anderson]

Originally Posted by andres20perez

The cRIO CPU usage is around 70%

But what is the Driver Station computer's CPU usage?

A couple of years ago we had annoying control lag for a little while, until we found and fixed an unthrottled loop in our custom Dashboard program.

[mesamb1]

Originally Posted by andres20perez

There isn't much of a delay between the joystick and the speed controller lights because they react almost instantaneously

Something I havent read yet, could it be an electrical or mechanical issue? If your speed controllers are reacting almost instantaneously, I would be inclined to check on the electrical/mechanical side. If the lag is in the code, the lights on the speed controllers should be delayed.