Greg, As to your point, in browsing around, I had found…
http://www.chiefdelphi.com/forums/archive/index.php/t-86259.html
Radical Pi
07-14-2010, 09:25 AM
…
I think I may have a reason for the slowdown and the jitter. In the C++ code, all requests to the CAN driver are routed through either FRC_NetworkCommunication_JaguarCANDriver_sendMessage, or FRC_NetworkCommunication_JaguarCANDriver_receiveMessage. Also, when the driver is loaded by the OS, the init calls FRC_NetworkCommunication_JaguarCANDriver_registerInterface with a pointer to the driver class. By the names, I’d assume that all messages are run through the NetworkCommunication library before they get to the driver itself, most likely so a disabled robot cannot continue to send CAN messages. NetworkCommunication is searching for a driver station and communicating with the driver station, so it could account for the delay and the jitter.
I could not find source code for FRC_NetworkCommunication_JaguarCANDriver_sendMessage().
Does this communicate to the NetworkCommunication task?
Could Jaguar messages be a potential for a significant extra level of load on the NetworkCommunication task (especially if a team is trying to retrieve data from the Jaguars)?
I did not see an equivalent for PWM controlled Jaguars to FRC_NetworkCommunications*sendMessage nor something equivalent.
The behavior we observed was different on the competition field than the behavior we observed during practice on tether or using a radio on the practice field.
The primary observation was an order of magnitude more Set and Get CAN message timeouts on the message log and a robot that acted extremely sluggish (or did not move at all).
We suspect motor noise impacting the DAP-1522 or impacting the CAN bus- It might be we had a bad CAN cable or a bad termination.
Other than a more hostile radio environment, what are the variables on the competition field using FMS that can result in a change in observed behavior as compared to tethered or practice field operation?
What is the expected additional delay, and jitter on transferred Ethernet messages when using the competition field?
After we failed to make the elimination round, we spent some time rewiring our competition robot for PWM and will use that in Boston.
We will move our DAP-1522 to a less radio hostile position/orientation on the robot.
We might spend a very small amount of time to try to set up FMS Light and our practice bot and create radio hostility to see if we can recreate the observed bad behavior outside a competition FMS field.
Most likely, we will not use CAN and 2CAN again to control Jaguars on a competition robot until we know what caused our problems AND we can create a normal test environment where we can more accurately and consistently produce the FMS competition environment outside the time stress of a competition.
We will likely continue to simplify until we get robustness and try to make the some test environment tests more hostile than we expect the competition field to be: (Add noise in proximity to the radio, lower radio signal through shielding, inject expected worse case latency and jitter into the communication path, monitor behavior with wireshark)
We will also likely add software to log behaviors per second and see if we can correlate errors to other monitored conditions.
…but that commit log entry is dated for when the change was replicated from the internal SVN server to the public one, not when the actual change was submitted. If there were actually files for this on the public server (as there are in the WPILib for C++ source), I believe that log would show you the correct date of check-in and the person who checked it in. The distinction here is that the record you are looking at is part of the source forge data, not the SVN data.