Car physics; inverse kinematics for suspensions

Hi all, First of all, thanks to Gregor/Todd/Doug for the info about instant centers a week or so ago. I'm looking into the kinematics of suspensions. Ultimately ofcourse, I'd like to describe it as a series of rods, and be done with it. So let's start from 5 rods. It doesn't seem that drastic, intuitively, to reduce the problem of the path that they describe, in 2 dimensions; front and side views. I've been scribbling a bit, and you could describe the rod endpoint (at the wheel) as a line (p0,p1): p0 = start point at the chassis p1 = end point at the wheel p1.x = cos(a+a0)*r p1.y = sin(a+a0)*r Where a0 is the static angle (when the suspension is in rest), and 'a' is the added angle that changes when the wheel goes up or down. Now suppose you have another rod, q, with the same type of description. When the wheel moves, and p1 moves along to p1', I start wondering how to find q1' (the new, moved q1). A constraint I see is that distance(p1,q1) remains constant. Writing this out gives a bunch of cos() and sin() arguments that seems hard to solve. Here's a nice Courier/fixed ASCII drawing: q0 o----o q1 |(chassis) | (wheel side) | p0 o------o p1 <- r -> Does anybody have a clue/hint as to a perhaps workable way to find q1'? The sin/cos mess doesn't seem solvable, actually. The above picture does look like an inverse kinematics thing. Does anybody do this in 2x 2D (front/side) already? Or would solving in 3D be a lot better? (although that would mean having 5 links at the same time, which is much more costly). Any eye-openers appreciated. ;-) Thanks, Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

Remember in maths at school when you had to draw two circles around two points to find the intersection points? Exactly the same idea here. One thing to remember is that this method will give you 2 points, one of which will be blatantly wrong and can safely be ignored :-) P0 is the center of one circle, radius r0. P1 is the center of the other circle, radius r1. P3 is/are the intersect point(s). P2 is defined as lying on the line P0 -> P1, as the midpoint of the overlapping region of the two circles. It can be found by simply subtracting one quarter of the overlap value from either of the circles' radius. a is P0 to P2, and b is P1 to P2. h is the distance from P2 to P3. If you can't visualise this then I will draw up a picture. a, b, P0, P2, P2, d all lie along the same line (P0 -> P1). d = a + b. First calculate the distance d between the center of the circles. d = || P1 - P0 ||. If d > r0 + r1 then there are no solutions, the circles are separate. Also, if d < || r0 - r1 || then there are no solutions because one circle is contained within the other. Considering the two triangles P0P2P3 and P1P2P3 we can write a2 + h2 = r02 and b2 + h2 = r12 Using d = a + b we can solve for a, a = (r02 - r12 + d2 ) / (2 d) It can be readily shown that this reduces to r0 when the two circles touch at one point, ie: d = r0 + r1 Solve for h by substituting a into the first equation, h2 = r02 - a2 So P2 = P0 + a ( P1 - P0 ) / d And finally, P3 = (x3,y3) is x3 = x2 +- h ( y1 - y0 ) / d y3 = y2 -+ h ( x1 - x0 ) / d

I have just re-read that, and it is quite confusing, so try this link: http://astronomy.swin.edu.au/~pbourke/geometry/2circle/ It doesn't help when copy paste converts r0 ^ 2 (r0 * r0) into r02 all over the place... Nick.

> It doesn't help when copy paste converts r0 ^ 2 (r0 * r0) into r02 allover > the place... Ah, close enough. It's just math innit? :)

Yeah, you got that right. If you can code a sim, you can figure out random equations... :-)

If your initial guess is close enough to the final solution, you might be able to use the "Solver" add on in MS Excel to do a multi-variable non-linear minimization to solve the constraints. Other than that, you could also buy one of the many software programs that do this. They are in the hunreds of dollars. Pass the plate? ;) - Matt

On Thu, 16 May 2002 19:40:40 GMT, "Rob Adams" <[email hidden]> wrote: >> It doesn't help when copy paste converts r0 ^ 2 (r0 * r0) into r02 all >over >> the place... Thanks Nick; I'll read the stuff over the weekend. Yesterday I also found a way using a 2-link IK solution. Some acos() and atan() calls in there, but should work. Only problem is how to define a generalized coordinate with all that. It all moves everywhere! ;-) I'll get back on this later, gotta run... Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

On Fri, 17 May 2002 13:48:50 GMT, Ruud van Gaal <[email hidden]> wrote: > Yesterday I also found a way using a 2-link IK solution. Some acos() > and atan() calls in there, but should work. Only problem is how to Probably carrying coals to Newcastle here, but it's a good idea to create a table / array of pre-calculated values on program launch so these cpu-intensive functions don't have to be called 500 times a second ;-) Cheers, Uwe -- Uwe Schuerkamp //////////////////////////// http://www.schuerkamp.de/ Herford, Germany \\\\\\\\\\\\\\\\\\\\\\\\\\ (52.0N/8.5E) PGP Fingerprint: 2E 13 20 22 9A 3F 63 7F 67 6F E9 B1 A8 36 A4 61

> Thanks Nick; I'll read the stuff over the weekend. > Yesterday I also found a way using a 2-link IK solution. Some acos() > and atan() calls in there, but should work. Only problem is how to > define a generalized coordinate with all that. It all moves > everywhere! ;-) I only suggested using the circular method because setting up the IK is pretty complex to use just for a 2D solution with 2 arms. It's kinda like buying a GeForce 4 to play Solitaire :-). Oh yeah, please don't read my first mail, check the website instead. When I was looking for that problem (on a totally unrelated project), I found that web page and copied the text, and it copied all the powers fine as well. But when I copy it into an email it screws up, so I went and found the original web page instead. Shouldn't try to take credit for somebody else's work anyway.... In 3D though (which I have no doubt you will end up using), an IK oriented solution is the only one really useful in a realtime environment. Especially as you will be calculating (usually) 4 times per car, times (say) 20 cars on the racetrack every frame. I never really thought about my solution being IK, but having looked at 3D Studio MAX and a couple of web pages on the subject, I realise I could have saved myself a whole bunch of work :-( Nick.

Here's something sort of cheesy you could try if you don't want to solve it analytically--make a little 5-bar linkage using a spring-damper-pointmass mesh--you should be able to get it stiff enough to not deform when there are only minimal forces applied to it--then grab one of the points on the spindle and drag it to several points, and record the path of the hub (position, camber, castor), then just slap some sort of tabular or polynomial fit to the set! If your hub position function looks like p(s) = <x,y,z> where s is the parameter of suspension movement, you could also use dp/ds to help apply the forces between the wheel and body. Of course it starts to get a little hairy with live-axle type rear suspensions, and you end up with something like p1(r,s) and p2(r,s) "Ruud van Gaal" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (53 lines)

> Hi all, > > First of all, thanks to Gregor/Todd/Doug for the info about instant > centers a week or so ago. > > I'm looking into the kinematics of suspensions. Ultimately ofcourse, > I'd like to describe it as a series of rods, and be done with it. > > So let's start from 5 rods. It doesn't seem that drastic, intuitively, > to reduce the problem of the path that they describe, in 2 dimensions; > front and side views. > > I've been scribbling a bit, and you could describe the rod endpoint > (at the wheel) as a line (p0,p1): > p0 = start point at the chassis > p1 = end point at the wheel > p1.x = cos(a+a0)*r > p1.y = sin(a+a0)*r > > Where a0 is the static angle (when the suspension is in rest), and 'a' > is the added angle that changes when the wheel goes up or down. > > Now suppose you have another rod, q, with the same type of > description. When the wheel moves, and p1 moves along to p1', I start > wondering how to find q1' (the new, moved q1). > A constraint I see is that distance(p1,q1) remains constant. Writing > this out gives a bunch of cos() and sin() arguments that seems hard to > solve. > > Here's a nice Courier/fixed ASCII drawing: > > q0 o----o q1 > | > (chassis) | (wheel side) > | > p0 o------o p1 > <- r -> > > Does anybody have a clue/hint as to a perhaps workable way to find > q1'? The sin/cos mess doesn't seem solvable, actually. > > The above picture does look like an inverse kinematics thing. Does > anybody do this in 2x 2D (front/side) already? Or would solving in 3D > be a lot better? (although that would mean having 5 links at the same > time, which is much more costly). > > Any eye-openers appreciated. ;-) > > Thanks, > > Ruud van Gaal > Free car sim: http://www.racer.nl/ > Pencil art : http://www.marketgraph.nl/gallery/

Hey, hasn't anyone been listening? Or have my posts been going to the old bit bucket<grin>?? Olley solved this stuff with some neat approximations (and then worked examples with a slide-rule) over 40 years ago...and now we have pulled it all together for your analytic pleasure. http://www.millikenresearch.com/olley.html ----------- On Mon, 20 May 2002, Dave Pollatsek wrote:

Quoted text (71 lines)

> Here's something sort of cheesy you could try if you don't want to solve it > analytically--make a little 5-bar linkage using a spring-damper-pointmass > mesh--you should be able to get it stiff enough to not deform when there are > only minimal forces applied to it--then grab one of the points on the > spindle and drag it to several points, and record the path of the hub > (position, camber, castor), then just slap some sort of tabular or > polynomial fit to the set! If your hub position function looks like p(s) = > <x,y,z> where s is the parameter of suspension movement, you could also use > dp/ds to help apply the forces between the wheel and body. Of course it > starts to get a little hairy with live-axle type rear suspensions, and you > end up with something like p1(r,s) and p2(r,s) > > "Ruud van Gaal" <[email hidden]> wrote in message > news:[email hidden]... > > Hi all, > > > > First of all, thanks to Gregor/Todd/Doug for the info about instant > > centers a week or so ago. > > > > I'm looking into the kinematics of suspensions. Ultimately ofcourse, > > I'd like to describe it as a series of rods, and be done with it. > > > > So let's start from 5 rods. It doesn't seem that drastic, intuitively, > > to reduce the problem of the path that they describe, in 2 dimensions; > > front and side views. > > > > I've been scribbling a bit, and you could describe the rod endpoint > > (at the wheel) as a line (p0,p1): > > p0 = start point at the chassis > > p1 = end point at the wheel > > p1.x = cos(a+a0)*r > > p1.y = sin(a+a0)*r > > > > Where a0 is the static angle (when the suspension is in rest), and 'a' > > is the added angle that changes when the wheel goes up or down. > > > > Now suppose you have another rod, q, with the same type of > > description. When the wheel moves, and p1 moves along to p1', I start > > wondering how to find q1' (the new, moved q1). > > A constraint I see is that distance(p1,q1) remains constant. Writing > > this out gives a bunch of cos() and sin() arguments that seems hard to > > solve. > > > > Here's a nice Courier/fixed ASCII drawing: > > > > q0 o----o q1 > > | > > (chassis) | (wheel side) > > | > > p0 o------o p1 > > <- r -> > > > > Does anybody have a clue/hint as to a perhaps workable way to find > > q1'? The sin/cos mess doesn't seem solvable, actually. > > > > The above picture does look like an inverse kinematics thing. Does > > anybody do this in 2x 2D (front/side) already? Or would solving in 3D > > be a lot better? (although that would mean having 5 links at the same > > time, which is much more costly). > > > > Any eye-openers appreciated. ;-) > > > > Thanks, > > > > Ruud van Gaal > > Free car sim: http://www.racer.nl/ > > Pencil art : http://www.marketgraph.nl/gallery/ > > > >

On Tue, 21 May 2002 00:21:49 GMT, Doug Milliken <[email hidden]> wrote: > >Hey, hasn't anyone been listening? Or have my posts been going >to the old bit bucket<grin>?? Hehe. Actually I've hinted to whether the Olley book would be useful for this type of thing some posts ago. :) Thanks for confirming it though. Just ordered it now; seems I have to jump to suspension geometry bandwagon. (already have John Dixons book which still will be good to read). The thing seems to be that you can do suspension geometry in a million ways; many ways of which are simplified but very useful still. The idea is to get the definition right (for the users/creators of the suspension geometry) and always be able to switch to a different implementation when you feel like it's raining too much outside. ;-) >Olley solved this stuff with some neat approximations (and then worked >examples with a slide-rule) over 40 years ago...and now we have pulled >it all together for your analytic pleasure. > >http://www.millikenresearch.com/olley.html Got it. Too bad shipping costs are a bit high from the US (tried Amazon in the UK but they didn't have it yet). Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

On Fri, 17 May 2002 23:26:28 +0200, Uwe Schuerkamp <[email hidden]> wrote:

Quoted text (8 lines)

>On Fri, 17 May 2002 13:48:50 GMT, Ruud van Gaal <[email hidden]> wrote: >> Yesterday I also found a way using a 2-link IK solution. Some acos() >> and atan() calls in there, but should work. Only problem is how to > >Probably carrying coals to Newcastle here, but it's a good idea >to create a table / array of pre-calculated values on program >launch so these cpu-intensive functions don't have to be called >500 times a second ;-)

Welcome to 2002, Uwe. ;-) Windows XP is CPU-intensive, acos() isn't anymore, lol. But still, indeed, 500 times/sec times 4 suspension times 20 cars... Hmm. Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

On Tue, 21 May 2002, Ruud van Gaal wrote: > On Tue, 21 May 2002 00:21:49 GMT, Doug Milliken <[email hidden]> wrote: > >Hey, hasn't anyone been listening? Or have my posts been going > >to the old bit bucket<grin>?? > Hehe. Actually I've hinted to whether the Olley book would be useful > for this type of thing some posts ago. :) Thanks for confirming it We just posted a new book review with permission from the Rolls-Royce Owner's Club: http://www.millikenresearch.com/olleyfl.html > Got it. Too bad shipping costs are a bit high from the US (tried > Amazon in the UK but they didn't have it yet). Chassis Design is also being sold by the IMechE in England -- they might have cheaper shipping to Europe (but the basic price might be higher...)