AGHSEagleRobotics / frc1388-2013

Automatically exported from code.google.com/p/frc1388-2013
0 stars 0 forks source link

Drive Train subsystem code #4

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Implement the code for the 2013 Drive Train subsystem.

Original issue reported on code.google.com by jtec...@gmail.com on 25 Jan 2013 at 7:25

GoogleCodeExporter commented 9 years ago

Original comment by jonie4 on 26 Jan 2013 at 7:22

GoogleCodeExporter commented 9 years ago
Doesn't throw errors, and ready to test. Testing started 1/31

Original comment by jonie4 on 1 Feb 2013 at 3:43

GoogleCodeExporter commented 9 years ago
Initial testing of drive train code is a bit more complex this year, since 
there are two motors driving the same gearbox.  The only real issue is making 
sure that the motors are being driven in the same direction.  The motors will 
fight each other if driven in opposite directions.  This isn't a concern at low 
power for short periods of time, but should be avoided at higher power and long 
periods of time.  It's not necessarily obvious if they're being driven in 
opposite directions, as the symptoms are similar to those if the gearbox or 
other drivetrain components are jammed.

Checking wiring and code is not sufficient to determine that the motors will be 
driving in the same direction.  CIM motors themselves exist in both 
orientations, so that application of the same power polarity may result in 
opposite direction of rotation.  Bottom line:  There are too many variables to 
assume that the motors will be driven in the expected direction, and the 
direction needs to be verified by testing.

Ideally one could test that the motors spin in the desired direction before 
they're assembled into the gearbox.  In reality, assembly will probably already 
have happened before testing is possible.  While the motors could be tested 
cautiously in this state, it would be safer to eliminate the possibility of 
motors being driven against each other.

A simple workaround would be to disconnect one of the pair of motors from its 
motor controller - making sure that the disconnected leads are not touching 
anything conductive.  Then test the system with only the one motor.  When 
you're satisfied that the system is working as expected, connect only the other 
motor, and test again.  When they're both working as expected, connect both 
motors for final testing.

From a coding perspective, since the two motors must be controlled the same, 
all control function calls should exist in parallel in the code, in a way 
that's obvious.

Original comment by jtec...@gmail.com on 4 Feb 2013 at 8:12

GoogleCodeExporter commented 9 years ago
Finally fixed the kernel crash that haunted us for a week, and it seems to be 
working fine on the developer board, but the robot may be a different story.

Original comment by jonie4 on 9 Feb 2013 at 3:56

GoogleCodeExporter commented 9 years ago

Original comment by jonie4 on 15 Feb 2013 at 11:08

GoogleCodeExporter commented 9 years ago
Updating the status to reflect that this issue is closed.  "Fixed" now means 
that work is complete, but hasn't been signed off.

Original comment by jtec...@gmail.com on 15 Mar 2013 at 12:30