Hi all,
To get a clearer progress on car editing, I'm trying to get my sim to
use the GPL-type cars. This will make comparisons easier so searching
for faults in the physics is easier.
As always, differentials are not really my piece of cake, but well.
I'm trying to come up with a nice pipeline'd tree structure which
describes the driveline, like:
E
| clutch (not really a component)
| G
| CD
/ \
FD RD
/ \ / \
FL FR RL RR
Where E=engine, G=gearbox, CD=central differential, FD/RD=front/rear
diff, FL/FR/RL/RR=frontleft upto rear-right wheels.
The idea is still to be worked out completely, but I have a hunch that
I start a torque flow at the top (the engine) down to the bottom, add
input from below (road reaction and braking forces) and after all
that, I calculate results using something like:
acceleration=totalTorque/(inertiaUpstream+inertiaDownstream)
Where ofcourse I'll meet problems probably that braking torques don't
really behave like applied torques, but as potentially applied torques
(so I don't think I can just add braking torques to the whole system).
Don't know yet how to tackle that (some time ago some discussions were
done about locking axles when braking was applied; like a lock mask
for each diff; formulas get really complex if you want a closed form
for a 3 diff car).
The above btw is for a rally car with 3 diffs, and the GPL cars
ofcourse have only 1 diff. The differential is, so far I know, a
Salisbury one. Which means clutches. Now, let's throw in some points:
- Each clutch has a certain maximum torque it can generate; this is
much like a brake (in that it only generates torque when requested
to). Right?
- How much Nm (torque) could a clutch approximately generate, or is
this somehow calculatable from GPL's settings.
- When the diff actually starts slipping (when the torque bias ratio
is crossed), can I assume the clutch will counter with exactly its
maximum torque (i.e. just like static and dynamic friction, IF the
clutch starts slipping, won't its locking torque diminish by half for
example; the same if you push a cupboard; once it starts sliding, it
is much easier to keep it sliding).
- I have a formula which seems to give the torque bias ratio;
cos(angle)*(1+clutches). Clutches come in pairs. You have 2 angles in
GPL; power on and power off (engine braking).
So for 2 clutches and 30 degree angles, you get cos(30)*(1+2)=2.598.
Would it be right if I took this as the torque bias ratio? I'm not too
sure namely.
So I would keep the diff locked until the torque bias ratio (and
preload) is overcome, then start unlocking, where the clutches keep on
generating their maximum torque to try and keep both wheels rotating
at the same speed. Not too sure if this is what the diff does, since a
diff is said to 'open up' at high torque differences, and this seems
more like a brake which can only apply so much torque. At its limit,
it just keeps trying to lock the axle with its maximum available
torque.
Thanks for any comments on this,
Ruud van Gaal
Free car sim : http://www.marketgraph.nl/gallery/racer/
Pencil art : http://www.marketgraph.nl/gallery/
My view is that thinking of it as a "Torque Flow"
may lead to problems. It is really a "Torque Quagmire" ;)
from which there is one correct slow and hidden stream
of brackish water meandering out of.
In other words, the torque doesn't flow until after you've
solved the particular equations of motion for your current
situation. And to do that, you have to look at the situation
as a whole. So as seductive as object oriented philosophy is
in this physical problem with well defined objects... the
utility is limited, because some object has to coordinate them
all. To do that, it has to know almost everything about the
internals of each object.
--
Matthew V. Jessick Motorsims
[email hidden] http://www.moto1.net
Vehicle Dynamics Engineer (972)910-8866 Ext.125, Fax: (972)910-8216
Very well put, Matt, I certainly couldn't have put it better myself!
Although, as long as inertias of all wheel assemblies are the same, the
proposed approach could work; I'm still checking it out (so little spare
time!), but I thing that it should turn out OK (as long as the wheels
aren't locked).
-Gregor
mjessick-Motorsims wrote:
Quoted text (19 lines)
> > My view is that thinking of it as a "Torque Flow" > may lead to problems. It is really a "Torque Quagmire" ;) > from which there is one correct slow and hidden stream > of brackish water meandering out of. > > In other words, the torque doesn't flow until after you've > solved the particular equations of motion for your current > situation. And to do that, you have to look at the situation > as a whole. So as seductive as object oriented philosophy is > in this physical problem with well defined objects... the > utility is limited, because some object has to coordinate them > all. To do that, it has to know almost everything about the > internals of each object. > > -- > Matthew V. Jessick Motorsims > [email hidden] http://www.moto1.net > Vehicle Dynamics Engineer (972)910-8866 Ext.125, Fax: (972)910-8216On Fri, 12 Oct 2001 13:32:45 GMT, mjessick-Motorsims
<[email hidden]> wrote:
>My view is that thinking of it as a "Torque Flow"
>may lead to problems. It is really a "Torque Quagmire" ;)
>from which there is one correct slow and hidden stream
>of brackish water meandering out of.
Hm, not a pretty foresight. ;-)
Sounds too bad. You would say in real life all the objects are
themselves unaware of all the surrounding objects, so it would map
somehow to programming objects as well.
Ok, I'm warned, perhaps Gregor can work out a subscenario that works.
Thanks,
Ruud van Gaal
Free car sim : http://www.marketgraph.nl/gallery/racer/
Pencil art : http://www.marketgraph.nl/gallery/
Quoted text (8 lines)
>In other words, the torque doesn't flow until after you've >solved the particular equations of motion for your current >situation. And to do that, you have to look at the situation >as a whole. So as seductive as object oriented philosophy is >in this physical problem with well defined objects... the >utility is limited, because some object has to coordinate them >all. To do that, it has to know almost everything about the >internals of each object.
> Sounds too bad. You would say in real life all the objects are
> themselves unaware of all the surrounding objects, so it would map
> somehow to programming objects as well.
> Ok, I'm warned, perhaps Gregor can work out a subscenario that works.
You can still do Object Oriented design. But because of the tight
coupling you lose many of the more powerful benefits.
Usually for real time simulations one ignores
very high frequency transients in favor of assuming
a quasi-static scenario. We ignore stuff like the
"play" between two gears and exactly how the teeth
bounce back and forth or bend each other.
When you slam a car into gear, all the parts of the
drive train give a mightly lurch and at very high
frequency they all affect each other and come
to a concensus ;) about how fast to accelerate.
All this very high frequency colliding and scraping is
what lets the real life engine ignore what the surface
characteristics under the left driving wheel are.
In the real time simulation we usually say:
"OK, I'm going to ignore the colliding and sliding:
just give me your best guess at what the "steady state" result
a millisec or so after the very short transient following my
control step."
But to do this you need to write equations to solve for
all the variables that characterize the steady state
condition. Because the surface to tire friction
characteristics affect the steady state solution,
they have to be included in the equations and thereby
affect the engine acceleration.
In real life, the parts just nearly instantly
BangBang.Bang scrape ..scrape... hhhhuuuummmmmmmmmmmmmm ;)
their way to the new steady state condition without
being directly affected by any parts that aren't directly
in contact with them.
The real time function that is doing the coordinating
(solving the equations of motion) has to ask pretty much
every object along the entire drive train for a large
amount of detailed infomation before the equations of
motion for the engine acceleration (and most everything
else and at the same time, unfortunately ;) can be written
and solved.
Until the engine acceleration is known, the engine
output to the clutch isn't known precisely, because
a significant part of the engine power is used to
accelerate the various rotating pieces of the engine.
And so on down the entire drive train.
This is why the software objects are so tightly
coupled. You can't really distribute significant
amounts of important processing down to the objects
like you can for a User Interface, for example.
--
Matthew V. Jessick Motorsims
[email hidden] http://www.moto1.net
Vehicle Dynamics Engineer (972)910-8866 Ext.125, Fax: (972)910-8216
>- Each clutch has a certain maximum torque it can generate; this is
>much like a brake (in that it only generates torque when requested
>to). Right?
>- How much Nm (torque) could a clutch approximately generate, or is
>this somehow calculatable from GPL's settings.
It's really unlimited. The ramps are pressed together according to how hard
the two ends are twisted. If the *ratio* goes beyond the maximum allowable,
then it'll slip. It's wierd, but that's how it works.
I don't think you need to account for differences between static and dynamic
friction in the clutch. If the torque bias ratio is exceeded, the excess,
remaining torque accelerates the wheels away from each other. If they're at
different velocities but not exceeding the max torque bias ratio, the "current
bias ratio" (not the maximum value you're talking about here) provides the
amount of torque that accelerates the wheels towards locking.
>- I have a formula which seems to give the torque bias ratio;
>cos(angle)*(1+clutches). Clutches come in pairs. You have 2 angles in
>GPL; power on and power off (engine braking).
>So for 2 clutches and 30 degree angles, you get cos(30)*(1+2)=2.598.
>Would it be right if I took this as the torque bias ratio? I'm not too
>sure namely.
Cool. I'll have to try that out :-) I don't think this is right though, as
the friction coefficient of the clutches ought to have something to do with it
too. Perhaps something like:
cos(angle)*(1+clutches * friction_coefficient) ?
Actually, it's probably dependent on the total clutch area rather than the
number of clutches, but the formula you're using gives really good numbers. I
recommend sticking with that one :-) Mind if I borrow it? :-P
Get rid of the thought that the brake "can only apply so much torque."
Instead, you'll be calculating the clutch "brake" torque according to both
wheel's input torques and the bias ratio at every time step. It can be
infinite. That doesn't make sense at first really, but for instance, turn to
RCVD page 742, top picture. Assuming a 2.90:1 torque bias ratio:
With RH wheel at (almost) 375 and LH at 125, right at the border where the
axle is still locked, there would have to be 250 lb-ft of torque to keep it
locked.
With RH wheel at (almost) 750 and LH at 250, right at the border where the
axle is still locked, there would have to be 500 lb-ft of torque to keep it
locked.
In both of these cases, being on the border of the graph, the ramps press the
clutches with enough force to provide *exactly* enough torque to keep the
wheels locked. You could extend these shaded areas towards infinity and the
clutch torque would go right up with it.
Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Quoted text (7 lines)
>- When the diff actually starts slipping (when the torque bias ratio >is crossed), can I assume the clutch will counter with exactly its >maximum torque (i.e. just like static and dynamic friction, IF the >clutch starts slipping, won't its locking torque diminish by half for >example; the same if you push a cupboard; once it starts sliding, it >is much easier to keep it sliding). >- I have a formula which seems to give the torqQuoted text (9 lines)
> >So I would keep the diff locked until the torque bias ratio (and >preload) is overcome, then start unlocking, where the clutches keep on >generating their maximum torque to try and keep both wheels rotating >at the same speed. Not too sure if this is what the diff does, since a >diff is said to 'open up' at high torque differences, and this seems >more like a brake which can only apply so much torque. At its limit, >it just keeps trying to lock the axle with its maximum available >torque.
mjessick-Motorsims <[email hidden]> wrote in message news:[email hidden]...
[snip]
> Until the engine acceleration is known, the engine
> output to the clutch isn't known precisely, because
> a significant part of the engine power is used to
> accelerate the various rotating pieces of the engine.
> And so on down the entire drive train.
On my Auto Eng course, we used lumped-mass-and-stiffness
driveline models (in Simulink) to demonstrate "shuffle" and
"rattle" modes (shuffle is driven by a step in engine torque,
and involves the engine inertia oscillating against the mass
of the vehicle; rattle is the gearbox inertia oscillating
pretty much on its own).
Just thinking that some sort of wind-up model might ease
the equations and allow discrete calculations for each
component, although what it'll do to the overall processing
power required I don't know.
It certainly worked tidily to prevent the engine running
away in my final year project model - I had to replace the
"etherdynamic" connection the previous author had left in
there ;-)
HTH,
Jonny
Quoted text (9 lines)
> Usually for real time simulations one ignores > very high frequency transients in favor of assuming > a quasi-static scenario. We ignore stuff like the > "play" between two gears and exactly how the teeth > bounce back and forth or bend each other. > When you slam a car into gear, all the parts of the > drive train give a mightly lurch and at very high > frequency they all affect each other and come > to a concensus ;) about how fast to accelerate.
On Fri, 12 Oct 2001, Ruud van Gaal wrote:
...
> - When the diff actually starts slipping (when the torque bias ratio
> is crossed), can I assume the clutch will counter with exactly its
> maximum torque (i.e. just like static and dynamic friction, IF the
> clutch starts slipping, won't its locking torque diminish by half for
> example; the same if you push a cupboard; once it starts sliding, it
> is much easier to keep it sliding)....
Years ago we measured static and sliding friction on some diff clutch
plates (from something like a Salisbury type diff). The ones we tested
were partly submerged in lubricant and the tests we did indicated that the
static and sliding friction were the same, no change in torque after the
relative motion starts up.
So that should simplify your life a bit...
-- Doug Milliken
With my car, those sounds are precisely what I hear when not being
gentle with the clutch/gas, and it doesn't get away all that
instantly.... ;).
Oh, and I agree with everything you say :).
-Gregor
mjessick-Motorsims wrote:
Quoted text (7 lines)
> > In real life, the parts just nearly instantly > BangBang.Bang scrape ..scrape... hhhhuuuummmmmmmmmmmmmm ;) > their way to the new steady state condition without > being directly affected by any parts that aren't directly > in contact with them. >On 13 Oct 2001 00:31:10 GMT, [email hidden] (J. Todd Wasson) wrote:
So if I have a max bias ratio of 2.0, and T1=100Nm, T2=150Nm, then I
have:
currentRatio=1.5
lockingTorque=(maxRatio-1.5)*(150-100) = (2.0-1.5)*50 = 25Nm.
Right? (if I try another route, I get different answers; if I would
say, 'max ratio is 2, so MaxT2=2*T1=200Nm; as it's only T2=150Nm right
now, we have 50Nm of locking torque'.
>>- I have a formula which seems to give the torque bias ratio;
>>cos(angle)*(1+clutches). Clutches come in pairs....
> Cool. I'll have to try that out :-)
Notice an error in the above function; it should be:
cos(angle)*(1+noofPlates), so noofPlates is 2*clutches (2 plates per
clutch).
> I don't think this is right though, as
>the friction coefficient of the clutches ought to have something to do with it
>too. Perhaps something like:
>
>cos(angle)*(1+clutches * friction_coefficient) ?
You'd say so yes, hm.
Perhaps the entire cos()... result must be denormalized with a factor,
where factor=1 means a clutch with x Nm (where x is unknown ofcourse).
I don't know, I'll perhaps try and use it and see how it feels.
> Actually, it's probably dependent on the total clutch area rather than the
>number of clutches, but the formula you're using gives really good numbers. I
>recommend sticking with that one :-) Mind if I borrow it? :-P
Not at all. Hope it doesn't mess up your calculations though. ;-)
Thanks for the help sofar. 3 more questions:
1. When we talk about the bias ratio, is this purely the tire reaction
forces (road friction + brakes + rolling resistance), or is the input
torque affecting the ratio as well?
So: ratio = T_reaction_1/T_reaction_2
or is the ratio affected by the *input* torque (from the engine) as
well?
2. Where does the input torque come in? If you have a bias ratio which
is lower than the max ratio, you get a moment (let's call it M1) which
rotates the wheel velocities towards eachother, but how do you split
the input torque across both axles/wheels then? Just even? (with the
M1 added to the one and subtracted to the other)
3. What if one of the wheels gets locked by the brakes. A wheel brake
only applies as much torque as is needed to keep the wheel from
rotating, as long as the brake is capable to generate that amount of
torque. It seems then you can't just write down a closed form that
immediately states the resulting torques of the system
(engine->diff->wheels) (but perhaps with a shoot-and-correct method
you may get close enough in a couple of steps).
Thanks again for the help, I have a hard time grasping what these
gears exactly do in mathematical terms.
Ruud van Gaal
Free car sim : http://www.marketgraph.nl/gallery/racer/
Pencil art : http://www.marketgraph.nl/gallery/
Quoted text (15 lines)
> >- When the diff actually starts slipping (when the torque bias ratio >>is crossed), can I assume the clutch will counter with exactly its >>maximum torque (i.e. just like static and dynamic friction, IF the >>clutch starts slipping, won't its locking torque diminish by half for >>example; the same if you push a cupboard; once it starts sliding, it >>is much easier to keep it sliding). >>- I have a formula which seems to give the torq > > > I don't think you need to account for differences between static and dynamic >friction in the clutch. If the torque bias ratio is exceeded, the excess, >remaining torque accelerates the wheels away from each other. If they're at >different velocities but not exceeding the max torque bias ratio, the "current >bias ratio" (not the maximum value you're talking about here) provides the >amount of torque that accelerates the wheels towards locking.On Tue, 16 Oct 2001 03:09:19 GMT, Doug Milliken <[email hidden]> wrote:
Certainly. :) Thanks for the info.
Ruud van Gaal
Free car sim : http://www.marketgraph.nl/gallery/racer/
Pencil art : http://www.marketgraph.nl/gallery/
Quoted text (18 lines)
> >On Fri, 12 Oct 2001, Ruud van Gaal wrote: >... >> - When the diff actually starts slipping (when the torque bias ratio >> is crossed), can I assume the clutch will counter with exactly its >> maximum torque (i.e. just like static and dynamic friction, IF the >> clutch starts slipping, won't its locking torque diminish by half for >> example; the same if you push a cupboard; once it starts sliding, it >> is much easier to keep it sliding). >... > >Years ago we measured static and sliding friction on some diff clutch >plates (from something like a Salisbury type diff). The ones we tested >were partly submerged in lubricant and the tests we did indicated that the >static and sliding friction were the same, no change in torque after the >relative motion starts up. > >So that should simplify your life a bit...Quoted text (8 lines)
>>>- I have a formula which seems to give the torque bias ratio; >>>cos(angle)*(1+clutches). Clutches come in pairs. >... >> Cool. I'll have to try that out :-) > >Notice an error in the above function; it should be: >cos(angle)*(1+noofPlates), so noofPlates is 2*clutches (2 plates per >clutch).Quoted text (7 lines)
>1. When we talk about the bias ratio, is this purely the tire reaction >forces (road friction + brakes + rolling resistance), or is the input >torque affecting the ratio as well? >So: ratio = T_reaction_1/T_reaction_2 >or is the ratio affected by the *input* torque (from the engine) as >well? >Quoted text (7 lines)
>3. What if one of the wheels gets locked by the brakes. A wheel brake >only applies as much torque as is needed to keep the wheel from >rotating, as long as the brake is capable to generate that amount of >torque. It seems then you can't just write down a closed form that >immediately states the resulting torques of the system >(engine->diff->wheels) (but perhaps with a shoot-and-correct method >you may get close enough in a couple of steps).On 19 Oct 2001 05:35:19 GMT, [email hidden] (J. Todd Wasson) wrote:
Ah thanks, I'll have to see when I get round to creating a single
Salisbury differential.
>>Not at all. Hope it doesn't mess up your calculations though. ;-)
>
> If it does, I'll have to hunt you down and run you over with a Brabham :-P
Hehe, not like THAT has never happened before to me. ;-)
Ah, right, thanks. Weird things these differentials. Utterly brilliant
though. :)
Ok, thanks again.
Lol. I'm afraid so. :)
That's ok, oh, but let's read on...
> Actually, I might be persuaded to share if someone could provide me with a
>dll that plays wav files at different frequencies and volumes..... :-)
Hehe, that's easy. Go to www.fmod.org and download their fmod. Comes
free for free applications, and for not much for commercial
applications. I even believe Chris is using it at this point (he
recommended it to me). It's a single FMOD.dll (you downloaded it with
Racer v0.4.8) and gives you WAV loading, as well as MP3, whatever, and
plays back in 2D, in 3D (software or hardware), with varying
frequences, volumes, the works. I must say, great API, and great
functionality (splined interpolations etc).
So where were we. ;-) No but you help enough as it is. I'll have to
hunt Gregor to get me the formulae for a 3 differential pipeline,
hehe. Almost impossible if you want to vary the differential types.
Fortunately the GPL cars have just 1 diff.
Ruud van Gaal
Free car sim : http://www.marketgraph.nl/gallery/racer/
Pencil art : http://www.marketgraph.nl/gallery/
Quoted text (9 lines)
>>Notice an error in the above function; it should be: >>cos(angle)*(1+noofPlates), so noofPlates is 2*clutches (2 plates per >>clutch). > > Looks good, thanks. Although I think that specifies far more locking than >you actually get in GPL. You might put a factor in it (maybe .15 to .5) to >bring the bias ratio down. With a low, wide track car like GPL's cars, a >torque bias ratio of 2-2.5 will probably keep the axle locked at all times >(except when flipping through the air like I usually do, of course.)Quoted text (7 lines)
>>So: ratio = T_reaction_1/T_reaction_2 >>or is the ratio affected by the *input* torque (from the engine) as >>well? >> > > Input torque from the engine doesn't effect it, it's purely tire reaction >forces.Quoted text (7 lines)
>>2. Where does the input torque come in? If you have a bias ratio which >>is lower than the max ratio, you get a moment (let's call it M1) which >>rotates the wheel velocities towards eachother, but how do you split >>the input torque across both axles/wheels then? Just even? (with the >>M1 added to the one and subtracted to the other) > > I do it evenly and it works right.Quoted text (11 lines)
>>3. What if one of the wheels gets locked by the brakes. A wheel brake >>only applies as much torque as is needed to keep the wheel from >>rotating, as long as the brake is capable to generate that amount of >>torque. It seems then you can't just write down a closed form that >>immediately states the resulting torques of the system >>(engine->diff->wheels) (but perhaps with a shoot-and-correct method >>you may get close enough in a couple of steps). > > > This one I haven't given much thought to yet. We're getting into classified >areas right now anyway, I think :-)Quoted text (7 lines)
> I'm still not really willing to share the specific algos yet, sorry. I can >say though that when testing it in Racer, just display the current, calculated >bias ratio you're coming up with at all times. If, when cornering, one wheel >goes up in smoke and the torque bias ratio locks itself to the max you've >specified, you've got it right. > > Sorry for being a bugger about this :-(Quoted text (10 lines)
>Hehe, that's easy. Go to www.fmod.org and download their fmod. Comes >free for free applications, and for not much for commercial >applications. I even believe Chris is using it at this point (he >recommended it to me). It's a single FMOD.dll (you downloaded it with >Racer v0.4.8) and gives you WAV loading, as well as MP3, whatever, and >plays back in 2D, in 3D (software or hardware), with varying >frequences, volumes, the works. I must say, great API, and great >functionality (splined interpolations etc). > >So where were we. ;-)On 19 Oct 2001 21:44:14 GMT, [email hidden] (J. Todd Wasson) wrote:
>>Hehe, that's easy. Go to www.fmod.org and download their fmod....
>>So where were we. ;-)
>
>
> Well that was just too darned easy! No deal! No deal! lol
LOL! First use a search engine before you request software, hehe, it's
mostly all there on the net. :)
A little note saying 'Yes I got it in closed form, it's really quite
easy'? ;-)
>Of course, when I need
>your help doing some of the outrageous things you've done with Racer's graphics
>and such, you will probably tell me,"Remember when.......and Gregor helped and
>you refused?"
Lol, sure. Not too sure yet how I'll do rain and reflections in
puddles. And have to get a look at GT3 one day on a PS2 and see how
it's looking. But still, looking at actual races is best to estimate
why the computer graphics still look too clean. A lot has to do with
lighting, it seems.
> That's great that Chris pointed you in FMOD's direction... He doesn't talk
>to me anymore :-(
Hm, he might just be busy; he sometimes doesn't read or respond to
email for quite some time.
> Thanks for the tip though, I'll check into it. The problem is, I don't work
>in an OOP environment and would have to write my own headers for it in all
>likelihood (good luck), so it may not be an option.
It's C, not even C++, and I think there are tutorials for VisualBasic
as well, which may map very nicely onto PowerBasic.
> Right now, I use an
>interuppted sine wave system for sound. It's great on a laptop, as throttle
>position effects the sound too, but not so great if you've got any bass in your
>speakers. It humms a bit.
No intermixed wave samples?
I'll have to give Staccato a buzz again I guess; once mailed about
their pricing, but never got a response. It seems it lets you mix
actual wave samples and give a ring to that. People start complaining
about the lack of detail in the sound engine at this point. ;-)
> Speaking of sound, I actually got around to running the exhaust profile from
>one of my engine sims through the speakers. It actually sounded like a real
>engine at low rpm's, but turned into an annoying high pitched sound at mid to
>high rpm. Still, I think there's potential there once I get all 8 or whatever
>cylinders running through a proper exhaust system. Sometime in 2030 maybe....
>;-)
Good luck with that. :) May depend a bit on how you interpolate your
sound; sound cards are using splined interpolations and what not. Just
like graphics cards no match for software solutions anymore almost.
FMOD has nice interpolation routines; I'm not much into doing audio
stuff myself, so that's a relief.
Ruud van Gaal
Free car sim : http://www.marketgraph.nl/gallery/racer/
Pencil art : http://www.marketgraph.nl/gallery/
