What sensors do you use?

[StevenB]

This is another of my random curiosity polls. Which of the above sensors does your team use?

[CrazyCarl461]

How could your list not have potentiometer? They are probably one of the most used sensors in FIRST. This year we only have potentiometers and rotary encoders (also not on the list) on the robot, unless the CMU cam counts.

[Matt Krass]

We're using the CMUCam, gyros, optical quad encoders, potentiometers, reed switches, pressure transducer, kit motor as tachometer, photosensors limit switches, a 10 position switch, and a field position toggle switch.

The fun part? We actually do use all of them a few times over....the not fun part? One breaks half our robot stops working

[Tom Bottiglieri]

Originally Posted by Matt Krass

...the not fun part? One breaks half our robot stops working

Redundancy! Redundancy!

Anyway, we don't really have an overly complex robot, so there was no need for our sensor package to be any different.

Optical Encoders for the drive train. We initially wanted to use a closed loop, velocity based control, but the drivers didn't like it and it was scrapped. Now the only job of the encoders is a measuring tape for our autonomous mode.

Yaw rate gyro for heading. It keeps track of heading in the background, and allows us to keep a running measurement of where we are on the field. Makes turning a specific heading a breeze. Nothing too fancy.

Ultrasonic range finder for distance from the wall. This is probably the most important sensor on our bot, and it was thrown on at the last minute! It reads the distance from the wall which gets thrown into a position based PI loop, and drives the wheels accordingly.

Our controls are pretty basic. Total open loop for the drive train in user mode. I know it can be harsh on the motor, but you know what they say.. If it ain't broke don't fix it! For autonomous movements, the robot is forced to drive straight by a PI loop, driven by readings from the gyro. This algorithm basically spits out a value to add or subtract from each side's output. The robot steers accordingly. This algorithm is pretty nifty. It allows us to specify a relative angle and drive speed. Enter 0 as the drive speed, and the robot turns in place to the specified angle.

My favorite autonomous feature on our robot has to be the ball dump mode. Closed loop control has become my best friend. There has been occasions where opposing robots have pushed us into the wall, but the bot is smart enough to know to push back (We have to be about 6" away to drop balls into the corner goal.)

Excuse me for the unorganized flow of this post. I just get too excited thinking about sensors!

[chrisinmd]

We were using the AB photo sensor set to auto load our shooter. The shooter roller would slowly roll until a ball got to the top and broke the IR beam, and the rollers would stop, and the shooter would be loaded. It was really, really cool, but I said 'would' a lot because the sensors stopped working after Pittsburgh.
see here
Now we only have the gyro for our shooter driver's controls, it works really well too.

-Chris

[Rickertsen2]

CMU cam
Used for turret autotracking on both the pan and tilt axis

Encoders
256 count on pan axis of turret
1024 count on tilt axis of turret
both used for closed loop control in conjuction with CMU cam and limit switches

AB Photoswitch
Used to sense balls in our loading mechanism

TI Analog pressure transducer
senses when we have enough pneumatics pressure to reliably fire

Limit switches
used to find the home position of both turret axis upon robot startup

[JJG13]

Team 180's robot has:

1 Camera. This aligns our turret in both manual and autonomous mode.
1 Accelerometer. This is used to measure the turret elevation.
2 Limit switches. These stop the turret if it moves to far to the left or right.
2 Banner sensors. These are used to space and control the balls in our conveyor system.
1 Tachometer. This measures wheel speed and we use this feedback to determine what the PWM output there should be to our shooter motors.
1 Yaw rate sensor. This is used for autonomous driving and for holding position while other robots are trying to push when shooting.
Also there is the pressure switch for our pneumatic system.

We also have the ability to put two encoders for autonomous mode driving. Since we have the same chassis this year as last year, using the encoders is just a matter of copying and pasting from last year's code.

[mechanicalbrain]

Did anyone use a optical mouse? From what I understand, besides needing a lense setup to give it any range, it only has 12 ips with a 1 to 1 lense ratio as set by NASA (http://www.nasatech.com/Briefs/Oct05/NPO_40173.html). I guess this should be odometers in general.

[StevenB]

How could your list not have potentiometer? They are probably one of the most used sensors in FIRST. This year we only have potentiometers and rotary encoders (also not on the list) on the robot, unless the CMU cam counts.

Sorry. I should have listed pots and the CMUcam on the list. We are using both on our robot. It looks like there isn't a way to edit the poll though. I put optical mice on the list because quite a few people seemed to be working on it past years. I was (and still am) curious how many people, if any, got it to work.

We were using the AB photoswitch to detect balls coming into our harvester, but we never really tested it, and so we took it off to make weight. We are using the CMUcam for auto-targeting, in both regular and autonomous mode (and it actually works! ) We decided not to use encoders or a gyro this year, since precicse navigation didn't seem as important with the camera.

[thoughtful]

Originally Posted by mechanicalbrain

Did anyone use a optical mouse? From what I understand, besides needing a lense setup to give it any range, it only has 12 ips with a 1 to 1 lense ratio as set by NASA (http://www.nasatech.com/Briefs/Oct05/NPO_40173.html). I guess this should be odometers in general.

I was looking into it. It doesnt seem hard to setup, apart from the focusing e.t.c. I personally have no clue as how to convert the output into something that the RC can read. But we have a couple fo great programming mentors who should be able to do something about it. If we have a team next year we might try it.

[devicenull]

CMUcam was probably the most important sensor this year.. without it, our turret would have been useless. Limit switches were used to prevent the turret from turning too far, although because of its construction, they weren't really needed.

The gyro was on our robot, but not used for much. It worked, but once we started using 4WD IFI traction wheels, it wasn't needed at all.

Encoder kept the shooter running at the proper speed which resulted in very small delay's between balls.

[Billfred]

We had the CMUcam mounted on Chomp for most of Palmetto, but it never functioned correctly. (Who saw our spin-around-in-a-circle autonomous?)

I believe that we had gear tooth sensors mounted in the transmissions, but I don't think they were connected to the RC in competition.

[Alan Anderson]

Originally Posted by mechanicalbrain

Did anyone use a optical mouse? From what I understand, besides needing a lense setup to give it any range, it only has 12 ips with a 1 to 1 lense ratio as set by NASA (http://www.nasatech.com/Briefs/Oct05/NPO_40173.html). I guess this should be odometers in general.

We did a lot of experimenting last year with using an optical mouse for position tracking. Mark Koors came up with the right lens for making it into a "telephoto" system, Wildstang's programmers contributed code for communicating directly with a specific mouse chip, and we had travel and turn sensing working okay as long as the height of the mouse above the carpet did not vary. However, as little as a millimeter of height change gave a significant difference in detected travel. I finally decided that it wasn't going to be possible to get consistent data from the scheme if the mouse wasn't physically in contact with the carpet.

Our robot last year used a trio of miniature "follower" omniwheels with encoders to give us feedback on forward/backward travel, sideways travel, and turn angle.

[Donut]

We used just the camera, a gyro, and 2 limit switches this year. We had 2 encoders and a potentiometer hooked up but never bothered wiring them up since we ended up with no testing time as it was and didn't want to spend even longer on those. Ironically since our programming team was the largest group on our team this year and we had lots of time for code reviews, everything with sensors worked the first try (all we ever had to do was tweak numbers to get to "just the right spot" instead of "very close, sometimes works").

Have any teams had success in using an accelerometer to derive position and velocity (not angle to the ground)? When I looked into it I found that we could tolerate very little error and still be even remotely accurate.

[Bob Gross]

All,
The MaxSonar-EZ1 (www.maxbotix.com) sensor was used on a number of First Robots. The text below was written to me (Bob Gross of Maxbotix) by a programming team mentor. I have shortened the text below some...
********
"I am writing this mostly to just tell you how much I like the EZ1.

We used the EZ1 to perform ranging to the goal for speed control and automatic scoring.

I asked one of the students to find an ultrasonic sensor with analog outputs, and they found yours.

The sensor works well... running three of them at the same time, pointing in the same direction, ... multiplexing them...

I don't know if you know anything about the FIRST competitions, but there are 1000+ teams from around the world (mostly USA) that compete.

The organization sells a kit each season with most of the parts the team will need; you might be able to get your sensor included in the kit. Also, there is a Web site, http://www.chiefdelphi.com/forums/, where a lot of discussions about the FIRST robots takes place, you might be able to inject some information there.

I will be working on some sort of software platform or framework this year, for next year's project, and make it available to any team. I will include a software object around the EZ1 as part of the package.

(I am the programming team mentor for the Arroyo Grande (CA) High School robotics team, http://www.eaglerobotics.com/, and they just participated in the FIRST robotics competition in Sacramento, http://www.usfirst.org/robotics/.)"
********
Again, I Bob Gross wanted to let you know about this product. It has only been out since Jan 2006, but it has been very well received. It has many features, is very low cost, and it is very easy to use!