Auto Chooser

[will-hou]

The Driveteam should be able to select which auto path to run before a match without pushing any code. We could probably do this we several dropdown SendableChoosers in the ShuffleBoard:

1. Delay: How long the robot should wait before starting the path. This could be useful if we're starting behind another robot and need to wait until they're finished with their auto before we do ours. Before comp, we should have a sheet with run-times for all the different auto paths.
2. Push-Back Whether or not the robot should move backwards a bit before starting the path to push another robot off of the intimation line.
3. Starting Location Either the center(right in front of the Power Port), right (aligned with the far-side trench tape), or left(aligned with the edge of the Power Port).
4. Ending Location Either at the far end of the Trench Run, somewhere to the left of the Power Port(to get out of the way of other autos), or by the Shield Generator (this will be difficult to tune in the classroom so we may save this one for last)

We could then use all of these constraints to figure out what paths we should run. I'm not sure what the most efficient way to do this would be though. Since most of the current paths we have are generated during the auto period, we could just write a command for each path group (which is how things are set up in the autonomous branch currently). It would work, but it feels kinda icky. Any ideas here?

[will-hou]

@Jamdan2 Are the SendableChoosers? still broken?

[snowsignal]

@will-hou: I think the best solution is to write one single function that generates all possible autonomous paths, and takes in the constraints as parameters. It would be redundant to write several functions that perform almost the exact same routines, besides changing a few numbers.

And should delay be a SendableChooser or some sort of number field?

[will-hou]

I agree, a function to generate all possible paths would be the most ideal because we wouldn't waste time generating them during auto. However, this is very different to how we're currently doing it.

All of our paths are generated on-the-fly atm using the robot's true movements (in the x- and y- directions) and its true heading. This make them more resistant to any changes due to how the robot differs mechanically. Of course, this does mean wasting ~1-2 seconds of autonomous (even though path generation is only supposed to take around 35 ms).

I think as long as we can complete our auto sequence within 15 seconds, there's no reason I can see to not to stick with on-the-fly path generation. It would definitely save a lot of time tuning with pre-generated values that may differ on the practice and competition robots.

[will-hou]

Oh and yes, the delay could be a TableEntry(fancy Sertain thing @Jamdan2 wrote) with initialValue=0

[gnawinganimal]

The sendy is working so now we can get on this