Questions about Off-Season Robot Design

FIRST General Forum
1

This past season, our team (Team 340) has received much praise for the active, floor load gear mechanism that our robot carries. However, as many of you may know, our robot did not boast a shooter. At the beginning of our season this year, we decided that we were not going to design and build a shooter and instead be the best gear runner we can be.

During this off-season, some of my fellow teammates and I are planning on converting an old drive base into a shooting focused robot.

Because of the size of the drive base that we are remodeling, space is going to be a concern. Obviously, the shooter/hopper is going to take up a majority of the space inside the robot. So our thought is that we are going to build a human load, active gear mechanism on the back of our robot. I just have a few concerns pertaining to this shooter and gear mechanism.

Shooter:
What is the most effective agitation system in your opinion?

What is the most effective harvesting style in your opinion?

How difficult is high goal vision to code?

Is there any value in being able to back-drive the mechanism to release balls onto the floor or into the low goal?

Gear Mech:
A question for people who have built a gear mechanism with a “pincher” (i.e 254, 1619): What are things that I should watch out for when designing this mechanism? Were there any issues with the driver when they were learning to harvest with it?

I ask the same question to the teams/people who have designed human load gear mechanisms. With this additional question. How long did it take for the driver of your team in order to become proficient in lining up to the feeder slot?

Thank you for your time.

2

291 is planning on building an offseason shooting robot also! We also plan on building a “gear claw” or pincher as you called it. I took a ton of detailed pictures of many of the robots in Saint Louis and asked a whole bunch of questions about shooter designs, agitators, intakes, and indexers. I’d be happy to share, though I am no expert on these things as 291 also focused solely on gears, but I did learn some valuable things.

I would consider myself, however, an expert on human loading active gear mechanisms. Here is our robot. I am the driver, it took me no time at all to learn to line up with the chute, but I will say we regret not picking up off the floor. If you drop a gear, that gear is wasted, and in the way. We didn’t drop many gears at all, but when we did it hurt, because now we had to go all the way back to get a new one. And those dropped gears were now available for our opponents (you in the case of buckeye semis) to steal.

This is why 291 will be designing a gear claw for the offseason.

All of that being said, 291 would be happy to help you develop an active human load gear mech! Don’t hesitate to ask questions.

3

Fun! We might be doing the opposite with our practice bot :slight_smile:

Shooter:
What is the most effective agitation system in your opinion?

We had a lot of success with our rotating floor hopper (we called it an impeller). It was very simple, and never jammed (once the outlet geometry sufficiently tuned), was safe to spin while not shooting, and was good for 5+ bps. Most teams had success with an rotating shaft with tread flaps that pushed on the ID of a ring of balls.

What is the most effective harvesting style in your opinion?

Don’t worry about this too much. everything works. The balls are light, and easily gripped. So many balls are needed that it probably takes a trip to a hopper or two anyway to make a cycle worth it.

How difficult is high goal vision to code?

It’s a challenge, but not impossible. GRIP takes some learning, but makes the processing easy. The harder challenge is getting your ball stream consistent and your aim accurate. Our turret tried to keep center within only 7 pixels.

Is there any value in being able to back-drive the mechanism to release balls onto the floor or into the low goal?

I wouldn’t think so, except perhaps to clear a jam in your intake (if you sucked in a squashed ball or something).

Gear Mech:
A question for people who have built a gear mechanism with a “pincher” (i.e 254, 1619): What are things that I should watch out for when designing this mechanism? Were there any issues with the driver when they were learning to harvest with it?

Here are my notes, although some if this applies to your existing mechanism, so you’ve probably addressed some of them already:

  • Keep your pickup wheels above the grippers so the gear can be sucked in even if it’s not perfectly aligned.
  • Put a good sensor (we used an IR retroreflective, but a mechanical switch works too) to let the drivers know they’ve got the gear.
  • This style pickup puts nothing in front of the gear to guide it on the peg. That requires more finesse (and more time) when placing the gear. I saw some teams hold their gear at 45 degrees forward, which might help guide the peg into the gear.
  • Be careful with gears against walls, in the field corners, or against the airship. The entire momentum of the robot can be transferred through the gear into your pickup mechanism, so it must be built strong
  • Make sure you have a way to clear or block balls from getting below the pickup, preventing you from dropping it. Test with a mixed pile of balls and gears
  • Visibility is terrible with a great big hopper between the pickup and the drivers. Consider a camera, or train your HP to help signal the drivers
  • Use as big a cylinder as you can justify to close the grippers, and good soft tread material to grip. You don’t want a collision in the neutral zone to force you to drop your gear.
4

On 6413, we used a pneumatic “claw” to pick up gears. (see http://i.imgur.com/TNe2Y3I.jpg) In the back of the claw we had a trigger that when a gear hit the back of the claw, the jaws would automatically close around the gear. It was fairly responsive, and would work about 90% of the time flawless. The driver could manually open and close it, of course, as well as an override to keep the jaws open incase of the switch failed and started closing the jaws automatically. Feedback was given to the driver through the vibration of the xbox controller, when the arms closed both driver controllers would rumble. We ran into a couple major problems with our approach that made things hard. First, it was really hard to pick up a gear across the field. We added some cameras after our first event that helped, but we were still kind of slow at it. More driver time would’ve fixed this probably. We also had major issues with the hinges on the arm sections. We went though a different iteration at each event. The hinges were cheap steel door hinges, they didn’t hold up at all… in Houston we sheared the pins off both sides. Once we replaced them with hardened steel bolts, it wasn’t an issue, but the steel on the hinges bent and would cause alignment issues. Which led to the last big issue we had, keeping a gear held. If we hit the spring with the gear, it’d often times knock the gear out of our jaws. The best solution we found for this was to use some foam window/garage door sealing tape. We’d put double sided sticky tape down on the metal of the arm, then put the non-sticky side of the foam against the double sided sticky tape, leaving the sticky side of the foam facing out. It was sticky enough that it’d help hold the gear in place, but when the pneumatics opened it pulled away easily. It was just a constant maintenance thing to replace the foam as it lost it’s stickiness from dirt and fuzz that it picked up off the field.

If I had to go back and do it again, I’d ditch the jaws… they were nice and worked great when everything was in line, but it was our biggest maintenance headache, and they did let us down in a few matches. A more automated and robust roller system that pinches the gear may have been better, but I heard from several teams that it was very speed dependent on how well those picked up.

5

I’ll share some of the experience that 27 had this year.

Make absolutely sure that your hopper extends to the outside edges of your bumpers. When you’re shooting for a high-scoring auton, you need to get every fuel you can possibly get, and adding any space between your robot and the edge of the hopper hampers this.

The belt system that 118 used this year is the best if you can get it to work (we couldn’t quick enough).
Second to that is probably the paintball hopper.

Full width over the bumper is the only way to go. Anything else is a compromise.

Fortunately this year we had two rectangular strips of retro-reflective tape, so its not as hard as it could’ve been.

We used a PixyCam with an IR-LOCK filter kit and once we switched to the IR-LOCK custom firmware everything was pretty easy to get going on that side.
Connecting the PixyCam to the robot was more difficult, we starting looking at connecting it directly to the RoboRIO but we couldn’t get it working like we wanted as quickly as we wanted, so we switched to using a python wrapper for LibPixyUSB on the RaspberryPI and sending the information over using PyNetworkTables to the RoboRIO. (this worked well)

The only reason I’d add this in a perfectly designed system is that it makes getting the fuel out of your robot at the end of the match easier.
(We added this feature because there was a possibility of a gear getting into the hopper, and back driving out the fuel meant we could remove the gear from the hopper relatively easily with good driving)

RE: Human Load Gear Mechs

Look at the FRC 5687 - The Outlier’s gear intake, they inspired our’s for this year and it was awesome. Basically, its all about opening up the amount of space that the gear can fall into while your at the feeder station, and then securing it into a smaller space once you leave.

If you design a good system, its not hard at all, again look at the outlier’s reveal video from this year, they could havest from the feeder station at a 45 degree angle and have no problem.

One more thing on the shooter side of the house.
Early on we saw value in combining gear cycles and shooting cycles by shooting from the center peg.
We compromised our design (a certain fixed hood angle) so that this was viable.
In the end, we only got this working at championship, and it was significantly less accurate then our closer shots.

I think 1986 had a fantastic vision this year. Pick two places to shoot from and be the best at those two places.
One place has to be the hopper, the other can be where-ever you’d like. (I’d recommend the side gear peg or in the key against the boiler)

EDIT:

THIS! SO MUCH THIS! We had LEDs on our robot to display information to both the human player and driver.
RED meant we were ready to acquire a gear.
GREEN meant we had acquired the gear and were ready to go.

We used a banner sensor (p/n QS18VN6LV) for this.

6

Love the tape with “NO GEARS NO” sharpied on it.

7

We had a near miss with a partner’s Human Player at our second event. Decided it would be prudent to have a warning (since we get gears from the ground) :slight_smile:

8

I forgot to add that the hardest part of vision for us was not the side-to-side aiming, but measuring and adjusting for range distance. We found that a 50 rpm difference can make the ball stream completely overshoot the boiler. We used the elevation of the retroreflective tape on the camera sensor (actually the blob that GRIP identifies once the turret was centered on the boiler) to measure the range, and then developed a curve (quadratic) for flywheelRPM vs TargetImageY. This was pretty accurate by champs - we could shoot without adjustment from anywhere within ~2ft of the Key line (with a fixed hood angle). But we had to be careful about camera mounting etc since each pixel on the sensor was worth about 10 rpm!

I’m not sure if other teams had luck with other rangefinding techniques.

9

This is solved by shooting from very specific locations, having an adjustable hood, and keeping a single efficient RPM as the motor speed. (aka not what we did :stuck_out_tongue: )

The biggest problem with some of these is repeatability and understanding the data as it goes through the process.

We (27) wrote two calibration techniques that were very successful.

First calibration was to get avgTargetY -> distance.
We did this by putting in the avgTargetY and distance into excel and using a logarithmic best-fit function. (see this)](https://i.imgur.com/WAkBD10.png)

Second calibration was to get distance -> shooter RPM
We did this by going to the practice field and measuring off distances and plotting those in excel with a linear best-fit curve. (see this)](https://i.imgur.com/QrBHDPx.png)

By doing this, we could log the distance the camera thought we were at separately from the speed, which allowed us to do a sanity check on the output of the distance calculation.

10

About the same as last year. Toughest part for us was that the high goal is, well, high - which meant we had to angle our camera up. This complicated our screen->world transformation code. As others have mentioned this calculation is very dependent on getting the camera angle correct. The other pain was dealing with actual field conditions. If you’re just testing and can tweak by hand just to get it work it’ll be considerably easier (also, there’s little penalty for the occasional false positive which causes you to shoot at the refs, not that something like that ever happened to us).

Our code was an evolution of last year’s, so check out our whitepaper on it (Zebravision4.0GoalDetection.pdf - Google Drive). We’ll publish an updated one this year once I can motivate the students to do it. But the basics will look fairly similar to 2016 it wouldn’t be wasted time to read up on that.

Our shooter was able to shoot from any range within ~15 feet or so. For that, an adjustable hood was vital. Like others, we had a lookup table which correlated shooter speed and hood angle to vision-reported distance. If you only want to shoot at a few fixed distances this might be overkill, but still fun?

Other notes - work on everything to keep the shooter speed constant. PID tuning helped a lot. As did extra weight on the shooter wheel shaft. Finally, we had a preshooter which brought the balls up to ~80% of full speed so the shooter wheel needed to add less energy to each ball == more consistency.

We did a lot of iteration on agitators for the feeder. The conclusion is that pretty much anything rigid attached to the central spinner either jammed or broke (or both). No guarantees we didn’t miss something obvious but our best feeder used flexible straps bolted to a central wheel.

11

We did exactly this, although we used these limit switch things instead of banner sensors.