[mikets]

We recently run into this issue as well. This is our first year using Jaguars on CAN bus. Apparently, a CAN bus command takes quite some time for a round trip. We are using 7 CANJaguars this year and we have implemented our own Cooperative Multi-Task Robot loop instead of using either the SimpleRobot or IterativeRobot templates. But it is based on the IterativeRobot class so we are also using the "20 msec" default DS loop time. The problem with this is that each loop involves updating each Jaguar. Updating each Jaguar not only involves setting the speed (the Set() method) but also possibly the GetPosition() or GetSpeed() methods if the Jaguar is involved in some sort of PID control. So the number of CAN messages per loop could be substantial. We found out that it consistently exceeds 50 msec for our loop. So we decided to do a SetPeriod of 100 msec. So effectively, we are hammering the CAN bus less frequently. We are going to add some more diagnostic code to collect info such as average number of CAN messages sent per loop and average time spent in each loop for sending CAN commands. We are experimenting with the implementation of a bandwidth limiting GetSpeed() method for the CANJaguar class. This basically checks the timestamp of the last call to SetSpeed and if the elapsed time between calls is shorter than a threshold, it will return the last speed value instead of sending another CAN command to get a new speed value. We probably don't have time this year but after the season ends, we would experiment with implementing an alternate CANJaguar class that is more parallel to the PWM system that no matter how often Set() is called, it will just update a variable remembering the new speed. Then a separate thread will be used to periodically send updates to the Jaguars. This will limit the bandwidth of the CAN traffic to a predictable level. Any comments on this approach?