[Mike Copioli]

Originally Posted by kamocat

My impression was that the CANipede had these all on a single device, much like a central controller. I'm proposing small units which would be dedicated to an actuator, to supplement the Jaguars.
Did I misinterpret the description? Is the CANipede actually several devices?).

No, it is one device.

Originally Posted by kamocat

Personally I don't see the utility of putting sensors into ADCs on a CAN bus when we have a cRIO.

The ADC CAN node does not need to return just raw analog data. The node itself could perform the math functions needed for a particular sensor. The application could then request the resultant data when ready. In the case of the Victor, the canipede generates the PWM signal and reads the encoder making it a closed loop speed controller. The application simply sets a position or velocity over CAN the CANipede takes care of the rest. It also normalizes the output of the Victor so that it becomes linear.

Originally Posted by kamocat

For example, the gyro and accelerometer are sensors that require high sampling rates in order to be useful. Thankfully we have an FPGA to integrate the gyro, .

An FPGA is a digital device, by itself it is unable to perform analog sampling. It could be used to perform the integration math but it is not necessary since gyros and accelerometers do not require high frequency sampling. Is this what you meant?

Originally Posted by kamocat

we must poll that analog input very rapidly. Such an action on a CAN bus would be either sporadic, or block out all other communication (including the messages that keep the Jaguars enabled

This is not the case when CAN is implemented correctly. The FRC implementation is not the most efficient way. The current approach sends every CAN message over Ethernet/serial from the cRIO. The CAN device then must send an ACK back over Ethernet/serial to the cRIO. If I remember correctly the function is also blocking. A better way would be to allow the gateway device (2CAN or Black JAG) to perform all of the CAN "hand shaking" and have the application simply make requests for position, speed or current... The reason for the current implementation is to allow teams to create their own CAN gateways without having knowledge of the Tokenization protocol used by the Jags.