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
revised rules
Re: Collision Code
Re: EE Times RARS Article
Re: example header of a robot driver file
Re: Collision detection (m replies to Carl)
RARS Version 0.63b
Race Reports
--------------------------------------------------------------------------- I just sent a revised "rules" file to the ftp site. Here is a copy for you: RARS Race Meet Rules These are the rules and procedures for the races that are hosted by The following are general rules that apply to all the races. For Entries will be received by e-mail, directed to m...@cac.psu.edu. The Robots may read a data file. Hence, the entry may consist of two The robot driver function name should be identical to the name string There are some information requirements for the first few lines of 1. the filename, your full name, your e-mail address, and your robot's name. 2. What races you want to enter. You can say all, or all oval track, 3. Whether or not you want me to keep the source confidential. 4. Tell me if your program needs to read a data file. If you send me a uuencoded object file, then send me a message The filename must change for each new version of your software. The If your robot reads a data file it must be sent at the same time as The software version to be used for each race meet will be announced Entries must be received by 1:00 PM, U.S East Coast time, on the day Any robots that cause run-time problems with any part of the Points will be awarded as follows for each race: 1st - 10 2nd - 6 3rd - 4 4th - 3 5th - 2 6th - 1 This point system will be used both for deciding the winners of one If there are sixteen or less entries, then all will compete in all Robot code should not make any direct DOS or BIOS calls, nor access Each robot must use no more than 25K of RAM, both for its code and When no prizes are involved, then Mitchell Timin or his close All robot drivers that I receive will be held in confidence until Don't expect me to do any kind of tuning or adjusting or debugging to CLASSES: We will now have two classes of authors, Novice and Expert. Number of novices competing Number who move to expert The novice races will always be run first. Those that advance to Whenever there are less than sixteen expert competitors then some of the Just thought I'd put in my opinion on the matter: :) I'm not too good with physics yet, so I couldn't say which is more realistic, m: There is even a graphic of the race track posted there with an IMG command. Since it is a network story, it went into EETimes-Interactive on the web, (News briefs are only saved for one week then flushed from the system.) Hello All, Nicole was the first person to submit a robot with a header meeting my > Please keep this file confidential! Hello Rartians, I have just uploaded rars063b.zip to the uploads directory. This will probably be used for the races this Sunday. The only changes There were several minor changes, some bug fixes, and a couple of Authors: If you detect another robot within touching distance, you should A final reminder to all competitors to get a new version to me, with a Thanks to Bill Benedict and Nate Thurston who contributed code and ideas. This won't affect the oval track races, but the cars motion during One user option has been added, -D, which lets you name one or more Hello All, In response to Dan Ash's inquiry, I have dug up four race reports, The rars-digest is compiled and published by (Dave `Gizmo' Gymer) # Dave "Gizmo" Gymer dgy...@gdcarc.co.uk http://www.mal.com/~dgymer/
From: "Mitchell E. Timin" <m...@cac.psu.edu>
Subject: revised rules
To: rars-l...@netcom.com (Rars- List)
Date sent: Thu, 13 Jul 1995 11:26:35 -0400 (EDT)
Mitchell Timin. These rules are subject to change at any time, but
any such changes will be announced to the mailing list a reasonable
time before they go into effect. Anyone else can also host races,
and they are free to design their own set of rules if they wish.
each race there will be an announcement that will detail any special
requirements for that race.
entries are of course, robot driver functions. They may be in source
code, either ANSI C or C++, or they may be object files, to be linked
with Borland C/C++version 3.1. Source files will be compiled with
that compiler. Object files should be uuencoded for transmission by
e-mail. It will also be acceptable for object files to be placed in
the "uploads" directory of our ftp site, and notifying me by e-mail
that the file is there. I will delete it from the uploads directory
as soon as I download it.
files, the program file and the data file. The filename for these
two files must be the same, except for .dat extension on the data
file. The robot file will have the extension .cpp or .c or .obj.
contained in the program. There should be no more than eight
characters in the name, and it must follow the usual C/C++ naming
rules. Therefore, if we have a robot driver named "Charlie" the name
of its function would be Charlie(), and it would be in a file named
CHARLIE.CPP and if it reads a data file the file would be named
CHARLIE.DAT. The filename should not differ from the robot name by
anything more than a sequence number at the end, and the lack of
case distinctions.
the program file. The first few lines of every robot driver must have
the following:
or just one date, for example. (Just be clear.)
with the above information in it. If you place a .obj file on the
ftp site, the accompany it with a .txt file with that information,
and a .dat file if one is needed.
easiest way is just to append a sequence number, so when BURNS.CPP is
changed it becomes BURNS1.CPP, and then BURNS2.CPP, etc. The robot
name and the function name should not change. For example, they
could remain "Burns" and Burns(). Of course you may rename all three
if you want to, and then the filename should be the same as the robot
name and function name.
the robot file. You must send a new data file when you send a new
robot. They should always be sent in pairs to help keep me from
using the wrong data file. It would be best if your data file began
with its own name, and the robot checks it when it reads it, but I
won't require that. You may send a new data file to go with an old
robot, but also send a text file giving its file name, so that I know
for certain which robot it goes with.
in advance. It will generally be the lastest version, or the one just
before that one. Needless to say, the programs must compile and link
with that version.
of the competition. If the net is slow, too bad, so send them as
early as possible. It is better if I receive them several days early,
in case there are any problems with compilation, linking, or
execution. (I will inform you A.S.A.P.) All problems must be
corrected before the 1:00 PM deadline. Finally, I won't accept any
new entries prior to one week before the competition. However, if I
already have your robot from a previous race you don't have to submit
it again. I will use the information in your robot program to know
in which races it should compete. Only one robot per author will be
allowed to compete, so if you have sent me more than one make it clear
which one is the entry.
software, including the other robots, will be disqualified. Timin's
judgement will be final here. In particular, check every division to
ensure that the denominator will never be zero. The same applies to
certain mathematical functions that can have illegal arguments, such
as sqrt(). If you allocate RAM, with "new" or malloc(), be sure to
do it only once, even if there are multiple races. (We can't have
you accumulating more RAM with each race!) Also check for
un-initialized variables that can cause seemingly random behaviour.
race meet with multiple races, and also for accumulating over a
period of many months. When there are multiple races the winning places
will be based on the point total for all races. When the race meet
consists of only one race the points will be added to the robot
author's accumulating score. For multiple races, another set of
points will be awarded to the best six robots of the day, and these
will be accumulated for the longer term. Hence, for each race meet,
someone will add 10 points to his long term total, someone will add 6
points, and so on.
races. If there are more than sixteen, then each robot will be run
by itself for four laps to establish its average speed. The sixteen
robots with the highest average speed will compete. If the race meet
is to use more than one track, then I will use only one track for
this purpose, it will be the longest track of those to be used.
memory in any strange ways. No peripheral hardware may be accessed,
with the possible exception of disk reading during initialization
(but see next paragraph). Robots may use the "extern" keyword to
access any data that they can find, but may not alter such data. Any
robot driver function that causes any problems with any other part of
the software will simply not be used. Mitchell Timin's judgement
will be final in this matter.
data. Each robot must execute in no more than 3 milliseconds (on a
DX2-66) each time that it is called, after initialization. In
practice this just means that the race can be run at realistic speed,
and no slower.
associates and family members may compete. They may not compete
for prizes.
after the races are completed. After that I will put them on the ftp
site. Also, I will not announce performance figures for the early
entries prior to race day. For those authors that request it, I will
place the .obj file on the ftp site rather that the source code.
any robot. Every entry must be ready to race, or it won't. I will
notify the author A.S.A.P if there are problems, but that might take
a day or two, or even three. (Although usually it will be a matter
of a few hours.)
All races will be run twice, once for novices and again for experts.
An expert is defined as any author that was among the leaders in in a
race meet according to the following table:
14 - 16 5
11 - 13 4
8 - 10 3
5 - 7 2
4 1
expert class will also be qualified for the expert races. (They will
be treated the same as any other expert entry.)
faster novice robots may be raced along with the experts. They will not
lose their novice status unless they place among the leaders according
to the above table.
---------------------------------------------------------------------------
From: JXi...@aol.com
Date sent: Thu, 13 Jul 1995 18:18:30 -0400
To: rars-l...@netcom.com
Subject: Re: Collision Code
but Bill's is definitely more efficient, in that it seems to correct these
pileups. The much-mentioned pileups are apparently caused by the 10% power
decrease, which means that very quickly, a whole pack of cars just starting
can turn into a multi-car pileup moving at ~10 mph. Another problem (that
is, with the original .62 code) is when two cars are trying to pass each
other in a turn (or otherwise), and they meet side to side. This apparently
generates two collisions, because both of them immediately slow down, *and
continue slowing down*. This causes a slow point in the entire traffic flow,
often causing another large pileup. (sometimes of all the cars, if it happens
to be 1st and 2nd having it out) Bill's model also seems to make passing
more interesting (is that good? :) on oval2. For example, in Bil's model,
two cars, A and B, B behind A, with B moving faster than A, and trying to
pass. What happens quite often: A approaches the turn, B approaches also,
but moving faster than A into the turn. B hits A in the rear, taking a bit
of damage, but also accelerating A into the turn. A then, unable, or
unprogrammed, to cope with external forces, skids and slips around the
outside of the turn, allowing B, moving faster through the inside, to pass A.
There are quite a few other interesting scenarios.
::scrolling back up:: Whew... Well, in a nutshell, I think Bill's revisions
are better, and would like to see them implemented for the next race.
---------------------------------------------------------------------------
Date: Fri, 14 Jul 1995 14:53:08 -0700
Message-Id: <199507142153.OAA21...@desiree.teleport.com>
To: "Mitchell E. Timin" <m...@cac.psu.edu>
From: cogni...@teleport.com (Colin Johnson)
Subject: Re: EE Times RARS Article
>The fellow whose address you gave me never responded.
>No one I know has seen it.
>Do you know if they ever published it?
>RARS is still alive and well, and the participation is slowly growing.
>The robots are getting smarter.
at: http://techweb.cmp.com/techweb/eet/current/notepad.html
The annual race's results are also posted there as is the various WWW pages
about RARS.
rather than on the printed version of the newspaper. The initial
announcement was also posted on the web, but is long gone since it went on
the regular daily news postings to:
http://techweb.cmp.com/techweb/eet/current/default.html
---------------------------------------------------------------------------
From: "Mitchell E. Timin" <m...@cac.psu.edu>
Subject: Re: example header of a robot driver file
To: Nicole.Grei...@fernuni-hagen.de (Nicole Greiber)
Date sent: Sat, 15 Jul 1995 12:48:20 -0400 (EDT)
Copies to: rars-l...@netcom.com (Rars- List)
new requirements. Here is the header from her robot driver file. Using
it as an example should make it easier for everyone else:
> Date: 07/15/95 (to definitely indicate the most recent version)
> Filename: marvin1.cpp
> Author: Nicole Greiber
> e-mail: Nicole.Grei...@Fernuni-Hagen.de
> Robot: Marvin
> Races: All! This driver replaces any drivers that were submitted
earlier
> The robot doesn't use any data files.
> ***************************************************************************
From: "Mitchell E. Timin" <m...@cac.psu.edu>
Subject: Re: Collision detection (m replies to Carl)
To: cbu...@mitre.org (Carl D. Burke)
Date sent: Tue, 18 Jul 1995 22:47:56 -0400 (EDT)
Copies to: rars-l...@netcom.com (Rars- List)
> I was looking through the code trying to improve my collision-avoidance,
> and have been a little chagrined about 'observe'. Too many times, cars
> cut off cars whose centers are slightly behind them, and thus don't show up
> in 'nearby', but which still overlap a bit. The leading car not only has
> no mirrors, but can't look sideways! The (slightly) trailing car is left in
> the position of braking HARD to try to avoid a collision, and usually
> can't succeed fast enough. The lead car knows it took damage, but has no
> idea where it came from.
> I'd like to be able to prevent collisions by looking before I change lanes,
> but I can't see a car there unless it's ahead of me (and then IT can't see
> ME!). Can we get this fixed, or does my driver need to access pcar[]
> directly?
as what to do when one is detected. It is complicated attempting to balance
good gaming, fast execution, reasonable realism, and not rewarding
undesirable behaviour by a cunning robot. I expect to release 0.63b this
week. I expect it will be a substantial improvement, but not perfect.
---------------------------------------------------------------------------
From: "Mitchell E. Timin" <m...@cac.psu.edu>
Message-Id: <199507202026.AA23...@wilbur.cac.psu.edu>
Subject: RARS Version 0.63b
To: rars-l...@netcom.com (Rars- List)
Date: Thu, 20 Jul 1995 16:26:45 -0400 (EDT)
that will affect the race involve collisions. The net affect is to enable
most cars to finish the race most of the time. (I'm speaking of 10 laps
on oval2. 80 laps on S? are still difficult, but a little less so.)
significant things. The main reason for less damage now is that damage no
longer occurs while the cars are moving away from each other after a
collision. When a collision occurs the cars usually move closer for a
while, and then gradually separate until they are no longer colliding.
This can take a large fraction of a second. The damage accumulates during
this interval.
steer away from it, as it is damaging you! The faster you get away, the
less damage. (But straighten out ASAP, or you will lose time and maybe
hit another car.)
header like I described earlier, and a unique filename. Write to me if
you are not sure about what is required.
(But we are not done with collisions yet!)
refueling has been made more realistic and natural, and with much less
damage.
drivers to NOT be entered in the race.
---------------------------------------------------------------------------
From: "Mitchell E. Timin" <m...@cac.psu.edu>
Message-Id: <199507202342.AA24...@wilbur.cac.psu.edu>
Subject: Race Reports
To: rars-l...@netcom.com (Rars- List)
Date: Thu, 20 Jul 1995 19:42:55 -0400 (EDT)
One from May, two from June, and one from July. I will send them
to whomever requests them.
---------------------------------------------------------------------------
dgy...@gdcarc.co.uk http://www.mal.com/~dgymer
/* DANGER! This tagline is still under construction. */