Question on wheel speed sensors

[TroyCDH]

Are any teams using sensors and programming to limit wheel spin? During turns and maybe acceleration?

Can we sense and count rpm on our driving (powered) wheels and also sense rpm on a wheel that simply free turns by contact with the ground to get a land speed.

Can software (labview) compare these two revolution numbers and then determine wheel slip? For example the powered wheels real rpm compared to the needed rpm for the land speed. Can you then vary the electric motor output to ensure the inner radius wheels are putting out less power (rpm) to "equal" the outer radius wheels?

Sounds like a lot of work to me but I would guess that out of 3000 plus teams, some team is doing something like that.

Thanks Troy

[EricH]

Lots of teams use sensors to check wheel speed.

As for the other "Can you" questions you have, you might want to look at the 2009 traction control threads. Short answer is yes, long answer is that it'll be a lot of work and probably not worth it on carpet (given that the floor may or may not be carpet next year). 2009 really saw a lot of development of what you're asking about due to the low-traction floor.

[Chris is me]

A lot of teams used sensors and programming to detect wheel slip in 2009, when there was very little traction with the ground. For any other year, I think most wheel slipping is either inconsequential (acceleration) or desired (turning) so teams don't attempt to sense that for the slight traction edge.

Labview can implement traction control as you described; teams did it in 2009. There's no "traction control vi" that comes with it or anything but it can be done.

Most wheel speed sensors are used to track distance traveled in a straight / nearly straight line.

[kgzak]

I have built a speed controller so we can go an accurate and constant speed. My dad has built a ramp to control how fast we take off from and we have distance control. so if you combine all those together you could make any type of control you need for your robot. So yeah it's possible. It's a lot of work too. I spent the summer making a speed/distance controller. If you start testing now I bet you could get something done. The one thing we need to add still is a torque controller but that might be a project for another day.

The sensors we use are encoders and maybe we'll use the jaguars this year.

[ajlapp]

We always implement encoders on the drivetrain, typically on the driven wheels for navigation during auton and to help keep us straight during high speed jaunts across the playing field.

In 2009 we used encoders on undriven wheels to manage wheel slip and to give us accurate slip free navigation data during auton.......we have considered using undriven encoder wheels for other games, but we haven't found good cause for spending resources in this area when operating on carpet.

[AdamHeard]

Like everyone else said, very useful in 2009 with limited traction, but on carpet not so much.

When we're in high gear, there is no wheel slip, and I've never really watched for it, but we don't really slip under unloaded acceleration in low either. We certainly accelerate plenty fast in my opinion.

Sensors on drive are however very useful for other concepts mentioned in this thread.

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

[Mike Soukup]

Originally Posted by kgzak

I have built a speed controller so we can go an accurate and constant speed. My dad has built a ramp to control how fast we take off from and we have distance control. so if you combine all those together you could make any type of control you need for your robot. So yeah it's possible. It's a lot of work too. I spent the summer making a speed/distance controller. If you start testing now I bet you could get something done. The one thing we need to add still is a torque controller but that might be a project for another day.

Since you did all this work before kickoff, you're either going to rewrite it or release it, right? You may want to read R25 from last year's rules.

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