Quote:
Originally Posted by Mr. Lim
We are also seeing an occasional CANTimeoutException being thrown under brownout conditions.
Strangely, it is one Black Jaguar in particular that is always the one that goes first. It is connected to a CIM in our 4-motor drivetrain, and it is a "master" Jaguar, in that we have an encoder hooked up to it, and run it under speed control.
Under a fresh, full battery, the exceptions don't occur, but within a 2 minute match, the voltage certainly drops enough to start throwing these exceptions. We feel it is voltage related, as when we are in low gear, the exceptions never occur, whereas in high gear, they happen very frequently.
Our workaround so far has been to catch the exception, and re-initialize the Jaguars when they occur.
These seems to work decently well.
We've gone through the wiring several times, and can't seem to isolate why one Jaguar is more prone than the others. Less tolerant Jaguar? A CIM that likes to draw more current than the others? Your best guess is as good as mine...
|
I can say for certain we had one CIM in our pile of parts that had some issues with brushes. No matter what we did with that CIM it was trouble everywhere it went. It sort of worked on a Victor 884, but every time it touched a Jaguar of either model you'd either fault on startup or you'd get moving and shortly there after strange and bad things would happen.
We discovered it early on. I thought we disposed of it, or at very least marked it. Suddenly it 'reappeared' and made for another 2 or 3 hours of troubleshooting. I believe one of the other mentors showed it to the garbage can when I wasn't around so that it couldn't find it's way back into anything important again.
I can also say that one side of our robot drive train exhibits higher inertia than the other. While messing around with encoders before we isolated them that side was by far more likely to really have serious show stopping issues than the other which for the most part is the same exact design. Once we made the isolation board it stopped misbehaving and for the most part accepted the same PID tuning parameters for a setpoint of velocity (you could at least start tweaking the values from the side with less inertia and you'd be close). It drove nice and straight once we isolated the encoders until we started getting the CAN bus issues and then, after we trapped that error, it was good again. It doesn't seem to me that this particular part of our robot is any less well built than the other. We didn't, after all, fabricate the gear boxes themselves, and cursory examination doesn't indicate any obvious mechanical issue. However, it seems just a slight variation in the mechanism and even if we take the Jaguars from the side with less inertia they seem to have issues on the side with more inertia. Now I do grant the reader that in swapping the Jaguars we are using the wiring from the side of the robot that has problems and that might be why that side keeps being slightly more prone to problems. The wiring just does not itself seem bad.
As soon as I get a chance I'll rig a datalogger up on the robot while it moves. I'd really like to see what the power supply side actually looks like when this goes on.