[mjcoss]

Here's what we were planning:

1) We are using a two speed transmission from AndyMark. It has uses 2 motors, and has a single optical encoder built into the the gearbox (on the output shaft). I had originally intended to use speed & position control on the drive subsystem. Position control for autonomous, and speed control during teleop. We first tried just using a y splitter to feed both Jaguars, and then tried a master/slave arrangement. While we got it to work, it seemed unstable. I'm sure that with more time, we might have been able to get it to work reliably but there really wasn't enough time.

2) Our lifter mechanism had the same problem. We had intended to use position control to put the arm at preset heights. Again, we had two banebot motors driving a custom gearbox with an encoder of the output shaft. The position controls would work for some positions, but would oscillate and not find the set point at others. I tried tuning it several times and couldn't get something that was 100% stable. Again we tried a Y split, and a master/slave configuration. We ended up moving the encoder to the CRIO and ran the PID loop on the CRIO. This gave me better control on the loop, and was immediately stable.

3) We have limit switches directly connected to the Jaguars, for the lifter mechanism, and the claw. The bottom one on the lift mechanism was used to home the encoder. We drop to the bottom limit switch and set the encoder count to 0. This works fine unless we timeout on the get limit message. If that message times out, the API returns at limit, and we stop. The premature stop of the motor made zero be in the wrong place, throwing all subsequent offset off by upwards of 6 inches. Apparently, in Java you can catch the exception, but I didn't see anything in the C++ code to allow the caller to know that the results of the call was bogus. I've modified my version of the limit switch calls to return an error status so that I can decide what to do if an error occurs.

Now add into the mix that, under some unknown set of circumstances, we get a flood of CAN bus timeout messages making the robot completely unusable. Given all that, one has to wonder if using the CAN bus is a good idea. In addition, we get some number of intermittent timeouts, which while not fatal causes weird behavior because the code can't determine that a timeout has occurred since the caller is returned a valid return value even if the call times out.

I have updated the firmware to the latest versions. I've tried two different bus terminators. And new cables.

One item that we've seen that has lead me to point a finger at the 2CAN is that on our robot we have an onboard compressor. We have noticed that if during autonomous if the air pressure in the system is low and the compressor needs to run immediately, we get the flood of CAN bus messages. It is as if the run all 4 CIM motors, plus rehome the lifter, plus drop the arm, plus run the compressor is a trigger for the failure My theory is that the voltage drop is causing a failure in the 2CAN. Of course, it could be something completely unrelated.

We are going to St. Louis and I'm seriously debating whether we should rewire the bot to use PWM cables.