Saturday, December 4, 2010

Lap sim - you down with O.D.E.?

Yeah you know me! Actually, truth be told, by the time I took Differential Equations & Linear Algebra (APPM2360? I don't remember) I was so burned out on applied math that I retained pretty much nothing. Additionally, that was probably Fall '04 semester so it's been a while.

Before we get into specifics of writing out ODE's, let's think out loud on how the hell I'm even going to get this to work. Invariably the first thing to do is establish some assumptions. Whenever you're doing any sort of simulation or model or whatever, you are not recreating reality. Get that notion out of your head, forever. You are creating your own abstraction of reality with whatever physical laws, rules, and limitations as you see fit. These might be based on lack of necessary data (e.g. tire data), lack of the skill set to make something really fancy (e.g. me when I was in college), or constraints of time and money (e.g. running a simulation on a laptop rather than a cluster, or desk side supercomputer - badass!).

Here's what I'm thinking as far as assumptions:
  • Point model - no kinematics, tire data, load transfer, or anything of the sort.
  • Mass fixed at 1000 lb (at least initially, may evaluate being over minimum weight)
  • Forward thrust available from the engine at a constant power - i.e. inversely proportional to velocity.
  • All cornering done at constant velocity and radius - at max lateral capacity
  • All acceleration and braking done in a straight line
  • No rolling resistance effects
  • Downforce and aerodynamic drag proportional to the square of velocity
  • Mechanical grip (coefficient of friction) values in x- and y- directions held constant. Down the road, it would be interesting to do a sensitivity study and do a number of sim runs, altering the grip level of one corner at a time. Goal - determine which corner has the biggest impact on lap time, and focus steering and balance tuning toward that corner.
As far as how the thing would actually work... first step would be to run through and establish the maximum speed each corner can be taken. Pretty straight forward. The second and much more difficult step essentially comes down to finding the braking point (if there is one) on every straightaway. Haven't entirely figured out the specifics, but roughly:
  1. Pick some arbitrary initial guess for length of braking zone on this particular straight
  2. Use the initial velocity of the on-throttle portion from the previous corner
  3. Run ODE solver over the length of the on-throttle portion to establish a velocity trace
  4. Use the final velocity from on-throttle as the initial velocity of the braking portion
  5. Run ODE solver over the length of the braking portion to establish its velocity trace
  6. Use some sort of goal seek, objective function, or incremental loop to work the braking point backward until the final braking velocity is at or below the next max corner speed. Need to be as close to it as possible really.
For that last step, the incremental 'while' loop backing the braking point up a little bit at a time is probably the 'dumbest' approach in being computationally inefficient, but also the easiest to program.

So we come to the actual governing ODE's themselves...

On acceleration:

On the brakes:
Bam! Easy, assuming I remember anything from sophomore year. There have been many beers consumed between then and now (including a few at lunch today). I'd probably be a halfway intelligent guy if I hadn't drank like hell my last couple years in college!

Anyway. Now comes the hard part... actually making it work in code.

5 comments:

Unknown said...

Maybe I missed something, but in the second line of your braking equations shouldn't the braking force and aerodynamic force have the same sign?

Also, as far as ODEs go... Simulink makes it easy. Assuming you have access, I would check out some of the simple mass-spring-damper type tutorials and adapt them to your equations.

Unknown said...

Should have looked closer the first time... seems you do have the correct sign in the third line.

Jersey Tom said...

Yeah after I posted it I realized I should have kept the sign same with it written out in English, but it's mathematically correct at least.

Simulink does make the layout of things easy but does have some quirks of its own. I think in this case it's just as easy to code through text and use a canned solver - especially in that the ODE's can become fairly complex functions.

Andres said...

I know you like odes, but don't you like the way simulink solves them easily? You could have your point model done in less than a couple of hours.

Just ask if you need help in matlab/simulink

Jersey Tom said...

As I was mentioning with Stephen.. yes.. Simulink is nice for certain things, particularly fairly straightforward LTI's. I used it fairly extensively in college for a systems class and some rudimentary modeling in FSAE.

I do think it's a bit easier to write out complex expressions by hand than having to drag in all the different gain and addition and whatever else blocks.

In any event the whole lap sim only really took 4-8 hours to put together, and as I started addition extra functionality to it I'm glad I stuck with doing it purely through code. Another reason for doing it that way is making it very easy to do integration over a distance interval than time - which is key in this application.