We thought we would share this cool video of TechFire 225 and Peddie 5895 pulling off a duel hopper autonomous at MAR Champs in Qualification match 104.
Thanks to Peddie 5895 for the idea, it sure was a lot of fun seeing this happen from behind the glass.
See you in St. Louis! 
I’m really glad this one worked out; it was great working with you guys!
Coolest moment of the whole weekend. I was in queue on the far side of the field when this happened and was freaking out.
From a programming point of view, what method do you guys use to get your robots to accelerate and turn so smoothly, and stop at the positions right in front of the hoppers?
Our normal hopper auto consists of two trapezoidal motion profile segments, the first part goes straight for a few feet and ends with a final velocity of ~8ft/s (we run auto in low gear)
The second part decelerates from 8ft/s back to 0, and also has an angular component that turns the robot from 0 degrees to 90 degrees with a maximum angular velocity of ~95 degrees/second. This is what creates the arc at the end, and is just hand-tuned to end at the hopper location.
The part where we pivot back from the hopper is just an unprofiled PID controller on our heading that runs one side of the drive - from here vision takes over and we start shooting when we’re aligned.
The auto you see in the video is a modified version of our regular one, we had to start closer to the boiler to make room for Peddie - here we just have a linear profile that accelerates to 8ft/s over a distance, then we jump right into a unprofiled pivot and drives into the wall with a constant velocity. I’m proud of our one-student programming team for getting this together on Friday night just for this match 
We also use trapezoidal motion profiles. Ours are pretty much a copy of 254’s 2014 autonomous code, but modified to work better with our code base (and in a way that makes more sense to me).
We give the code some waypoints to hit along the way and it generates a path to get there, with position/velocity/acceleration/angle for each side of the drivetrain at every point along the path. It was very easy to generate a new path for this match, we just had to adjust the waypoints.
Here is 254’s repo for the path generation/following. We’ll also release our code sometime after champs (we’re javadoc’ing it, even the 254 parts, so it should be easier to follow).
Also, 254 gave a wonderful presentation at champs a few years ago about how this all works. Here’s a link to the recording.
The second part decelerates from 8ft/s back to 0, and also has an
angular component that turns the robot from 0 degrees to 90 degrees with a
maximum angular velocity of ~95 degrees/second. This is what creates the arc
at the end, and is just hand-tuned to end at the hopper location.
Do you still calculate individual paths (position, velocity, and acceleration) for the left and right wheels? If so, how do you calculate them? If this isn’t the method you use, how do you make sure the robot turns at the right radius, stops at the right angle, and at the right speed?
By hand-tuned, do you mean trial and error? Or did you use a different method?
We’re basically doing the same thing that 1678 describes here: https://www.chiefdelphi.com/forums/showpost.php?p=1675137&postcount=2
We aren’t calculating waypoint-to-waypoint paths like Pathfinder or TrajLib will give you, just trying to hit a distance (encoder average) and angle (gyro) goal at the same time. Both of these components are just simple trapezoidal profiles (going to a target given max velocity and acceleration).
Thought I’d add to the list!
1619 and 3309 attempted a two hopper auto this last weekend in Houston. Unfortunately, 3309 couldn’t find the target as there was an issue they didn’t know about. (I don’t blame them, this was only the second time this has been attempted.) It was Qual 66 in the Hopper Division; I’ll post video once it’s released.
Thanks to 3309 for coordinating with us to make it happen! It may not have completely worked, but it was still really cool to watch!