|
Re: Robots not under driver control- does it happen- do you determine why?
We ultimately found a number of problems that could have effected our robot. Going down the list:
1) The classmate PC had a broken ethernet port that prevented the cable from clicking into place. If memory serves, the cable only needs two specific wires to be connected for it to think there is a proper connection (even though some data wires may not be connected). This may explain our dead robot during teleop while the field showed we were connected.
2) In labview there is no error handling in the CAN-Jag VIs. The potential is that if there is a CAN error and the cRIO does not at least accept the error (it doesn't necessarily have to do anything about it), it could cause the cRIO to freeze or lead to partial functionality of the CAN network.
3) During autonomous it was evident that the robot was not being fully killed when autonomous ended. At the end of one of our autonomous routines the robot is commanded to rotate at the very end of the period. Often times this command is chopped by the end of the period. After reviewing replays we found that on some occasions the robot would stop rotating once the period ended, then after a brief pause would finish the command as teleop was starting. This, however, did not coincide with our occasional loss of comm or occasional loss of some of the CAN-Jag controllers.
Ultimately we decided to not roll the dice and took a number of precautionary measures in the week hiatus between Kansas City and Oklahoma:
The autonomous was no longer commanded to rotate at the end of the period.
We rewired all but one of our Jaguars to PWM control. The one remaining Jag was now technically operating off RS-232. This one was necessary as it used an encoder to determine arm position and we did not want to reprogram the cRIO to incorporate an internal PID control.
We replaced the classmate with one of our development laptops, a run of the mill Dell or Toshiba, to resolve our connector issue.
Ultimately these changes resulted in a flawless performance of the robot at Oklahoma, but does not necessarily provide any answers to our previous problems. It is evident, however, that we had at least two problems (loose ethernet connector and no CAN error handling) that should have been addressed before Kansas City and potentially would have quenched all of our problems. However, it was not worth potentially ruining another regional to test that theory out.
We may attempt to do more testing next year with the CAN control. Additionally we found that during testing in the build season, the laptop was never operated in practice mode (so we never truly simulated "field" conditions) and we never used the classmate in testing (potentially our biggest mistake).
Regretfully, after observing numerous Jaguar failures for other teams, and a few of our own, we may end up moving to the more bulletproof Victor controllers unless a hardware change is implemented in the Jaguars to improve their reliability.
__________________
Team 935 RaileRobotics Alumni: 2001-2004
Team 935 RaileRobotics Mentor: 2009-Present
|