Lucky7Chess
commented
6 years ago I think I'm getting a good understanding of the drive. I cleaned up Christians good code up a lot for clarity sake and pushed it just now. To cover as much as we can of these issues today, I'm hoping to:
-
test the autonomous recording on the surrogate as much as possible
-
Once we get the robot, first thing we have to do is test that we can hold the arm at an angle without breaking it. This means unplugging it, watching the numbers, then plugging back it when we feel confident.
-
I'm leaving the IMU in for this reason. I can feed Chrsitian's drive a .7 .7 for instance in autonomous and make the straight paths. Count the distance with the readEnc method and then exit the command with the distance we need. Then I can use last year's turning code with last year's IMU and make any path I need with very little effort. This might be the fastest way to Auto if we can get that to work today.
I am out of time to do the autonomous choosing thing, but we can do that after today's meeting. It looks to me really straightforward once we get the drive straight and turn commands working. It's just a question of reading the manual then. If we can get the recording to work this afternoon then I consider that a great bonus too.
Wow, I'm actually using GitHub (sorry, newbie excitement)! (1) The KennyDrive for the drive train has nice feedback but it uses sticks directly, and we may want to "cook" the joystick inputs for Jimmy like we did for the direct tank drive. Team 272, the Comcast Bootcamp folks, talk about "cooking the inputs" prior to having the robot process the inputs; they don't do Command-based, so they can code that way - 293 has commands execute based on JoystickButton and the drivetrain is "always on", so adding the joystick sensitivity feature should be a method within the system for the drivetrain, OR, a separate Class that can be used by the auto playback feature as well. (2) OI.java still needs to resolve adding Stop commands separately or putting them internal to the end process within the original command that got fired from the button activity (3) RobotMap lists IMU as input 5 on Digital I/O, which might be the CAN assignment? Do we use it? Is it part of the "alternative" auto code Kenny is doing? No worries - it can stay on the robot (don't have to cut CAN wires!). (4) autonomousInit within Robot.java has an if statement with equivalent results; I'm sure this is going to be tweaked when we are ready for it. You guys have to remind me how we simulate auto mode. (5) Drivetrain still is controlling 3 motors per side. yeah, the 3rd is unplugged, but the motor controller is still providing a voltage to the unplugged wires that are only avoiding shorting out to the robot due to the red and black plastic covers on the outputs of the Talons. Better to not drive them at all - so we sort out the wiring to them, or, just pull the breakers (easier). (6) kennyDrive has proportional feedback on the speed but no feedforward to the control, so the error will always be nonzero for the robot to drive forward. Feedforward would let the drive be more responsive (I think) by making the error correction smaller, as well as have better tracking. This is due to the fact that the motor is controlling speed, vs. shaft position, for this function. (7) FeederShooter is currently power-command, vs. RPM command, and will sag as battery voltage drops during the match. Hillman wants RPM control; this would be good to fix and make him happy. (8) I haven't replaced autoLogger (with properly named, improved AutoLogger) yet ... (9) I haven't gone through the Commands much, most look pretty trivial and clean. I think I'm done for tonight, too. Uh-oh, it's morning ...!