Hello! I’m am using a CAN based (speed mode) control this year for a mechanum drive equipped with the us digital E4P encoders that come in the KOP (with 360 encoder wheels), and a mentor brought up a very good question. What happens if an encoder stops working or malfunctions? My gut feeling is that with all the safety checks implemented in the CAN Libraries (Labview), The Jag would figure out that it’s not getting a valid signal from the encoder and simply shut down, but is there the possibility that it would just go full speed ahead in attempt to get to the set RPM (because it’s reading 0 RPM)? If a Jag can detect whether or not an encoder is out, and one does, I intend to have all of the drive-motor jags switch to voltage mode so you aren’t stuck with a dead wheel, or robot, depending on how it reacts… Does anyone know?
The Jag can’t tell if an encoder is out because the signal from a dead encoder is perfectly valid and could be telling the real state of a good encoder. I believe it would behave as your second guess… it would go full speed ahead. If you choose to monitor the speed by reading the feedback over CAN, then you could write code to attempt to detect the issue and switch modes.
-Joe
Spencer,
Yes, it goes full speed. We had this happen two days ago. That really helped drive home the safety issues to several of our students. No one got hurt even slightly, but it was scary.
We are looking to do something like Joe suggested by adding some code to look for this state. We also have the encoder signals on the drive train routed to the cRio to get distance, so we will likely put the safety code in that part of the loop. The good news is that it did stop when we disabled it.
I like your idea to have it switch to voltage mode if that happens. That might be a bit tricky to do, but it seems feasible.
-Hugh
Thanks a lot! It’s good to know that. Now that I’ve thought a bit about it, it would probably be equal effective to give the driver the ability to switch modes. The driver can recognize an out of control wheel just as well as a [well written] program. He would probably react slower, but having the driver do it would ensure that the robot wouldn’t go into V-mode at an undesired time, and the driver may want to go into V-mode for some reason. In fact, some drivers prefer the V-mode for everything except fine control, which is where speed mode really comes in handy. Just for safety though, it would probably be good to have an auto-switch feature: if an encoder is stationary for more than one second while more than, say, 2 volts are being applied to the motor, switch modes! I’ve heard, however, that the serial port on the cRIO has a little trouble both setting values and reading RPM from the jags simultaneously…
That’s not the case, except for the fact that only one message can be outstanding at one time. This is a limitation of the Jag, not the serial port. Each message only takes about 3ms - 4ms. You can typically have about 3 outstanding messages to different motors at a time.
-Joe
Does this mean the 2can has the same limitation?
Thanks,
Jason
Yes.
This is a limitation of the Jaguar firmware (or the sensor itself), not a limitation of the CAN bus.
You would have this same limitation in a PID loop on the cRIO.
If the limitation you are referring to is the inability to have more than one outstanding message at a time to a single Jaguar, then yes… it is the Jaguar and the 2CAN does not remove that limitation.
-Joe
Thanks for the information! What about the 3 outstanding messages in total? Is that a limitation of the serial port, the crio, or the Jaguars?
–Jason
That’s based on the time it takes for a message to be bridged from the serial port to CAN, the Jaguar to process each message, the time for the reply to be bridged to serial, and the actual transmission times on each bus.
-Joe
Thanks again for the information!
Jason