I’m trying to figure out how do teams calculate the angle of the hood and the velocity for the perfect shoot, having the distance from the target and a perfect alignment.
Thanks!!
I’m trying to figure out how do teams calculate the angle of the hood and the velocity for the perfect shoot, having the distance from the target and a perfect alignment.
Thanks!!
We use a linearly interpolated look up table, that contains all of the distance values as a function of distance, and a linearly interpolated hood value as a function of distance. You can then through testing figure out the ideal values, then input them into the table. Once that information is compiled, a PIDF loop should be run for velocity on the flywheel motor, and a PIDF loop for the position of the hood value.
Trial and error.
We take shots from a series of distances, spaced out no more than a few feet apart from each other, and then adjust good angle and flywheel speed until we get the shot we like.
Then we plot those parameters vs camera target “y”, fit smooth curves through the points, and then use the curve equations in our code to drive the hood and flywheel.
Makes sense?
Fwiw, we’ve found linear interpolation to be well within the tolerance of our flywheel and hood for a reasonable amount of points, and it’s probably somewhat easier to implement.
What Brendan said. 1 foot increments, starting up close to all the way to the drive stations. You can take the points and interpolate between them or make a fancy polynomial best fit thing.
we used this to calculate the needed info.
More importantly easier to tune at competition. Regenerating a curve at competition is impossible given the limited amount of time, however, linear interpolation is fairly fast to retune especially if only a subset of the shots are inaccurate
Add another vote for linear interpolation based on actual shots from a range of distances where speed and angle are manually adjusted to produce successful shots.
Note that a range of speeds and angles can be found to make shots from a given distance. You can tune for “flat” shots or high-arcing shots. We attempted to find the set of speeds and angles that resulted in roughly the same maximum height the cargo reached in its trajectory from the complete set of distances. We liked the robustness and cargo bounce action inside the hub cone with trajectory apex heights of about 12 feet.
Also, be wary about using parabolic trajectory simulations to build your interpolation table or curve. The fuzzy cargo trajectory is strongly affected by spin rate, which can be hard to model accurately. If your cargo has any appreciable spin, empirically-determined data will be your friend.
To build on this, you can even have the operator/second drive watch the shots and adjust them on the fly, and then use that new interpolation map in the next match. There are lots of options!
On the topic of interpolation, the Apache commons math library offers an excellent spline interpolator class that can be used for a hood, or variable speed flywheel etc. You just have to add the dependency to your build.gradle
file.
Add the following to the dependencies
section of your build.gradle
file:
implementation 'org.apache.commons:commons-math3:3.+'
Mechanical guy here, I know we tune shoots at various distances, but no idea how it works in the software. What I do know as an ME, is that parabolic trajectories rely on negligible air resistance, and predictable exit speeds and angles. Trouble is, air resistance and spin often isn’t negligible, and shot speed and angle is hard to measure even if your shooter is very consistent.
The physics calculations can be good for figuring an approximate range of speeds and hood positions to design for and start your tuning from, but building a sufficiently accurate model to predict shot trajectory is insanely difficult and unnecessarily for FRC. Tune shots, use the empirical data.
I’m gonna add to what Patrick said here as a software guy. As many others say on this thread, we also use a linearly interpolated lookup table for both velocity and hood angle. These lookup tables are essentially a “key” and “value” pair. Generally, your “key” is your distance reading, and depending on the game and consistency of accuracy, the difference in distance between your “keys” can vary. To be more clear, you can interpolate between 3 feet versus 1 foot depending on the accuracy you notice.
I’ll add something to the linear interpolation idea. Make sure you use short increments. In 2020, my team used 10-foot increments to interpolate flywheel speed and hood angle. We failed horribly. We then went to 5-foot increments and it got a little better. Based on what I saw that year, I’d recommend you use increments no bigger than 1 or 2 feet.
My programming student had the idea this year of just using a simple array of shooting/hood values and then converting all distances to an upper and lower bound in feet. The U/L bounds are just indexes into the arrays and feeds the interpolation calculation. This simplified getting values because there’s no need to traverse the distance values and do comparisons for the U/L bounds, but it does mean that you have to be very strict on measuring distance when calibrating. Probably could have used the API, but it’s fun when they have their own solution, too.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.