If you are looking for a physically realistic solution, you started at the
wrong way at all - a Truck will never follow a spline. The rear axis never
follows the front (steering) wheels. Think of a long vehicle turning sharp
around a corner - while the front will pass it, the back will cut the edge!
All I want to say is that you can't expect a physically right simulation of
your trailer with any mathematic model, while your truck doesn't follow
physics at all!
But even if you can fix this - for a full phyisical simulaton you will need
a more detailed mathematical and physical description of truck and trailer.
The center of gravity will play a role as much as the mass of the trailer,
the speed of all components and even the friction of the ground. Think of
movements with high speed, on ice or in empty space!

But lets do a simpler model - at first for the simplest trailer-system: a
two-wheeled trailer pulled by hand.
Build a pole - a triangle, where (A) is the left wheel, (B) the right and
(C) the coupling in your hand. So (AB) is the axis and (M) shall be the
middle of the axis (AB). Then lets pull the coupling (C) to any new
position (P) in the easiest way we coul describe and without hurting
physics:
1. turn the trailer around (M) towards (P) so that the trailer is 'looking'
at (P) (the axis (AB) is orthogonal to the direction (MP))
2. move the trailer straight along (MP) until (C) is at (P)

To follow a given path in a smooth manner, we have to do many steps - turn,
move, turn, move, turn, move... - until we are there. Note that this
movement will look different than doing the same at one step and
interpolating the position!!!

In my thoughts and on paper this seems to result in a nearly realistic
movement - i had no time to try it in a simulation yet.

Once we have a solution for this two-wheeled trailer, a pulling system
(truck and trailer) and even a four-wheeled trailer will be simple: put
some poles together, where every coupling is at the center of the previous
axis.
Every four-wheeled trailer will need a pole (otherwise it can't be pulled
around corners!), so you can simply connect two two-wheeled trailers to get
a four-wheeled.
The truck itself will be a two-pole-system, too, where the first coupling is
a thought one: the point where the driver is aiming at. This point will be
the one following your spline step by step.

What do you think about this model?

Post a reply to this message

Yeah, that's it! I just wrote a simulation in Visual Basic (code see below).
Didn't think it would really work so naturally! It feels really great, you
can even drive backwards with a trailer! And it's easy to add as many
trailers as you want. :-)))

I made some drawings to illustrate the description above. Since I can't post
attachments here, you will have to download it as PDF from my server (need
the Acrobat Reader from adobe.com - it's free)

http://enter.diehlsworld.de/raytracing/truck.pdf

BTW, Thomas, you were on the right way with your first posting: the angle
and the whole behavior just depends on the length of the trailer.

Perhaps this weekend, I will try a POV-implementation that will be posted
here when working... (it will need more trigonometry than the VB-script
below)

And here the VB-code:
----------------------------
Rem Truck-Trailer-Problem
Rem Visual Basic Script
Rem (c) 2002 by J. Diehl
Rem http://enter.diehlsworld.de

Rem make a form with a picture object called 'picture1' and paste this code
into the codeview
Rem start the program and move the mouse over the picture

Rem Data for the trailers 1-3
Rem cx,cy the pole where the trailer will be pulled
Rem ax,ay the middle of the axis (and the coupling for the next trailer)
Dim cx1, cy1, ax1, ay1
Dim cx2, cy2, ax2, ay2
Dim cx3, cy3, ax3, ay3


Rem do a drive-step for any trailer
Rem where myax,myay,mycx,mycy are the specific trailer data to be modified
in this step
Rem newx,newy: the target for the pole in this step
Rem length: the length of the pole
Public Sub drive(ByRef myax, ByRef myay, ByRef mycx, ByRef mycy, newx, newy,
length)

Rem get the vector axis - new position
dx = newx - myax
dy = newy - myay

Rem set the trailer along this vector and move it to the new position
d = Sqr(dx * dx + dy * dy)
tomove = d - length
myax = myax + dx / d * tomove
myay = myay + dy / d * tomove

Rem draw the trailer
Picture1.Circle (myax, myay), 4, 0
Picture1.Circle (newx, newy), 2, 255
wx = (newx - myax) / length * 20
wy = (newy - myay) / length * 20
Picture1.Line (-wy + myax, wx + myay)-(wy + myax, -wx + myay), 255
Picture1.Line (-wy + myax, wx + myay)-(newx, newy), 255
Picture1.Line (wy + myax, -wx + myay)-(newx, newy), 255

End Sub

Private Sub Form_Load()
Rem set ScaleMode pixel for graphic output
Picture1.ScaleMode = 3
End Sub

Private Sub Picture1_MouseMove(Button As Integer, Shift As Integer, X As
Single, Y As Single)

Rem clear screen and get user mouse position
Picture1.Cls
px = X
py = Y

Rem first trailer drives to px,py (user-position)
Rem next trailer drives to the middle of the axis of the previous trailer
and so on...
drive ax1, ay1, cx1, cy1, px, py, 50
drive ax2, ay2, cx2, cy2, ax1, ay1, 50
drive ax3, ay3, cx3, cy3, ax2, ay2, 130

End Sub

----------

That's all!
Have a nice time with it...
Jo

Post a reply to this message

"J. Diehl" <j.d### [at] firemailde> wrote in
news:web.3d6e0f83a31ba4aaf70c33440@news.povray.org: 

> If you are looking for a physically realistic solution, you started at
> the wrong way at all - a Truck will never follow a spline. The rear
> axis never follows the front (steering) wheels. Think of a long
> vehicle turning sharp around a corner - while the front will pass it,
> the back will cut the edge! All I want to say is that you can't expect
> a physically right simulation of your trailer with any mathematic
> model, while your truck doesn't follow physics at all!
> But even if you can fix this - for a full phyisical simulaton you will
> need a more detailed mathematical and physical description of truck
> and trailer. The center of gravity will play a role as much as the
> mass of the trailer, the speed of all components and even the friction
> of the ground. Think of movements with high speed, on ice or in empty
> space! 

I don't think I said that I was looking for a completly correct physical 
model. The things I want to model are not physical correct anyway (the 
trucks can't steer for instance)

> But lets do a simpler model - at first for the simplest
> trailer-system: a two-wheeled trailer pulled by hand.
> Build a pole - a triangle, where (A) is the left wheel, (B) the right
> and (C) the coupling in your hand. So (AB) is the axis and (M) shall
> be the middle of the axis (AB). Then lets pull the coupling (C) to any
> new position (P) in the easiest way we coul describe and without
> hurting physics:
> 1. turn the trailer around (M) towards (P) so that the trailer is
> 'looking' at (P) (the axis (AB) is orthogonal to the direction (MP))
> 2. move the trailer straight along (MP) until (C) is at (P)

I came up with something quite similar over the last few days, but slighty 
diferent due to the fact that my implementation is different ofcourse.
 
> What do you think about this model?


Looks promising!!! 

I had a look at your VB code but to be honest I don't quite understand it, 
but I will try and implement something this weekend and with a bit of luck 
I can show an animation somewhere in the near future. I also downloaded 
your PDF file. It looks great!

Thanks!!!!

Thomas

Post a reply to this message

>I came up with something quite similar over the last few days, but slighty
>diferent due to the fact that my implementation is different ofcourse.

Quite similar - thats not surprising. I think it's the only way to catch the
problem.

>Looks promising!!!
>
>I had a look at your VB code but to be honest I don't quite understand it,
>but I will try and implement something this weekend and with a bit of luck
>I can show an animation somewhere in the near future. I also downloaded
>your PDF file. It looks great!

That was a nice topic for my homepage: I've just finished a site describing
my model with all math and trigonometry in more detail. Inclusive a
realtime flash-simulation and a POV animation with realistic steering front
wheels (commented POV source available).

So if you get stuck with your implementation (or anyone else being
interested in driving POV trucks) feel free to have a look at mine.
http://enter.diehlsworld.de

No alcohol when driving!
Cheers
jo

Post a reply to this message

"J. Diehl" <j.d### [at] firemailde> wrote in message
news:web.3d715afea31ba4aac8339f710@news.povray.org...
> I've just finished a site describing
> my model with all math and trigonometry in more detail. Inclusive a
> realtime flash-simulation and a POV animation with realistic steering
front
> wheels (commented POV source available).
>


    Very nice! I had minutes of fun driving the flash-sim truck around - it
even exhibits the wishbone-ing (for the want of a better word) when
reversing problem - I now understand why my Dad insisted on deciding where
we'd set up the trailer tent on family holidays _first_ and then drove it
_forwards_ on to our chosen spot and would curse if we said "no, move it
back a little" ! (Actually we all understood why, at the time, but that
never stopped us wanting it moved back every year...)

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

"J. Diehl" <j.d### [at] firemailde> wrote in
news:web.3d715afea31ba4aac8339f710@news.povray.org: 


> That was a nice topic for my homepage: I've just finished a site
> describing my model with all math and trigonometry in more detail.
> Inclusive a realtime flash-simulation and a POV animation with
> realistic steering front wheels (commented POV source available).

Your site looks great! and the flash thingy is excellent, great fun to play 
with.

I tried the last two evenings to implement it and I ran into all kinds of 
weird problems, mostly because the stuff I'm trying to animate are a bit 
limited compared to you model. This is one of the models I'm trying to get 
going is:

http://library.brickshelf.com/scans/2000/2149/

As you can see the front wheels of the truck don't steer, And I have been 
playing with some real Lego for the last few days at my desk and decided 
that I just turn the truck around the point in the middle between the two 
axle's (I simplified my model a bit more than the 2149, just two axle's on 
the truck and a single on the trailer). I do realize that that is not 
entirely realistic but it seems that real Lego "squeezes" through corners 
as well.

The second problem seems to be that the point where the trailer is attached 
to the truck is not directly on an axle as it in your model. I tried to get  
a single pole model going but something goes wrong..... :(

> No alcohol when driving!

Oooooopppppssss to late ;)


Thomas

Post a reply to this message

I already thought about a link-offset (and some other things, see below) and
I’ll give you a fast solution you can try. (I had no time to simulate
yet, but this will follow)

You remember this part in the driveTo-macro:

//get the new position of the pole
#declare d=sqrt(dx*dx+dy*dy);
#declare tomove=d-Length[Pole];
#declare PosX[Pole]=PosX[Pole]+dx/d*tomove;
#declare PosY[Pole]=PosY[Pole]+dy/d*tomove;

In the last two lines we first normalize the d-vector (divide it by ist
length to get legth=1) and then multiply it by our distance to move. A link
with LinkDist units behind the axis (positive value) can be computed
similar. So add the following two lines:

#declare LinkPosX[Pole]=PosX[Pole]-dx/d*LinkDist[Pole]
#declare LinkPosY[Pole]=PosY[Pole]-dy/d*LinkDist[Pole]

This should give us the absolute coordinates of the Link after moved.

When the driveTo macro is called for your trailer, just tell it to follow
LinkPosX/Y instead of PosX/Y - that should fit the problem.

(You will have to add the new Array definitions outside this macro before
running)

Coordinate system of the new model:
Length gives us the distance from rotating point (origin of the truck model)
to the front link. LinkDist is the distance to the back link. The whole
length of this special 'pole' will be Length+LinkDist.
For your pulling truck, define Length and LinkDist with the same value
(every the half of the truck’s length), and it will rotate around ist
center. Putting no axle or wheels at the defined axle (origin), but
somewhere else in the front and back means that the wheels will squeeze
when driving around. Hurts my ears a bit ;-)

The model is still very idealistic. A very interesting thing i.e. will be
how far every wheel rotates to draw realistic rolling rims when steering. I
already have a solution in my head - coming soon.

Post a reply to this message

First a question: why do you want to use single back axles? In my eyes it
would look better with the second axle.

I would try to animate it with two pole definitions like this:
Having a look at the plans of 2149 (assuming two axles) I  would put the
origin of the truck (where it turns around) at exactly the half of the
16-unit-construction. Putting the 'front link' (the point to follow the
path) exactly at the front axle, we get a 'PoleLength' of 6 units (dist.
origin --> front axle). The distance from origin to back link is 5 units
('LinkDist'=5). Translate your truck model so that the front axle is drawn
at z=6, the first back axle at z=-3 and the second at z=-6 (on an x-z-plane
with the truck looking at the +z direction)
For the trailer, lets put the origin to turn around at the middle of the two
axles (at the two red round 1 unit-bricks at the bottom of the trailer). In
my eyes, the front link of the trailer is 18 units away (please count
again). This is our 'PoleLength' for the trailer. LinkDist can be 0 here
(there is no further trailer). Translate your trailer so that the axles are
at z=1,5 and z=-1,5.

Post a reply to this message

"J. Diehl" <j.d### [at] firemailde> wrote in
news:web.3d75e4d8a31ba4aaf70c33440@news.povray.org: 

> First a question: why do you want to use single back axles? In my eyes
> it would look better with the second axle.


I have been playing with a simplified model for the last few days in order 
to speed up rendering. And tha uses only on axle. Once I get the concecpt 
going I would put the turning point of the truck between the two axle's.

I just saw your two note and I will give it a try, but I don't know when I 
have time to do it :( busy, busy busy. But I will keep you posted on my 
progress.

Thanks!!!

Thomas

Post a reply to this message

//my suggestion (with clock 0-1)

//-------------------------------------------------------
// truck-and-trailer problem
// POV-implementation
// (c) 2002 J. Diehl
// http://enter.diehlsworld.de
//-------------------------------------------------------


//-------------------------------------------------------
// some math macros
//-------------------------------------------------------

//the main macro to drive a pole to a given destination (NewX,NewY)
//it computes the new position and angle of the pole
#macro driveTo (Pole, NewX,NewY)

 //get the vector [axle --> new position]
 #declare dx=NewX-PosX[Pole];
 #declare dy=NewY-PosY[Pole];

 //get the new position of the pole
 #declare d=sqrt(dx*dx+dy*dy);
 #declare tomove=d-Length[Pole];
 #declare PosX[Pole]=PosX[Pole]+dx/d*tomove;
 #declare PosY[Pole]=PosY[Pole]+dy/d*tomove;

 //get the new position of the back link
 #declare LinkPosX[Pole]=PosX[Pole]-dx/d*LinkDist[Pole]
 #declare LinkPosY[Pole]=PosY[Pole]-dy/d*LinkDist[Pole]

 //get the angle of the pole
 #declare Angle[Pole]=0;
 #if (d!=0)
 #declare Angle[Pole]=atan2(dx,dy)/pi*180;
 #end
#end


//a macro for a simple path (very simple, of course! - a line)
//Put your own spline here
#declare ax=-10;
#declare ay=6;
#declare ex=30;
#declare ey=40;
#macro getPath(time)
        #declare PathX=ax*(1-time)+ex*time;
        #declare PathY=ay*(1-time)+ey*time;
#end

//-------------------------------------------------------
//definition of poles
//-------------------------------------------------------

#declare Poles=2;

#declare PosX=array[Poles]
#declare PosY=array[Poles]
#declare Length=array[Poles]
#declare Angle=array[Poles]

//variables for back link
#declare LinkPosX=array[Poles]
#declare LinkPosY=array[Poles]
#declare LinkDist=array[Poles]


//the initial position of each pole is the position where it was 'parked'
before linking first.
//it affects the direction the pole will be linked to the previous in the
first step.
#declare PosX[0]=20;
#declare PosY[0]=0;
#declare Length[0]=6;
#declare LinkDist[0]=5;

#declare PosX[1]=0;
#declare PosY[1]=2;
#declare Length[1]=18;
#declare LinkDist[1]=0;




//-------------------------------------------------------
//Follow the path
//-------------------------------------------------------

#declare myclock=clock;

//since we can't store the actual position from one frame to the next,
//we have to follow the path up to the current frame everytime.
//the smaller the steps, the more realistic the movement
#declare time=0;
#declare step=0.001;
#while (time <= myclock)
        getPath(time)

        //pole #0 follows the path,
        //pole #1 follows pole #0 and so on...
        driveTo (0,PathX,PathY)
        driveTo (1,LinkPosX[0],LinkPosY[0])

        #declare time=time+step;
#end




//-------------------------------------------------------
//draw the scene
//-------------------------------------------------------

camera {location<12,18,12> look_at < LinkPosX[0],0,LinkPosY[0]>}
light_source {<0,3000,0> color rgb 1}
light_source {<1000,1000,1000> color rgb 1}

plane
{
  y, 0
  pigment {color rgb <0.7,0.6,0.5>}
  normal {granite 0.3 scale 5}
  hollow on
}



//this one shows the path on the ground the truck will follow
cylinder{< ax,0,ay> < ex,0,ey> 0.2
        pigment{color rgb <0,0,1>}
        }



//the truck (pole #0)
union{
    box{<-1,1.8,-8><1,2,8>}
    cylinder{<-2,1,6><2,1,6> 1 pigment {color rgb 0.3}}
    cylinder{<-2,1,-3><2,1,-3> 1 pigment {color rgb 0.3}}
 cylinder{<-2,1,-6><2,1,-6> 1 pigment {color rgb 0.3}}
 pigment {color rgb 0.7}
 //first rotate, then translate the whole to the destination
 rotate y*Angle[0]
 translate < PosX[0],0,PosY[0]>
 }


//the trailer (pole #1)
union{
    cylinder{<-2,1,1.5><2,1,1.5 > 1 pigment {color rgb 0.3}}
    cylinder{<-2,1,-1.5 ><2,1,-1.5 > 1 pigment {color rgb 0.3}}
    box{<-1,2.2,-4.5><1,2.4,19.5>}
    pigment {color rgb 0.5}
 //first rotate, then translate the whole to the destination
 rotate y*Angle[1]
 translate < PosX[1],0,PosY[1]>
 }

Post a reply to this message