Contact Area and its Relation to Friction?

[Herodotus]

Originally Posted by squirrel

An example of friction being weird: Most material interfaces have a higher coefficient of static friction, than of dynamic friction. But aluminum to aluminum has a higher coefficient of dynamic friction than static friction.

I find this concept very confusing. So it takes more force to continue to move aluminum against aluminum then it does to start moving it I read this and I thought to myself.... well that just can't be right, so I looked elsewhere to verify it, and go figure it's true. I just don't see how that works.

[Kevin Sevcik]

Originally Posted by sumadin

I also don't understand the idea of PID traction control. I've heard of PID velocity control using encoders, and I'm planning to implement that on our robot this year, but I don't understand the idea of PID traction control. How would you do that?

PID traction control is pretty simple, just not anything that's typically done in FIRST. The whole point is to keep your wheels from slipping. Wheels slip when applied force exceeds the static friction force. Applied force is proportional to applied torque which is (mostly) proportional to motor torque which is proportional to motor current. So your goal would be to PID control the current being supplied to (or sourced from) the motors. Current-mode motor drivers and amplifiers are awesome for this, but we don't have any, sooo the idea would be to use a solid state current sensor on your motor leads, and PID control this.

Now, I'm not sure our available loop rates are really adequate for good stable control of this current, but you could certainly easily implement a simple controller to back-off on commanded PWM signals to keep the current in an acceptable bound that you know won't slip.

Originally Posted by techtiger1

The easiest way too figure this out is to put the bot pushing against the wall and record the numbers from dashboard when the wheels slip then set them up in programming as limits.

The above means I'm slightly skeptical about programming hard limits into your code based on what PWM values caused slipping at a stand still against a wall. The PWM values control (to a 1st order approximation) the voltage that you're applying to the motor, not the current. As a motor spins, it creates its own source of voltage (back EMF) proportional to the motor speed that cancels most of this out, with the left over voltage differential driving the current flow and thus creating torque. What this boils down to is that, if your robot is moving forward while you're commanding a constant voltage, you're theoretically applying less torque than you could get away with. Annoying, but not really a problem. However, if you're applying your constant voltage and still getting pushed backwards without slipping, this actually increases the torque you're putting out. Which means that if someone pushes you back fast enough (and it doesn't have to be a lot if you're cutting things close) you'll suddenly put out too much torque, spin your wheels, and very rapidly lose the pushing match. Plus, you'd be pointlessly limiting your top speed when you're not pushing someone, because you've simply put in a limit to how much voltage you'll put out and, thus, what your top speed is. Now, there are ways to compensate for this using velocity feedback and such, but they're not going to be as accurate and reliable as a current sensor feedback.

[JesseK]

I apologize for continuing off on a tangent, but I feel we're on a roll with the tangent and it's pertinent to the original topic to an extent. The biggest advantage I see for traction control is the ability to climb rough terrain (ramps) without too much driver input.

Originally Posted by sumadin

I also don't understand the idea of PID traction control. I've heard of PID velocity control using encoders, and I'm planning to implement that on our robot this year, but I don't understand the idea of PID traction control. How would you do that?

Jesse, there are some ways. One way is to have a passive wheel on an independent axis in the center of your robot, and encode it. It will only move if the robot is moving. You could also use mouse sensors or trackballs to accomplish similar things, I think.

We too use the encoders for PID velocity control in order to keep the robot driving straight at high velocity.

Hmm, after a bit more thinking the mouse sensors seem easy enough to do if you have 1 mouse sensor on each side -- even though the PID control, for perfection and theory, would slightly change during a turn (higher I value) than in a straight (higher P value). I'll have to bring this up to the drive train design team tonight to see if we can focus a bit of time experimenting with it.

Originally Posted by Kevin Sevcik

Wheels slip when applied force exceeds the static friction force. Applied force is proportional to applied torque which is (mostly) proportional to motor torque which is proportional to motor current. So your goal would be to PID control the current being supplied to (or sourced from) the motors. Current-mode motor drivers and amplifiers are awesome for this, but we don't have any, sooo the idea would be to use a solid state current sensor on your motor leads, and PID control this.

This might be a good start for general traction control as I know exactly what you're talking about. We definitely need some data before we can come up with anything concrete for limiting values however, and be able to test many scenarios to make sure it dynamically understands turns vs straights. We'll also have to review the rules on custom circuits since this sensor would be inlined with the motor leads. Bah, such a great idea so little time!

[Kevin Sevcik]

Originally Posted by JesseK

This might be a good start for general traction control as I know exactly what you're talking about. We definitely need some data before we can come up with anything concrete for limiting values however, and be able to test many scenarios to make sure it dynamically understands turns vs straights. We'll also have to review the rules on custom circuits since this sensor would be inlined with the motor leads. Bah, such a great idea so little time!

Similar sensors were legal and included in the Kit a few years ago. In fact, R62 and R63 from last year make it clear that these are legal. And yes, making the control adapt properly to the dynamic nature of the FIRST field would be challenging. I think true traction control would be decidedly difficult, and would basically end up monitor wheel velocity and motor load and maybe a few other factors to decide if the wheels actually are slipping.

[Joachim]

Grippy non-linear materials like natural rubber, when on relatively smooth surfaces, can have a higher effective coefficient of friction at lower pressures--so for a fixed robot weight, larger contact patches can give higher friction becuase the rubber of the contact patch is under less pressure.

For an experiment showing the non-linear coefficient of friction of rubber (higher coefficient with lower load on the interface) see http://www.tuftl.tufts.edu/files/asu..._Testing.2.doc particularly graph 1 and graph 3. See also http://www.robotbooks.com/robot-materials.htm toward the bottom of the page, where you find the statement:

"The confusion here comes from the fact that rubber has a very unusual property. The more lightly it is loaded, the higher its apparent coefficient of friction."

Of course carpet can change everything, so you need to experiment for yourself.

[Qbranch]

So... the consensus is that contact area has little or nothing to do with friction? But it does?

Ok... i'll go get empirical data sometime...

-q

[Richard McClellan]

Originally Posted by Kevin Sevcik

PID traction control is pretty simple, just not anything that's typically done in FIRST. The whole point is to keep your wheels from slipping. Wheels slip when applied force exceeds the static friction force. Applied force is proportional to applied torque which is (mostly) proportional to motor torque which is proportional to motor current. So your goal would be to PID control the current being supplied to (or sourced from) the motors. Current-mode motor drivers and amplifiers are awesome for this, but we don't have any, sooo the idea would be to use a solid state current sensor on your motor leads, and PID control this.

This thread has spawned a lot of good discussion. While we're on the topic of traction control, I wanted to ask another question, how exactly does an anti-lock brake system on a car work? This would seem to require some sort of a traction control system, where you would PID control the current of a motor (or for a car, the gas being injected into the engine). Theoretically, this control system would work when the wheel material and the ground were made of the same material, as is the case in a FIRST competition.

But for cars, the problem is much more challenging, because road conditions are always different. ABS systems allow fairly large deceleration on dry roads, but when the road is wet or icy, this is somehow compensated for and maximum deceleration is much smaller. Can anyone explain this? This concept seems like it would be extremely useful if it could be applied to a FIRST robot.

[JesseK]

This used to be a good guide with an animated gif showing how the internal cyllinders work in the brake pump -- but it looks like they've changed it a bit in the couple of years since I've looked at it. I too had this question a few years ago:
http://auto.howstuffworks.com/anti-lock-brake.htm

It's "sorta" how it works. Instead of a speed sensor, some cars used to use a "slip" sensor that was a combination of a shaft encoder and accelerometer. Since then it's been proven to be easier and faster to use speed differentials to control the brake fluid pressure.

[Richard McClellan]

Originally Posted by JesseK

This used to be a good guide with an animated gif showing how the internal cyllinders work in the brake pump -- but it looks like they've changed it a bit in the couple of years since I've looked at it. I too had this question a few years ago:
http://auto.howstuffworks.com/anti-lock-brake.htm

It's "sorta" how it works. Instead of a speed sensor, some cars used to use a "slip" sensor that was a combination of a shaft encoder and accelerometer. Since then it's been proven to be easier and faster to use speed differentials to control the brake fluid pressure.

Ok, so according to that article, the control system operates with a predetermined constant for the "maximum allowed deceleration" to prevent the wheels from slipping. But this "constant" is extremely dependent upon the coefficient of friction between the wheel and the ground, which changes depending on the surface of the road.

Based on my experience with ABS, this "constant" is smaller when driving on ice, than when driving on a dry road. But how does the control system know this?

Theoretically, this could be done with an accelerometer and encoders on the wheels. Is this the way it's done? The problem that might happen is that by the time the controller realizes the wheel speed is different than the car speed to start removing brake pressure, the wheels will already be slipping. Doesn't ABS prevent this situation completely?

[mikeleslie]

Not to want to carry on the ABS thing too long, but the article is a bit misleading. (and this part is actually valueable in a FIRST situation)
The wheel sensors look at rotational speed at each axle (i.e. an encoder at each wheel) The system then can look at the realtive speed of each wheel. When you mash on the brakes, it monitors each wheel to see that they are moving (more or less) at the same speed. When one stops turning, (no changes at the wheel sensor), the system sees the difference and dumps the pressure to that brake line until it starts turning again, whn it's turning again, the dump valve is closed and pressure returns. now since the systems lost pressure, the pump pushes some extra back in so your foot does not hit the floor. (this is a very generic description here, so some license is taken with when the valve closes etc)

Now looking at vehicle stability systems is where you find the big use of the acceleramoters. They know what is supposed to be happening (accel, brake, turn etc,) and look at the body response. If it's out of bounds (accel a direction not intended), they use the ability of the ABS to apply and release the brakes in combination with changes in engine timing to reduce power to try and get things back within a safe zone. (again, this doesn't describe everything and there's much variation in the specific systems)

So how can you use this on a robot?....well, if you can look at each of your wheels independently (one channel per independently rotational wheel ) to see what they are doing, and you can look at the operator input to see wht you want to be happening, and you can look at the net affect on the body (2d acceleramoter) then you can use this info to do things like pulse the motors (to change from the dynamic friction during wheel rotation) or stop the wheels from turning, or trun away......of course, a really good driver just does this without even thinking about it. sort of a hardware vs software trade

[mikeleslie]

Paul is right. It's not the surface area.

and since it's not what is it? (and this is just my thoughts here)

The surface we are dealing with is not normal. It's complex, it has threads, and some of thes threads are in contact with the wheel. so looking at the thread to wheel interaction is a start. I would look at the shape of the thread under your wheel when they are in contact. How can you use the fact that the thread is glued to the carpet mat as an advantage? The carpet is 3 dimensional. can projecting into the carpet be an advantage, can there even be a "best shape" for these projections relative to the carpet fibers? Don't think at the 1 square inch level, think at the .1sq mm level. How do I get the fibers to do more for me than the other guy? How can I trap them, bend them and make them do my bidding? Don't think about pushing down, think about pulling across. Find the exact right combination of shape, projection and force direction and you will solve this puzzle.