Write basic Drivetrain code

[gerth2]

Some decisions have been made for Drivetrain, so we can get started!

Write basic drivetrain code for our drivetrain this year.

Requirements:

• Four motor outputs (two left, two right) to Talon SRX's
  • Output motor indices should be tunable easily at the top of the software (ie, if they change the order of the motor controllers, it should be easy to adjust in sw. No magic constants.)
• Two Joystick Inputs (Up/Down, and left/right)
  • Same thing with motor indices - make it easy to re-assign which joysticks map to what functions.
• Tank drive control
  • Pushing forward should cause both motors to go forward, pushing both backward should go backward
  • Pushing full left or right should cause counter-rotation in the correct direction.
  • Pushing at an angle should cause arcing

[gerth2]

Estimates as of Wednesday night say drivetrain should be ready to accept software by Saturday afternoon or evening. Before then, please check that basic driving is possible and as correct as possible (from visual inspection).

If time permits, also please check that the current estimation and battery param estimation are integrated properly and logging data to the .csv files

Schedule wise, if the drivetrain is actually done before end of saturday, I may come in Sunday to have some 1-on-1 time with the robot for debugging and tuning the current estimation. Will discuss schedule as it gets closer.

[Thuney]

If you do come in Sunday, let me know. I'm free and I'd like to help debug.

[gerth2]

Peachy . discussion over lunch today indicated it was not super likely, but I'm still hopeful. On Jan 21, 2016 11:30 AM, "Aaron Thune" notifications@github.com wrote:

If you do come in Sunday, let me know. I'm free and I'd like to help debug.

— Reply to this email directly or view it on GitHub https://github.com/RobotCasserole1736/RobotCasserole2016/issues/3#issuecomment-173645373 .

[gerth2]

Reviewed commit 0af31901bd , a few observations:

For logging purposes, need to expose the following data:

--Left/Right motor group commands --Left/Right motor group estimated current draw

Left/right encoder setDistancePerPulse should set to return 2pi radians per revolution which makes distance per pulse = 2*pi/NUM_PULSES_PER_REV. Make NUM_PULSES_PER_REV configurable, similar to the encoder port numbers. The setReverseDirection may have to be called on the left motor, not sure which one will be inverted (if either).

Be sure to call the current estimation getCurrentEstimate() method within every call to DriveTrain.drive().

None of this is needed for Saturday, of course :)

[Thuney]

I have a more up-to-date version that I haven't pushed yet. I'm checking the current draw before setting the motor values with a separate method. I'll push it later today so you can see it.

[imdunne8]

I just did some basic testing on this and found many errors. Please don't reinvent the wheel! There's no reason at all that we should be writing our own drivetrain code this year - the RobotDrive class provides all of the functionality that we need and it has the benefit of being used (and therefore tested) by thousands of other teams.

Recommended:

• Remove any calculations and manual motor setting in the DriveTrain class (remove drive() and setMotorVals() methods)
• Make DriveTrain extend RobotDrive
• Save the references to the SpeedController objects. Their get() method can be used in the future as a part of current estimate calculations
• Get rid of tunedVal and replace it with boolean squaredInputs (this is an input for both arcadeDrive and tankDrive methods of RobotDrive)
• Implement a constructor that takes in 4 SpeedController objects and calls super(frontLeft, rearLeft, frontRight, rearRight)

The drivetrain is nearly finished and electrical has a test board ready to put on the robot, so if @Thuney isn't able to get this done on Monday please comment back and let me know.

[Thuney]

You're absolutely right about us not needing to rewrite functionality that's already in the provided classes; an oversight on my part. I have changed the code to reflect the changes you suggested and will push the changes in the morning. I'm going to look into overriding the RobotDrive method "setLeftRightMotors" so that I can implement the current limiting at that stage in the code, as I feel that it's more logical (and easier) at that point. Sorry for missing the meeting today; I had a scholastic bowl competition in Bloomington/Normal and didn't make it back in time for there to be a point to go to robotics. Hopefully conversing through e-mail is enough for most trivial things to get done.

[imdunne8]

No worries about missing the meeting - there were only 2 programming students there and I spent most of the day trying to get GRIP working and getting our roboRio fully updated.

What you're saying should work perfectly. Just be sure to call super() and pass along the inputs in your overridden method.

[gerth2]

Validated. Check it out: log_4782488682661839640.zip