I just published a post which highlights my method for calculating the coefficient of friction for robotic drivetrain systems.
In my opinion… it is not sufficient to test the coefficient of friction of a single piece of tread, or a single wheel on carpet – we need to test whole systems, and determine THEIR coefficient of friction. Only by testing the actual configuration of the robot you’re going to use (i.e. the correct number of wheels, the correct tread contact size, the correct weight etc) will you get the correct coefficient of friction.
So this brings up my next question…
Who actually bothers to do this?
Does anyone? Is it just me?
Does your team have their own method?
Does your team just trust the manufacturer’s specs?
Do you even care, or do you just say “this is grippy as heck” and not bother?
Our team did calculate the COF on the wheels as I was having an argument with one of the mentors regarding the number of motors to use. Personally, I just used one wheel for the test.
These wheels were 29635T31 from McMasterCarr. The argument was whether or not these would slip; if they did slip, a second motor in the gearbox would be useless. I do not have the results as they were written in someone’s journal; I do not believe he/she still has it. Sorry for the relatively pointless post.
Years ago we did some friction testing on 968, but it was far from scientific. Our primary goal was to determine how much of a role wheel width played on friction with regards to maximum pushing force. In the past, 968 had run rather skinny wheels (as skinny as 5/8" tread width). We made up two sets of wheels with tread (and I don’t remember if it was wedgetop or roughtop). One set was 1 inch wide, and the other set was 1.5 inches wide. We installed the narrower wheels and filled a plastic container with batteries so it was quite heavy and experimented with having the robot push this container on carpet. We then added more weight until the robot could no longer move it. We then swapped out the wheels for 1.5" wide ones and gave it another go. The robot pushed it with no problem, and it took adding something like another 40lbs to the container to make it un-moveable again.
While not very scientific, we did determine that wheel width can play a substantial role in friction.
Beyond that, the only thing I really bother to do each year is press some wheels against the ground while simulating turning them and think to myself “yeah, this grips well.” I know, not very ‘engineer’ of me. If the need arises in the coming season, perhaps I’ll have some students do the test you describe.
Some years ago, we actually had to find the COF between a rough-ish sponge and a piece of wooden board (relatively smooth), for a physics lab.
My group promptly used the method you’ve detailed, and why not, it’s so dang easy. However, our results were not what we expected. We saw huge variances in the “sliding” angles. We’re talking +/- 20 degrees here.
We never did figure out what were causing the variances. The teacher provided a whole host of possible reasons, none of which really did the problem any justice.
The most common/successful method was probably to weigh down the rough surface and then use a force gauge that provided a force vs. time reading. Then, from rest, slowly pull. At a certain point, the rough surface+weights will start moving. At that same point, your force will peak, and that becomes the maximum static friction (Fs). From there, it’s a simple Fs = Fn * mu calculation. Granted this did require more technical equipment, it also seemed to provide much more consistent results.
Wow the timing of this post is funny because I have been trying to decide if I should simulate one wheel or a whole system, and I’m still somewhat conflicted. My problem is that one side goes faster than the other and I cannot figure out how to simulate this properly. I know there is latency involved, I suspect this is just load mostly and I suspect the mass count on each side is different. If I attempt to correct the heading too aggressively I get a fish tale effect that oscillates and I don’t like having to back off the corrections interval as a solution.
None of the teams I’ve been on have ever tested it themselves, trusting the manufacturer (or CD, in the case of roughtop/wedgetop) instead.
Nothing against those that do, we just inevitably run into bigger problems that eat up our time during the time it’s a relevant question. (After all, the system is different next year.)
We don’t calculate the CoF. If we need to know, we test relative to some other standard (i.e., another robot) by pushing it along carpet and measuring force - sometimes with ‘calibrated legs’ only.
Your method is valid for static friction, but dynamic friction is also important IMHO, since once you start moving the value is usually quite different from static friction (= Sticktion). To measure that in your test setup, you lift to just below your normal angle, set the robot sliding, then reduce the angle to where it stops. This was very important to us in Lunacy, for example, where the wheels were generally not at rest relative to the surface.
Probably the ‘interlocking’ of the soft, rough sponge with the smooth-but-not-as-smooth-as-you-think wood. Get a particularly strong splinter of wood, and it grips more than if you only get weak (or short) ones.
Fun question: Is dynamic friction a constant with respect to velocity? I know a Physics 101 textbook will tell you it is, but I wonder if you ask a tribology (isn’t that a fun word) expert about the dynamics of tread on carpet what the answer is. Or if anyone has ever tested it?
That is, do you have the same coefficient of friction with a tire sliding at 1 ft/s as you do with a tire sliding at 10 ft/s.
This test has flaws also; the “puller” is usually not able to provide a pull of constant velocity. If there is any acceleration or change in acceleration, the waters get muddy quickly, and the data can be flawed.
We found that the tilt test is much more consistent for FRC applications as described.
We don’t do this routinely (being both somewhat limited and somewhat naive in wheel choices), but with the bridge this year we did several true experiments, including using the full robot and bridge with various wheels and other surface texture changes. We used both tipping and dragging (as our CG meant tipping sometimes preceded slipping). With all our off-season drivetrains, we’re setting up weighted testbed chassis and switching in wheels/treads on carpet, polcarbonate and polypropylene (approximation for polyethylene).
The situation you describe is not strictly Coulombian, because of inconsistency both in approximating contact area as proportional to normal force and in the angle(s) of the contact planes(s) in general. (Leaving the sponge’s contact with the wood and the wood’s own imperfections to prevent constant behavior in both time and space).
Weighing down the surface (higher but constant normal force) gets you past some of that initial “noise”. However, beware both the “pull slowly” difficultly JVN describes and the failure of Columbian models when contact area isn’t proportional to normal force (below saturation) and/or frictional force isn’t proportional to normal force (independent of contact area).
The first question we wanted to answer was if 12 wheels were any better than 6. One test was to have a 6-wheel robot and a 12-wheel robot (both same wheelbase and weight) push against each other, to see who would win. At first, the loser was universally the one which spun its wheels first. With extremely careful and skilled control, the 12 could win but the 6 could not. Repeatable with difficulty, but repeated enough times that we went with 12.
The second question was related to whether traction control - to prevent wheel spin - would provide an advantage.
We first needed to find the amount of wheel slippage that would be acceptable, and for Lunacy, IIRC we found that grip vs wheel velocity relative to the surface was somewhat linear - higher speeds giving less grip. We did this by powering up the wheels with a PID loop to a certain speed, and measuring the resulting pull with a scale (think fish scale, but of a higher quality, up to about 40 Lbs).
We then needed to measure the effect of a slip limiter. Using a 5th wheel for odometry, we used a PID loop to limit PWM input to Jaguars such that the slip was some percentage of the robot speed. (I think we settled on 12%, but I can’t say why). We then went drag racing, timing the robot over a fixed distance, the driver simply giving full throttle and letting the system throttle it back.
Our final result was that a simple rate-of-change limiter in software was nearly as effective, avoiding a lot of hardware, and that’s what we competed with.
we did a test with a kit robot and various wheel widths and diameters.
when we got done, we could not make sense of the data.
we made a test robot and used a pull scale. The robot was set in a frame, with carpet on the floor. We set the control system to ramp up the motor power at a predetermined rate. we ramped up until the wheels broke free and recorded the pulling force at that break point.
I think this test could easily be repeated with various types of wheel treads, using the bridge material instead of carpet.
Generally the published results were fairly reflective of our results, but we ended up with more noise than I was expecting, for which we couldn’t find any real trend or explanation. We also found that the blue nitrile wore better and handled dust, etc better than the roughtop. (No numbers–a reflection that’s reminded me to belatedly add wear testing to our summer procedure.) Colsons are somewhat better on the bridge, but by the time we did the switch we were using our real robot (CG around ~15") and we always tipped before falling* – at well over the bridge’s maximum angle. We haven’t done much wedgetop testing yet–on the summer list.
*EDIT: Do’h. Absolutely need to point out that this test was conducted with our pivots at 45deg angles. Wow. My bad.
/…
\ …/
Very cool post. I have used a similar method for estimating COF of material on material.
The tilt test is also a pretty good way of testing CG location, but it can get tricky.