Quote:
Originally Posted by Levansic
How often was too often?
Our calls are mostly embedded within the holonomic drive VI, but they are fire and forget as far as our code goes. At a lower level, there is a command and response that is required by the FRC architecture, on the CAN bus. So there may be some hanging for a response at levels far below what we can touch. We occasionally get timeout errors for the jaguars, but that happens far less often than the above-mentioned wrong number of bytes error.
|
We had the SD write calls in 10 & 20 mS loops. Per Doug, the SD write calls each try to send a TCP packet, and that takes time. No, the drivers don't need that much data. We also discovered that 1/S was too slow; we were missing reports of transitions in state machines. At 3/S, we were getting good info the DS, and the robot behaved much better. Setting some motors in both autonomous and periodic was not a good thing either.
My CAN comments were a shot in the dark for you to contemplate. I haven't dealt with it yet in FIRST, and at work, CAN interfaces are just another bunch of transistors. The (somewhat naive) point is to keep the control loop speed outside the time it takes to set up the CAN messages.
I'm still pining away for those CAN ports hiding down deep in the cRIO
Tim