Team 254 2013 FRC Code

[BigJ]

Originally Posted by joelg236

I did a diff on your CheezyGyro class, and the only important change was making initGyro() public. Is this only to calibrate the gyro when you want to? Why didn't you just adjust it in the wpilibj and compile with the custom version?

Then anyone checking it out would have to have the modified WPILibJ

[joelg236]

Originally Posted by BigJ

Then anyone checking it out would have to have the modified WPILibJ

I suppose so. Although who would compile it? Not everybody has an Overkill

[BigJ]

Originally Posted by joelg236

I suppose so. Although who would compile it? Not everybody has an Overkill

Any other 254 programmer with a new dev environment?

[joelg236]

Another question, I haven't seen a single final variable, even in cases where I can't see a good reason not to. Any reasoning behind that or is it just because you know you won't write code to mess with them?

[xmaams]

You actually can use the DPad up and down if the switch on the controller is set to D. Then it is axis 6.

[apb2390]

My compliments to Team 254's Programming team and mentors. That's some beautifully structured code you have there. I especially love how elegant your seven disc auto sequence is.

[xmaams]

Could you explain the purpose of the negative inertia maths in CheesyDriveCommand.java? Is it to limit the change in PWM?

[Jeremy Germita]

Thanks to everyone at 254 for the yearly release of your software. Since you began doing this, 254 software releases have been a source of inspiration and learning for me as a programmer. I especially appreciate the style guide. I will be using it to format 399 code for release later this month.

Originally Posted by xmaams

Could you explain the purpose of the negative inertia maths in CheesyDriveCommand.java? Is it to limit the change in PWM?

As a user of a variant of cheesy drive, I've observed that negative inertia calculations and outputs help prevent overshooting during turns by momentarily outputting a calculated output(whose sign is opposite the actual turning direction) to help act as a tuneable brake. This makes turning on a dime and other quick yaw-axis motions a little more controllable when coupled with the rest of the cheesy drive algorithm. Cheesy drive aids controllability on robots that are fast(14+fps) and can turn quickly because of that.

[Tom Bottiglieri]

Originally Posted by joelg236

I did a diff on your CheezyGyro class, and the only important change was making initGyro() public. Is this only to calibrate the gyro when you want to? Why didn't you just adjust it in the wpilibj and compile with the custom version?

This route would require maintaining a fork of the library and requiring anyone who wants to build our software to use the forked library. Putting it in our source tree makes it easier to maintain AND gives the added benefit of giving compile time errors if something changes upstream.