Ultrasonic Range Sensor vs Gyro

My team is looking for a new sensor to add to our robot so that we can have better autonomous routines that are more precise. We got recomended to add both an Ultrasonic Range Sensor and a Gyroscope, but we only have room for one at the moment.

My question is, which one is easier to program and which one helps me get the autonomous right most of the time?

I think the gyroscope would probably be the best investment if you’re only looking to add (literally) one sensor. Usually you need two or three ultrasonics pointing different directions out of your robot to be really effective. Sometimes because of the mirroring of red vs. blue. On the other hand, a gyroscope will probably help your autonomous a great deal if you ever do any turning. Instead of relying on time, which is variable based on battery power at the time, you can turn a specific amount (the gyroscope measures in tenths of degrees).

Which is better, Apples or Oranges?

I would say the ultrasonic sensor is easier to program in so much as the results are more reliable. The gyro is a useful sensor but, due to it’s tendency to drift, using it can be a little tricky.

Which sensor really depends on the design of the robot and what you want to try and achieve during autonomous. There is no right or wrong answer.

Why do you only have room for 1? They use different ports.
What sensors are you already using? Encoders/potentiometers should pretty much be all you need, and in our experience quadrature encoders are the most reliable sensor available (with the exception of buttons I guess).

I currently have 3 sensors (2 quad encoders in the base, and 1 potentiometer in the lift)

I mentioned I have room for 1 sensor because we only have enough cash for one sensor at this moment, and our competition is coming up. We got recommendations to add both sensors from a judge.

Ah, as JPearman said it depends what you want to accomplish with them. In what way are the quad encoders not cutting it?

Thing is, this is our first season using encoders, and we really didn’t end up programming them. We plan to have them ready for our next skills event though. :confused: We did start programming them a few days ago.

Then, I would just focus on making good use of the sensors you already have.

I’m going to put my two cents in.

The Ultrasonic and Gyro have their pros and cons as previously mentioned. Both give a great feature to your robot for autonomous or whatever other use you may imply. After hours upon hours of testing sensors and programming each and everyone of them I’d have to say neither can always be accurate.

The Ultrasonic can sometimes jump in values. It can also cause drifting as I’ve witnessed.

The Gyroscope on the other hand can be useful but it is unreliable at times. Vibrations from the robot and other factors can cause drift. Making precise movements difficult at times. Like if you were to make a 100% autonomous programming robot. The turns could not always be accurate.

If you truly want an accurate reading for these and don’t want to go with any other options. I’d look into applying an iteration of an algorithm called a “Kalman Filter”. It will help with some of the inaccuracies.

If you wanted to have the best possible version for movement accuracy ever out of all of the sensors I’d go with Optical Shaft Encoders. If you have those on your wheels along with a well written system for PID control you can have one of the most accurate autonomous programs out there.

so are IMEs not as accurate Quadrature encoders? IMEs have more counts per revolution (unless it’s turbo speed gears).

We’ve had problems with IMEs and static; they can reset to 0 or (more rarely) crash your Cortex. Also, if your wheels or whatever aren’t directly driven, IMEs won’t be as accurate due to slop.

I’ve heard from more experienced members that IME’s can sometimes be more inaccurate compared to the actual Encoders. I’m not 100% sure why, possibly vibration or some other factors cause for inaccuracy (I’m just guessing).

hmmm. There’s a place on our robot where we were trying to use an IME but it was terribly inconsistent and I couldn’t get an autonomous run made so we put a potentiometer on instead. There lies the issue of limited rotation and we are running out of analog ports!

We needs Codie’s cortex then. http://polynomic3d.com/user/smith/cortex.png
Or his older brother http://polynomic3d.com/user/smith/cortex_xl.png

Or his older brother http://polynomic3d.com/user/smith/cortex_xl.png

lol, that would be nice, but for now I think we can just use a quad encoder.