torcs-devel Mailing List for TORCS - The Open Racing Car Simulator

Alright, the rotation code is actually working properly in the
quaternion domain but it is the transformation back to euler that is
messed up. I am not sure if that's because there is a bug in the
sgQuatToEuler() function or if it's OK but it's doing the conversion
assuming a wrong order of rotation..


-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

On Mon, 23 Feb 2004, Eric Espie wrote:

> > 1. I should postmultiply each angular velocity component
> > separately (dubious, since they are infinitesimal components and thus they should
> > be almost independent)
> >
> > 2. There is a problem with the transformation from quaternion/matrix
> > back to euler angles (which is necessary, unfortunately).
>
> Can the simulation only rely on the matrix ? the euler angles
> are useful for the robots to drive, but can we consider replacing
> the euler angles in the simulation engine by the use of the matrix.
>

It can, I just have to replace some calls.

If I just keep a rotation matrix, I have the problem of keeping it
normalised so that it is always a rotation matrix and not a shearing
matrix, for example.

If we have an implementation that works, the following experiment
should work:

1. Place the car at an arbitrary initial position.
2. Set a constant roll, pitch, or yaw angular velocity.
3. The car should perform the same rotation no matter what its initial
position was.

Let's see what I am doing.... currently I am just post-multiplying the
current rotation matrix with the infinitesimal angualr velocity.. but
this may be wrong:

The car is in a particular position. We consider its instaneous
position as an inertial frame. R_c is the rotation matrix at the
car's frame and R_g is the rotation matrix at the global frame.

The rotation matrix of the car in the car's frams is obviously just
the identity matrix I at the beginning of the infinitesimal movement.
We rotate this by the infinitesimal angular
velocity dW to get

	R_c(t+1) = I * dW_c(t)

Then we transform back to the global co-ordinate system by multiplying
with the inverse of R_g at the previous time-step... Hm...

	R_g(t+1) = R_c(t+1) * R'_g(t)

where ' denotes the inverse

So basically the update should look like:

	R_g(t+1) = dW_c(t) R'_g(t)

.... currently I am using:

	R_g(t+1) = R_g(t) dW_c(t)

which is perhaps the reason why the thing is not working...

Do you think there is a mistake here?


-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

Hi,

As the problem of using force feedback devices with
TORCS was raised, here are some points were to investigate:

The joystick interface is located in "src/interfaces/js.h"
and was borrowed from PLIB's code (for historic reasons).
It would be cool to add force feedback interface here
and propose to the PLIB team the modifications.

On Linux there is a force feedback driver here:
<http://user.it.uu.se/~johannd/projects/ff/index.shtml>

The joystick interface is used in the player's management code
"src/driver/human/human.cpp" and a "control API" is
located in "src/libs/tgfclient/control.cpp" this is here that
the force values have to be applied to the wheel.

The aligning torque on the wheels (the main force you
feel in the wheel) is not yet computed, so this should
be done in the simulation module "src/modules/simu/simuv*/wheel.cpp"
(only the front wheels should be used).
the result have to be stored in the tCarElt structure defined in
"src/interfaces/car.h". A forcefeedback parameter can be added
to the structure and the values are filled by the SimUpdate function of
"src/modules/simu/simuv*/simu.cpp"

Collision effects can be sent to the wheel too, the collision code
is located here: "src/modules/simu/simuv*/collide.cpp"

Well, here are the first points to look at,
I hope it is clear enough to start.

Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                        TORCS
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
                  http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Christos Dimitrakakis wrote:
[...]
>>>PS2. The update will be available together with the final stability
>>>fixes for simuv3. Rotation is still a problem.
>>>
>>
>>Have you given a look at the flightgear code ? they seem
>>to use quaternions to make the rotations around the 3 axis.
>>
> 
> 
> Yes, though actually fg has 3 simulation engines. As far as I can see
> from the code everything is correct. I just find a new rotation matrix
> or quaternion describing the angular velocity and postmultiply the
> current rotation matrix/quaternion with it. There might be two
> problems here:
> 
> 1. I should postmultiply each angular velocity component
> separately (dubious, since they are infinitesimal components and thus they should
> be almost independent)
> 
> 2. There is a problem with the transformation from quaternion/matrix
> back to euler angles (which is necessary, unfortunately).

Can the simulation only rely on the matrix ? the euler angles
are useful for the robots to drive, but can we consider replacing
the euler angles in the simulation engine by the use of the matrix.

Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                        TORCS
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
                  http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Hi

>> while I appreciate this features, I think one should restrict them to
the
>> pro mode. The reason is simply that I think that no robots instead of
ours
>> will ever support this features (not even our robots support the pro m=
ode
>> rules for example, not all robots support clutch).
>>
>
>OK, that is easy to fix. So.. the clutch only does something in pro
>mode?

The clutch of simuv2 does also work without applying it, if that is the s=
ame
in simuv3 then it can stay on all modes, IMHO. I=B4m more concerned about=
 features
which have an influence on the grip, like weather, tire wearing, etc., be=
cause
the robots of new people will simply not able to manage that, I think.=20

If a new user starts to write his robot he get then overwhelmed by all th=
e
stuff, its not like our robots which grow step by step with TORCS. So I=B4=
m
a bit concerned about too much relalism... my goal was when I started wit=
h
TORCS really to have robot races one day.

bye, Bernhard.

=20

> In fact, it depends of the tyres, for slick tyres it's true, but for tyres
> with thread grooves, the performance increase on dry road and decrease
> on wet road with wear...

I think that the tyres have a 'soft' layer with good grip on the
outside and when this layer wears out you don't have any more grip,
irrespective of type of tyre.

But this is a point for further deliberation.

> >
> > PS. Note that in the simple implementation of the tyres I only update
> > _tyreT_mid().
> >
> > PS2. The update will be available together with the final stability
> > fixes for simuv3. Rotation is still a problem.
> >
> Have you given a look at the flightgear code ? they seem
> to use quaternions to make the rotations around the 3 axis.
>

Yes, though actually fg has 3 simulation engines. As far as I can see
from the code everything is correct. I just find a new rotation matrix
or quaternion describing the angular velocity and postmultiply the
current rotation matrix/quaternion with it. There might be two
problems here:

1. I should postmultiply each angular velocity component
separately (dubious, since they are infinitesimal components and thus they should
be almost independent)

2. There is a problem with the transformation from quaternion/matrix
back to euler angles (which is necessary, unfortunately).



-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

Hi all

while I appreciate this features, I think one should restrict them to the
pro mode. The reason is simply that I think that no robots instead of ours
will ever support this features (not even our robots support the pro mode
rules for example, not all robots support clutch).

bye, Bernhard.

Hi Christos,

Christos Dimitrakakis wrote:
> I have now included tyre temperature effects. Tyre temperature
> increases with rolling speed, skidding speed, proportionally to the
> contact force with the road and decreases proportionally to the
> airflow times air pressure (->airspeed squared).

Great, it'll be another challenge for the robots and drivers !

> 
> Tyres now have an ideal operating temperature of 75oC, which is
> implemented as a bell curve centered at 75oC and falling to 50%
> efficiency at -25oC and 175oC.
> 
> Tyre wear is implemented as a rate of wear proportional to
> skid amount and road contact force, while it depends exponentially on
> the temperature (the rubber melts and starts to lose cohesiveness). It
> is reduce for stiffer tyres. (Tyres with high K, IIRC). Tyre width is
> also taken into account (since there is more material to strip away).
> 
> Currently the tyre performance is proportional to 1-tyre_wear,
> although that should probably change so that the first part of wearing
> out the tyre should not have any effect on its performance.

In fact, it depends of the tyres, for slick tyres it's true, but for tyres
with thread grooves, the performance increase on dry road and decrease
on wet road with wear...
It is may be too early to introduce different tyre types,
but anyway, there are some thoughts about that:
The grip can be the result of different interactions between the tyre and
the ground depending on the tyre type and the ground type:

1- contact grip : the one currently simulated, for smooth road, the grip is 
function of the contact surface.

2- hook grip : the effect of thread ribs against the ground asperities, this
is for offroad applications on rocks for example or studded tyres on ice.

3- rack grip : the grip is achieved by rack effect on soft soil (mud, sand,
snow...) and it depends on thread grooves and soil nature.

So the idea was to describe the ground with one or two layers, one
hard and optionnaly above it, one soft layer.
the hard layer can be described by the roughness (macro and micro)
and the soft one by the viscosity and depth.
If the tyre can evacuate enough of the soft layer, then the hard layer
can be used for grip too.
Note that for high level of simulation, the soft layer can change
along the race depending on the cars passing by and may be the weather.

I have no equations yet but we can start thinking about that.
Note that the temperature have an effect on the tyre pressure, so
it would be a good idea to introduce it in the grip equations too.

Another idea: the brakes wear and efficiency can also
depend on the temperature of use ;-)

> 
> I am updating interfaces/car.h to include the following information,
> which is to be displayed on the board, using the following #defines:
> 
> _tyreT_in(i)
> _tyreT_mid(i)
> _tyreT_out(i)
> _tyreCondition(i)
> 
> I guess pitstops should automagically change tyres when they are of
> type REPAIR, rather than STOP_N_GO.

It'll be easy to add the tyre change order in the pit procedure.

> 
> PS. Note that in the simple implementation of the tyres I only update
> _tyreT_mid().
> 
> PS2. The update will be available together with the final stability
> fixes for simuv3. Rotation is still a problem.
> 
Have you given a look at the flightgear code ? they seem
to use quaternions to make the rotations around the 3 axis.

Thanks,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                        TORCS
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
                  http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Hi Bernhard

>>- Now you think you can start using multitexturing -> segfault:-(
>>
>>The clean fix is to improve the drivers. A workaround could look like this
>>(just unices, so more #ifdef WIN32 fun):
>>- fork a process.
>>- parent: wait.
>>- child: probe the multitexturing capability.
> 
> 
> If you could extract a function which does just this, I could help with
> the fork/wait/signal stuff, but I guess you even know the fork/wait stuff
> well enough.

I have attached the basic framework which I have created today. It does
not do anyting yet (just testing).

> We should also set an alarm signal in the child or/and the parent
> so that our wait also returns or is interrupted if something takes
> way too long.

I have built that in somehow, have a look at it.

> If it's not wanted to integrate this into the torcs binary itself, 
> I could also imagine to have it as small, stand-alone program which
> is called from the launcher script and adds -s to the torcs arguments
> if the test fails.

At the moment it is very easy to use, so if Eric agrees we can integrate
it (in fact the integration is just around 3 to 5 lines per test). But
we have to discuss that when he is back.

> So if we have function which does trigger the multitexturing problem,
> we would have a test case for the developers and something to use for
> a test program for the mean time.

Yes, we can also build a standalone version. Tomorrow I will start
developing the test case for multitextureing. Probably I will have at
the end of the next week something that works.

Bye, Bernhard.

-- 

visit my homepage http://www.berniw.org

Hi Bernhard

>>- Now you think you can start using multitexturing -> segfault:-(
>>
>>The clean fix is to improve the drivers. A workaround could look like this
>>(just unices, so more #ifdef WIN32 fun):
>>- fork a process.
>>- parent: wait.
>>- child: probe the multitexturing capability.
> 
> 
> If you could extract a function which does just this, I could help with
> the fork/wait/signal stuff, but I guess you even know the fork/wait stuff
> well enough.

I have attached the basic framework which I have created today. It does 
not do anyting yet (just testing).

> We should also set an alarm signal in the child or/and the parent
> so that our wait also returns or is interrupted if something takes
> way too long.

I have built that in somehow, have a look at it.

> If it's not wanted to integrate this into the torcs binary itself, 
> I could also imagine to have it as small, stand-alone program which
> is called from the launcher script and adds -s to the torcs arguments
> if the test fails.

At the moment it is very easy to use, so if Eric agrees we can integrate 
it (in fact the integration is just around 3 to 5 lines per test). But 
we have to discuss that when he is back.

> So if we have function which does trigger the multitexturing problem,
> we would have a test case for the developers and something to use for
> a test program for the mean time.

Yes, we can also build a standalone version. Tomorrow I will start 
developing the test case for multitextureing. Probably I will have at 
the end of the next week something that works.

Bye, Bernhard.

-- 

visit my homepage http://www.berniw.org

I think the user problem is solved now and I think it's better to
switch to the -devel list now(changed cc)

On Wed, 18 Feb 2004, Bernhard Wymann wrote:

> Now I remember the problem what caused the use of a switch:
> - We can query the availablility of multitexturing.
> - But the DRI OpenGL drivers report then the multitexturing capability even if
> they are not able to support it properly.

Then I think it would be best, also for other applications, to fix the drivers.

But from reading the comment I've seen in the thread before, it looks like Mesa
wants to emulate it then, so it says yes it can... but then crashes any way,
so I think being dead slow would be another possibility what can happen.

> - Now you think you can start using multitexturing -> segfault:-(
> 
> The clean fix is to improve the drivers. A workaround could look like this
> (just unices, so more #ifdef WIN32 fun):
> - fork a process.
> - parent: wait.
> - child: probe the multitexturing capability.

If you could extract a function which does just this, I could help with
the fork/wait/signal stuff, but I guess you even know the fork/wait stuff
well enough.

> - get from the wait status if the exit was normal or caused by an uncaught
> signal.

man wait:

   pid_t wait(int *status);

       WIFSIGNALED(status)
              returns true if the child process exited because of
              a signal which was not caught.

> - if it was a signal, check if it was a segfault.

       WTERMSIG(status)
              returns the number of the signal  that  caused  the
              child  process to terminate. This macro can only be
              evaluated if WIFSIGNALED returned non-zero.

We should also set an alarm signal in the child or/and the parent
so that our wait also returns or is interrupted if something takes
way too long.

If it's not wanted to integrate this into the torcs binary itself, 
I could also imagine to have it as small, stand-alone program which
is called from the launcher script and adds -s to the torcs arguments
if the test fails.

So if we have function which does trigger the multitexturing problem,
we would have a test case for the developers and something to use for
a test program for the mean time.

Bernhard

I have now included tyre temperature effects. Tyre temperature
increases with rolling speed, skidding speed, proportionally to the
contact force with the road and decreases proportionally to the
airflow times air pressure (->airspeed squared).

Tyres now have an ideal operating temperature of 75oC, which is
implemented as a bell curve centered at 75oC and falling to 50%
efficiency at -25oC and 175oC.

Tyre wear is implemented as a rate of wear proportional to
skid amount and road contact force, while it depends exponentially on
the temperature (the rubber melts and starts to lose cohesiveness). It
is reduce for stiffer tyres. (Tyres with high K, IIRC). Tyre width is
also taken into account (since there is more material to strip away).

Currently the tyre performance is proportional to 1-tyre_wear,
although that should probably change so that the first part of wearing
out the tyre should not have any effect on its performance.

I am updating interfaces/car.h to include the following information,
which is to be displayed on the board, using the following #defines:

_tyreT_in(i)
_tyreT_mid(i)
_tyreT_out(i)
_tyreCondition(i)

I guess pitstops should automagically change tyres when they are of
type REPAIR, rather than STOP_N_GO.

PS. Note that in the simple implementation of the tyres I only update
_tyreT_mid().

PS2. The update will be available together with the final stability
fixes for simuv3. Rotation is still a problem.

-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

> Note that I realized that the Alpine-1 track have missing textures.

The are bad texture path for every new oval tracks too :-(

Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                        TORCS
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
                  http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Thank you very much Thierry :-) I'll fix all that.

Note that I realized that the Alpine-1 track have missing textures.

Also a note for all the packagers, the use of freeglut (in static mode) should
be priviledged instead of GLUT for a better fullscreen support (at least
on Linux).

Thanks,
Eric.

Thierry Thomas wrote:
> Le Dim  8 fév 04 à 10:46:36 +0100, Eric Espie <eri...@fr...>
>  écrivait :
> 
>>Hi all,
> 
> 
> Hello,
> 
> 
>>The 1.2.2 release candidate 1 is available here:
>><http://torcs.free.fr/tmp/index.html>
>>
>>Please test it and report the problems on the mailing-list.
>>If no major problem is found, the 1.2.2 will be released
>>soon.
> 
> 
> It builds fine on FreeBSD-4.9 / i386, but I have to remove some
> uncleaned objects:
> 
> find . -name "*.o"
> ./src/tools/accc/accc.o
> ./src/tools/nfs2ac/nfs2ac.o
> ./src/tools/nfsperf/nfsperf.o
> ./src/tools/texmapper/texmapper.o
> ./src/tools/trackgen/trackgen.o
> 
> There are some warnings ->
> <http://pompo.net/ports/torcs/warnings>.
> 
> Then, I have got problems when installing the robot sparkle. The
> following patch fixes it:
> 
> --- src/drivers/sparkle/Makefile.orig	Sun Feb  8 16:10:09 2004
> +++ src/drivers/sparkle/Makefile	Sun Feb  8 16:12:15 2004
> @@ -22,7 +22,7 @@
>  
>  SHIPDIR     = drivers/${ROBOT}
>  SHIP        = ${ROBOT}.xml logo.rgb
> -SHIPSUBDIRS = 0
> +SHIPSUBDIRS = $(shell find * -maxdepth 0 -type d -print | grep -v CVS)
>  
>  PKGSUBDIRS  = ${SHIPSUBDIRS}
>  src-robots-berniw_PKGFILES = $(shell find * -maxdepth 0 -type f -print)
> 
> However, I have not yest tested it, my usual machine with DRI is running
> other tests...
> 
> Regards,


-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                        TORCS
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
                  http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Le Dim  8 f=E9v 04 =E0 10:46:36 +0100, Eric Espie <eri...@fr...>
 =E9crivait=A0:
> Hi all,

Hello,

> The 1.2.2 release candidate 1 is available here:
> <http://torcs.free.fr/tmp/index.html>
>=20
> Please test it and report the problems on the mailing-list.
> If no major problem is found, the 1.2.2 will be released
> soon.

It builds fine on FreeBSD-4.9 / i386, but I have to remove some
uncleaned objects:

find . -name "*.o"
./src/tools/accc/accc.o
./src/tools/nfs2ac/nfs2ac.o
./src/tools/nfsperf/nfsperf.o
./src/tools/texmapper/texmapper.o
./src/tools/trackgen/trackgen.o

There are some warnings ->
<http://pompo.net/ports/torcs/warnings>.

Then, I have got problems when installing the robot sparkle. The
following patch fixes it:

--- src/drivers/sparkle/Makefile.orig	Sun Feb  8 16:10:09 2004
+++ src/drivers/sparkle/Makefile	Sun Feb  8 16:12:15 2004
@@ -22,7 +22,7 @@
=20
 SHIPDIR     =3D drivers/${ROBOT}
 SHIP        =3D ${ROBOT}.xml logo.rgb
-SHIPSUBDIRS =3D 0
+SHIPSUBDIRS =3D $(shell find * -maxdepth 0 -type d -print | grep -v CVS)
=20
 PKGSUBDIRS  =3D ${SHIPSUBDIRS}
 src-robots-berniw_PKGFILES =3D $(shell find * -maxdepth 0 -type f -print=
)

However, I have not yest tested it, my usual machine with DRI is running
other tests...

Regards,
--=20
Th. Thomas.

Hi all,

The 1.2.2 release candidate 1 is available here:
<http://torcs.free.fr/tmp/index.html>

Please test it and report the problems on the mailing-list.
If no major problem is found, the 1.2.2 will be released
soon.

Happy testing,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                        TORCS
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
                  http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=