Quote:
Originally Posted by Tom Line
Last time I checked, having dual controls hooked to a speed controller was Illegal, so the rules may need to change as well.
However, I agree 100%. The reason we have never switched to CAN is because of the reliability issues some teams have had. We've Beta tested CAN on our robots with no problem, but right or wrong, I see PWM as a more robust option.
Is there a quick way to troubleshoot CAN, short of plugging in a computer and polling the devices? I.e. - is there a LabVIEW VI for the dashboard that shows each device and it's communication status?
|
Tom,
You are correct with the rules. I agree though that it would be a tweak in the rules. Just as long as they can show good compliance to the robot safety side.
As for the CAN reliability, we have some issues with the CAN bus but not tons. The biggest issues include some of the Jags losing ID's, some 2CAN boot issues. But it is obvious that others have had many more issues. Our Debugging usually consists of rebooting the 2CAN then checking the 2CAN page to verify all the Jags. In my mind CAN is a widely used Bus standard why FIRST cannot make it reliable is beyond me.
Quote:
|
Originally Posted by slijin
- Allow controllers to double as sensor interfaces - the closed-loop feature of the Jags was nice, but it would've been nicer if we could've read the sensors feeding into the Jags in our code.
|
I really like this idea. It can allow for more seamless data transfer between Jags and or data to the cRio! I am a big proponent of utilizing CAN for sensor/Telemetry data!