Team 1410 2015 Robot Code

[King Nerd III]

Hello. I am the Lord Supreme Programmer at Team 1410, and we will be competing in the Utah Regional tomorrow. Our code has been mostly done (minus auto) for the past few weeks, and we have spent that time tweaking the TeleOp to run as smooth as possible. Tomorrow we will be finishing up Auto, so I will update when that happens, we just have some mechanical tidbits to clean up. Here is the GitHub link: https://github.com/FRC-Team-1410/RR2015-FRC1410
Now, on to the code. The code is written in C++, using the Command Based Robot template (included below). We have 4 subsystems, the DriveBase, IntakeArms, ToteLifter, and CanManipulator.

The DriveBase Subsystem has 4 CANTalons, two per side to drive the robot. It also has a Gyro, for turning. We drive the DriveBase using a two stick tank drive, meaning that the left stick drives the left side of the robot, and the right stick drives the right side. Inside of this subsystem are also methods to return the Encoder (we have 2, one per side) values and Gyro values during Auto.

The IntakeArms Subsystem has 4 CANTalons, two per side, with one motor to move the arm and one to turn a roller on each side. There are two methods, one to move the elbows, and one to toggle the rollers. Also, we have methods to use potentiometers, but we figured that we couldn't have them on the robot for mechanical reasons, so these methods are never used.

The ToteLifter Subsystem has 1 CANTalon, used to drive the elevator up and down. We have one method to drive the elevator, one to return the state of the top (reverse) limit switch, and one to return the bottom (forward) limit switch.

The CanManipulator Subsystem has 3 CANTalons, one to drive the elevator, and one on each side to move the arm. There is also one potentiometer plugged into the left and right CANTalon, and two limit switches in the elevator motor. There are two main methods, one to drive the elevator, and one to drive them arms. We also have methods to return potentiometer and limit switch values, and to reset the potentiometers.

Moving on to control of the robot we have 2 Joysticks, which are Xbox 360 controllers for us. One is driver_stick, and is only used to drive the robot around, axis 1 for left, and axis 5 for right. The second is operator_stick, on which we use 4 JoystickButtons and 2 axis. JoystickButton 1 (A button) toggles the rollers. JoystickButton 2 (B button) toggles the back (ToteLifter) elevator. JoystickButton 3 (X button) moves the front (CanManipulator) elevator down, and JoystickButton 4 (Y button) moves it up. Axis 0 moves the upper (CanManipulator) arms, and axis 4 moves the lower (IntakeArms) arms.
All of the Commands are organized into folders labeled with their respective Subsystems, so there are 4 (DriveBase, IntakeArms, CanManipulator, ToteLifter) folders. There is also an Auto folder, but this is unfinished at this time.

You may notice two weird things. The first is the array and method at the top of the OI. These are used to add a dead-zone into the controller, making them less sensitive. The second would be the SimultaneousOp CommandGroups in the IntakeArms and CanManipulator Commands folders. These are used so that we can both drive the rollers/arms, and the elevator/arms simultaneously. We could have had a command for this, but by using a command group we can also use the separate commands outside of it.

The code that is posted here may not be perfect, but it works 100% for us. Please feel free to leave any comments or questions below.
Enjoy!

[King Nerd III]

Autonomous is almost finished, and most of the code is worked out. The way we had to do it to get everything to work using all the command groups can get confusing, so please leave any questions below. Just incase, here's the link, again: https://github.com/FRC-Team-1410/RR2015-FRC1410

-Isaac, Team 1410 Chief of Programming and Head of Autonomous Control

[King Nerd III]

So autonomous worked once the code was uploaded, so let me explain what it does. The robot starts ready to pickup both the first tote and can. Right when auto starts both elevators lift up. Once those finish the robot drives forward to the next tote, while swinging the left arm and first can out of the way. Once at the second tote it lowers both elevators at the same time. Right after that it swings the right arm in and lifts the second tote. Once the second tote is lifted it lefts the second tote. Once all of that is finished the robot lifts the second can. Right after that it continues to drive to the third tote while swinging the right arm and second can out. Once at the third tote it lowers and subsequently lifts the third tote. After lifting all three totes the robot turns towards the auto zone, drives to it while lifting the front elevator a little bit more, and then stops in the zone. Finally it drops the totes, and drives backwards so we aren't touching the stack.

All of this had to be split up into separate CommandGroups because the AddParallel() doesn't work as it is supposed to with our robot. So if anyone wonders why everything is shattered into small parts, that's why.

-Isaac, Chief Programmer/Head of Autonomous Control

[Hjax]

You should really look into using a .gitignore file to avoid committing excess configuration files. These files are making your commit history nearly impossible to read and the changes that are automatically being made to them are not necessary for someone to download and compile your code

[King Nerd III]

Final Commit.

Final commit after Colorado Regional. We got to the semis, but were crushed. Code is a bit of a mess because of all the Autonomous changes that were made... I may clean it up later, I haven't decided if it's worth it. Over the summer we may work on getting a perfect Auto as an offseason activity.
-Isaac

[King Nerd III]

Originally Posted by Hjax

You should really look into using a .gitignore file to avoid committing excess configuration files. These files are making your commit history nearly impossible to read and the changes that are automatically being made to them are not necessary for someone to download and compile your code

The abundance of config files was due to how we had to move files around to commit, therefore they were brand new each time, not just updated.