Write code for the Drivetrain subsystem.

This is for the Talon SRX + CIM drivetrain.

Add a README.md giving a basic description of this repo and also includes sponsor logos.

This is for the Talon SRX + CIM drivetrain.

At this stage it's not possible to complete the entire thing yet, but we can get started on the very basic parts.

Find docs here.

• Distance estimation
• NetworkTables API

RIP all the work I've done in the past two weeks

Add vendor deps for NavX, and CTRE Phoenix.

If we do decide to use a Neo drivetrain, add libraries for Spark MAXes as well.

Add our own libraries, including RobotLib, StdPlug-API and optionally RobotPathfinder.

Add auto closed-loop target alignment from Limelight data.

Refer to #14 for docs.

Add a .travis.yml to set up Travis CI.

Write code for the TeleopDrive command.

This is for the NEO + SPARK MAX drivetrain and includes two parts:

1. Writing the basic command for split arcade drive
2. Utilizing advanced features on the MC such as ramping

Set up logging for the robot using com.arctos6135.robotlib.logging.RobotLogger.

Write code for the Drivetrain subsystem.

This is for the NEO + SPARK MAX drivetrain.

Changelog: https://wpilib.org/blog/wpilib-202022-update

Update the version in build.gradle and install new extensions. Optionally, use the new XboxController.Axis instead of the RobotLib constants class for TeleopDrive.

This thing is very convenient when it comes to testing, especially since it allows you to run a side at a time at any speed, which is useful for diagnosing gearbox issues. The main issue is that the robot doesn't actually use a DifferentialDrive object to drive, so we'll have to do some hacky magic to convince Shuffleboard to put our own drivetrain object on the dashboard.

The NEOs' temperatures should be constantly monitored. if they exceed a certain amount, there should be a warning on the dashboard and possibly also disable the motors.

Write code for a TeleopDrive command to drive the robot using a controller.

This is for the Talon SRX + CIM drivetrain and includes two parts:

1. Write basic command for split arcade drive
2. Utilize advanced features in the MC such as ramping and overcurrent protection.

The indexer design is also mostly finished, so we could start working on a very basic version of it for now. We don't yet fully know how exactly it will work and how it will integrate with Tigger (the tower feeding into the shooter), but for now we know:

• We will be using the V-indexer (you should've seen the prototype by now)
• The indexer has 2 separate motors (most likely both brushed, so use Talon SRXes)
• There should be one button that spins both belts in the same direction for a fast feed into the tower
• There should be one button that spins the belts in opposite directions to avoid jams

The controls for the 2 basic indexer features outlined above should be on a separate controller. If not already declared, this would be the controller with index 1 (new XboxController(1)). Be sure to confirm with the people working on the intake (#23) so you don't end up using the same buttons. If you have any questions, please ask me or Michal.

The indexer is directly attached to the intake and will funnel power cells and feed them into Tigger, the tower that will bring the power cells up into the shooter. Shown above is a CAD model for it (belts not shown, bottom image is the latest).

The indexer will have 2 motors, one for each belt. (The belts might be running in opposite directions to prevent jams.) Tigger has a motor for its belts which bring the power cells up to the intake, and another motor for the front roller, which will feed power cells from the intake into it. Tigger will also have 2 photoelectric sensors positioned on the back wall at the bottom which allows us to stack the power cells neatly.

Here's how it should work:

• When the intake (#23) is lowered and also a few seconds after it is raised again, run Tigger and the indexer, unless Tigger is already full.
• The two indexer belts should run together along with Tigger's front roller to bring power cells in until the bottommost photoelectric sensor of Tigger is activated. Then, stop the front belt and roller, and start running the up roller/belts of Tigger to bring the power cell up, until the other sensor is activated and the bottommost sensor is deactivated. Repeat as needed.
• Tigger should keep a count of how many power cells are in it. It can only hold 3 power cells maximum, so if there are two power cells in it, run only the front roller and indexer belts to bring the third power cell into the bottom, but don't run the up rollers to bring it up. If there are 3 power cells in it, don't do anything.
• When neither sensors are activated, Tigger is assumed to be empty. The power cell count can then be cleared.
• We will likely sense when we have shot a power cell through monitoring the RPM of the shooter wheel or some other method. For now, don't worry about power cells exiting Tigger.

The intake subsystem is close to being finalized. It will take some time to be built, but if you want some work to do, we can start writing controls for it now. (This is entirely optional for now.)

Here's the CAD for the intake we will be building:

There will be one motor to control the rollers (most likely brushed - go with Talon SRX for now if you're doing this), and one piston to control the raising and lowering of the intake. The intake should always start raised so it fits inside the frame perimeter. The raising/lowering should be a button for toggling, and the rollers can be controlled by either an analog trigger or button. The intake controls should be on a separate operator controller - if not already defined, this will be a new XboxController(1).

If you want to work on this, please let me know. Otherwise, I will assign this or do it myself when the intake is closer to being done.

P. S. Oops just realized I didn't teach pneumatics yet. It shouldn't be that hard. Ask me if you have any questions, but if you want an example of how it's done, you can look at the pneumatic-prototype branch.

Waiting until everything else is done.

Add an auto chooser onto the dashboard and options for no auto or init line auto.

We're not sure if we're going to have one yet or come up with any designs, but just putting it out here. This should be a pretty simple mech so it's good for new members to work on, but if time is too tight I might have to do it myself.

• Driven by 2 CIMs in the same direction
• Controlled by left analog stick on operator controller - pushing forwards (negative Y value) raises the elevator, pushing backwards (positive Y value) lowers the elevator
• Usually can only be raised during endgame (last 30 seconds), use DriverStation.getMatchTime() to get the match time remaining (but can be lowered any time)
• If the button under the analog stick (XboxController.Button.kStickLeft) is pressed, the above behaviour is overridden, and the elevator is free to extend and retract any time regardless of time limit

The subsystem should be called BryceFour in code, and the behaviour can be implemented through a default command.