CSC2529F: Computer Animation course,
Course Project
Simulation of car dynamics
|
CSC2529F: Computer Animation course, Course Project Simulation of car dynamics
|
| Quick links |
What it is, Status, Physics, MPEGs, Source, Future work.
| What it is |
This project is (an attempt at) a simulation of car dynamics.
It was done for my Computer Animation course as a course project.
It was my hope to learn more and get a better feel about dynamic
simulations (a goal which is has been more than satisfied :).
Total time logged on the project so far: somewhere around 60.
| Status |
As of the present, the simulator is NOT fully functional. The project has reached a point where I have come to the conclusion that some of the physics formulas and concepts I was using (model for static friction, especially), even though are correct for real world physics, do not suit physical simulation very well, and do not give the desired results. These will be discussed more in the Physics section. Suffice it to say that I now have to backtrack and rework the system of linear equations used to simulate the world, so that it uses a more appropriate formulas.
| Physics models employed |
This section will give an outline of the history of the physics models behind this simulation.
| The initial design |
I started with the idea of the car being just a rectangular solid (something which we have modelled in a previous assignment and I felt pretty comfortable with), with one minor modification, and that was that it would have appended to the four lower corners four massless wheels (the assumption of a massless wheel seems valid since usually the mass of the wheel compared to the mass of the car is quite negligible).
The main rectangular solid's behaviour would follow the standard dynamics of a single rigid body in space (Newton, Euler), with the addition of the forces exerted on it by the four wheels (these would be considered "external forces" on the main body). The most notable case when these extra forces would come into play would be when the car would be standing on all four wheels, and the shocks would be keeping the car up by pushing up.
Furthermore, the force of the shocks would not be the only force being exerted at each axel point, where the wheel was attached; there would also be the force of friction being exerted on the wheel, which then be propagated onto the main car body.
The representation of the force of friction in the system of linear equations right away posed a problem since friction is strictly speaking non-linear (ok, it is piecewise linear, but that's not good enough when you have to put something in the matrix). The idea I had at this point would be to have each wheel be in a certain "mode" (airborne, static friction, kinetic friction). After each time step, the code would check and update this mode, if possible. For example, if a wheel was in static mode, then the equations reflected the idea that the ground would exert any force necessary to keep the wheel from sliding, and THEN at the end of the time step, it would check whether the force that was actually exerted by the ground did not pass the "myu_s*F_normal" threshold. If they did, then the mode of the wheel would be changed to kinetic, and that particular model would be used in the next time step. This little trick assumes that the time steps are small enough such that at the point when the friction changes from static to kinetic, the threshold is passed by a very small amount, so that the simulation does not diverge from reality too much. (ie. if you had a 1 kg box sitting on the ground, it is assumed that the time steps are small enough such that you don't end up having the ground exert a resisting force of 10000N before it is changed to kinetic mode in the next time step).
Also, from the above discussion it became apparent that we will need to know what the normal force exerted into the ground is in order to calculate kinetic friction as well as the static friction threshold. For that purpose I introduced four unknows called F1down, F2down, F3down, and F4down, each of which represents the downward force into the ground at each of the wheels, and these would get solved for (as well as further used) in the system of linear equations.
Finally, it came to my attention that the above model still would have trouble imitating certain situation correctly, such as when three of the wheels were driving forward while the last wheel had the brakes engaged. Obviously in real life that wheel would have further force exerted by the ground on it to keep it from sliding, if possible. Hence in my calculations for force exerted by the ground I would also have to consider the force being exerted on this wheel by the pull of the other wheels (when in static friction mode). For this, further unknowns were introduced (F1on, F2on, F3on, F4on).
| The problem with pseudo-separate wheels |
Well, right of the top the initial design was doomed as I later found out. After simulation with the initial design it became painfully obvious that one cannot treat the wheels half the time as seperate objects, and half the time as integral parts of the car solid itself.
My inital calculations/equations for the static friction force consisted of two components: those in response to gravity and those in response to the F?on forces (forces exerted on this wheel by the other wheels).
For the static friction response to gravity, my inital plan was to for each wheel break up that force into two components: a component which goes from cars center of mass towards the wheel, and any remaining component (this I essentially considered to be torque with respect to the wheel). The ground would resist the horizontal component of the "center of mass to wheel" component of gravity. Torque about wheel didn't matter. (Notice that this is where the "seperate object/integral object" problem starts manifesting itself: by projecting gravity towards the wheel I am tacitly assuming that it is a separate object, with a seperate free-body diagram...)
For the static friction response to forces exerted by the other wheels, I thought that the wheel the wheel in consideration (and under static friction) would resist the pull of the other wheels (which I calculated as the component of the net force at each of the other wheels in the direction of the wheel which I was dealing with). Using net force was not a brilliant idea because right away at the first simulation I noticed strange things happening such as: wheel 1 is trying to resist gravity which is pulling it down a slope, but wheel 2, which is also in static friction would see that force as a challenge to its own static friction condition and would pull right back (in tune with gravity). In the end you had a car which the wheels were trying very hard to rip apart... :)
I realized here that the more appropriate way to proceed would be not to consider the net force, but only the forces non-related to gravity (that of propulsion and braking).
I also became aware at that point that this is not at all the way to proceed, as there is at least one case which is unsolvable by this setup: a car which has the two wheels in propulsion mode (the ground exerts a forward force on them), while the other two wheels having the brakes engaged. In theory all four wheels start in static mode, but in reality, some or all of them enter kinetic friction mode. In my model there is no provision for that. That time step, before the switch to another friction mode is detected, has no solution since it is impossible to satisfy all four requirements for zero slip at each wheel (in that particular single time step).
| Even worse problems with simple friction |
At this point I started doubting and questioning the physics of friction. I was really getting perplexed by even the simplest stuff now: while poring through my undergrad physics behemoth texts, I encountered the ever familiar free body diagram of a block on an incline. You have a block sitting on a slope. There are two forces at play: gravity and static friction. The gravity pulls straight down, and this can be split up into two components: a component pushing perpendicularly into the slope surface, and a component parallel to the same surface. The static friction force pulls the block equally hard but in the reverse direction to the parallel component mentioned above. This last force is being exerted at the junction of the two surfaces (incline and block) and is usually depicted smack in the middle of that junction. This totally perplexed me now since, as drawn, that force of friction constitutes pure torque about the block's center of mass (there is no "towards the COM" component of the friction force). Whoa, what's going on here.
After I considered reality later on I came to solution that each of the finite surface elements on the block at the junction is exerting this friction force, and for most of these there is a component through the COM. To make a long story short, the answer is that this friction is exerting an equal and opposite force, but this opposite force is through the COM of the block (it should be drawn through the COM and opposite to gravity's parallel component), and is not equal to the infinite number of subforces being actually physically exerted at the junction ( as these provide the opposite force through the COM, AS WELL AS torque about COM). But I'm starting to babble... ;-)
| You thought that was bad... Look at this |
Following the trying period of sorting out all this mess in my head, I've adopted the idea that the wheels are strictly integral parts of the car (although they do not add any more mass; see previous argument regarding this).
To counter gravity I've adopted the idea that each wheel handles 1/4 of the parallel component of gravity of the car (see a couple section down for the rationale ). In essence I would calculate the parallel pull of gravity, create an opposite (static friction) force, and split it into quarters, letting each wheel handle a piece. This again, later I would find out with some thought experiments, is not a good solution (consider a car with only three wheels in static friction; split the opposite force into three? but the remaining wheel, in kinetic friction, is also exerting SOME forces; do these matter?). This became less important later, as the reader will see.
| What about just rolling down a hill? |
One day as I was sitting over this, I had one of those unwelcome "moments of clear sight". :) What I was doing is not correct. What about if I put a car in neutral on a hill? It should roll down. In all the static friction thought so far I assumed it was going to resist any and every force. That is not so. The theoretical fix was easy though. It is just a matter of converting everything so far to the idea that static friction is only exerted to the sides of the wheels direction. Any force that is pulling in the same direction as that in which the wheel is pointing should be allow to do so (this will start and keep the car rolling). The model we had so far was proper of a wheel with its breaks engaged (a topic I did not delve into too deeply, as I haven't made as much progress as I initially anticipated).
| The "Death Blow" |
Ok, now we come to the clincher, which should have been obvious from the VERY beginning, but which I did not realize. In theory, all the above is/should/could/might be correct in the real world [ now I question everything! ;-) ], but it has one major flaw when you are talking simulations: in any discrete time step approximation to the continuous (as far as we know) time flow of reality we are bound to pick up slight errors here and there, especially when you factor in that we are using (very)finite precision math, and top it off with the fact that we use integration to get some of the results, as well as the other fact that our solution at each time step depends on the results of the previous iteration. So it is VERY conceivable that our object might, say, pick up a transient minute velocity in some arbitrary direction. But, that should not matter, right? NOPE. Newton kicks in here, with his law: "a thing will keep doing whatever it is doing, unless some net force acts on it" (to put it tersely). If you have a car parked on an slope (all the forces on it balance, there is no net force), which has somehow picked up a slight drift velocity, it is going to KEEP DRIFTING. That is most certainly what we do not want.
The solution to this would be to express the consequences of static friction by way of specifying that any wheel in static friction should have zero velocity with respect to the ground (I am of course referring here to the wheel patch in contact with the ground, not the whole wheel object itself). It is at this point that I now find myself. Further work would involve back tracking in the design, and reworking the system of linear equations to employ this different constraint. This would involve still some considerable work.
| Why not seperate rigid-body wheels then? |
Anyone might at this point ask the question: "Why not just then use seperate rigid-body wheels? Wouldn't it be much simpler? It seems all these complications arose from the fact that we are using a simplified model of the real thing, and because of that, we have to come up with these kludges which attempt to bring the simulation in line with reality, but which only cause more problems?" The short and sweet answer is "no, unless you have a Cray or Reality Engine". The number one criterion for the project was reasonable speed (just judging by the speed of the two rigid body assignment in class I was well aware that this sucker would be slow). I think in terms of the number of equations one would have the same if not more, with more rigid bodies (the constraints that keep the wheels attached to the car). Not to mention that that approach would have be palgued by its own unique set of problems (keeping the two blocks attached in the two-rigid body sim was hard enough; now we are talking five objects!!! Yow!). Furthermore, any solution to these drift problems would unavoidably involve throwing more equations into the system of linear eq'ns. On the whole, I think that approach would be MUCH slower.
| Weight distribution on the wheels |
In all the stages of the sim I was constantly plagued by the question: "how is the weight of the car distributed among the four wheels?". Well one day I hit on the solution of a 1/4 each (ok, it's more of an approximation, not a fulproof solution). The rationale goes something like this: consider a car on an incline. It has "mg" acting on its COM, straight downwards. This can be split up into two components: one perpendicular to the incline surface, and whatever remains. Now, having drawn the free body diagram on a piece of paper, rotate that piece of paper so that the incline surface is horizontal. From the car's frame of reference, it is being pulled straight down, and sideways. The perpendicular component is pushing the car straight into the incline, so each wheel supports a 1/4 of that force (much like a car parked on a flat piece of land). Of the sideays force, each wheel also (more or less) handles a quarter. This is actually just an approximation. On top of that quarter one must consider the torque about the car's center of mass which presses the downhill wheels further into the ground, while unloading the uphill wheels. But this torque, as far as the shape of normal cars is concerned: usually wider than taller, is for the most part perpendicular to the surface, so if we were concerned only with sideways component of gravity (as we were when we pondered this question; we were trying to determine this in order to figure out static friction reactive force), this would be "close-enough" approximation.
| "System of Linear Equations": SLE queries |
As might be very apparent, any specific mention of the actual equations being used (in mathematical form at least) is quite ostensibly missing from this document. For a very good reason: for the past week before the deadline it has undergone numerous alterations, on a daily basis, in my final (desperate :) attempts to resurrect the code and have it do more useful stuff (now that I have discovered/"finally stumbled on" the problems of static friction). BTW, only the brave should read the code now... it probably resembles something out of Micro$oft. Should you have an inclination discuss some of these equations, please email me freely.
In the program I have provided an interactive method of examining the numerical values of the system of linear equations, mostly for debugging purposes. Since whoever looks at the program might find it interesting/educational/entertaining, or just can't figure how to get the sim going, I have included here a quick blurb on using and bypassing the query prompt.
Whenever you start the simulation (press the Start button), in the xterm from which the program was started there will be a print out of the "b" and "A" matrix (each spot actually represents a 3x3 of the actual matrix; a blank represents that the whole 3x3 is 0s, while an "x" or "b" indicates that there is some non-zero values there). This comes up at each time step and is followed by a prompt. The choices here are:
| MPEGs |
You'll have to pardon the poor quality of these. I had to recompile my mpeg_encode from new source and don't seem to have ironed out all the wrinkles yet. I think it has something to do with too high a compression/loss ration...
drop.mpg Here you have the very basic test of the shocks
A number of things you might notice; the wheels sink into the ground and the whole body hangs quite low. Well, the body is quite low since the Kp, Kd constants on the shocks are not strong enough, but I chose against upping them since the DtSim would have to be made appropriately smaller. The wheels sinking into the ground: actually this just needs a little bit of code added that would push up the wheels to be just on the surface. The proper way of thinking about the car is that the body has attached to each axel end a vertical spring/shock, and the wheel is simply attached to the other end of that spring. Initially I did not foresee the sinking hence the display code is using the naive concept of wheels directly attached to body. It's on the todolist, but lower than "fixing static friction".
over_thrust.mpg Whoa!!!
This is just a little demo of what happens when you put too much torque on the back wheels. Just wanted to see the "transfer of mass" effect. Kind of hard to judge whether it is there or not. (Gotta fix that @#@%@^ static friction...)
incline.mpg Bad, bad car!!!!
Visual display of exactly just what is wrong with the simulation right now. You are looking at a "theoretically-parked" car on an incline.
| Source |
Get the source code:
indy.tar.gz
| Be warned though: this program is using rather slow code for solving of linear equations, hence it crawls on most computers. The only platforms that the code has been run that were producing acceptable frame rates (5-10fps), was a Pentium II-266 and an Indigo2 IMPACT. Anything less will probably put you to sleep. |
Notes on the version of indy.tar.gz that you have just downloaded:
| Future work [ and there's lots needed... ;) ] |
 |
|