Modeling Friction

Harys Dalvi

Project from September–November 2020, written April 2021

To start, I'll say that the official title of my paper for this project was "Quantifying the effects of geometry on friction coefficients". Clearly, this is a very different idea from "Modeling friction". I think that goes to show how this project didn't exactly go how I had initially planned. Still, it was a helpful learning experience as my first big project involving both physics and code.

Premise

A basic and well-known idea of friction is that it has to do with the "roughness" of a surface on a small scale. That's why sandpaper seems to have much more friction than a smooth sheet of metal. My first idea for this experiment was to better understand why this is and how it works at a microscopic scale. In order to do so, I wanted to model these materials at a microscopic scale using a computer and compare the model to experimental results. I thought I might even be able to graph friction based on roughness and find some sort of quantitative relationship, hence the name "Quantifying the effects of geometry on friction coefficients".

3D printing

The first step for me was getting blocks of varying "roughness" to test experimentally. I designed these blocks on Tinkercad first by making a cube, and then my making copies of the cube with small irregularities on the bottom. So one cube had small (about 2mm tall) cones on the bottom, one cube had triangular wedges, one cube had hemispheres, one was hollow, and one had a gap so it was standing on two "legs". Then I went to my school's 3D printer to try to print the cubes.

However, the hollow cube in particular was a problem, as the 3D printer couldn't build on air. I removed this cube from my experiment. As for the other cubes, they were too big to be printed at a good price. Instead of cubes, I shrunk each to a small platform 3 inches by 1.5 inches by 5 mm. My final designs looked like this, bottom surface facing up.

At first, I tried to use wooden blocks to bring back the mass I had lost by cutting off the cube. Then I remembered acceleration due to friction doesn't depend on mass, so I just used the small "blocks" (really more like platforms) as they were.

Coding

Next, I started working on modeling the blocks sliding down a steel ramp with code. My idea for a model was to split each block into many tiny blocks connected with springs. However, to be realistic in modeling a block, I knew the springs had to be much more rigid than the kind you might find in the toys aisle. My question was, how rigid should the spring be (specifically, what should be the spring constant \(k\) from Hooke's law) in order to accurately model a solid block?

As I did more research on the topic, I discovered stress-strain curves were the answer to my question. However, I was unable to find a full stress-strain curve for Onyx, the material used in my 3D printed blocks. To deal with this, I used data for nylon to extrapolate a full stress-strain curve for Onyx. This is what I came up with, graphed in Desmos. The linear part on the left before the yield point is the part that obeys Hooke's law.

With this, I started by making blocks of equal mass with springs of a large but not properly calculated spring constant in order to get the mechanics right. I tried a few simple simulations, including a double pendulum, to make sure everything was working. Although I included an option for 3D space, all of my simulations were set up so that motion was confined to two dimensions.

Interestingly, even though I had only really coded in for linear motion with \(F=-kx\), I found that rotation-like things seemed to be represented fairly accurately. I realized that this is because rotational mechanics is just tiny pieces moving in circles around a central point according to regular linear mechanics. When I thought about the equation \(I = \int r^2 \, dm \) for rotational moment of inertia, I saw that the equation expresses the same idea (\(dm\) is the tiny piece), and so this realization isn't unique to me. It was still nice to make a small independent discovery.

Then I was ready to move on to modeling actual Onyx. First I used the Ra value (average absolute distance from the mean elevation) for steel and modeled the steel ramp as a sinusoidal function with tiny amplitude. Then I split the Onyx block into eight smaller blocks in three dimensions, connected by springs. My code was based on Euler's method with small time increments of \(dt\), and I found that unless I made \(dt\) small enough, the pieces would explode. There was nothing I could do to fix it. I reasoned that it is probably because since Onyx is so much more rigid than a toy aisle spring, the smallest disturbance \(x\) leads to a huge force \(F=-kx\), so small time increments are needed to make sure those small disturbances get undone by the force going in the opposite direcion before it is too late.

So I reduced \(dt\), but of course, this required more processing power. I would let the program run for hours, and the virtual block would hardly slide down a virtual centimeter. To speed up processing, I removed the 3D funcionality and did everything in 2D. However, the processing was still too slow! My last resort was to break the blocks into fewer tiny block components. In the end, I used blocks 0.5 millimeters on a side. My simulation looked like this:

Of course, 0.5 millimeters is huge compared to the small microscopic ridges you might see on a steel surface. Therefore, none of the tiny pieces got "stuck" in the crevices of the steel as I had hoped, and my model predicted no friction. It's one thing when the results are different from your hypothesis, but a completely failed model looked really bad. I had to find something that would work.

Experimentation

At this point I took a break from coding and went outside to test the friction in real life. My setup imitated the classic free body diagram for a block on a ramp with friction.

For the experiment, I would gradually tilt the steel ramp up and use a video to record the angle at which the block started to slide, then use \(\mu = \tan \theta\) to find the coefficient of friction as can be derived from the free body diagram and Newton's second law. This is how my setup actually looked. Notice in the bottom right you can just make out a blue protractor (it is almost entirely cut off) for measuring the angle.

The physical experimentation part was somewhat tedious, as I did 90 trials (5 blocks with 15 trials each, plus 15 for one block going backwards), but it went smoothly. Nothing much to say there.

Math

Since my computer didn't have the processing power for a coded model, I turned to math. Note that at this point, I was far less interested in the varying geometry of the blocks, and more interested in getting a model that worked.

The model I eventually settled on imagined each block as a collection of vertical beams of length \(L\) made of Onyx. The beams are stuck a distance \(a\) inside the cracks of the steel ramp, so the block does not move. Each beam is pushed down by the beams up the ramp, and pulled down by the beams down the ramp. As the angle of the ramp increases, the total force \(F\) from the other beams increases. The steel must push back with an equal force \(F\), otherwise the beam would go through the steel. These two opposing forces cause the steel to bend. If the steel bends too much, it breaks. Here is a diagram. Note that in the diagram, the ramp is horizontal; but in real life, the ramp is tilted up by an angle \(\theta\). This is why gravity does not appear to be going down in the diagram. However, it is pointing towards the ground (which appears to be tilted from this frame of reference).

The big remaining question was how thick each beam should be. I decided to say that the block will slide when the strongest beam breaks. The strongest beam would be the thickest beam, and its thickness will correspond to the biggest microscopic hole in the steel ramp. To figure out this length, I used this image of steel microstructure (Liu, Li, Schneider, Lu, & Wang, 2016).

I analyzed the image in Python's PIL library to split it into "light" and "dark" spaces. I used the statistics (mean and standard deviation) on the relative frequency of these in a vertical line across the image in order to create my own vertical lines, which looked like this:

I created 1000 of these vertical lines in a program, and took the biggest hole to be the mean length of a stretch of darkness plus one standard deviation. Plugging this value into the stress-strain equations for my beam model, I got something a little bit close to my experimental results. At this point, the due date was coming up, so I just went with it.

Why this doesn't really make sense

Ok, so that was my process as I did my experiment. But if I'm being honest with myself, it didn't make much sense. I had a feeling it didn't make much sense right when my simulated blocks started exploding out of nowhere. Now that I'm done, I can look back and really think about all the reasons. I'll go in the order than I mentioned the relevant part of the project.

Look at the 3D designs for my block, particularly the one on the left, with the gap between two "legs". Now look at the regular flat one on the right. What's the difference between these two? Well, the material is the same, and the interface with the ramp is the same so you could say the "roughness" is the same. The big difference is the mass. But I even said at the time, when changing my mind about using wooden blocks, that acceleration due to friction is independent of mass! Somehow, even though I knew this fact, I designed a 3D model where the variable I changed was really mass and not shape. To make things worse, my hollow cube idea was also the same thing with a different mass, so I made this mistake twice.
Compared to the small ridges on something like sandpaper, the cones, wedges, and hemispheres on my 3D designs are extremely large. They're definitely much larger than the tiny holes in the microstructure of steel. It really wouldn't make sense for this varying geometry to have any impact on friction. This is a big reason why my title, "Quantifying the effects of geometry on friction coefficients", was in fact a small part of the project.
What's the point of having a computer model for friction? In my paper, I justified it by saying it will lead to a better idea of friction in general, potentially maximizing friction where it is good (like tires on an icy road) and minimizing it where it is bad (like machine parts). Maybe there's something to this, but it's easy enough to just measure the coefficient \(\mu\), and the model \(F_f = \mu F_N\) (friction proportional to normal force) seems to work pretty well.
Does each beam really support all the weight of the block parallel to itself? I remember trying to verify this with Newton's third law, and it seemed to work out. However, there might be some effects I didn't look at from beams that are to the side, not directly up the ramp or down the ramp.
Does the block really start sliding when the strongest beam breaks? After the block slid, I would pick it up and put it back on the ramp. If the beams were broken, why did they suddenly "reappear" for the next time I slid the block down the ramp? I'm thinking maybe they didn't reappear, and the damage is associated with the damage we see with kinetic friction. This seems a little bit lined up with reality, but somehow it doesn't quite make sense to me. It seems too simplistic to have these beams breaking every time, and it seems like they would be damaged faster than we observe with kinetic friction.
Why is the beam model so different for the different blocks? The main difference in calculation between blocks had to do with the varying weights of the blocks, so this question is somewhat connected to the previous one. Something weird is going on.
These beams are microscopic in scale. Should I be looking at intermolecular forces from chemistry rather than macroscopic forces from Newtonian physics? What is the scale where these becomes relevant? I know that the Newtonian normal force is really derived from intermolecular forces, as the negatively charged elecrons of adjacent atoms repel each other. But if intermolecular forces are involved at this scale, maybe I'm trying to go the other way around (deriving intermolecular forces from Newtonian macroscopic forces) which doesn't make sense.

Even though this didn't really make sense, it was good preparation for future physics research. Most importantly, I learned to make sure that my projects are both practically applicable and feasible with the resources availible. These two ideas are somewhat in conflict with each other, because practical applications tend to be hard and require resources, or else someone would have figured them out already. I will have to learn to find a balance. In this case, I don't think I met either very well. There wasn't a clear application, and I didn't have the processing power to do a good model. I hope to do a better job of meeting both these goals next time.