This week, we now have a drivable robot, a prototype intake, and a motion profiling system ready to go. What is there to do but write a few auto routines? Even without a shooter, we can still test most of the important functionality. After some discussion with the strategy team, we began work on the following routines:

• One cargo (from any position)
• Two cargo (collect any of the three cargo around the tarmac)
• Three cargo (collect two cargo from the lower tarmac)
• Four cargo (intake one from the terminal)
• Five cargo (intake from the terminal, including the HP cargo)

See the videos below for the three, four, and five cargo autos in action.

Five Cargo

Four Cargo

Three Cargo

(The three cargo test had an extended shooting duration.)

The Flywheels

While we don’t have a shooter on the robot yet, we know enough about the design to control it in software. The structure of the subsystem code allows the hardware to be replaced while preserving the control logic — we can switch between SparkMAX and CTRE motor controllers, disable the hardware in replay, or turn it into a physics simulator. Throughout these tests, the robot is running the flywheels in a simulation, meaning the routine can check if they’re up to speed when shooting. We use the WPILib FlywheelSim  class. The graph below shows the flywheel speeds produced by the robot during the video of the five cargo auto. The red boxes show when the feed system was “running.”

The Paths

We decided to position the intake and shooter on opposite sides of the robot, which makes these routines much simpler. The three and four cargo paths are fairly intuitive, as they aren’t significantly limited by time. On the five cargo path, we considered two possible ways to run the routine:

1. Shoot one cargo immediately, collect two from around the tarmac, shoot two, collect two from the terminal, shoot two.
2. Collect one cargo from around the tarmac, shoot two, collect one from the tarmac, shoot one, collect two from the terminal, shoot two.

We ended up going with the second option for several reasons. First, shooting immediately requires waiting for the flywheels to spin up. While this may happen quickly, we don’t know for sure right now. Second, moving between the two cargo around the tarmac in a single path is tricky. With a differential drive, the fastest method seems to be a “back up and turn,” which is complex and still inefficient.

Another unknown variable is the time required for shooting. While the three and four cargo routines can be fairly generous by sitting still for multiple seconds, we don’t have the same luxury during the five cargo auto. The middle shot (with one cargo) requires that the feed be timed such that the robot continues moving. We may take a similar approach with the other shots as well, depending on the speed of the feeders.

As we haven’t yet mounted a camera to this practice bot, we aren’t using vision to aid with odometry tracking. The trajectory constraints are therefore tuned to reduce wheel slip as much as possible — in the future, we hope to adjust these constraints to shorten some of the paths. This may allow us to spend more time shooting or intaking from the terminal during the five ball auto.

Full Simulation

The robot was using simulated flywheels while running the routines, but we can also run the autos entirely in a simulator for testing. The video below shows the five ball auto running without a real robot at all.

As with the flywheel, this is as simple as replacing the hardware implementation of the drive with a physics simulation. We use the WPILib DifferentialDrivetrainSim class. Running the routine in a simulator allows us to iterate very quickly, and it means we’re more confident that everything will work when we test it on the real robot.

Code Links

• Motion profiling command (here)
• Five cargo auto (here)
• Four cargo auto (here)
• Three cargo auto (here)
• Two cargo auto (here)
• One cargo auto (here)

We’ll continue to work on refining these routines in the near future, like making sure that they stay clear of the lower exits to the hub. In the meantime, we’re happy to answer any questions.