I’m not sure who to target with this question, but I was wondering if the DIO module is capable being upgraded to a higher sampling frequency next near. I noticed that this year it has a sampling rate of 153kHz (which seems to be just perfect for 8bit resolution control for the Vics, Jags, and whatever other PWM devices one might use). Is there any talk of increasing the sampling frequency, or is the FPGA stuck with hardware limitations? Thanks.
For the Victors at least, there is no benefit in going to a higher pulse resolution. There are discrete digital steps used to control the output - the resolution of these are unchangeable.
For more information, see: http://www.ifirobotics.com/forum/viewtopic.php?t=317&sid=b4b2a1e44553e82aaecbe12fb23c60f8
I can’t speak about the Jaguar, though.
The diligent coders at NI willing, the Jaguars won’t even need PWM control next year, because we’ll be using the CAN interface on them. And they’ll be doing closed-loop position, velocity, and current control. With integral encoder and limit switches that you’ll be able to get feedback from through the CAN bus. Assuming, of course, that the gods of the GDC and FIRST don’t step in after kickoff with rules against using the CAN bus…
Ahem. Anyways, the FPGA itself can support base clock rates up to 40 MHz, but actual loop rates depend on the code you’re implementing. So only the NI gurus with the secret password know how much faster they could bump the loop rates.
Very interesting. Does anyone know if the Jaguar has discete steps as well?
Ok. Does the cRio even have a CAN interface? Or will it be part of another module? The only other interface I remember seeing is an I2C connection.
Since CAN is just a network protocol, I see no reason why the cRIO FPGA couldn’t be configured to support CAN through either the ethernet or serial ports.
NI has two CAN modules available. I would assume that’s what we would be given if FIRST decides to make the advanced abilities of the Jaguar open to us.
Your first statement is technically true, your second statement is not.
CAN in and of itself does not define the physical layer. However, it does define that the physical layer must have one dominant and one recessive state. Neither the serial port nor the ethernet port have this feature.
Additionally, “CAN” almost always implies a physical layer specified in ISO 11898-2. It is very possible to use other physical layers, but in conversation you would need to specifically mention you are doing something unusual.
In short, new hardware is required.
Gotcha. Thanks for the clarification!