Team 254 Presents: Dropshot Technical Binder 2016

[Cory]

Originally Posted by mman1506

I guess it's only okay to use machine tools to spin up a shooter wheel when 254 does it

/S

I can't remember what their setup was that my comment was in reference to, but we did this in a fully enclosed machine with no chance of any debris flying out of it in the event of the wheel disintegrating at speed.

[AdamHeard]

Originally Posted by mman1506

I guess it's only okay to use machine tools to spin up a shooter wheel when 254 does it

/S

Weren't you shooting balls with the lathe? requiring hands, etc... to be involved?

[mman1506]

Originally Posted by AdamHeard

Weren't you shooting balls with the lathe? requiring hands, etc... to be involved?

I'm just kidding, none of the people who were involved on 865 in 2006 are still on the team today nor is it something we would repeat.

We use the thread as an example of how not to post on CD.

[Jared Russell]

Whoa, this thread died before I saw these questions

Originally Posted by NotInControl

So just a few questions from your friends on 2168.

1. Can you share a little bit more about how you arrive at shooter geometry (compression, contact time, exit speed etc.) required to make the shot. Every year these factors seem to be areas teams must learn from trial and error, wondering if the poofs have a more polished process.

Nothing too polished here, just prototype-driven iteration. We knew that our overall design concept would not result in a whole lot of contact time/wrap, so we made sure our prototypes convinced us that we could still shoot consistently despite that. We went through dozens of variants of our prototype to play with various factors.

Embarrassingly, the robot that we competed with at CVR shot nothing like our prototypes. We transferred over all of the geometry, contact materials, and speeds correctly, but our initial competition shooter could deform during the shot and did not cradle the ball as consistently (after driving over defenses) as we had hoped. We found out about these issues before the event, but did not have time to address them until SVR.

Originally Posted by NotInControl

2. Can you share more about what drove the Team to a turret all together, as far as I know this is the first turret 254 has used in competition. I am curious what drove the design, where did 254 pull the inspiration from if anywhere, did any team mentors/students have prior experience with turrets in FRC applications in the past? I find it typical for teams to avoid certain solutions because they have never fielded them in an event and would rather choose a solution they have more experience with. That definitely is always a good approach in my opinion, just wondering how 254 gets over that idea to follow a solution they never fielded.

Even though 254 has never rocked a turret before, a number of mentors have used them while on past teams (ex. 973, 341, 190). We chose this design because we were more confident that we could quickly and accurately aim with a turret than by servoing a pneumatic drivetrain. The traditional wisdom is that if FIRST gives you a protected area to shoot from, you should build the simplest robot possible and shoot from there. But we figured that most good teams would do this, and moreover thought that shooting from the outer works would lead to congestion and more difficulty aligning. So we set out to differentiate ourselves from the pack. As it turned out, while we ended up being one of the quickest shooting robots on the field, other teams were able to optimize their outer works shooters to be nearly as good (at a cost of a fraction of the complexity).

Originally Posted by NotInControl

3. Can you share a little more about how you determine whether to go chain #25, #35, or belt. This has been an age old question, and I am not really asking which you think is better, but how do you go about choosing which one for the application. The reason I ask is some teams use belt, and use it for everything, some teams use chain and use it for everything, and other teams kind of are in the middle, they use one, have failure, and use the other, and keep bouncing around. I am wondering if 254 has a more scientific approach to the choice because it seems like 254 chooses different solutions more purposefully.

4. Going back to the chain question. I recognize that in certain years 254 has went from belt to chain or #25 chain to #35 chain etc. When this occurs do you have to redesign your drive rails or are their certain considerations into the design that makes changing from one to the other easy without much modification? (i.e certain spacing common to all)

254 has never used belt in the drive, and had only used #25 chain in the drive (in the bumper era) until 2016. Chain is nice because it is easy to replace, easy to tension, cheap and modular, etc. We started our build with #25 chain in our drive, but knew that this year the tensile load would eat into our safety factor (small sprockets, big wheels). After busting a few chains on our practice field, we swapped out for #35 chain. The chassis was designed to support this contingency from the start.

On non-drivetrain mechanisms the team has used belt exclusively since I joined the team (on things like intakes, flywheels, and elevators). None of these have been super high load applications.

Originally Posted by NotInControl

5. Your Vision on the Nexus was stated to come out of necessity due to the unreliability of the Tegra, I am curious if the android solution seems like something 254 would use in the future or if there are equal pros and cons to possibly look for another? We did use a tegra, and after soldering come caps off to make it boot reliably we did not have an issue with the board. But again thats besides the point, looking for 254's opinion on the next best solution. Could you share some pain points, or cons/hurdles which needed to be overcome before the android solution was put into practice. I am sure many teams are testing an android solution in the off-season (we may be one).

We would definitely consider going the Android route again (if a simpler solution doesn't make more sense...Pixycam is pretty sweet). A lot of the biggest hurdles were integration questions that we largely were able to answer. Adb port forwarding for communications (which allows charging over the USB cable), the fact that you get a screen and input device build-in, the availability of great APIs (seriously, Camera2 is awesome) and IDEs for development, relatively powerful hardware and a nice camera, and low cost...it all just makes sense.

Pain points were (a) figuring out the comms and power interface (including ways to make sure that you can unplug/replug the cable and reboot either side and have the link come back immediately); (b) physically mounting the thing such that the camera was facing the right way (phones are not designed for ease of mounting on a robot); (c) finding the most performant way to capture an image and process it (there are a bunch of ways available - we tried em all). Also, we noticed that we got lots of tearing in our images at times due to the camera being mounted so close to our flywheel (likely because of optical image stabilization capabilities...the camera is basically mounted on a tiny spring). Our vision code was able to deal with this, but it was a nuisance.

Originally Posted by NotInControl

6. Can you share more on the servo solution? How did you ensure the servo was meshed properly and never skipped? We tried to use a servo this year for our articulating hood, but slippage was a big issue so we pulled it for a multi position pneumatic solution right before our first competition. Typically on this team if it failed once we never try it again. I am curious how 254 was able to have a successful servo implementation. Would you mind sharing which servo was used, and how it was interfaced to the hood and did you have any issues with slippage?

We used continuous rotation servos that drove a pinion along a curved gear rack on our hood. We used a separate encoder for feedback, so slippage wasn't a big deal. Someone else should be able to lookup the servo part we used (we also used a digital programmer to make sure that the servo stopped when the robot got disabled...it didn't out of the box!).

While this worked, it was a big pain in the butt. I wish there was a tiny, lightweight, low-speed motor in the kit last year appropriate for such an application and we could have used a Talon and been done with it. We burned out a lot of servos during testing while we tried to find the best ones, and still shredded gearboxes from time to time (typically when we would accidentally lower our hood onto a still-spinning flywheel, such as if we accidentally drove into the low bar).

Originally Posted by NotInControl

7. How was the hood angle determined from vision? Was it based on distance to target, center of target to center of camera frame, or some other method?

We calculate the pose of the goal relative to the robot origin (where we started the match) for each camera frame. We then track the pose over time (keeping track of robot motion using encoders and gyro while tracking) so that the goal remains roughly in the same place during tracking. We can determine range by taking the distance from our shooter to the goal pose (both relative to robot origin). Of course our estimate of robot position (and therefore goal position) drifts significantly over a match (especially after going over a few defenses), but it doesn't matter since this error cancels out during aiming.

Once we know the range, we use a lookup table to determine hood angle.

Originally Posted by NotInControl

8. How many drivers were used this year for the machine? I have heard that some years 254 has 2 drivers, some years 254 has 1 driver with a bunch of automated stuff. Could you share what was automated, requiring little/no commands vs what was always manual for this years bot?

2 drivers this year and every year since I've been here. This year the base driver controlled all things drive (shifting, traction control mode) and had the "fire" button (since the driver knows what he wants to do, this way we don't have issues pressing "fire" just as the robot changes direction). The operator was responsible for our utility arm (hanger and defenses manipulator), intake, and state of the turret assembly (low bar configuration vs. intaking vs. auto-aim). For shooting, the operator basically just holds down the auto-aim button until the driver shoots.

That's a lot of responsibility on the operator, so aside from auto-aim, we had a massive state machine for the robot to help automate transitioning from intaking to low bar, to shooting, to hanging, etc. The operator presses buttons that command a "wanted" robot state, and then the state machine transitions through the correct sequence of operations (ex. stop the flywheel, center the turret, bring back the hood, stow the hood, etc.) with the correct timing and/or sensor events to ensure that no matter how the operator console gets mashed, the robot always gets into the goal configuration as quickly and safely as possible.

[MrRiedemanJACC]

Originally Posted by Travis Covington

We have no plans to release the CAD of the robot but are happy to answer any questions you have.

I was curious on your climbing gearbox, what gear ratios did you use? Could you explain a bit more about it? Thanks and great document!!!

[weller2811]

im trying to find the same wheels they used but i cant find any that are not extremely expensive on mcmastercarr.

[Cothron Theiss]

Originally Posted by weller2811

im trying to find the same wheels they used but i cant find any that are not extremely expensive on mcmastercarr.

Yup. That's the drawback. They're $30-40 each.

[mman1506]

Originally Posted by weller2811

im trying to find the same wheels they used but i cant find any that are not extremely expensive on mcmastercarr.

http://www.andymark.com/product-p/am-2647_Blue.htm

http://www.andymark.com/product-p/am-3480_50.htm

Are good alternatives if your looking for something cheaper, same material and something with a little more flex would likely do better with this years game piece.

[Cory]

Originally Posted by Cothron Theiss

Yup. That's the drawback. They're $30-40 each.

They are sort of expensive individually but if you think about it, you need 1, maybe 2 per robot, they literally do not wear. They will last until well after you stop using the robot, they are very consistent, and it's the most critical system on your robot for scoring points outside of drive.

When you account for all those factors, $80 is downright cheap IMO.

[Cothron Theiss]

Originally Posted by Cory

They are sort of expensive individually but if you think about it, you need 1, maybe 2 per robot, they literally do not wear. They will last until well after you stop using the robot, they are very consistent, and it's the most critical system on your robot for scoring points outside of drive.

When you account for all those factors, $80 is downright cheap IMO.

Oh I'm think they're an excellent investment, that's for sure. My team kinda balked at the price tag, so I doubt they'll get any, but we'll see. Course, that's still cheaper than waiting until the last minute to buy all of the parts we want and paying for next day shipping.

[JohnFogarty]

What exact pulley did you use for your belt driven flywheel shooter on the 775 pro motor?

[Mk.32]

Originally Posted by weller2811

im trying to find the same wheels they used but i cant find any that are not extremely expensive on mcmastercarr.

We just got some in for testing...

They may be a little more expensive then the AM ones, but they IMO totally worth it. And do a great job of putting fuel into boilers.

[Chris is me]

Originally Posted by Cory

They are sort of expensive individually but if you think about it, you need 1, maybe 2 per robot, they literally do not wear. They will last until well after you stop using the robot, they are very consistent, and it's the most critical system on your robot for scoring points outside of drive.

When you account for all those factors, $80 is downright cheap IMO.

What isn't cheap is buying them before you know they will work for whatever particular game piece or function you're testing them on. If you're confident they are a great fit for the game piece, they're a steal compared to something like a BaneBots wheel which you have to replace every few matches. But prototyping is expensive!

That said, there's another kind of expensive and unique McMaster wheel for this game which I think might be a better fit...

[s-neff]

Did you make or buy the mecanums on the intake? They look super tiny. Apologies if this was answered earlier in the thread, I can't find anything going page-by-page

Sparkfun has discontinued the ones I have lying around at home
https://www.sparkfun.com/products/retired/11578

[Travis Covington]

Originally Posted by s-neff

Did you make or buy the mecanums on the intake? They look super tiny. Apologies if this was answered earlier in the thread, I can't find anything going page-by-page

Sparkfun has discontinued the ones I have lying around at home
https://www.sparkfun.com/products/retired/11578

We used the sparkfun mecanums but took them apart and re-anodized the plates black. I believe you can get the same wheels elsewhere. I do not recall where else I saw them though unfortunately.