Team 1519 - 2015 Code Release (Java)

We on Team 1519 had great aspirations of polishing our code over the summer and fall this year in order to do a fall 2015 code release with some nice, well-commented software.

Alas, the summer came and went with off-season tournaments, demonstrations and some downtime. We then found ourselves beta testing the 2016 control system and never really made the time to clean up the 2015 robot code so that we could post it.

So now, here we are, the morning of kickoff, and all we can share is the code we had in the robot during the competition season - complete with warts, spaghetti, dead code, and all. It also lacks as many comments and design documentation as it should have.

Nonetheless, maybe it will be of help to some other teams. Our autonomous worked pretty well last year, and we had high levels of automation during teleop driving.

Oh, and the robot’s name was “Kaizen” – that’s why you’ll find the top-level folder to be named Kaizen2015.

Feel free to post questions here or to email or PM me if I don’t seem to be paying attention to this thread during the build season… (117 KB) (117 KB)

Hello! I am the lead programmer for team 5484, and we are running into some issues with Java. I have our code, but it fails to deploy. I followed all of the 2016 instructions for setting up java for eclipse. When I run it, however, I get this error:

C:\Users\Ethan\wpilib\java\current\ant\build.xml:220: Assertion failed boolean test.
roboRIO Image does not match plugin, allowed image version: 19

Also, where is the 2016 or 2015 java installation for the roboRIO? I am using a slightly older version, but I do not think that that is an issue.

Any help would be appreciated. Thanks!

You need to image your RIO, that error is reporting the RIO should have image v19.

And instructions for RIO java install are

Generally I recommend you start at the top of this list and work thru each relevant section.

Hey Ken,
So it looks like for teleop your Mecanum drive used speed-closed-loop pretty much all the time (FP closed-loop).

Did you find that helped improve driving the robot during teleop?

Kaizen looks pretty good to me, I’ll take functionality over clean-up any day.

+1. If you do the above, the error you are seeing will go away – you need to get image v19 into the roboRIO.

Yes, our mecanum drive used exclusively speed-closed-loop, with the TalonSRX performing the closed-loop control in the Talon with directly-connected USDigital encoders. We tuned the PIDF control parameters manually (we ended up only using F & P as you mention), but once they were set, we simply told the TalonSRX the parameters to use, and let the TalonSRX do all the work.

We did code a contingency “open loop” capability via a button press on the driver station in case we had an encoder failure during a match. However, we never needed to use that in any matches. A nice feature of the “open loop vs. closed loop mode” button, however, was it permitted a direct comparison to see what was being gained with the “closed loop” control – one could drive the robot a bit in “closed loop” mode to see how it performed, then press a button to try “open loop” mode and see how it performed without the closed-loop. The difference was significant – the closed-loop control provided greatly enhanced driver control, particularly at low speeds.

By using the speed-closed-loop control, commands to make all 4 wheels turn slowly would actually make all 4 wheels turn at the desired rate, even if one wheel had slightly greater mechanical resistance or was carrying greater load due to weight distribution, or was up on the corner of a scoring platform. This was most beneficial at low speeds, particularly when trying to move as slowly as possible, such as in the final alignment of a tote or placing an RC. The closed-loop control also helped the robot drive more consistently whether it was carrying no totes, 1 tote, or a few totes.

The other feature that really helped our driving was implementing “heading preservation” when commanding the mecanum robot to translate, but not rotate. Whenever the robot was being commanded to translate, but not rotate, the code would determine the cumulative heading error since the last time the driver had commanded a rotation, and proportionally correct the heading (using a gyro as the heading reference). What this meant is that when commanding the robot to strafe sideways or diagonally, the robot would hold the initial heading, even in varying CG situations (such as whether or not totes were being carried.) This feature was a huge help.

We implemented a “field-oriented drive” capability (it’s actually nearly trivial to do so with the control paradigm used for mecanum drive) but our drivers preferred the traditional control scheme.

As an aside, we used position-closed-loop on the TalonSRX for both of our elevators. Again, we wired the USDigital encoder directly to the TalonSRX, simply set the PIDF parameters (we only needed P and D), and let the Talon do the heavy lifting. We made use of the “VoltageRampRate” feature to prevent sudden “jolts” of the elevator when starting / stopping, and were very pleased with how that worked out, too. These experiences have us sold on the TalonSRX.

Thanks for the kudos. Some of the code is still a mess.

It did work well, though – I haven’t yet tired of watching last year’s auto: