Controller Lag on Feild

[XXShadowXX]

My team was experiencing bad controller latency on the field. Our issue is simple as that, when tethered, or communicating wireless with our team equipment there is no issue but as soon as our robot touches the field we slow down.

We ran pings, sniffers, etc. Its to the point that our programming team was starting to think that our drive team was using it as an excuse xD or simply trying to give us problems because we cannot create issue at all.

Any suggestions please?

Thank you
William Cody Laeder

[Mark McLeod]

You might check your Classmate CPU load while on the field to see if circumstances have it bogged down. (Cntl-Shift-Esc)

Ask the field staff to watch your packet transit time to see if it's really, really slow.

[WizenedEE]

You may want to use the system manager (tools -> real time module -> system manager) to see how much CPU the C RIO is using. If it's near 100%, then it may just be the FMS is sending it over the edge.

You may want to try speeding up your code in general though, perhaps by adding longer delays to everything (it may be a good idea to put one in the main loop). If you're just edging the line between lag and no lag, you probably want to back it off a little bit.

[Kevin Sevcik]

Are you using CAN? Were you getting any errors in the diagnostic window one the Driver Station? Are you cRIO and DS as up to date as possible?

[Kevin Sevcik]

Originally Posted by WizenedEE

You may want to use the system manager (tools -> real time module -> system manager) to see how much CPU the C RIO is using. If it's near 100%, then it may just be the FMS is sending it over the edge.

You may want to try speeding up your code in general though, perhaps by adding longer delays to everything (it may be a good idea to put one in the main loop). If you're just edging the line between lag and no lag, you probably want to back it off a little bit.

The FMS should add a completely negligible load to the cRIO CPU, if any. The FMS talks with the DS, not the cRIO. Mark's suggestion of checking the Classmate CPU load makes more sense.

[rsisk]

Double check the wiring on your radio, it goes to the power converter, power converter plugs into the 12v plug on the end of your power distribution board.

Also confirm you are running version 2.27.11 on the driver station.

I have seen both of these conditions cause the symptoms you are describing.

[Greg McKaskle]

In addition to what has been said, I'd take care of any other code that causes error messages to be sent to the driver station. The auto-error-handler is not really that efficient and is one of the first things to correct. It is not common, but certainly possible that the errors happen on the field and not in your tests. To check for this, I'd recommend using the Practice Mode of the DS and if necessary, vary some of the bootup sequencing -- boot the robot first, then plug in the DS, reboot the robot with the DS already present, etc.

Greg McKaskle