Joystick Delay
 

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?

Re: Joystick Delay
 

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

Re: Joystick Delay
 

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.

Re: Joystick Delay
 

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

Re: Joystick Delay
 

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

Re: Joystick Delay
 

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.

Re: Joystick Delay
 

The delay should be far less than a second.

Greg McKaskle

Re: Joystick Delay
 

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.

Re: Joystick Delay
 

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.

Re: Joystick Delay
 

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).

Re: Joystick Delay
 

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

Re: Joystick Delay
 

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.

Re: Joystick Delay
 

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.

Re: Joystick Delay
 

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

Re: Joystick Delay
 

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

Re: Joystick Delay
 

Yes, that's what I meant.

There are occasionally While loops where timing really dosen't matter, but it can't eat the entire CPU running as fast as it wants.

I recently wrote some code for the Insight LT which uses I2C, and I don't particularly care how fast the data gets out as long as it takes at least 100ms to do so and dosen't block my high priority controls task. I basically ended up with an array of I2C transfers, and FOR'd through them all with a 2ms wait in each loop, so since I had 42 transfers it would definitely take at least 84ms to complete the write cycles. I did not wait for I2C verification since I really didn't care what happened (the worst case I have a funny screen image for 100ms), plus a 20ms wait at the beginning of the higher-level While loop.

The RT loops are definitely the best way to get good timing. Basically every FRC LabVIEW tutorial uses a Wait XXms as a method of controlling loop time and processor load, which does work but the timing performance is much worse.