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

Hi
I just release a new version of TrackEditor and a howto tutorial to help
you in your first track.

Hi Xavier

> I had a look at the K1999 algorithm. I think that one important
> limitation for TORCS (and this is consistent with it's weakness in
> high-speed curves that was mentioned), is that it only considers the
> tire grip to be a constant, independant from speed. This is entirely
> logical when one remembers that it was written for RARS, where cars have
> no wings, and thus do not get any additional grip when going faster.
> 
> IMHO, one should add to this constant a value that depends on the speed
> and the aerodynamic of the car. Couldn't this improve the trajectories
> for high-speed curves?

It depends. If the parameter for the friction is chosen a bit above the 
limit, and you let your "controllers" hold the car on the trajectory, 
then it will make perhaps no big difference.
But if it is much below the limit it might improve a lot. It's hard to 
predict for me without further analysis.

> [Looking at the code in berniw2/pathfinder.cpp...]
> 
> Hmm... I did not find any mention of acceleration or speed in the K1999
> path computing algorithm as implemented in berniw2. They appear in the

Yes. I just took the path, NOT the trajectory. The whole speed thing is 
completely different. It considers an approximation of aerodynamics, 
bumps and uses as well constant tire friction depending on the surface 
of the segment.

> computation of the allowable speed (implementing algorithms C2 and C3 of
> section C.1.2 in Rémi's thesis), but this is a final step that is
> executed only after the trajectory has been computed.
> 
> Am I mistaken in thinking that improvements described in sections C.2
> and C.3 of the thesis were not (yet) implemented? Did I miss them?

No. I think I use the "old" variant in berniw, but I'm not sure:-)

bye, Bernhard.


-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

On Thu, 23 Sep 2004 22:03:54 +0200 Eric Espie <eri...@fr...> wrote:

> If I can suggest: http://remi.coulom.free.fr/Thesis/
> the Rémi Coulom Thesis on the trajectory computation.

Thanks a lot for this pointer...

I had a look at the K1999 algorithm. I think that one important
limitation for TORCS (and this is consistent with it's weakness in
high-speed curves that was mentioned), is that it only considers the
tire grip to be a constant, independant from speed. This is entirely
logical when one remembers that it was written for RARS, where cars have
no wings, and thus do not get any additional grip when going faster.

IMHO, one should add to this constant a value that depends on the speed
and the aerodynamic of the car. Couldn't this improve the trajectories
for high-speed curves?


[Looking at the code in berniw2/pathfinder.cpp...]

Hmm... I did not find any mention of acceleration or speed in the K1999
path computing algorithm as implemented in berniw2. They appear in the
computation of the allowable speed (implementing algorithms C2 and C3 of
section C.1.2 in Rémi's thesis), but this is a final step that is
executed only after the trajectory has been computed.

Am I mistaken in thinking that improvements described in sections C.2
and C.3 of the thesis were not (yet) implemented? Did I miss them?

--
Xavier Nodet
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." - Benjamin Franklin, 1759.

Bernhard Wymann wrote:
> Hi Xavier
> 
>>> - Speed: Because the trajectory is always in the "mind" you can 
>>> compute the speed you can drive on it.
>>
>>
>>
>> Right, but this actually supposes that the pre-computed trajectory will
>> always be the fastest one, which is not necessarily the case. Let me
> 

If I can suggest: http://remi.coulom.free.fr/Thesis/
the Rémi Coulom Thesis on the trajectory computation.

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

On Thu, 23 Sep 2004 10:36:08 +0200 Bernhard Wymann =
<be...@bl...> wrote:

> In fact you can improve some lap times up to 6 seconds just =
with=20
> fiddling the setup. The current settings are just quick and =
dirty setups=20
> (with 30 robots you cannot spend more that 3 laps for a =
setup:-)), and I=20
> tried to make the robot survive the race.

Ok. So the setup are not really tuned. This explains why I was =
able, for
some tracks, to get so much improvement... :)

> Which TORCS version do you use? I'm not that happy with =
simuv3 (CVS), so=20
> I still develop my robots for simuv2. The "dirty air" effect =
on simuv3=20
> is IMHO broken (like some other things, IMHO).

CVS, and I did not change the default. So I suppose this is =
simuv3, as I
get dirty air effects (less downforce, less drag).=20

Thanks,

--=20
Xavier Nodet
"They that can give up essential liberty to obtain a little =
temporary
safety deserve neither liberty nor safety." - Benjamin =
Franklin, 1759.

Hi Xavier

>>- Speed: Because the trajectory is always in the "mind" you can compute 
>>the speed you can drive on it.
> 
> 
> Right, but this actually supposes that the pre-computed trajectory will
> always be the fastest one, which is not necessarily the case. Let me

I cannot remember to have claimed that...;-) Like I already said, it is 
quite bad for fast turns with high downforce setups and some other 
features, but it is easy and cheap to compute.

> explain what I just did in the last few days...
> 
> I noticed that berniw robots were quite fast, and had very appealing
> trajectories, and I therefore decided to try to take the most out of
> them. I chose 'berniw two 9', that drives a MacLaren F1, and I fiddled
> with the friction and aero magic values, the rear wing, and the ratio of
> the differential. For the seven tracks that I studied, I was able to let
> it drive faster in 6 cases. Here are the results I got:
> 
>   eTrack 1:     1'02"94     vs  1'03"73
>   eTrack 2:     1'11"54     vs  1'18"36
>   Alpine 1:     2'01"01     vs  2'02"97 (D)
>   Eroad:        1'01"12     vs  1'03"06
>   Aalborg:      1'01"60     vs  1'04"55
>   CG Speed 1:     35"97     vs    35"44 (D)
>   CG Speed 2:     47"07 (D) vs    47"31 (D)
> 
> The (D) means that the car had some slight damage at the end of the run
> (in the order of 10 to 100 after 4 laps). You will find attached the
> changes I did for eTrack 2.

In fact you can improve some lap times up to 6 seconds just with 
fiddling the setup. The current settings are just quick and dirty setups 
(with 30 robots you cannot spend more that 3 laps for a setup:-)), and I 
tried to make the robot survive the race.

> But while I was running some races on eTrack2, I noticed that many cars
> (particularly those that compute good trajectories, like the berniws)
> put themselves out of track when they are following another car in the
> two very high speed left curves just before and after the 'bus stop'.
> That's because they don't take into account the lack of aerodynamic
> forces when following another car.

Which TORCS version do you use? I'm not that happy with simuv3 (CVS), so 
I still develop my robots for simuv2. The "dirty air" effect on simuv3 
is IMHO broken (like some other things, IMHO).

You can configure in torcs/config/raceengine.xml either
<attstr name="simu" val="simuv2"/> or
<attstr name="simu" val="simuv3"/>.

> Now, to the point... If there are other cars on the track, it may very
> well be the case that the fastest trajectory is not the one that would
> be the fastest if alone on the track. It may be beneficial to e.g. come
> out of a curve slightly on the interior, to avoid aerodynamic
> turbulences. Another example is that on straight lines, one should stay
> as long as possible just behind the car in front, to benefit from less
> aerodynamic drag...

Of course:-)

bye, thank you,

Bernhard.

-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

On Tue, 21 Sep 2004 18:27:00 +0200 Bernhard Wymann <be...@bl...> wrote:

> - Speed: Because the trajectory is always in the "mind" you can compute 
> the speed you can drive on it.

Right, but this actually supposes that the pre-computed trajectory will
always be the fastest one, which is not necessarily the case. Let me
explain what I just did in the last few days...

I noticed that berniw robots were quite fast, and had very appealing
trajectories, and I therefore decided to try to take the most out of
them. I chose 'berniw two 9', that drives a MacLaren F1, and I fiddled
with the friction and aero magic values, the rear wing, and the ratio of
the differential. For the seven tracks that I studied, I was able to let
it drive faster in 6 cases. Here are the results I got:

  eTrack 1:     1'02"94     vs  1'03"73
  eTrack 2:     1'11"54     vs  1'18"36
  Alpine 1:     2'01"01     vs  2'02"97 (D)
  Eroad:        1'01"12     vs  1'03"06
  Aalborg:      1'01"60     vs  1'04"55
  CG Speed 1:     35"97     vs    35"44 (D)
  CG Speed 2:     47"07 (D) vs    47"31 (D)

The (D) means that the car had some slight damage at the end of the run
(in the order of 10 to 100 after 4 laps). You will find attached the
changes I did for eTrack 2.


But while I was running some races on eTrack2, I noticed that many cars
(particularly those that compute good trajectories, like the berniws)
put themselves out of track when they are following another car in the
two very high speed left curves just before and after the 'bus stop'.
That's because they don't take into account the lack of aerodynamic
forces when following another car.

I tried to correct that with the attached code (effectiveCa.cpp) that is
to be inserted in the Pathfinder::plan method (the one that takes the
situation into account). What strikes me is that I absolutely had to
make the aerodynamic forces *reduce* the apparent weight of the car,
otherwize they would still, at some point, go out of track. It was not
enough to drive the ca to zero, it had to be negative.

This code is the first one I write for Torcs, and is certainly far from
perfect, but I hope it can give ideas to others...


Now, to the point... If there are other cars on the track, it may very
well be the case that the fastest trajectory is not the one that would
be the fastest if alone on the track. It may be beneficial to e.g. come
out of a curve slightly on the interior, to avoid aerodynamic
turbulences. Another example is that on straight lines, one should stay
as long as possible just behind the car in front, to benefit from less
aerodynamic drag...

Hope this helps,

-- 
Xavier Nodet
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." - Benjamin Franklin, 1759.

Hi Timo

>>What else have I tried:
>>- Fitting circles into the track, works very well on simple tracks like 
>>a-speedway (Rémi's algorithm is not so good for high downforce setups 
>>and fast turns).
>>- Forcing splines onto the track.
>>
> 
> That's what I want to do. What was your result?

The spline thing worked actually very well, I think I will implement a 
bt successor with splines if I find the time. This was with TORCS 
0.0.19-0.0.22 IIRC, I have lost the code (it was horrible anyway, the 
berniw code is a beauty compared with that...). It did also compute the 
path for one complete lap. It did totally ignore the opponents, no pit 
stops, etc:-)


How did it work:
1. Find a good set of initial points for the spline with heuristics.
- Find all apexes of all turns.
- Find good points on long straights.
- Select a set of apexes and points on straights which have a certain 
minimal distance.

2. Spline (generate points).

3. Find all points ranges aside from the track, push the most outside 
point of one Range back to the track.
- Range: the spline leaves the track e.g. 567m from start and comes back 
to the track 678m.
- If not all points are on the track go back to 2.

4. Find regions with a high density of points, remove points and check 
if the spline is still on the track (if you have too much points the 
spline is "noisy", therefore you cannot drive fast on it.


The next spline thing will work like this if I find the time to 
implement it:
- It will not anymore compute the whole lap, it will just care about the 
next X meters (~300-500 m I guess).
- It will generate the upcoming path in every timestep.
- To make this possible it will generate points with exponential growing 
distance from the current position of the car (e.g. with base 2: 
2,4,8,16,32, ... meters ahead). I do not know the base yet. perhaps 2 is 
too coarse. If the efficiency allows it I will try to do some 
optimization to find a fast path. If not, I will use (like always) 
heuristics.


The main problem is not the lack of ideas, but the lack of computing 
power (it is still my goal to run 10 robots smoothly on my 550MHz box, 
or 40 on my most current system).

What learning concerns, Christos put a nice library into TORCS for 
reinforcement learning, you can find it in the CVS. He points in the 
README to an online book, it is quite interesting. I have not yet 
implemented anything with it, I just tried trivial techniques with 
berniw and bt (e.g. analyse the deviation of the planned path, if it is 
small drive faster the next time, if it was big the last time steer 
more, if that does not help, drive slower, such stuff).


bye, have fun,

Bernhard.


-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Am 21 Sep 2004 um 18:27 hat Bernhard Wymann geschrieben:

> Hi Timo
> 
> > Hmmh... I've compared the tutorial robot with the berniw2 robot. There=
 are 
> > some improvements in the used path. Can you briefly explain what you'v=
e 
> > done?
> 
> Hm, the bt (tutorial) and berniw robot are very different animals, 
> altough they share the most "core" formulas from the tutorial.
> 
Yes, I already have seen the really very different source code.

> The bt simple trajectory:
> - Simply steer toward a point ahead of the car on the track middle. For 
> overtaking/letting overlap/collision avoidance/pitstop simply add an 
> offset to either side.
> - Acceleration/braking/speed limits is made with some reasoning combined=
 
> with heuristics.
> - Bt in CVS has also simple learning.
> - Tries to overtake a bit more clever (CVS).
> 
> The berniw trajectory:
> - Compute a quite good path very cheap with the algorithm of R=E9mi 
> Coulom. It does actually linearize the curvature of the path.

Ah, I already have seen that these two robots take very similar pathes.
Hmmh, I'm not very good in mathematics, but I thought about cubic splines =
to create the path through the track.

> - Overtaking: Compute a spline as new path (along the middle), very 
> cheap to compute, but bad as well.
> - Letting overlap: the same.
> - Speed: Because the trajectory is always in the "mind" you can compute 
> the speed you can drive on it.
interesting aspect...

> - Steer: select a point slightly ahead of the car, steer toward it (that=
 
> is the reason why I used in bt a "getTargetPoint" method, so that one 
> can easily switch to paths given as a bunch of points).
> - Control: Various controllers which try to avoid to much error, try to 
> avoid flying, taking bumps carefully, etc.
> 
Yes, this is really a good idea, especially on dirt tracks.

> What else have I tried:
> - Fitting circles into the track, works very well on simple tracks like 
> a-speedway (R=E9mi's algorithm is not so good for high downforce setups 
> and fast turns).
> - Forcing splines onto the track.
> 
That's what I want to do. What was your result?

> What I would suggest for a new robot is taking bt as base (or a 
> completly new idea if you have one), because of its structure. The 
> berniw's are not that easy to modify.
> 
I read the tutorial carefully (BTW it is really an excellent entrance to t=
he world of TORCS and very, very well documented :-)) and my robot will al=
so be based on the bt robot.

Have you already used some learning techniques in your robots?
- Thanks for your answer!

Bye,

Timo

Hi Timo

> Hmmh... I've compared the tutorial robot with the berniw2 robot. There are 
> some improvements in the used path. Can you briefly explain what you've 
> done?

Hm, the bt (tutorial) and berniw robot are very different animals, 
altough they share the most "core" formulas from the tutorial.

The bt simple trajectory:
- Simply steer toward a point ahead of the car on the track middle. For 
overtaking/letting overlap/collision avoidance/pitstop simply add an 
offset to either side.
- Acceleration/braking/speed limits is made with some reasoning combined 
with heuristics.
- Bt in CVS has also simple learning.
- Tries to overtake a bit more clever (CVS).

The berniw trajectory:
- Compute a quite good path very cheap with the algorithm of Rémi 
Coulom. It does actually linearize the curvature of the path.
- Overtaking: Compute a spline as new path (along the middle), very 
cheap to compute, but bad as well.
- Letting overlap: the same.
- Speed: Because the trajectory is always in the "mind" you can compute 
the speed you can drive on it.
- Steer: select a point slightly ahead of the car, steer toward it (that 
is the reason why I used in bt a "getTargetPoint" method, so that one 
can easily switch to paths given as a bunch of points).
- Control: Various controllers which try to avoid to much error, try to 
avoid flying, taking bumps carefully, etc.

What else have I tried:
- Fitting circles into the track, works very well on simple tracks like 
a-speedway (Rémi's algorithm is not so good for high downforce setups 
and fast turns).
- Forcing splines onto the track.

What I would suggest for a new robot is taking bt as base (or a 
completly new idea if you have one), because of its structure. The 
berniw's are not that easy to modify.

bye, Bernhard.


-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Am 21 Sep 2004 um 15:18 hat Bernhard Wymann geschrieben:

> Hi Timo
> 
> > Has anybody out there a good ressource about optimal pathes on race 
> > tracks?
> 
> No:-( If you want to precompute an optimal trajectory you can do this 
> offline with minimization techniques... but it is not trivial, at least 
> for me.

Hmmh... I've compared the tutorial robot with the berniw2 robot. There are 
some improvements in the used path. Can you briefly explain what you've 
done?
- Thanks!

Bye,

Timo

Hi Timo

> Has anybody out there a good ressource about optimal pathes on race 
> tracks?

No:-( If you want to precompute an optimal trajectory you can do this 
offline with minimization techniques... but it is not trivial, at least 
for me.
Perhaps you can get some inspiration from rars.sf.net. I read quite some 
papers about similiar subjects from robotics (search in the ACM online 
library if you have access, otherwise ask a friend from the university, 
they have usually access), but the problem is usually:
- The physical model is much too simple for a race car (point mass, no 
aerodynamics).
- And even then the methods evaluate dog slow (we talk here the about 
minutes for some meters of trajectory...)

Anyway, you could try to accelarate and improve such a method. If you 
find something interesting let me know.

Thank you,

bye, Bernhard.


-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Hi all!

Has anybody out there a good ressource about optimal pathes on race 
tracks?

- Thanks a lot!

Bye,

Timo

Hi Timo

> Hmmh, I'm not sure, but should this line not look like this: 
> 
> info->totalPitTime = MAX(2.0 + fabs(car->_pitFuel) / 8.0, (tdble)(fabs(car->_pitRepair)) 
> * 0.007);
> Because refuelling and repairing should be possible at the same time. In such way 
> will it at least done on TV ;-)
> 
> What do you think?

There are racing series (in fact a lot) where you are not allowed to 
refuel and work on the car at once, e.g. on some 24 hours races, gt 
series, etc. I think it is ok the way it is, but in fact it does not 
matter for me...

bye, Bernhard.

-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Hi Charalampos

> I just published the first version of a track editor which i make.It is in
> very primitive stage right now but if someone want to take a look on it i
> will appreciate any suggestions or comments.It is written in Java which
> mean it is cross platform while i tested only in Linux.

I have no time to look into it at the moment, but its great that you 
work on it. I have some ideas for the editor:
- It would be nice to load images as background and then being able to 
construct (kind of draw) the track on the image. The idea is that there 
are a lot of track layouts as jpgs or gifs on the net. Finally one 
should be able to enter its original length and the track is scaled up 
to the right size.
- Autojoin for the track end.
- Plugins for track export/import (so that the trackeditor is "general", 
not just for TORCS only).
- Material palettes to assign surfaces (perhaps with a nice image of the 
texture)

bye, Bernhard.


-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Hi Timo

> Hello together,
> 
> is there a possibility to calculate the needed time to fix a specific amount of damage 
> or to refuel the car? 

Ah, somebody is working on an evil strategy finally I guess...;-) Yes, 
there is, simply look up the formula implemented in TORCS and copy it to 
your robot, its in src/libs/raceengineclient/raceengine.cpp:
info->totalPitTime = 2.0 + fabs(car->_pitFuel) / 8.0 + 
(tdble)(fabs(car->_pitRepair)) * 0.007;

Have fun, bye

Bernhard.

-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Hello together,

is there a possibility to calculate the needed time to fix a specific amount of damage 
or to refuel the car? 

Bye,

Timo

Hi Timo

>But now to my question: Is it possible to set up the car properties during
>practice/race? Or at least changing these settings in pit stops.

No as far as I know, at least there is no API to do it (finally everything
is just a pointer in c...;-))

>I thought about a robot, which memorises the lap time (or even the time
of
>each 
>segment) and to automatically optimise the car setup (i.e. if the lap time
>is better with 
>a smaller spring value, save the new lap time and test it with an again
smaller
>value. If 
>the lap time is then worse, then look for the optimum between the new and
>the old 
>value and go a little back to the old value).

We discussed this idea some years ago, but nobody implemented it, AFAIK.

bye, Bernhard.

Hello together!

At first: Nice app! Very good work! :-)

But now to my question: Is it possible to set up the car properties during 
practice/race? Or at least changing these settings in pit stops.

I thought about a robot, which memorises the lap time (or even the time of each 
segment) and to automatically optimise the car setup (i.e. if the lap time is better with 
a smaller spring value, save the new lap time and test it with an again smaller value. If 
the lap time is then worse, then look for the optimum between the new and the old 
value and go a little back to the old value).

Bye,

Timo

Hi
I just published the first version of a track editor which i make.It is in
very primitive stage right now but if someone want to take a look on it i
will appreciate any suggestions or comments.It is written in Java which
mean it is cross platform while i tested only in Linux.

You can find it in : http://katergo.rege.org/projects/trackeditor/