The rars-digest is a compilation of choice cuts from the RARS mailing list.
It's published once a week to comp.ai.games, rec.autos.simulators, and to
individual subscribers. Send mail to dgy...@gdcarc.co.uk with a subject of
'subscribe rars-digest' to subscribe, or 'unsubscribe rars-digest' to
unsubscribe.
Contents
Some Questions concerning porting
Re: Some Questions concerning porting (comments by m)
practice conditions (solo or all together)
bug & fix for 0.61 - to be used today
joystick driver on the ftp site now...
New Collision Code
To the Robot Authors, and Would-be Authors
Race Report and Upcoming Races
Re: Some Questions concerning porting
Re: practice conditions (solo or all together)
UNIX RARS 0.62 on ftp site.
---------------------------------------------------------------------------
From: Nicole.Grei...@FernUni-Hagen.de (Nicole Greiber)
To: rars-l...@netcom.com
To: rars-l...@netcom.com
Subject: Some Questions concerning porting
Date sent: Sun, 11 Jun 1995 20:32:57 +0100
Hello
since we couldn't find an existing port of RARS to OS/2,
Ralph Scott (rsc...@alpha.netusa.net) and I will do that.
The portability of the code is great, and it is very easy
to get along with the OS-specific parts. But when I wanted to
add another .cpp file or two, I found it very difficult
to get through all of these static variables that are spread over
the whole project.
Is it necessary that these variables are declared static?
Wouldn't it be easier to have a header file for each of the
.cpp files that can be included where needed?
Another "difficulty" is caused by some of the graphics functions
in draw.cpp. The function graph_setup() calculates the track and
paints it. This produces some overhead in a graphical OS
because when the program window will be refreshed during a race,
there is no need to recalculate the track, only the painting
is needed. To avoid this, the function could be split.
Is anybody already working on changes like these, or is
anybody interested in them? For us it doesn't make sense
just to implement them in our version since that will reduce
compatibility and portability very much.
---------------------------------------------------------------------------
From: "Mitchell E. Timin" <m...@cac.psu.edu>
Subject: Re: Some Questions concerning porting (comments by m)
To: Nicole.Grei...@fernuni-hagen.de (Nicole Greiber)
Date sent: Sun, 11 Jun 1995 22:53:22 -0400 (EDT)
Copies to: rars-l...@netcom.com (Rars- List)
Hello Nicole,
It's OK with me if people make structural changes to their ports. My version
was developed originally for DOS, and my own convenience. Later I made a
lot of changes to help the porters, but certainly not everything possible.
The important thing with a port is that the cars run the same, so that a
robot that can average X mph on track Y will do the same on any system.
A person should be able to develop and test his robot under OS/2 and then
compete in a race in a DOS system, or vice-versa.
About static variables, that is done to give them file scope instead of
global scope. It make the program a little more resistant to programming
errors, especially those in the many robot functions from different authors.
m
---------------------------------------------------------------------------
From: "Mitchell E. Timin" <m...@cac.psu.edu>
Subject: practice conditions (solo or all together)
To: rars-l...@netcom.com (Rars- List)
Date sent: Sun, 11 Jun 1995 10:39:32 -0400 (EDT)
Hello All,
Randy suggested that I disable collisions during practice so that each car
would have the track all to itself, so-to-speak. There is some merit to
this suggestion, but after thinking about it, I prefer it the way it is,
Buy the floor is open for your comments.
I am of the opinion that practice should be under race conditions, with
the necessity to avoid other cars. The main reason is that I have seen that
cars that are optimized to run on an empty track are usually hyper-sensitive
to disturbances of any kind, hence they are easily run off the track by
other cars. To win in realistic races a driver needs a robust algorithm
that sacrifices some speed for much higher reliability.
Starting with the next races we will have a much higher collision probability
and it will be essential to have some crash avoidance code to have much of
a chance of winning.
I will release a tutorial with an example of crash avoidance code in a
couple of days.
In the real world I thought that most practice was done with other cars on
the track. I don't follow racing very closely, but I have seen some sports
car races many years ago, and I think I remember that most practice was not
solo. Also, I used to race moto-cross, and we always practiced together.
m
---------------------------------------------------------------------------
From: "Mitchell E. Timin" <m...@cac.psu.edu>
Subject: bug & fix for 0.61 - to be used today
To: rars-l...@netcom.com (Rars- List)
Date sent: Sun, 11 Jun 1995 10:22:34 -0400 (EDT)
Hello All,
Rob Creager, our entomologist, pointed out a small bug. It only affects
practice sessions, and only when they are long enough that cars can run
out of fuel. What happens with the current code is that after a car
runs out of fuel it is checked for damage, and maybe put out of the race.
The cars are not supposed to be checked for damage during practices.
Only a very small change in CARZ.CPP is required. After the following text:
if((stage != PRACTICE && damage > MAX_DAMAGE) || fuel <= 0.0) {
You will find this line:
if(damage > MAX_DAMAGE) {
It should be changed to:
if(damage > MAX_DAMAGE && stage != PRACTICE) {
I have made this change for today's races, to allow the cars to practice
for 200 laps. We have at least two cars that learn from practice.
m
---------------------------------------------------------------------------
Date sent: Sat, 10 Jun 95 12:28:37 +0200
From: dv3ki...@ida.his.se (Kim Laurio)
To: rars-l...@netcom.com
Subject: joystick driver on the ftp site now...
Well, now the joystick.zip and joystick.txt are on the ftp site.
Have fun!
---------------------------------------------------------------------------
From: "Mitchell E. Timin" <m...@cac.psu.edu>
Subject: New Collision Code
To: rars-l...@netcom.com (Rars- List)
Date sent: Sat, 10 Jun 1995 07:26:11 -0400 (EDT)
Hello All,
Tomorrow's races will be run with the regular version 0.61, just like is
on the ftp site. (i.e., no surprise changes for tomorrow.)
But, the next races, in two weeks, will use different code to handle
collisions. There are changes to three files only, CARZ.CPP, MISC.CPP and
MISC.H. I will now send you all these files; just replace your current
versions and re-compile.
The main effect is more frequent and realistic collisions. Cars no longer
run through each other, they crash. Some visual overlap is still present,
but much less than before.
The robots will have to become better drivers. I am about to release tutorial
7 which will have some code using s.nearby to attempt collision avoidance.
---------------------------------------------------------------------------
From: "Mitchell E. Timin" <m...@cac.psu.edu>
Subject: To the Robot Authors, and Would-be Authors
To: rars-l...@netcom.com (Rars- List)
Date sent: Mon, 12 Jun 1995 17:36:14 -0400 (EDT)
Hello All,
I am considering whether or not to continue putting the source code for
the robots on the ftp site after each race. Some of the authors would
prefer to not make their code public.
If I adopt the new policy I will leave it to the authors to put their
robots on the ftp site if they wish. I will upload only the .obj files,
which I realize are only useful to borland compiler users.
I invite your comments.
---------------------------------------------------------------------------
From: "Mitchell E. Timin" <m...@cac.psu.edu>
Subject: Race Report and Upcoming Races
To: rars-l...@netcom.com (Rars- List)
Date sent: Mon, 12 Jun 1995 13:33:06 -0400 (EDT)
RARS Bi-weekly Race Report
& News About Upcoming Races
June 12, 1995
RARS is the Robot Auto Racing Simulation, a competition for
programmers and an on-going challenge for practicioners of Artificial
Intelligence and real-time adaptive optimal control. It consists of
a simulation of the physics of cars racing on a track, a graphic
display of the race, and a separate control program (robot "driver")
for each car. All RARS software and activities are free and open to
the public. For more information e-mail to m...@cac.psu.edu.
Contents
Authors Point Standings
Upcoming Races
June 11 Competitors
June 11 Race Commentary
June 11 Race Report
--------------------------------------------------------------------
Expert Class Point standings
Jussi Pajala 22 pts (Finland)
Randy Saint 13 pts (U.S.A.)
Tim Battersby 10 pts (Canada)
Safai Ma 10 pts (Canada)
Bill Benedict 9 pts (U.S.A.)
Mike Inman 6 pts (U.S.A.)
Muir Lee Harding 6 pts (U.S.A.)
Novice Class Points:
Oscar Gustafsson 14 pts (Sweden)
Grant Reeve 8 pts (New Zealand)
Tristrom Cooke 7 pt (Australia)
Carl Burke 6 pts (U.S.A.)
Patrick Tierney 5 pts (Canada)
Thomas Rooney 2 pts (U.S.A.)
--------------------------------------------------------------------
The Next Six RARS Race Meets
For the next twelve weeks we will have the oval track races three
times and the road races on the June 11 tracks three times. This is
to give the authors time to master passing, collision avoidance and
the geometry of the two road race tracks, S1.TRK and S2.TRK.
There is live race commentary on IRC channel #RARS, 5:00 PM EDT.
June 25, July 23, August 20:
No. of races: 6 novice and 6 expert
Track: oval2
Laps: 10 each race
Software version: 0.62 (or latest variant of 0.60)
Surface type: 0
no practice on race day, practice at home all you want!
The default starting order system will be used, i.e. alternating
random and reversed.
July 9, August 6, September 3:
No. of races 2 novice and 2 expert
Tracks: S1.TRK and S2.TRK, one race on each
Laps: 80 each race
Software version: 0.62 (or latest variant of 0.60)
Surface Type: 1
no practice, random starting order.
--------------------------------------------------------------------
June 11 Race Report:
Competitors, Novice Class:
Grant Reeve New Zealand Piranha
Oscar Gustavsson Sweden OscCar2
Tristrom Cooke Australia Bingo1
Carl Burke U.S.A. Blender2
Competitors, Expert Class:
Bill Benedict U.S.A. Rusty
Safai Ma Canada Burns
Jussi Pajala Finland WappuCar
Randy Saint U.S.A. Ramdu
Mike Inman U.S.A. Indretti
The novices found S1.TRK to be too much for them! None could finish
more than 5 laps. Piranha was clearly the fastest car by far, but
this race was determined by distance completed, not speed. The novices
did better on S2.TRK, with all but Piranha able to go the distance.
There was no clear winner on the S1 races, but OscCar2 dominated the
races on S2. Point totals gave first place for the day to OscCar2.
After the novices races were over it seemed to me that none of the
novices were ready to be advanced to expert. Accordingly, I did not
enter OscCar2 in the expert races. I now feel that that was a
mistake, because now that the races are over, it seems that OscCar2
compares favorably with some of the expert drivers. Only WappuCar
and Ramdu, among the experts, were able to complete 25 laps on both
tracks. If Oscar Gustavsson wishes to move into the expert class, I
will do that. OTOH, he may prefer to stay a novice a little longer
in order to (maybe) take a first place in the novice class.
The expert races were dominated by WappuCar, which worked its way into
the lead early in every race, and kept it. Ramdu had to fight with
Burns for 2nd place, but only for a while, as Burns was prone to
contact the walls and damage himself. Ramdu and WappuCar were the
only robots capable of learning, and they were both able to increase
their average speed by over one mph during the 200 lap practice
session, on each track. The robot Burns was very fast, and held the
lead briefly, and 2nd place for considerable time in several races.
But it couldn't avoid contact with the walls of the track, and was
therefore eventually damaged beyond repair.
--------------------------------------------------------------------
Novice Races
4 cars for 25 laps. The track was s1.trk. The drivers were:
Blender2, Bingo1, Piranha, and OscCar2.
The initial RVG seed was 2834.
results of race 1:
starting positions:
Bingo1, Blender2, Piranha, and OscCar2.
1 Piranha avg spd 71.11 5 laps 30090 damage 131 fuel 10 pts accum
2 Bingo1 avg spd 63.32 5 laps 30318 damage 127 fuel 6 pts accum
3 OscCar2 avg spd 67.25 3 laps 30262 damage 137 fuel 4 pts accum
4 Blender2 avg spd 0 0 laps 30968 damage 148 fuel 3 pts accum
results of race 2:
starting positions:
OscCar2, Piranha, Blender2, and Bingo1.
1 Bingo1 avg spd 63.35 5 laps 30197 damage 127 fuel 16 pts accum
2 Piranha avg spd 71.26 4 laps 30043 damage 134 fuel 16 pts accum
3 OscCar2 avg spd 67.1 3 laps 30566 damage 137 fuel 8 pts accum
4 Blender2 avg spd 0 0 laps 30191 damage 148 fuel 6 pts accum
--------------------------------------------------------------------
4 cars for 25 laps. The track was s2.trk. The drivers were:
Blender2, Bingo1, Piranha, and OscCar2.
The initial RVG seed was 17486.
results of race 1:
starting positions:
Piranha, OscCar2, Blender2, and Bingo1.
1 OscCar2 avg spd 60.13 25 laps 768 damage 62 fuel 10 pts accum
2 Blender2 avg spd 59.28 25 laps 222 damage 58 fuel 6 pts accum
3 Bingo1 avg spd 57.07 24 laps 211 damage 55 fuel 4 pts accum
4 Piranha avg spd 63.45 1 laps 30146 damage 142 fuel 3 pts accum
results of race 2:
starting positions:
Bingo1, Blender2, OscCar2, and Piranha.
1 OscCar2 avg spd 59.82 25 laps 10247 damage 62 fuel 20 pts accum
2 Blender2 avg spd 59.28 25 laps 5155 damage 59 fuel 12 pts accum
3 Bingo1 avg spd 57.05 24 laps 752 damage 55 fuel 8 pts accum
4 Piranha avg spd 63.03 1 laps 30123 damage 143 fuel 6 pts accum
--------------------------------------------------------------------
Overall Results of Novice Races:
day pts season pts
1st place OscCar2 28 10
2nd place Bingo1 24 6
3rd place Piranha 22 4
4th placd Blender2 18 3
--------------------------------------------------------------------
Expert Races
5 cars for 25 laps. The track was s1.trk. The drivers were:
WappuCar, Ramdu, Burns, Rusty, and Indretti.
The initial RVG seed was 30850.
200 practice laps were requested.
results of race 1:
starting positions:
Rusty, Indretti, Ramdu, Burns, and WappuCar.
1 WappuCar avg spd 74.03 27 laps 6996 damage 71 fuel 10 pts accum
2 Ramdu avg spd 68.13 25 laps 4416 damage 66 fuel 6 pts accum
3 Indretti avg spd 67 24 laps 5263 damage 76 fuel 4 pts accum
4 Burns avg spd 71.96 12 laps 30099 damage 114 fuel 3 pts accum
5 Rusty avg spd 62.15 1 laps 30152 damage 145 fuel 2 pts accum
results of race 2:
starting positions:
WappuCar, Burns, Ramdu, Indretti, and Rusty.
1 WappuCar avg spd 74.27 27 laps 654 damage 71 fuel 20 pts accum
2 Ramdu avg spd 68.17 25 laps 6147 damage 67 fuel 12 pts accum
3 Indretti avg spd 67.03 24 laps 1154 damage 76 fuel 8 pts accum
4 Burns avg spd 71.91 10 laps 30466 damage 119 fuel 6 pts accum
5 Rusty avg spd 62.25 1 laps 30468 damage 145 fuel 4 pts accum
--------------------------------------------------------------------
5 cars for 25 laps. The track was s2.trk. The drivers were:
WappuCar, Ramdu, Burns, Rusty, and Indretti.
The initial RVG seed was 28777.
200 practice laps were requested.
results of race 1:
starting positions:
WappuCar, Indretti, Ramdu, Burns, and Rusty.
1 WappuCar avg spd 67.29 26 laps 192 damage 63 fuel 10 pts accum
2 Ramdu avg spd 62.36 25 laps 11998 damage 60 fuel 6 pts accum
3 Indretti avg spd 59.66 7 laps 30029 damage 121 fuel 4 pts accum
4 Burns avg spd 61.58 2 laps 30278 damage 140 fuel 3 pts accum
5 Rusty avg spd 60.01 2 laps 30288 damage 142 fuel 2 pts accum
results of race 2:
starting positions:
Rusty, Burns, Ramdu, Indretti, and WappuCar.
1 WappuCar avg spd 67.29 27 laps 3581 damage 63 fuel 20 pts accum
2 Ramdu avg spd 62.31 25 laps 14766 damage 60 fuel 12 pts accum
3 Indretti avg spd 59.6 6 laps 30050 damage 124 fuel 8 pts accum
4 Burns avg spd 61.59 2 laps 30008 damage 140 fuel 6 pts accum
5 Rusty avg spd 58.23 1 laps 30094 damage 145 fuel 4 pts accum
--------------------------------------------------------------------
Overall Results of Expert Races:
day pts season pts
1st place WappuCar 40 10
2nd place Ramdu 24 6
3rd place Indretti 16 4
4th placc Burns 12 3
5th place Rusty 8 2
--------------------------------------------------------------------
---------------------------------------------------------------------------
To: "Nicole Greiber" <Nicole.Grei...@fernuni-hagen.de>,
"RARS mailing list" <rars-l...@netcom.com>
From: "Marcel Offermans" <mar...@wbmt41.wbmt.tudelft.nl>
Date sent: Mon, 12 Jun 1995 12:54:26 +0100
Send reply to: "M.F.Offermans" <M.F.Offerm...@wbmt.tudelft.nl>
Subject: Re: Some Questions concerning porting
Organization: Private TCP/IP node
Hello Nicole,
> (rsc...@alpha.netusa.net) and I will do that.
comments. :-)
> with the OS-specific parts. But when I wanted to add another .cpp file
> or two, I found it very difficult to get through all of these static
> variables that are spread over the whole project.
> Is it necessary that these variables are declared static? Wouldn't it be
> easier to have a header file for each of the .cpp files that can be
> included where needed?
should have been header files with each source module. This would have made
the "interface" of each module much clearer.
The static variables (should) have been declared that way to hide them from
other modules completely. I'm sure there's room for improvement here.
In short, for future versions of RARS, I'd propose:
- to put all global variables at the top of each module;
- to make all global variables that are only of use to that specific
module static;
- to create a header file for each module, containing:
- prototypes for all globally accesible functions;
- a list of all "exportable" variables, constants and defines.
- to add prototypes for local functions at the top of the module and to
declare those functions static.
Does anybody have any other suggestions or comments about this? I'll make
this an item in the "ideas database" if necessary.
> draw.cpp. The function graph_setup() calculates the track and paints it.
> This produces some overhead in a graphical OS because when the program
> window will be refreshed during a race, there is no need to recalculate
> the track, only the painting is needed. To avoid this, the function
> could be split.
has a graphical OS. However, unless you really want to refresh window
contents yourself, you don't have to deal with this at all. In other words,
I haven't had problems with this, and I suspect that redrawing and
especially flood filling every time the window gets damaged is a
complicated thing. I am assuming you're talking about repairing "damage" to
the window after it has been (partly) overlapped by other windows.
Suggestions:
- look for a solution that lets the OS redraw the window without your
intervention (this will probably mean that the OS has to make a copy
of the part(s) of the window that are overlapped before it actually
draws another window on top of it);
- make a copy of the whole window yourself, and use it as a backup to
restore parts from;
- make a separate "repair" function that copies some of the functionality
of the graph_setup() function (and perhaps take this functionality
out of the graph_setup() itself and just add a call to your new routine
there.
> interested in them? For us it doesn't make sense just to implement them
> in our version since that will reduce compatibility and portability very
> much.
idea. So if it increases portability (is this perhaps also an issue for the
Mac or X-Windows version?) I'm all for it.
Good luck with the port.
Greetings, Marcel
---------------------------------------------------------------------------
To: "rars-list" <rars-l...@netcom.com>
From: "Marcel Offermans" <mar...@wbmt41.wbmt.tudelft.nl>
Date sent: Mon, 12 Jun 1995 02:12:34 +0100
Send reply to: "M.F.Offermans" <M.F.Offerm...@wbmt.tudelft.nl>
Subject: Re: practice conditions (solo or all together)
Organization: Private TCP/IP node
> car would have the track all to itself, so-to-speak. There is some merit
> to this suggestion, but after thinking about it, I prefer it the way it
> is, Buy the floor is open for your comments.
Optimizing parameters for a circuit is difficult as it is. If you use a
genetic algorithm or any other optimization algorithm, you will usually use
the lap time as an indication of the success of the current settings. If
another car collides with you, and you get a bad laptime because of that,
the algorithm will not work well.
> the necessity to avoid other cars. The main reason is that I have seen
> that cars that are optimized to run on an empty track are usually
> hyper-sensitive to disturbances of any kind, hence they are easily run
> off the track by other cars. To win in realistic races a driver needs a
> robust algorithm that sacrifices some speed for much higher reliability.
routine from now on. Your new collision detection routine has shown that
most cars make a mess of it right now. I don't think this is caused by the
fact that they drive so much on the edge that there's no room for
corrections, most cars choose to simply ignore other cars. You will see
from the collision routines that I sent you that most cars won't even
finish if the collision mechanism itself is made more realistic (using
semi-elastic collisions).
> probability and it will be essential to have some crash avoidance code
> to have much of a chance of winning.
> couple of days.
> on the track. I don't follow racing very closely, but I have seen some
> sports car races many years ago, and I think I remember that most
> practice was not solo. Also, I used to race moto-cross, and we always
> practiced together.
that is done on an empty circuit. On the other hand, practice and
qualification sessions are on a "full" circuit. In the Indy cars, at least
on the Indy 500 the qualification is on an empty circuit. I guess it
differs. It wouldn't be too difficult to support both options in RARS. We
could just make it `yet-another-switch' and decide from race to race what
option is going to be used. Actually, we already have both options, as long
as the cars save practice results to a file. Just run RARS once for every
car before starting the actual race. :-)
Marcel
PS: If you want to choose only one option, I'm for the 1 car in practice
(or no-collision) option.
---------------------------------------------------------------------------
Date sent: Wed, 14 Jun 1995 09:48:19 -0500
To: rars-l...@netcom.com
From: sa...@phoenix.net (Randy Saint)
Subject: UNIX RARS 0.62 on ftp site.
The latest version of the UNIX RARS (0.62) is now on the ftp
site. This includes the latest collision detection code, as
well as the bug fix for checking damage when out of fuel during
practice.
Ftp site administrator: you may remove rars061.*.unix.* files
as they are superceded by this current version.
To the people that were having problems with undefined symbols:
Has the latest version fixed this problem, or are you still getting
> ___ls__FR7ostreamRCt6smanip1ZUl
or what to change to fix the error.
> operator<<(ostream &, smanip<unsigned long> const &)
Randy
---------------------------------------------------------------------------
The rars-digest is compiled and published by (Dave `Gizmo' Gymer)
dgy...@gdcarc.co.uk http://www.mal.com/~dgymer
-- Dave "Gizmo" Gymer Telephone +44 (0)1268 534228
-- General DataComm Advanced Research Centre Ltd, Basildon, UK
-- dgy...@gdcarc.co.uk Team Shark-Porsche online racing
-- http://www.mal.com/~dgymer/ LFRS 95-96 co-director & car #3