Quote:
Originally Posted by mjcoss
We are using CAN and used them as well last year. My concerns are the introduction of a single point of failure (2CAN), and the side effects of the safety features of the Jaguars. In a properly running system, the Jaguars run fine, and don't brown out. BUT this is a robotic competition, and bad things happen.
There has been persistent issues with timeouts. Some claim it's all just bad wiring on the part of teams, others claim that the CRIO/CAN driver is to blame, others that the 2CAN is the issue, and others that the Jaguars are bad. The upshot is that we have a number of components and lot a software in between.
One thing that I stumbled upon lst year was that if a CAN bus message timed out, the caller (in C++) receives no indication that an error occurred. This results in the CAN request returning valid (0) but incorrect data. So the test GetForwardLimitOK will return false on a timeout'd request. This can wreak havoc on code that is unaware of the issue.
|
We've been messing with CAN a bit this week in some testing and validation of our code. I'm using a home made Serial to Jaguar cable since our good one is bagged up with the robot. We're getting tons of CAN bus time out errors, but it doesn't seem to have any effect on the output. We're setting 4 motors every 10ms and using the Update Sync Group command. I don't think 10ms is too short of a time frame, but I may be wrong. We can probably increase it to about 50ms without any adverse effects. It's in a closed PID control loop.
We also did some reliability testing today as well... with the 4 motors setup and running, we yanked one of the cables out. No matter the position on the bus, all motors faulted, and stopped the output, which is a GOOD thing... at least in our case with all 4 motors driving the same device. Upon connecting the cable, the system got its act together in a seemingly short amount of time and was output power within a second of reconnecting. Seems good. Yanking the cable had immediate effects, but simply pulling the breaker seemed to output power for half a second or so before faulting. Not too bad, but not what I would like to see.
We're still on the "CAN is cool and all, but we don't trust it yet" phase. We're using it for one function on our robot, while all other functions rely on other means of control.
The 4 motors are controlled in a loop placed within periodic tasks, and they are only called there, so there are no floating calls elsewhere in the code to cause data intersections.
I can try to slow down the loop a bit, but really, I'm not too worried about it at this point.
Our code running on our simulation test bench is using about 75% of the CPU usage, and everything is running nice and smooth. We'll see how it is on the real robot later this week.