Team 254 Presents: 2017 Misfire Technical Binder and Build Blogs

I’m not on 254, but according to the tech. binder: “An Interpolating Tree Map determines the correct flywheel RPM for the current distance”

Considering that googling “interpolating tree map” gives 254’s FRC-2016-Public/InterpolatingTreeMap.java on GitHub as the first result, I’m willing to bet that this is mostly an original term.

Anyways, I’ll just explain a good way to do this, which is not quite how 254 did it. On my team, we set up closed-loop velocity control for the flywheel. Then, we positioned the robot in intervals of 10 inches away from the goal, and found the exact right flywheel speed to make the shot every time, from 20 inches away to 100 inches away (We had a fixed firing angle and could not shoot from 10 inches away). Once we found the perfect speed to make every shot, we recorded that distance and flywheel speed as a data point.

After gathering the 9 data points from those tests, we put them all into Excel. Then we graphed them, and fit a quadratic curve to them. Essentially, this gives an equation with an input of inches from the goal, and it outputs the perfect flywheel speed to shoot from that far away. This worked really well, and from any reasonable distance, the flywheel could autonomously find the right speed to shoot at, even if we didn’t have a nearby data point.

Again, I haven’t looked at 254’s code, but it’s on GitHub. However, generating an equation like this is an excellent way to solve this problem. The only real drawback that we found is having to take fresh data points whenever we changed something on our turret, which was a bit of a hassle.

To calculate the angle of the hood, we took into account where in the field we wanted to shoot from (front hopper during autonomous), where the hood would be vertically placed on the robot, and at approximately what angle we wanted the ball stream to enter the boiler. For SFR and SVR, our first iteration of the hood had a fairly shallow angle (around 20 degrees above the horizontal) which led to a non-optimal trajectory which gave us an accuracy of roughly 60-70% at these two regionals. For Champs, our priority was changing the hood to a) have less compression and b) reduce the angle to give us a better trajectory. To test out which angle we wanted, we went through a series of iterations consisting of placing blocks below the front of the robot to effectively decrease the exit angle of the balls and then translating that new effective angle into a CAD hood prototype which we laser cut and mounted in place of our current hood. We ran through around 5 iterations to get to our final hood angle of 14 degrees.

To create our distance to shooter RPM function, we first collected a set of distance to RPM data points by fixing our shooter RPM to various values and finding the optimal distance for each RPM. We then used a quadratic polynomial regression to find the best fit function for these data points.

The general idea behind finding distance to the boiler is to find the vertical angle to the boiler then use trig/similar triangles to calculate distance from this angle. First we calculate the vertical angle between our camera and the vision tape using this equation: atan(y_pixel_position / focal_length) where a (0,0) pixel position is at the center of the screen. Once we have the vertical angle to the target we use some basic trig to calculate the distance to the boiler ( range = cot(vertical_angle) * height_difference where height_difference is the height difference between the camera and the boiler). We gave an in depth explanation about it at the Integrating Computer Vision with Motion Control presentation at the 2016 FIRST Championship.

I believe an Interpolating Tree Map is basically linear interpolation between several calibrated values.

Linear interpolation: Imagine a set of plotted points, then draw lines to connect them instead of fitting a curve to the data.

Just sent you a PM.

.003 is nowhere near enough in our experience. Paul Copioli has a tool somewhere (I think in a presentation he made) that we used as a starting point and then did empirical testing of additional added distance.

We used +.018" on a 10.75" C-C run (very close, if not exactly what Paul recommended) and +.030" on a 20.75" C-C run.

I’ll second the empirical approach. We found that chains from different manufacturers will require different additional c-c for the same run. (Vex heavy duty #25 vs McMaster #25 for example).

Thirded. We found that even chain from the same vendor, but purchased at different times, will require different additional c-c for the same run.

Mind sharing your teams’ methods of empirically determining addendum distance? It’s a bit of a tangent and possibly deserving of its own thread, but I’d appreciate a quick run through.

Here you go!

I heard from a student at WCMP that current draw while shooting was a large concern. How bad was it, and what adjustments were made?

What, if any, fine-tuning needed to be made after importing from the Cheesy-path app? During refinement, was the default strategy to re-tune the path in the app, or re-calibrate sensors (etc) to get the actual path to match the desired path? What margin of precision was “good enough” for the gear + hopper auton?

Edit - Also, was it seen as a risk that a drive train CIM would be hit, given how close (or over?) the edge of the angled frame it is?

Ours is a modified method from 2363’s post above. We milled the bearing holes in a 2x1 tube, then cut the tube in the middle. Then we assembled the chain on, pulled the two pieces apart, tightened the vice, and measured.

https://i.imgur.com/VPSwTPP.png

Nothing fancy here. Machined test rails with bearing bores at .005" increments and picked the one that felt best.

Was 25 chain used? Did you have any chain skipping or had to swap it out in the middle of the season?

#25 chain, no issues.

Our shooter was pretty finicky and required a lot of current to work well. To deal with this problem, we minimized current draw from other subsystems while we were firing. Stuff like turning off the compressor, stopping the gear grabber motor, reducing intake voltage, etc…

We had some problems with the accuracy of our odometry this year, so we needed to do quite a bit of tuning after importing paths from Cheesy Path. To tweak the path, we directly edited the waypoint coordinates in robot code as it was a lot faster than importing everything back into Cheesy Path then exporting it again.

Due to the way our robot was built, the gear portion of our path needed to be pretty precise, because if we backed too far into the spring, it would bend against the back of our feeder. We had around a 5 inch window to hit. The hopper portion of our path didn’t need to be too precise. We just needed to ensure that our angle of approach wasn’t too shallow or deep.

Was the initial effort of empirically determining C-C distance for individual chain runs worth it compared to adding some sort of adjustable tensioning device?

It was 20 minutes of CAM/CNC time and saved us making 3 days worth of parts, so 100% worth it.

In your fuel intake design, I see two pistons on each side. I don’t exactly understand their use and placement. Can you explain?

The purpose of the two pneumatic cylinders is to deploy the fuel intake at the start of each match. Their placement is such that when the intake is stowed within the frame perimeter, they push it and it swings down over the bumper. In our initial design, these cylinders also expanded our hopper when the intake swung down. However, this proved to be somewhat inconsistent, and we have since changed the hopper deployment to be triggered by two independent cylinders that push the hopper walls outwards on each side.