Coefficient of Friction Testing

[Chris is me]

Originally Posted by KrazyCarl92

Does anyone have thoughts on how a test bed like this could be used in season to produce useful results prior to the drive train design phase of the season (like gathering information in days 3-5 of build)? My question deals more with the utility and practicality of such an apparatus in the actual season rather than the theory, design, or production of the apparatus.

I think there are a few options:

1. Previous robots - if you do a particular style of drivetrain twice in a row, take an old robot, maybe remove some parts from it, redistribute weight with bricks / batteries to approximate various CGs.

2. Kitbot - This test might not be as functional since the Kitbot frame may be less rigid than a welded tube frame, but for many teams testing with a kitbot is a good approximation.

It's important to note for both of these tests, you don't even need to have gearing established yet, since the wheels will be locked. The key things to simulate in these tests from what I can gather are weight, CG, frame rigidity, wheel type, and your contact polygon, so aim to prototype with those in mind.

I'll go ahead and throw this on the "list of things I wish we did". We've approximated our way into a great drivetrain the past 3 years.

[JamesTerm]

Originally Posted by JVN

Don,
Do you have any of the data from the tests you've done, or any more info on how you take dynamic friction into account?

-John

I'm going to throw an idea out there and I hope people will respond with why it would or would not work. As a starting point for explanation this stems from the spreadsheet for the cell "Drivetrain Efficiency", where I propose kinetic friction = %100 - "Drivetrain Effiency". What I've observed in my real and simulated tests is that kinetic friction will reduce the overall top speed that would have happened, and this is easy to measure by use of encoders. So perhaps it could work like this:

In reference to this (assuming you use CIM)
http://www2.usfirst.org/2005comp/Specs/CIM.pdf

1. Try to use the peak efficiency voltage to measure 19.8 amps by setting victors to a constant speed percentage. Measure with amp meter what you have.
2. Read back the rps from the encoder
3. Using the stall torque of 45 Oz-In converted to newtons use spread sheet equations to determine the max speed for the encoder
4. Similar to linearization of victors, get robot running at a steady state of the known speed in step 1... you may record each iteration of the encoders for later analyses

It should fall short of the optimal speed just as the drive train efficiency also lowers the max speed in the spread sheet. This would be because some of the 45 Oz-in torque is used to fight the friction.

My studies also show that Cof impact a delay in acceleration but a quicker response in deceleration (assuming victors are in coast). So far these timings are very small probably 5ms worst case when robot has light payload. I need to do further research for heavy payload.

In regards to dynamic friction and the stribeck curve... I think the steady state should have the most valuable coefficient, and it should be possible to conduct same test at different velocities.

I do not quite yet understand the link between kinetic and dynamic, so for now I propose the kinetic is the overall average one-number that represents the friction but only for one given velocity... just as it is for drive train efficiency cell in the spread sheet.

It should be noted that I believe a similar test to these steps are being done here:
http://www.chiefdelphi.com/forums/sh...hreadid=107889

[JamesTerm]

Hi everyone... today I wanted to share some data in hopes that someone can help explain why our robot has the right side slower than the left. Here is a quick graph:



And here is the actual numbers it represents:
http://www.termstech.com/articles/TestDirections.txt

What this test does is simply goes full throttle forward, and then full throttle backwards. The green 'v' is voltage left and right (both left and right sides are interleaved within the pixels). The 'Y' grey is displacement in meters. The "p" magenta is the desired speed (p for predicted). The cyan 'e' encoder is the actual velocity recorded. Both 'p' and 'e' are linear velocity measured in meters per second. That leaves the yellow 'eo' which is the PID influence. Each line of text (or two pixel columns) represent 10ms iterations.

At first I thought the speed differences were due to CoF, but looking closer at the right side it does something contrary to that theory. Like CoF it will reduce the overall top speed... clearly when voltage reaches 1.0 the left side always has a faster speed. I wanted to make sure that there was not significant motor bias of one direction to another (e.g. motor brushing placement). So here's the part where it gets interesting... when it decelerates and I try to slow down both sides... the right side all of a sudden goes faster than the left. If it were CoF... this would not be the case in fact just the opposite as high CoF would act like a mild brake and make it decelerate faster. So that leaves two possible answers I can think of:

1. The mass on the right side is much heavier
2. There is not as much current going on the right side given the same amount of voltage.

Also note how the PID tries to increase the voltage but still the right side is going faster... the speeds want to have a 300ms lag from its natural momentum.

I believe it's a lack of current as I have observed it getting worse when the battery gets lower voltage readings (e.g. 11.2)... on several robots.

Does this sound right? Anyone have an explanation why the current distribution becomes unbalanced?

[Jared Russell]

Possible explanations:

1. With manufacturing tolerances and different wear patterns, it is possible that the right CIMs are "slower but torquier" and the left CIMs are "faster but less torquey". There could also be mismatch and therefore non-equal current draw within an individual gearbox, if there are more than one motor per gearbox.

2. Different retarding forces on each side, including both "coulomb" type stick-slip friction (~proportional to acceleration) and viscous damping (~proportional to speed).

3. Different lengths of wire or quality of crimps between the sides resulting in more or less current reaching the actual motors.

4. Unequal mass.

5. Damaged CIMs. A toasted motor continues to run, but draws more current and produces less mechanical power.

I don't know how much time you want to sink into this project, but a some relatively simple experiments you could run would be swapping CIMs around, measuring wire/crimp resistance with a multimeter, bench testing each CIM/gearbox, swapping whole transmissions left/right, and measuring and balancing weight on each set of wheels.

[JamesTerm]

Thanks for these items for checklist... I'll want to keep these in mind for our new off-season drive we'll be experimenting on. I guess after seeing this same problem on 4 different robots... it's time to really put some effort into fixing this mechanically.

For now, I have however fixed this problem in software by simply changing the overall scale of voltage prior to applying the polynomial equation to linearize the victors. It looks something like this:

LeftVoltage=(LeftVelocity+m_ErrorOffset_Left)/ (MAX_SPEED + m_TankRobotProps.LeftMaxSpeedOffset);
RightVoltage=(RightVelocity+m_ErrorOffset_Right)/ (MAX_SPEED + m_TankRobotProps.RightMaxSpeedOffset);

[Chris is me]

Have you calibrated your speed controllers? Improperly calibrated controllers can cause a lot of drift.

[JamesTerm]

Originally Posted by Chris is me

Have you calibrated your speed controllers? Improperly calibrated controllers can cause a lot of drift.

No we have not... that may indeed be the problem. I'll have a chat with the team about this... any good links or tips on how to do this would greatly be appreciated. Thanks.

[JamesTerm]

Originally Posted by JamesTerm

No we have not... that may indeed be the problem. I'll have a chat with the team about this... any good links or tips on how to do this would greatly be appreciated. Thanks.

We found this link and it seems pretty straight forward on how to calibrate it.
http://content.vexrobotics.com/docs/...al-9-25-06.pdf

[JamesTerm]

Originally Posted by JVN

I just published a post which highlights my method for calculating the coefficient of friction for robotic drivetrain systems.

John, (or anyone else who has followed the math of this approach)

I found this link
http://tcdprd.autodesk.com/tcdprd/ev...html/15/48.htm

Can this same ramp technique -using testing material (e.g. carpet) on ramp- work to determine the static CoF for wheel traction by simply locking down the gears (i.e. make them never move during this test)? Or is there an easier way. I know wheels are rated, but it would be nice to actually measure it.

p.s. I presume robot must have a low CoG for this test so it will not tip over.

[JVN]

Originally Posted by JamesTerm

John, (or anyone else who has followed the math of this approach)

I found this link
http://tcdprd.autodesk.com/tcdprd/ev...html/15/48.htm

Can this same ramp technique -using testing material (e.g. carpet) on ramp- work to determine the static CoF for wheel traction by simply locking down the gears (i.e. make them never move during this test)? Or is there an easier way. I know wheels are rated, but it would be nice to actually measure it.

p.s. I presume robot must have a low CoG for this test so it will not tip over.

James,
Thanks for the link, but that is nothing new to me -- since I wrote it.
It is part of the pre-2012 version of the Autodesk VEX Robotics Curriculum. (New version just went up here, coincidentally).

Where did you find it linked?

Yes, locking the wheels, putting your robot on a ramp of carpet, and tilting the ramp is the test being described in this thread. That was the math I showed in my initial post.

-John

[sanddrag]

Originally Posted by JVN

James,
Thanks for the link, but that is nothing new to me -- since I wrote it.
It is part of the pre-2012 version of the Autodesk VEX Robotics Curriculum. (New version just went up here, coincidentally).

I don't mean to derail this thread, but I'm surprised to see the 2012 curriculum available now. The website didn't notify me, although I had put in my e-mail address previously. The 2012 curriculum has some rather significant differences from the 2011 and 2010 curriculum. Is there another thread existing someplace where it is discussed, perhaps from an educator-to-educator point of view?

[JVN]

Originally Posted by sanddrag

I don't mean to derail this thread, but I'm surprised to see the 2012 curriculum available now. The website didn't notify me, although I had put in my e-mail address previously. The 2012 curriculum has some rather significant differences from the 2011 and 2010 curriculum. Is there another thread existing someplace where it is discussed, perhaps from an educator-to-educator point of view?

PM me or email me john.vneun@gmail.com. We did a soft launch, in anticipation of a more "announced" launch shortly.

-John

[JamesTerm]

Originally Posted by JVN

James,
Thanks for the link, but that is nothing new to me -- since I wrote it.
It is part of the pre-2012 version of the Autodesk VEX Robotics Curriculum. (New version just went up here, coincidentally).

Where did you find it linked?

Yes, locking the wheels, putting your robot on a ramp of carpet, and tilting the ramp is the test being described in this thread. That was the math I showed in my initial post.

-John

I found this link using google as I was double checking my wording (after chatting with Ether these past few years I tend to double check my wording before I post). The funny thing is that I totally missed this line in your blog:

"Make sure the wheels are "locked" so the robot cannot roll."

So all of this time I thought it was drive train performance that this was trying to find, and why I've been asking about dynamic/kinetic friction... which by the way for the good of the group, I'd like to share the method you presented to me for this:

"
I believe kinetic and dynamic friction are the same thing.
I think that the method you outlined would work if you want to calculate the kinetic friction at any given wheel speed. I believe these values shouldn't change much based on speed. The simpler test to figure out kinetic friction is similar to the static test. You put the robot on a ramp, tilt it until it starts moving, then tilt it back until it stops moving. Take the tangent of the angle at the time it stops moving to find the kinetic CoF.
"

And funny thing... yep... I thought this too was to solve for drive train performance... as I interpret moving as rolling. Doh!

Part of the reason I missed that this test was about traction the first time around was because I was so focused on being able to simulate how fast a robot will move given time, gearing, motor(s) and, voltage. I think for me personally to avoid confusion I may wish to adopt the term Coefficient of Traction.

On a side note I made an interesting discovery today that I do not have an explanation for yet. It deals with some measuring results that "appear" that it took more voltage to slow down the robot (wheels were up on boards too) than to accelerate. I'm sure there is a simple explanation... I'll just need to study a bit more on kinetic energy.