Common or uncommon sensors used in FRC

[mathking]

Ultrasonic range sensors (almost every year, to find the distance from the wall) and garage door sensors (two of the last three years, to know whether we had loaded a game piece) have been useful for us.

[brennonbrimhall]

Originally Posted by mathking

...garage door sensors (two of the last three years, to know whether we had loaded a game piece) have been useful for us.

I don't think I've ever heard of a garage door sensor. Would you mind explaining what it is?

[Brandon_L]

Originally Posted by brennonbrimhall

I don't think I've ever heard of a garage door sensor. Would you mind explaining what it is?

IR (Infrared) beam sensors. The kit sensors can be used in a proximity mode or as a IR emitter/phototransistor combo (Basically "Break the laser beam" mode). There is a selector switch you can rotate to choose which mode.

With the right mode, and some programming magic, you can do some pretty cool stuff. We used them in 2012 in proximity mode for our ball indexing.

Other common FRC Sensors include:

• Encoders/Hall Effect Sensors to measure RPM (some higher rez encoders can be used for measuring angles)
• Variable Resistors/Potentiometers (POTs) for a more precise method of measuring angles, or in some cases linear POTs for distances.
• Digital switches (on/off, such as a limit switch)
• Gyroscopes, which measure angular acceleration (or general acceleration in some cases)
• Ultrasonic, which send out a sound wave and times its response. From that measurement + the known speed of the sound wave, distance to the object it hits can be calculated
• My favorite, the webcam provided in the KOP for fun stuff such as vision tracking or simply a robot POV for the drivers.

[ekapalka]

My team is also trying to branch out with our use of sensors. After tons of begging and fundraising, I convinced my team to buy one of these (the analogue version). It's perfect. Our team's autonomous and even teleop relied significantly on this, and it hasn't ever failed us. Also, I've heard from other teams that these are very decent encoders (and are easy to mount), and they work with the encoder classes provided by FIRST with the programming software.

[mathking]

Garage door sensors are the IR beams used to detect if something (like a child) is in the way of your garage door as it descends. The sensor is actually a pair of devices: an IR emitter and an IR receiver. The receiver sends a different signal when it can and cannot see the emitter beam. We have used them for a variety of purposes. Taking Rebound Rumble as an example, we had a garage door sensor mounted low in the robot. When we started picking up a ball it would block the beam and the sensor would signal that something (a ball) was blocking its beam. When the ball cleared the beam and the receiver could again see the emitter the robot knew to turn off the conveyor. A similar set up at the top was used to "count" balls going to the shooter. Together these two garage door sensors let us move balls efficiently inside the robot and count the balls we picked up and shot.

[Gregor]

Originally Posted by mathking

Taking Rebound Rumble as an example, we had a garage door sensor mounted low in the robot. When we started picking up a ball it would block the beam and the sensor would signal that something (a ball) was blocking its beam. When the ball cleared the beam and the receiver could again see the emitter the robot knew to turn off the conveyor.

How did you know to start rotating the conveyor again after the first ball passed through?

[mathking]

Originally Posted by Gregor

How did you know to start rotating the conveyor again after the first ball passed through?

The front roller that gathered in balls was not connected to the conveyor system which lifted the balls. When we wanted to gather balls we ran the front roller, and it would pull balls into the lift conveyor. When the lift conveyor detected a ball it would run until it could no longer detect the ball, then stop. (This is pretty much the reverse of how a garage door sensor is used in a garage.) This lifted the ball up into the robot, but not too far. This was important because the lift conveyor also fed the shooter. The sensor at the top was used when we activated the shooter. When the optical sensor determined the shooter wheel was at the proper speed the conveyor would run until the top sensor detected one ball, and would keep running until it could no longer detect the ball (meaning it had been pulled through the shooter). Then the conveyor would wait for the command to shoot again. We had a "shoot until empty mode" that counted balls in and out, but we found that our shooter was never accurate enough that the 2 seconds this could have was better than verifying the first shot manually. I might have a picture if you would like.

[brennonbrimhall]

Originally Posted by mathking

Garage door sensors are the IR beams used to detect if something (like a child) is in the way of your garage door as it descends. The sensor is actually a pair of devices: an IR emitter and an IR receiver. The receiver sends a different signal when it can and cannot see the emitter beam.

Really cool! Thanks for the clarification. Do you guys make your own, scavenge them from old garage doors, or purchase them?

[aryker]

From what I heard, this can be accomplished easier by plugging the limit switch directly into a Jaguar, and using jumpers to determine which directions the motor can rotate when the switch is activated. You will have to consult the Jaguar information sheet for this, though, as I have never attempted this.

I implemented one of those in 2011 for a soft stop on our robot's elevator--it wasn't too bad, although if I remember correctly I had to solder a few transistors onto a proto board and stick it between the switch and the Jag jumper to step down the voltage.

Also, our team tried out a Hall Effect(magnetic) sensor this year to work was a soft stop for the cam that pushed our Frisbees into our shooter, and it worked perfectly--all the convenience and functionality of a limit switch, but with no physical contact involved, so it never wore out!

[aryker]

Originally Posted by aryker

I implemented one of those in 2011 for a soft stop on our robot's elevator--it wasn't too bad, although if I remember correctly I had to solder a few transistors onto a proto board and stick it between the switch and the Jag jumper to step down the voltage.

Also, our team tried out a Hall Effect(magnetic) sensor this year to work was a soft stop for the cam that pushed our Frisbees into our shooter, and it worked perfectly--all the convenience and functionality of a limit switch, but with no physical contact involved, so it never wore out!

Oops, forgot to include the link to the Hall Effect sensor we used:
https://www.sparkfun.com/products/9312

[Ginto8]

We used a hall-effect sensor (put together by the team) to measure wheel speed -- two opposite-facing neodymium magnets in a bracket on the axle let us use the Counter class's getPeriod() (implemented in the cRIO's FPGA) to determine how fast it was spinning.

We also used IR bounce-back sensors (also team-constructed) for no-contact limit switching, similar to how aryker used a hall-effect sensor.

After our district competitions, we also added a string-potentiometer, which in our case we used to keep our tilter from going too high and pulling out our lead screws -- yes, there were mechanical alternatives, but we didn't want to risk dismantling the system on the first day of MAR champs. Also, our drivers ended up using it as an alignment system when our camera died (that is, never worked on the field).

[jasp]

Our team generally uses

• ir
• encoders
• limit switchs
• camera/ircamera

generally we use IR instead of ultrasonic because IR works better for the ranges we need, and generally the ultrasonics we have are too short a range.Also limit switchs are nice, the problem with them is that they break easly.

last year one of the mechanical teams made us put on a Hall Effect Sensor to know the rpm for shooter wheel. We never used it because it was to much work with little benift. Not sure if they realized it wasn't pluged in.

[mathking]

Originally Posted by brennonbrimhall

Really cool! Thanks for the clarification. Do you guys make your own, scavenge them from old garage doors, or purchase them?

We have both scavenged and purchased them. The first one we ever used from from a parent's garage. It is nice having a sensor you can run out and buy at a local store the Saturday before bagging if you need an extra. One nice thing about garage door sensors is that they tend to come with a lot of attached wire, so it is usually pretty easy to position them inside a robot.

Originally Posted by Racer26

Sensors are great: when they're needed.

Many FRC applications need no sensors at all, or very limited sensors with a very specific purpose.

Sensors used poorly will make a decent robot perform WORSE, not better.

One of the most important things to consider when using sensors in an FRC application is what will happen when your sensor fails.

This is a very important point. One which we try to (and don't always succeed in) take into account with each sensor. You want to make sure that you (A) have a manual override option where appropriate and (B) make sure the the default reaction of the controller when a sensor fails does not disable an important function of your robot.

A quick example of an instructive failure. Last year at Queen City, our ability to shoot autonomously mysteriously failed. The cause was a piece of retro-reflective tape placed wrong side up. As a result the optical sensor could not determine the shooting wheel speed. So the robot just waited the whole autonomous period for the shooter wheel to get up to the correct speed to shoot. The fix was easy. We coded a timer so that after waiting for 1 second without a change in speed from the sensor the robot would just shoot. (For the record, that fix was incorporated in the code at one point before competition, but in making a couple of changes at competition it was accidentally deleted. Because we didn't have wifi access to the code repo no one noticed at first.)

[Brandon_L]

Originally Posted by mathking

A quick example of an instructive failure. Last year at Queen City, our ability to shoot autonomously mysteriously failed. The cause was a piece of retro-reflective tape placed wrong side up. As a result the optical sensor could not determine the shooting wheel speed. So the robot just waited the whole autonomous period for the shooter wheel to get up to the correct speed to shoot. The fix was easy. We coded a timer so that after waiting for 1 second without a change in speed from the sensor the robot would just shoot. (For the record, that fix was incorporated in the code at one point before competition, but in making a couple of changes at competition it was accidentally deleted. Because we didn't have wifi access to the code repo no one noticed at first.)

Would also be a good idea to give some kind of error readout after the 1 second as well, so you don't continue on your merry way thinking everything's working fine.

[mathking]

Originally Posted by Brandon_L

Would also be a good idea to give some kind of error readout after the 1 second as well, so you don't continue on your merry way thinking everything's working fine.

We had the wheel indicator in smartdashboard, so in teleop it was pretty easy to tell if the sensor was working.