Question on wheel speed sensors

[Al Skierkiewicz]

If you want an accurate auton, you will need some kind of wheel encoder. You need to know how far the robot has traveled. We have used an imprinted wheel with black and white spaces with a simple LED/photodiode sensors (gives up to .25"-.5" accuracy) and digital pots which give much greater detail. If you are worried about slip, use more sensors and compare several. Ignore the one that is far off and average the others. Crab turns introduce less error than tank turns but can be compensated for in software. If your design is prone to high current draws during turns, it may be better to use current sense to limit drive then to use wheel tach.

[Gdeaver]

Good quality Quadrature encoders are expensive. Another option is to use a latching hall effect switch and a diametrical magnet. They are very cheap and give 2 transitions per revolution. They are very tolerant of misalignment. They do not give direction.

[Alan Anderson]

Originally Posted by Gdeaver

Good quality Quadrature encoders are expensive.

Expensive is relative. The US Digital E4P is relatively inexpensive, and with appropriate attention to detail it works perfectly.

[Dave Scheck]

Originally Posted by Al Skierkiewicz

Crab turns introduce less error than tank turns but can be compensated for in software.

That's not really true Al. Using either encoders or a gyro, you can get some really precise tank turns, especially with a lower gear ratio. Let's take driving through these 4 points as an example

    D
    |
    |
B---C
|
|
A

With a crab system, there is usually a significant delay in turning the wheels 90 degrees. So, unless you come to a complete stop, without coasting, your turns will be skewed. Your B->C transition will cause you to arc instead of making a sharp cut leaving you above C. Then your C->D transition will arc again and leave you to the right of D.

Also, don't forget that there is always concern for wheel alignment with a crab system that may also cause for other inconsistencies in the drive pattern.

With a tank drive with proper gearing, when you get to B and C, you will be able to make sharp, accurate turns.

Yes, you can probably get to point D faster with crab, but you sacrifice some accuracy doing it. Sometimes that matters, sometimes it doesn't. Look back to one of our less used programs in 2006. That was some of the most accurate driving that we've done (although any misalignment was compensated for with the turret). Look at some of the things that teams like 1114, 2056, 469 and countless others have been able to just tank drives, encoders, and gyros.

Crab isn't always the answer, and when it is, it isn't always an accurate one.

[TroyCDH]

Thanks for all of great responses.

Sounds like many people think that wheels on carpet would not benefit from sensors compared to the large amount of time it would take during the build season.

Thinking along the same lines, but more general now, what can be done during autonomous mode to keep straight directions actually straight and "X" degree turns really "X" degrees?

Is GPS legal? Do-able? Cost effective? Other ideas?

Thanks, Troy

[EricH]

Gyro, accelerometer, and wheel speed sensor with programming are good options. GPS has a good chance of not being able to give the <54 foot accuracy an FRC robot needs, especially when going through a stadium roof.

[Lil' Lavery]

Nobody is saying wheels on carpet don't benefit from sensors, but rather, they don't benefit from a "land speed" sensor as you were proposing. Almost every competitive team uses some form of sensors in their drivetrain, but usually just to monitoring their driven drive components. They'll mount a shaft enconder to their drive shaft or the output shaft on their gearbox, for example. They trust that the slip effects are small enough that any error they induce will not effect their gameplay.

If you want "external", field-oriented input, you don't always have to base it off the playing surface. Your GPS comment is on the right track. There have been games in the past with non-moving optical targets (such as the lights in 2004 and 2006) that can be incorporated into navigation software. While there hasn't been a game with enough stationary vision targets to triangulate your position on the whole field, using these points can certainly be helpful in many other ways.

[Ether]

Originally Posted by TroyCDH

Sounds like many people think that wheels on carpet would not benefit from sensors...

That's too much of a generalization of the responses.

If the only purpose of the sensors is to control wheel slip then that might be a fair generalization.

But if the purpose of the sensors is to improve autonomous accuracy then even on carpet - with minimal wheel slip - if you have no feedback of wheel position your accuracy is at the mercy of drivetrain friction and battery voltage and manufacturing tolerances of the motors.

Originally Posted by TroyCDH

...compared to the large amount of time it would take during the build season.

It doesn't take a large amount of time to put the KoP-provided sensor(s) on the wheel(s) and use that feedback in autonomous to improve the accuracy.

[Dave Scheck]

Originally Posted by TroyCDH

Thinking along the same lines, but more general now, what can be done during autonomous mode to keep straight directions actually straight and "X" degree turns really "X" degrees?

As has been mentioned, a gyro or wheel encoders will be your best bet. The tuning of your PID loop will determine how accurate your turn really is.

As far as driving straight goes, you can use those same sensors to make adjustments to your motor speeds to try to maintain a heading.

The tricky part to both of those problems is the experimental tuning of your PID loop(s). (This assumes that you can't get close mathematically). If you need a good C++ PID library, the Simbotics wrote a good one that we've been using for a couple years now. You can download it from their website