Quote:
Originally Posted by WSiggs
I would recommend making your own drive class, have it extend the RobotDrive class if you want, and set all of the motor values yourself. The main arcade and tank drive methods in the RobotDrive class are simple enough that you can recreate them easily with however many motors you need to.
|
This is what I also recommend you guys do. Re-implementing arcade/tank drive is super trivial and also gives you more control over what's going on under the hood.
On a side note, in 2014 we had 6 drive motors and implemented our own drive subsystem that automatically switched on motors based on the amount of current the drive train was pulling. It would also stagger motor startup to try and prevent brown outs. Basically when we were just driving around at a constant velocity it would only use one cim per side. The moment we hit an obstacle, the current used by that single cim would spike up and the robot code would bring online more motors to give the robot extra oomph and help break static friction. We called it hammer drive, because when we ran into other robots we would hit them like a hammer. You might want to experiment with something like this if you have time.
