robototes / infiniterecharge2020 Goto Github PK

The limelight system only works if robot code is deployed after the robot is powered on. The codes needs to retry limelight initialization if it fails the first time

If the pre-calculated hood angle is too low or too high and shots are consistently being missed, allow the drive team to "trim" the hood angle to improve shooting. This functionalty should only be enabled when another switch is enabled.

• Enable switch on drive board
• Update hoodangle code to read switch and slider value and update hood angle if switch is enabled

Includes:

• Loading autonomous mode from
• Initial start position
• Trajectory to shooting position
• Shooting time window
• Shooting position
• Loop of
  • PC positions for pickup
  • Trajectory to PCs
  • Tertiary shooting positions
• Final position
• Trajectory to Final position

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

Rather than depending on humans to correctly configure all the motors before they are installed and/or replaced, the code should instead do a factory reset of them and set all configurable parameters when the robot starts. This specifically needs to include:

• Motor type
• Idle mode (coast or brake)
• Current limit
• Encoder counts per revolution
• Ramp rate enabled & speed
• Inverted or not
• Follower config & ID

Using information from the BOM from the subteams, do proactive current draw planning to make sure the robot doesn't disable itself when it's driving, intaking, indexing, lifting & rotating the shooter.
The link above has a good process for doing this that we should follow. Note that last year's robot would brownout simply by accelerating forward with max power to the drivetrain, so we likely will need enforce power limits in software to help protect the robot electrical system:

• Establish the max “sustained” current draw (with sustained being loosely defined here as not momentary). The WPI link suggests 180A
• Enumerate the different functions of your robot & assign available current to these functions
• Decide how to allocate power when the drive team is requesting the robot do things that will cause it to brownout. The drive coach must be involved in this decision.
• For mutually exclusive functions in this analysis, consider enforcing the exclusion in software

//Answer the following questions when given
- Robot Position (x,y)

//Questions

• Can we hit the inner target?
  • Yes / No
    • Nice to have shooting percentage?
  • Flywheel speed to hit
  • Hood angle to hit
  • Turrent angle to hit
• Can we hit outer target?
  • Yes / No
    • Nice to have shooting percentage?
  • Flywheel speed to hit
  • Hood angle to hit
  • Turrent angle to hit
• Target position
• Defensive sector (can't shoot full court)
• Our trench location
• Control panel location
  • Prevent lift (Just under control table?)
• Initiation line

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

Probably do not need to know unless we are adding more autonomy:

• Loading zone position
• Redenzvous point / climb
• Trench
  • their's (no contact)

The right motor on climb doesnt stop extending or retracting when the left motor does

Includes

• Logging module should have different logging levels (DEBUG, INFO, WARNING, ERROR, FATAL)
• Log messages should automatically add a timestamp with at least millisecond precision
• Log messages should able to be logged from any subsystem

The drive team will need to tell the robot what the plan is for autonomous mode.
Create an app to allow the drive team to pick various options which will be made
available to the robot via networktables.

This assumes there will be other possible hardcoded stages for each choice.
(ie if next to the trench, pick up more and keep shooting)

//Questions

• Starting position
• Shooting timeframe (when are we allowed to shoot)

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

Includes:

• Subsystems implementation
• Constants for subsystem
• Basic commands
• Unit tests for subsystem with commands
• Mocks for hardware used by subsystem
• OneNote page for subsystem created
• OneNote section for each hardware piece created
• OneNote section for any logic required by the subsystem
• Code style guidelines followed
  • Code formatted with default Eclipse style (Source -> Format)
  • Comments in code explaining non-obvious algorithmic items
  • JavaDoc comments for functions describing parameter ranges

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

The codrive board is still the prototype, not the real, competition driver board.

• Speak to drive team about codriver layout ergonomic changes
  • Remove climb buttons
  • Move shooter slider into that position
  • Move shooter switch above the slider
• Speak to drive team about joystick / laptop layout ergonomic changes
  • Align the joysticks including height (ideally get two of the same)
• Cut a new codriver board based on drive team feedback
• Connect network / adapter and secure it so network plug is readily available
• Shuffleboard changes to update based on feedback from drive team
• Nice to have : add LEDs (Should have 6 LEDs to match sensors)

Time is going to be tight when programming gets the robot to finish programming and testing.
Having a plan a head of time the includes what to test and verify should save time and help make sure nothing gets forgotten.

Testing should include happy path and failure modes.

Includes:

• Testing each piece of hard ware (sensor and actuators) for each subsystem
• Test each command for each subsystem
• Test functionality of each subsystem
• Test integration for each subsystem
• Test all the driver controls and overrides
• Test autonomous modes
• Get power usage for each subsystem
• Get peak total power usage
• Test power limiting logic, if any
• Test field location (IMU and Limelight)
• Verify logging
• Verify driver display
• What else?

Includes:

• Subsystems implementation
• Constants for subsystem
• Basic commands
• Unit tests for subsystem with commands
• Mocks for hardware used by subsystem
• OneNote page for subsystem created
• OneNote section for each hardware piece created
• OneNote section for any logic required by the subsystem
• Code style guidelines followed
  • Code formatted with default Eclipse style (Source -> Format)
  • Comments in code explaining non-obvious algorithmic items
  • JavaDoc comments for functions describing parameter ranges

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

Includes:

• Add a Limelight to an old robot
• Program the robot to locate a target
• Calculate the horizontal angle to the target
• Calculate the vertical angle to the target
• Calculate the distance to the target
• Program the robot to drive toward the target

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

Includes:

• Subsystems implementation
  • Proposed controls
    • Two joystick / tank drive - driver
    • Shift - driver
    • Lift up / down - codriver??
    • Intake up / down : on / off - codriver??
    • Shoot - driver
    • Target stop / start / pause (reset if it is tracking the wrong thing) - codriver
    • Limelight off/low, on - codriver
    • Acquire target - codriver (also acquire back target??)
    • Shoot - driver
    • Turret home - codriver
    • Dump balls from index (front, back, all)? - codriver
    • Control panel auto rotate - codriver
    • Control panel find color - codriver
    • Control panel manual rotation - codriver
    • Climb extend - codriver
    • Climb reach (low, mid, high) - codriver
    • Climb pull
    • Adjust flywheel speed ?
    • Adjust turret angle ?
    • Adjust hood angle ?
• Drive station hardware creation
• Constants for subsystem
• Basic commands
• Unit tests for subsystem with commands
• Mocks for hardware used by subsystem
• OneNote page for subsystem created
• OneNote page for each hardware piece created
• Code style guidelines followed
  • Code formatted with default Eclipse style (Source -> Format)
  • Comments in code explaining non-obvious algorithmic items
  • JavaDoc comments for functions describing parameter ranges

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

Includes:

• Subsystems implementation
• Constants for subsystem
• Basic commands
• Unit tests for subsystem with commands
• Mocks for hardware used by subsystem
• OneNote page for subsystem created
• OneNote section for each hardware piece created
• OneNote section for any logic required by the subsystem
• Code style guidelines followed
  • Code formatted with default Eclipse style (Source -> Format)
  • Comments in code explaining non-obvious algorithmic items
  • JavaDoc comments for functions describing parameter ranges

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

Includes:

• Subsystems implementation
• Constants for subsystem
• Basic commands
• Unit tests for subsystem with commands
• Mocks for hardware used by subsystem
• OneNote page for subsystem created
• OneNote page for each hardware piece created
• Code style guidelines followed
  • Code formatted with default Eclipse style (Source -> Format)
  • Comments in code explaining non-obvious algorithmic items
  • JavaDoc comments for functions describing parameter ranges

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

The drive team wants to know the pressure in the pneumatic tanks.
They (and / or programming) may also want to control the pressure or when the compressor runs.
(If we won't have enough pressure to extend the climb arms or we need to stop it for power savings.)

This suggests compressor / tanks may be a good candidate for a subsystem.

Includes:

• Subsystems implementation
• Constants for subsystem
• Basic commands
• Unit tests for subsystem with commands
• Mocks for hardware used by subsystem
• OneNote page for subsystem created
• OneNote page for each hardware piece created
• Code style guidelines followed
  - [ ] Code formatted with default Eclipse style (Source -> Format)
  - [ ] Comments in code explaining non-obvious algorithmic items
  - [ ] JavaDoc comments for functions describing parameter ranges

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

Whent the robot starts, it soon crashes here sinceLiftState isn't something that can be logged:
@Log private LiftState m_currentState = LiftState.DOWN;

Full error message is:
"Error! Attempted to log invalid data type m_currentState in container LiftSubsystem. Data was of type frc.team2412.robot.subsystems.constants.LiftConstants$LiftState; acceptable types are Sendable, Number, Boolean, and String"

@SumedhP mentioned that this likely means a lot of the logging is broken and will need to be updated

There are certain conditions where intaking more powercells will likely lead to index jams. At this point, the drive team either needs to spit or shoot (preferably to shoot). They need feedback they are in jam prevention mode.

• Update shuffleboard to prominently display when the robot is in "jam prevention mode"
• Update code to determine and log jam prevention

The drive team should know certain information about the robot to be able to drive most effectively.
This will need to be displayed on the drive station PC. It will gather information from the robot / shuffleboard / networktables.

Includes:

• Limelight view
• Distance to target
• Turret error
• Turret position
• Shooter / limelight active
• In inner targeting area (It is possible to hit the inner target from this position)
• Inner target acquired
• In outer targeting area (It is possible to hit the outer target from this position)
• Outer target acquired
• Intake active (front, back, neither)
• Intake position
• PCs locations in robot (intake and index)
• Control Panel color
• Control panel rotations?
• Lift position?
• Hanging switch
• Pneumatic Pressure
• Battery voltage
• Total Current draw
• Drive base draw
• Climb arms see the bar

Nice to have:

• Flywheel speed?
• Limelight

@SumedhP or someone else, only lift is using a double solenoid - everything else is using a single solenoid with a spring return. Please fix the code to match, and update the solenoid port #s so they don't overlap or fall outside the range 0..7 that are physically possible.

Here is the main issue for suggestions and comments from Team 3161 for the ChiefDelphi code review party.

• RobotState could probably be split up into smaller classes, ex. individual subsystem states. ie RobotState, ClimberState, FlywheelSubsystem, etc. Or, if possible with the Oblog annotations, expose the various states directly from the subsystem implementations?

• Robot#teleopPeriodic, Robot#autonomousPeriodic simply decrements timeRemaining by 0.02 upon each invocation. This is theoretically correct because the main robot loop "should" run at 50Hz, but in practice there can be some variance depending on external factors like CPU load or IO, so the timeRemaning value has some degree of uncertainty compared to the "real" match time remaining. WPILib Timer can probably replace this (ie Timer.getMatchTime())

• Robot#robotPeriodic looks like it's logging every other frame, but it's not really clear why this strategy was chosen. Also the static member log is declared in the middle of the file, rather than more conventionally at the top

• Robot#autonomousInit has some magic constant values for various commands, like adjusting the hood to "300" or setting the flywheel to -0.9. These should be extracted to a class constant (private static final double) for easier maintainability and reduced odds of missing changes in various places when refactoring

• RobotMap has some cool static members like CLIMB_CONNECTED, which appear to be used to conditionally (at compile time) disable robot subsystems which may be physically disconnected and not present. This is a neat feature, but the naming could probably be clearer, or at least some comment explaining how/why subsystems can be "disconnected" and various components such as solenoids intentionally initialized to null. It also isn't entirely clear to us why RobotMap contains these static members, which seem to really be used as instance state for the RobotContainer. Overall RobotMap is quite long and contains a lot of global, static "state" things.

• Following on from above - there are a lot of nullable fields for various components. Why do these all need to be nullable? What happens if ex. a sensor is not physically plugged in and the DigitalInput is instantiated anyway?

• RobotState and RobotMap both feel like large, do-everything, global state holders, but the separation of concerns between them doesn't feel too clear

• IndexIntakeSelector is an interesting pattern. The fields that it assigns belong to its parent class, RobotMap, and its constructor simply sets a series of fields by calling a utility method owned by the Selector. Why is this preferable to simply setting the indexSelector field of RobotMap by directly calling a utility method, rather than wrapping that utility method within a class and a constructor and a heap allocation?

• OI has nice enums for things like left and right Joysticks, but it seems like it misses the opportunity to also have an enum for the axes of these Joysticks

• More of a question - why does DriveBaseSubsystem set the motors to follower mode as well as put them into a SpeedControllerGroup?

• DriveBaseSubsystem#getWheelSpeeds has a magic number of 10 used somehow for scaling the sensor velocity. This should be extracted to a meaningfully-named constant

• DriveBaseSubsystem#getMoveThreeMetersForwardFromStartCommand seems redundant when you also have getMoveCertainAmountCommand

• Similarly, HoodSubsystem#servoExtend/servoWithdraw could probably just call setServo instead of copying the implementation

• DriveBaseSubsystem#getMoveToPowerCellPathFromPathWeaverCommand gets the deploy directory, then resolves an absolute path from it. But absolute path resolution doesn't depend on what the base path was. Also, the absolute path resolved includes a drive letter and a specific username. This should probably be a path relative to the deploy directory. Also, if the file at the path does not exist or is otherwise unreadable, an IOException is caught but the trajectory object is left null and passed to the RamseteCommand. How does the RamseteCommand handle a null trajectory? Should the exception handler return a different command, or some "empty" Command implementation?

• Why are there both IntakeOnOff and IntakeUpDown subsystems if they both deal with the intake? Could there be one "larger" subsystem that handles all responsibilities of the intake, similar to your indexer subsystem superstructure?

• ControlPanelColorSubsystem#colorToString seems like it could just be a method on each of the color enum members, rather than a method to perform this mapping of enum member to String

• ControlPanelColorSubsystem#rotateControlPanel has a magic number of 7 for the rotationCount, which should probably be extracted to a field/constant. Also the 0.25 and 0.5 wheel speeds could be constants

• Unit tests: there is a common pattern that looks like:

FooCommand command = new FooCommand(someSubsystem);
MockButton button = new MockButton();
button.whenPressed(button);
button.push();
CommandScheduler.getInstance().run();
button.release();
verify(someSubsystem).somethingHappened();

What is the reason for creating the MockButton and running through the command scheduler here? This seems like a very heavyweight approach. It looks like this would be equivalent to the following:

FooCommand command = new FooCommand(someSubsystem);
command.initialize();
command.execute();
verify(someSubsystem).somethingHappened();

But this way requires far less test setup since there is no command scheduler involved.

The logging system doesn't have a design for how to archive logs for test runs and official matches.

To keep the robot from pulling out and destroying wire, the turret needs to be limited to turning at most 90 degrees from zero.

• Update software to limit the turret from going past plus minus 90 degrees.
• Protection should include any situations where the turret may reset or re-zero itself.
• Verify the turret will never try to go past these limits with real world testing on the robot.
• Verify logging includes turret angle.

Includes:

• Subsystems implementation
• Constants for subsystem
• Basic commands
• Unit tests for subsystem with commands
• Mocks for hardware used by subsystem
• OneNote page for subsystem created
• OneNote section for each hardware piece created
• OneNote section for any logic required by the subsystem
• Code style guidelines followed
  • Code formatted with default Eclipse style (Source -> Format)
  • Comments in code explaining non-obvious algorithmic items
  • JavaDoc comments for functions describing parameter ranges

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

There will be times when we want to run diagnostics or make configuration changes to the robot, but we don't necessarily want the additional functionality convoluting the competition drive board.
On the other hand using the driveboard can help make sure it is working for the competition.

A diagnostics board should allow testing of the various subsystems using a joystick

• climb
• intake
• indexing
• shooter
• drive base ?
• lift belt?

The Limelight LED's may be too bright to keep on all the time. When the limelight is off, it will save time if the robot has an idea of where it is to keep the turret aimed to make target acquisition faster.
It may also help with trajectories in autonomous mode.
We also may want some guidance for the robot when the turret hits the physical stop and needs to spin back around the other way to acquire the target.

Use an IMU to help give guidance information to drivebase and to the turret.

Includes:

• Implementation
• Basic commands
• Unit tests
  • Mocks for hardware used by subsystem
  • OneNote page for subsystem created
  • OneNote page for each hardware piece created

Code style guidelines followed
- [ ] Code formatted with default Eclipse style (Source -> Format)
- [ ] Comments in code explaining non-obvious algorithmic items
- [ ] JavaDoc comments for functions describing parameter ranges

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

Includes documentation to

• Update robot software to the correct version
• Update the drive station software to the correct version
• Steps to test the drive station functionality
• Steps to test robot functionality

Includes:

• Subsystems implementation
• Constants for subsystem
• Basic commands
• Unit tests for subsystem with commands
• Mocks for hardware used by subsystem
• OneNote page for subsystem created
• OneNote section for each hardware piece created
• OneNote section for any logic required by the subsystem
• Code style guidelines followed
  • Code formatted with default Eclipse style (Source -> Format)
  • Comments in code explaining non-obvious algorithmic items
  • JavaDoc comments for functions describing parameter ranges

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

We need to settle on IDs for each piece of hardware.
Create a wiring diagram to layout sensors and hardware sensors used on the robot for each subsystem (but not physical location).
Ideally, it will also note voltage and current draw.

If the index feeds multiple PCs to the flywheel in too rapid a succession, the shots will fall short.
The PCs should be fed at the fastest speed possible to consistently make shots.

• Get data to find out flywheel speeds necessary to consistently make 5 PCs in succession
• Update index shooting code to make sure a PC is only fed to the shooter when the flywheel is at speed.
• Slow the index belts down to make sure they feed at more appropriate speed to help reduce the stress of rapidly starting and stopping on the index motors

Includes:

• Subsystems implementation
• Constants for subsystem
• Basic commands
• Unit tests for subsystem with commands
• Mocks for hardware used by subsystem
• OneNote page for subsystem created
  • OneNote page includes details for each RIO-controlled hardware element used
  • OneNote page includes details of any logic required for the subsystem
• Code style guidelines followed
  • Code formatted with default Eclipse style (Source -> Format)
  • Comments in code explaining non-obvious algorithmic items
  • JavaDoc comments for functions describing parameter ranges

Done:

• All above items are checked
• Pull request created
• Pull request approved & merged

The gyro variable is created, but not initialized.

Climb has changed the hardware connecting the chain. The software needs to be updated to reflect the changes so it can properly control the subsystem.

• Meet with climb to determine what code changes are needed (Zero and stop positions / conditions)
• Code needs to be updated to reflect the new logic or values.