More automated system test

[aidnem]

Our systems test is currently very qualitative and also kind of a nightmare to perform. Instead:

• Buttons in Elastic that will test one mechanism each. The first button will be an "enable system test" button that sets some state flag in the CoordinationLayer so that it stops trying to do its normal coordination tasks. Probably, coordinateRobotActions should have a check at the start which, if the robot is in test mode and that flag has been set, it will call some other method (e.g. systemTestPeriodic) and return to cancel the rest of the functionality.
• Each mechanism's test will record:
  • Time to setpoint
  • Current draw at steady state
  • Error after a certain timeout (if it never reaches setpoint)
• If any of these go outside of a "normal" threshold (we will define this in constants) it should report it, probably as an alert

[thetaback]

@aidnem What should each subsystem do specifically for the systems test?

[aidnem]

@thetaback Here's a list. When I say "measure how much current is drawn" I think peak and average current draw is enough data.

• Drive: We should just test this one with a joystick in my opinion
• Hopper (spindexer): spin up to full speed, then stop. Measure time to spin up and how much current is drawn
• Indexer (uptake): Spin up to full speed, then stop. Measure time to spin up and how much current is drawn
• Intake pivot: pivot down, then up. Measure the time of each action and current draw
• Intake rollers: spin up to full speed, then stop. measure time to spin up and how much current is drawn
• Climber: no climb for blacksburg, don't worry about it rn
• Shooter: Spin up to 2100 RPM, then 2600 RPM, then 3100 RPM, then stop. Measure peak current and average current draw for each of these actions. I'd like to detect if we've somehow made it harder to accelerate or harder to maintain speed.
• Hood: aim up to max hood angle, half max hood angle, then back down to 0. Measure time & current of each action
• Turret: Aim to the robot's heading - the heading offset, then the robot's heading, then that + 90 degrees, then plus 90 more, then plus 90 more, then to the max turret angle, and then back to zero. (the reason this is in terms of robot heading is that the turret already has a state to control to a heading. If you want to track to an angle instead, feel free to add a state, just make sure it won't mess up our normal match gameplay). Measure max and average current during all of these. This should make it obvious to someone observing the test that the turret snapped to each of the cardinal directions.

To implement this, I would recommend using WPILib's command composition features. I would probably give the CoordinationLayer some kind of state flag that's like "inSystemTest" and then whenever that flag is true, it should return early out of coordinateRobotActions to avoid fighting the normal commands given.

[aidnem]

I marked this as low priority just because it's not going to win or lose us a competition by itself. There are definitely a shortage of "at-home" tasks to be done right now so it would still be great to have it be done.

[aidnem]

To publish commands to elastic, you can just do the following:

SmartDashboard.putData("Test Turret", /* turret command, e.g. SystemTestCommands.getTurretSystemTestCommand(turret, drive) */);

I suppose it might make sense to publish these commands in the first periodic cycle or in the set[Subsystem] methods as each subsystem is initialized.