Quote:
Originally Posted by apalrd
Basically, the Jaguar's CAN chip has a 1-message rx buffer, and the receiving software in the Jaguar is either not interrupt driven or the 1khz control loop has higher priority, so multiple messages will overwrite and possibly corrupt the buffer (why not lock the buffer while reading?). The FRC solution is to not send another message to a single Jaguar until the Jaguar responds with an Ack. The WPIlib implementation waits for the Ack by locking the thread and waiting, which is terrible programming practice, especially in a single-threaded program sending command messages at 100hz plus configuration messages possibly as fast. Also, a single Jaguar failure will cause a 10ms task delay for each message missed when a Jaguar is down, which can cause several task iteration to be skipped waiting for Acks from other Jaguars.
A better solution would be to queue all messages to send to the Jaguars for a given loop tick and send one message to a jaguar at a time and hope the spacing is enough, relying on the CAN checksum, or use a state machine for each Jaguar to check if an Ack has been received without block-waiting for it and locking the thread.
Luckily, the great folks at Cross The Road Electronics are working hard to fix this for the 2015 control system. Until then, Jaguar CAN sucks.
|
Continuing to parrot this rhetoric at every opportunity over a season after No-Ack commands have been implemented in the Jaguar firmware and LabVIEW libraries doesn't seem quite right.
Now if you want to complain about the C++ and Java libraries not implementing them, that would probably be more appropriate.