High Average Trip Time - What to look for?

[topgun]

At our regional this last week we saw our avg trip time between the robot and the FMS system running about 180 ms. Everyone else was usually under 10 ms, with most being under 4 ms.

I asked the FTA about it and he said that it was something in our code.

Does anyone have any ideas on how to go about detecting what is slowing our code down so much? Is there a way to simulate the average trip time?

We are using Java and CAN. Versions of cRio, Java and DS were all up to the latest versions.

Thanks for your help!

[Jared Russell]

Vision processing, sending back a lot of Dashboard/SmartDashboard messages, sending back raw video, and use of a lot of "xxxContinuous()" methods without Wait statements are all possible causes.

Probably the best way to test is to incrementally disable different parts of your code until the trip times seem reasonable. I would start with the possible causes listed above, if they are applicable.

[davidthefat]

This might be far fetched, but I think he is right. When you program, you have to be conscientious about what you are doing in the code. Try streamlining your code and try making it more efficient. Remember less lines != mean more efficient. Less instructions = more efficient (eh, not always, some instructions take longer than others, but that is besides the fact)

Eh, I guess post your code here and I will help make it faster?

[Joe Ross]

It could also be caused by problems on the classmate side, for example a dashboard that uses too much CPU (we saw problems with video at 30fps, but reducing that to 10 made the problem go away). It could also be background tasks on the classmate (ie a virus).

Another cause on the robot side could be too many CAN messages that cause blocking. Check the diagnostics tab and see if any errors are being reported.

[Vikesrock]

Another possible cause:



Radios:

Radios mounted between/on-top-of/near the drive CIMs and/or buried deep in the robot metal lose communications when the robot starts to drive. Talk to the FTA before a match to ask him/her to watch the packet round trip time for your robot. Slow times (>20ms) probably mean the radio needs to be repositioned.

http://www.chiefdelphi.com/forums/showpost.php?p=1035407&postcount=9


180ms seems really high though and may be a code or Driver's Station issue, or a code/DS issue in combination with a radio placement issue.

[Mark McLeod]

I'll backup what's already been mentioned.

Check the Classmate CPU utilization (Cntl-Shift-Esc), because it can easily get bogged down by the video stream or other intensive Dashboard operations. Isolate by disabling/commenting out code.
Check the CPU utilization on the cRIO for the same thing.
Check the radio placement for disruptive interference.

[topgun]

Thank you for the suggestions.

If you want to look at our code it is located in read-only mode here:
http://www.firebears.org/hg Suggestions are welcomed.

We have our radio mounted about 4 feet high in the open with polycarbonate on one side to attach to our mast. We have never had an issue achieving connection and I didn't see where the avg trip time would speed up when the radio's open side was facing the FMS versus when it was facing away from the FMS.

We do a fair amount of system.out.println statements in our code, plus watching variable values on the dashboard.

[Mark McLeod]

From your description it wouldn't be the radio position.
I have noticed that a large volume of println's can also slow the system down.

Mostly it's measuring the processing load on the two primary processing systems involved: the Classmate and the cRIO.

[Jared Russell]

Try disabling your SmartDashboard I/O and see what happens. You have a *lot* of it, and we noticed that our round trip times started to rise as we put more and more SmartDashboard calls in there.

[topgun]

... and we noticed that our round trip times started to rise as we put more and more SmartDashboard calls in there.

How were you able to notice that? Did you also notice that at a regional or is there a way to see the avg trip time with just the normal setup that teams have in their workshop?

[Arjun Namineni]

We also had a large trip time and upon further investigation, we concluded that it was the ridiculous amount of smart dashboard outputs that we had put in to help us debug our code.