Common or uncommon sensors used in FRC

[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.

[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.

[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.

[Clem1640]

We use BI Technologies Magnepot Hall Effect Potentiometer (Part # 6127V1A360L.5FS) as angle sensors for our pivots. A great 360° (stopless) angle sensor.

http://www.bitechnologies.com/pdfs/6120.pdf

[faust1706]

Our team loves limit switches. For our claw in logomotion (anyone here remember that game, or am I just getting old?), when we picked up a tube, it pressed a limit switch in our claw and when that switch was pressed, our claw would automatically raise to it's locked position. (not our arm, big difference).

This was something I am very fond of: For our minibot deployment, we had a piece of lexan blocking the circuit to our motors on our minibot. When our deployer was fully extended, the cord with lexan at the end would get pulled off because it couldn't reach that far, which would then start our motors automatically and the minibot would begin its ascent to the pressure plate.

We use the kinect as a sensor and not a camera. We don't send what the camera is seeing, but the distance it calculates and the x rotation (and in 2012 it gave pose). I like to call it a sensor because that's really what it is, and even more so in how we use it.

In rebound rumble:Like the garage door opener (which was mentioned earlier in this tread) we used a similar concept. For an rpm sensor in our turret, we drilled a hole in our shaft. We had a ir sensor and light. Every time the sensor saw the light, it added to the count by 1, then divided it by 2 (for every 1 revolution, the light will be seen twice)

We also used it in our hopper. We had a high sensor and a low one. Once a ball was detected in the lower sensor, it would raise the hopper until the top sensor detected a ball, then it would lower it back to the bottom sensor until it was detected. this assured that we had optimal space in our hopper. If that makes sense. It has ensured we only had 3 balls in the hopper.

We also made a custom circuit, so that when our arm what touching the bridge to pull it down, it completely a circuit that would shine bright green towards our drivers to let them know they can use the arm.

In Ultimate Ascent:

We used a limit switch on our hanging mechanism. We had octacanuum drive, so we would raise onto our traction wheels, which would put our chin-up bar as well called it right at the 10pt level on the pyramid. We'd drive onto it, and start hanging. When the bar on the pyramid was in position so we could hang, it has pushed 2 limit switches (one per side), which automatically raises our wheels and cuts all power to our motors.

Hope that makes sense. It's early and I just finished reading The Idiot by Dostoevsky in english class. Not all here.

[mwilbur]

A number of people have mentioned ultrasonic distance sensors, but our team has used IR distance sensors successfully in the past. The ones we've used are made by Sharp, and there are a variety of ranges to choose from. These are great for sensing game pieces anytime, or the walls of the field during autonomous. There are a number of vendors that sell the sensors, but I will refer you to the link that we generally use at Acroname Robotics:
http://www.acroname.com/robotics/inf...arp/sharp.html

One thing to watch out for with these guys is that they use a conductive plastic case. This can cause problems when the inspectors check to see if your cRIO is isolated from the robot chassis, so you will need to electrically insulate the Sharp IR sensor if you mount them on metal structural components.

[JamesCH95]

US Digital E4P Encoders (AM)
Magnetic Reed Switches (McMaster) which are more durable than limit switches IMO

That's about it, we're pretty basic on sensors.

[tr6scott]

Polarized retro reflective photoeyes.
Banner DS18VN6LP about $50 each, need polarized reflectors.
Banner BRT-35DM refectors. $7 each
Banner SMB18A mounting bracket.

In industry polarized are used, as they are less likely to be fooled by shiny objects. Really not a problem with rebound rumble balls or discs, but may be in the future.

I like these better than the AB ones that came in the kit of parts, Logomotion, as they seem to be more stable at lower battery voltages than the AB units. Logomotion year, they allowed them to be wired to 24vdc supply, I did not see that allowed rebound rumble, or ultimate assent.

534-1-1-503 Spectrol 50K 10 turn POT, this is just something we had on the shelf from job, used as angle sensor.

If using industry stuff, you need to look for the 10v dc range for lower end, and NPN switching for the digital side card. NPN is not typically used in the US industry, so you may need to order.

I work in industrial controls, so TORC is lucky to have these donated to the team.

[Everett33]

This year 2145 used one of these http://www.automationdirect.com/adc/...tor/AAP2T51Z11 to stop the robot when it got to the wall in autonomous. We also used two of the small KOP touch sensors to tell when our lift was all the way up or down for ease of driver control and consistent autonomous runs.

[kiettyyyy]

1538 typically uses the following on our robots:

Rotary Encoder(US Digital S4, usually on one drivetrain wheel)
Angular Rate Gyroscope(KTC Research package)
Digital or Analog IR sensor
Potentiometers (Typically mounted on output shafts of arm gearboxes, etc)

[itsjustmrb]

Wow...this is one of the reasons I love FIRST and Chief Delphi. Thanks for all the suggestions and links to available sensors. Feel free to keep adding to the list.

Mr. B.

[Joe Ross]

Here are the sensors we have used over the last few years:

Gyro: AndyMark AM-2067 (Analog Devices)
Encoders: Us Digital E4P
Potentiometer: Vishay 534B1103JCB10
Hall Effect: Allegro A1101EUA-T
IR: Sharp GP2Y0D805Z0F

[yash101]

To measure RPM of motors, I was thinking about using something like hall-effect sensors. I have not used this technology before and I would like to learn how to use these and how to program these, We currently program our robot in Java because most of the team members already know it. So, could we use hall-effect with sintered Neodymium Rare-Earth Magnets. Also, could we use dual axis hall-effect sensors to detect the orientation of the robot (using the magnetic field of the Earth)