frc868/2017-robot

The code for FRC 868's 2017 robot, Ratchet

2017-robot's Issues

CTRE Library Javadocs

Add to .classpath (eventually) - maybe then add to .gitignore since it's a pretty user-specific path for the docs.

Software Rotation Limit On Turret

0 degrees will need to be determined (probably the halfway point between limits) and then we need to figure out how far each way we can rotate, then limit the various subsystem set...() methods so they can't force the turret to rotate further.

Turret Rotation Subsystem

• Set Position Method (Resets encoder count?)
• Set Angle Method (set position of motor)
• Read Limit Switches (will be hard-wired to Talon as well - use DigitalInput for now)
• Set PID values

Volatile Fields with Thread Subsystems

Any field within a Subsystem that is modified or read by a separate Thread should be declared volatile to ensure synchronicity.

Localize Serial Objects to Threads

Auton Launcher

It's currently unfinished

ShooterSubsystem Naming Conventions

Change shooter/otherShooter to left/right shooter...see RobotMap for which is which.

ClimberCommand implementation

RecordMotors Interface

Implementable interface which forces you to provide a record() method or something, which then returns a value that can be saved to a CSV file or something.

Feeder Only Operates After Shooter Speed is Higher Than Limit

The feeder should only be able to be run forward if the shooter's speed is higher than some minimum amount - this will prevent the ball from getting lodged in the shooter wheel. The feeder should still be able to be run backwards.

Dump Hopper And Shoot Command

RotateTurret via Relative Angle

ShooterSubsystem SetSpeed

Using PID, though manual setting could be done (in Command?).

Subsystem Encoders

• Shooter
• Turret
• Drive

Drive will be a bit different, since we can't simply read the value from the CANTalon (they're going to have Sparks).

Feed & Shoot Command

• Spin up shooter
• Agitate
• Feed

Advanced Starting Points for Commands

Some auton routines will be run after others, for example dropping off a gear first then driving over to dump the hoppers.

• Gear to Hopper
• Hopper to Gear
• Gear to Baseline
• Gear to edge of neutral zone (ready to grab another gear at start of teleop)

Drive with Encoder/Gyro & PID

Drives forward, attempts to correct for deviation with the gyro.

Command Arguments & Command Factory

Idea for simpler command structure:

• Command Groups call only the main CommandFactory
• CommandFactory has static methods such as getGearOpenCommand() or getGearClosedCommand()
• CommandFactory calls subsystem-related command factories, such as GearCommandFactory
• Subsystem factories such as GearCommandFactory take arguments such as a boolean for open/closed, build a command via creating a new object and calling the add... methods, and return the created object
• More advanced factories for auton routines would exist, such as ones that take a starting point and build the auton routines accordingly

Possibly also an AutonFactory itself which adds multiple auton routines from different starting points: for example, builds a DropOffGearCG from RedOne, then a DumpHopperCG from GearPegOne, then a FeedAndShootCG from Hopper.

Robot Parts

Instead of Robot Map...

Spin Up Shooter Command

Pre-emtively spins shooter up to speed. We'll need to bind an operator's button to this.

Different Serial Subsystems for Different Ports

I understand we've been playing with the PixyCam on both Serial and I2C ports...we should have different classes for each of these e.g. ColorPixySubsystemSerial and ColorPixySubsystemI2C.

Shooter Counter Period

In the constructor, you should call count.setDistancePerPulse(1)

Calculate Turret Encoder Values

This can only really be done experimentally

• Drivetrain
• Turret

UpdateSmartDashboard Interface

?

Create Controllers in OI

Serial Device Subsystems throw Exceptions

When a subsystem for a device which uses some sort of serial communication (such as the LIDAR or PixyCam over USB or MXP) is constructed and a device isn't attached to that serial port, it throws an exception which breaks the entirety of the robot code.

It would be possible to catch this exception within the constructor itself. This would mean getInstance() has to do one of two things: return null which would create NullPointerExceptions in other parts of the code; or, continue trying to construct the device on the serial port until it succeeds, which would cause the code to hang indefinitely. Neither of these are very good solutions, though they're pretty easy to implement.

The current solution is to simply not use these Subsystems (e.g. don't call them in the UpdateSmartDashboard command) when the devices aren't hooked up OR just hook up every device properly, though both slow down the testing/debugging process.

Instead, we could have the constructor catch this exception and set the serial object to null. Every method which reads from serial would check to make sure it isn't null before reading, and in the case that it is null would return 0 for any measurement. Additionally, it would be good to have a public connect() method which reattempts to construct this serial object, and a method isConnected() which returns serial != null (essentially if the serial data being read is valid or just returning 0 as the error case).

Alternatively, we could just surround every interaction with the serial object with a try-catch, and set any expected return values to 0 in the catch statement.

LIDAR Subsystem readByte()

Call to isConnected() is redundant, as bytesAvailable() calls isConnected() as well.

Synchronize Pixy Field Accessors

As the IR Pixy Subsystem is now threaded, any of the getters or setters to the class fields need to be declared synchronized. These include methods such as processRecord() and getSizeOfTarget().

Thread ColorPixySubsystem

Just use the IRPixySubsystem as a template.

Drop Off Gear Command

• Drive
• Spin
• Drive More
• Release Gear

Fix Shooter Command

Currently sets the power of the motor, but sets it to about 0.8 volts. Should instead use the PID to set an RPS of something like 80.

Fix TODOs in Project

Move randomUtils to lib-robot

Flashlight Subsystems

RotateToAngle vs TurnToAngle?

I think it might be better to name it TurnToAngle in order to better differentiate it from RotateTurretToAngle...what do you think?

FeedAndShoot Command Group Should Call RotateUsingIRPixy

RotateUsingIRPixy will probably be started anyways at the beginning of auton or teleop, though it'd be good just to double check that it's running.

Drivetrain Subsystems

Sort out the difference between the DriveSubsystem and the DriveTrainSubsystem.

Create Style Guide

I'm noticing inconsistencies in the code (spaces vs. tabs, space between () and {, if x rather than if { x }, etc), and thinking that a unified style guide may be in order.

As an initial proposition, the Google Java Style Guide may work.

Move lib-robot Submodule into Source Directory

Pretty simple, move the submodule into src/, change necessary imports (only for the gyro really), and remove the copy/pasted lib/gyro source files.

Doing it sooner than later would be good, as it would likely mean less refactoring.

Auton Commands

Positions:

• Start
• Gear
• Hopper
• Neutral/Baseline

Auton Routines

• Start - Gear
• Start - Hopper (may not actually shoot)
• Start - Neutral (may not go far enough into neutral zone)
• Start - Gear - Neutral
• Start - Gear - Hopper (again, may not actually shoot)
• Start - Hopper - Gear
• Start - Hopper - Neutral

Motion Profiling

Using Atif's code from last year and Team 254's library.

Turret PID Tuning

• Shooter
• Turret

Simple Commands

• Drive by Distance
• Turn by Angle
• Rotate Turret to Angle
• Shoot
• Release Gear
• Agitator
• Feed to Shooter

Add Javadoc

Subsystems

• Agitator
• Drive
• Gear Collector
• LIDAR

More files tbd.

Turret Calibration

As in the title. Also (probably) a prerequisite for any kind of turret stops.

GetInstance Interface

It is possible with Java 8, though I'm not sure if the syntax for implementing static methods in interfaces is any different.

Simplified OI

• Sendable Chooser is pointless - adds clutter to SmartDashboard (just hardcode types)
• setupController(type) is pointless, we won't ever have more than one driver or operator

For the last one, the setupDriver and setupOperator should still be encapsulated to look nice.

Add Actual Values to RobotMap

Clean Up Warnings

Mostly import stuff, may be some other issues too

Agitator Back & Forth Command

Should repeatedly move agitator back & forth. We should bind an operator button to this.