Autonomous

[ky28059]

Tasks to do before merge:

• DT constant tuning (ENCODER_ROTATIONS_TO_METERS) Monterey Bay Regional #27
• Path following constant tuning (PID, kS, kV, kA) Monterey Bay Regional #27
• Determine autonomous strategy
• Write paths for all 3 scenarios

[ky28059]

I don't think it's realistic for a driver to request a new shot in the 20ms periodic window between the first tick after the old shot is fired and the tick immediately following it. Also, drivers won't be able to request shots in autonomous (which is when this command would be used) and there's no way for two calls to this command in a SequentialCommandGroup to trigger this because the first command's isFinished() needs to return true before the second command's initialize() runs.

For isFinished(), we may not have to store shotRequested either; if initialize() always runs before the first call to isFinished(), isFinished() can be implemented like

@Override
public boolean isFinished() {
    return !internals.shotRequested();
}

[e3l]

ok, does it hurt?

[ky28059]

I guess not? But it's an impossible scenario anyways and it adds another field variable

[ky28059]

We'll need to think about how team color plays into the auton sequences. Do we just write 6 command groups or should we try to dynamically set which balls we're pathfinding to in the code? Will start positions change?

[e3l]

We'll need to think about how team color plays into the auton sequences. Do we just write 6 command groups or should we try to dynamically set which balls we're pathfinding to in the code? Will start positions change?

I think it makes sense to have 6 command groups, because we'll be starting in different positions. It seems easiest to me to return a different commandgroup based on some state variable that can be adjusted from shuffleboard