[jhersh]

Originally Posted by boomergeek

Greg, As to your point, in browsing around, I had found...
http://www.chiefdelphi.com/forums/ar...p/t-86259.html

Radical Pi
07-14-2010, 09:25 AM
...
NetworkCommunication is searching for a driver station and communicating with the driver station, so it could account for the delay and the jitter.

This is not quite how it works. The Network Communication task does not search for a DS. It simply blocks waiting for a packet. A variable in the Network Communication object keeps track of status of the communication and if the robot has been enabled. The SendMessage entry-point simply reads that variable to decide if a message should be sent. It should not affect timing.

Originally Posted by boomergeek

I could not find source code for FRC_NetworkCommunication_JaguarCANDriver_sendMessa ge().
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)?

There is additional load on the system in general when using CAN, but I believe we've minimized a lot of that since last year.

Originally Posted by boomergeek

I did not see an equivalent for PWM controlled Jaguars to FRC_NetworkCommunications*sendMessage nor something equivalent.

That's because the PWM is controlled in the FPGA. NetworkCommunication is responsible for keeping the FPGA watchdog fed so that the PWM will continue to output.

Originally Posted by boomergeek

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

I'm not aware of anything in the parts that I have access to that even distinguishes that the FMS is involved, except for NetConsole deciding to squelch output if the FMS is attached and the robot is enabled (to reduce extraneous traffic on the field radio).

Originally Posted by boomergeek

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.

I'm not certain that this is the cause, but I can't think of anything at this point that I would expect to make a difference between field operation and practice operation.

-Joe