2. Adding robot drivers
I downloaded some more drivers from WWW site.
How can I compile them into Rars? How can I add my own driver?
For changing drivers you should edit file drivers.cpp. You should replace
one of the existing robot's name (and/or colors) in robot's list AND in
drivers array. Robots name can be found in robots file on line con_vec
ROBOT_NAME(situation &s) It might be different from what robots shows
on screen. Also, change robots filename in makefile. That's all. Nevertheless,
if you are ADDING robots to drivers[] array, you should increase constant
MAXCARS in the beginning of file car.h
I have programmed a car nearly from scratch which
seems to be pretty efficient, it nearly finishes all tracks at third position
which seems to be quite good. Could it be possible to download the latest
versions of other players in order to compare its car against others?
Most of the robots are available from my robots
page. Some additional robots are also in FTP
site.
3. Status of RARS
Could you tell me what is the current status
of RARS?
Status is active :-), with one current season on F1 tracks and several
occasions of other competitions. Check out announcements
about current racing series.
I have heard of a 3 dimensional version of Rars,
does it really exist ?
If you mean 3D-graphics of RARS then check out Marc
Guery's page. It looks nice, but it is not universally ported to all
platforms (needs OpenGL).
3D model for track description was planned as a part of RARS
2 (see next question).
What is the status of RARS 2 (OORARS)?
Here is a short comment from Kim Laurio:
>There has not been any substantial additions since the progress
>report was released to the public at 7 January 1997.
>This page should give you
>a pretty good picture of the current status. No coding was done
>(except for some minor tests to evaluate the CPU-usage of some
>algorithms).
>I'd suggest that you'd at least take a quick glance on that text to see
>where we were and what we thought of. It is not part of any 'overall'
>continuity/design plan of RARS, it's just a bunch of ideas that you are
>free to use or not. For a good introduction to tire physics,
>I'd recommend that you read the short text by David Sparks;
>that should get you up and running in no time.
>If you have any questions, I'll do my best to answer them.
>Although I certainly don't have time to do any work with coding,
>feel free to send me any ideas that you want feedback on.
>Here is the main page for OORARS.
>Good luck! Kim Laurio
4. RARS source code
AIX: tkn@VNET.IBM.COM (Thomas K. Netousek):
I have done a "port" of the linux version to AIX.
It is a matter of some #include's #ifdef'd AIX
Amiga: m.f.offermans@wbmt.tudelft.nl (Marcel
Offermans):
Amiga version Release 3, based on the RARS 0.60 sources.
Special requirements:
Where could i find the latest versions of Rars
?
http://www.ebc.ee/~mremm/rars/software.htm
http://evolution.bmc.uu.se/~maido/rars/software.htm
Latest for DOS and UNIX systems is version 0.72b.
For VC++ on Windows 0.71c.
For OS2 - 0.67,
For Amiga 0.65
I've downloaded Java version of rars. It looks
great, but: how can I make my own robot in Java?
Is source code of Java version available?
Ralph can probably answer
that question.
I don't think it is possible to adjust just the last curve.
The way I do it is to have my car driver code print out the
start and end coordinates in its setup routine.
I then use that to determine how far I'm off, find a straight
that is approximately equal to the direction I want and just
adjust that straight. ---ralph
I use a program called TRACKEDT (I think!). It tells me by
how much the ends don't meet, both in angle and x,y. I then
fiddle with the track to make the ends meet.
Usually I'm content with a deviation of <1 ft in either direction :-)
I'm quite sure that I found this utility on the RARS ftp site
somewhere (sorry, that's as precise as I can remember it).
A GUI-ish tool to assist in track-building would be much
appreciated - anyone? ;-) - Torben6. Car flashing
7. Alpha, vc and distances.
What is alpha? How is it measured?
Alpha is angle between your car's velocity vector
( which direction your car is moving) and your cars pointing vector (which
direction your car's body is). It is measured in radians. It is positive
when your cars body is pointing left from direction of motion and negative
if your car's body is rigth from your direction of motion. Alpha is set
according to your request (result.alpha) and it can be thougth as how much
you turn your wheels (or steering wheel). It is not entirely realistic,
because real car does not turn its body instantly when you turn the steering
wheel. That is the reason why alpha is sometimes compared to "angle of
attack" from aeronautics.
What is vc? How is it measured?
Vc is "velocity commanded" - the desired speed
you set with your robot code. It is measured in feets per second as most
other speed variables inside the RARS code. You can set vc higher than
your s.v (current speed), which gives you acceleration or lower than s.v,
which gives you braking.
Of course you do not get your desired vc instantly
- real situation will depend on traction and physics. For example if you
ask for vc=0, you just block your wheels and slide straigth until you stop.
If you set vc=1000, then RARS program calculates how much power you have
and sets the real vc according to it (you get maximum acceleration that
your car's engine can afford).
IMHO, vc should be replaced by other variable
(between 0 and 1)- that measures fraction of throttle opening. But this
needs major rewrite of rars physical engine (fraction of throttle_opening
is not equal to fraction of requested power).
Also, I was wondering, if I am 15 feet from the
left wall, does this mean my left edge is 15 feet away from the wall, or
is my center 15 feet from the wall?
s.to_lft and s.to_rgt (as most other distances) is measured
from the center of the car.
Remember, s.to_lft + s.to_rgt = track.width.
8. Understanding s.nearby
How to use variables in s.nearby for passing
function?
>I've been working on my passing algorithm and have just realized I'm
>not sure about the data I get from s.nearby[x].rel_x. For
>s.nearby[x].rel_y, I believe the data given is the distance to the
>front of the car. But for
>s.nearby[x].rel_x is the data given back the distance to the left edge
>of the car, the right edge of the car, or the center of the car? Does
>it matter if the car is to you right or left (e.g. s.nearby[x].rel_x
>is the distance to the nearer edge of the car)? I'm going to
>investigate this when I have some free time but if anyone already
>knows the answer I would appreciate it.
Both rel_x and rel_y are related to the center points of the cars.
So the check (s.nearby[x].rel_y - CARLEN < 0) works (somewhat,
depending on rotation of cars wrt velocity) for checking
if you're bumping into a car from behind.
What coordinate system are rel_x and rel_y based on?
They're not based on y pointing down the track and x to the side walls.
They're not based on my car's pointing vector (aligned with alpha).
They're based on the velocity of my car.
So it's not easy to determine an absolute position of the other car.Since version 0.71, you can use car's public variables for finding their absolute X and Y position.
For that use:
extern Car* pcar[];
othercar_x = pcar[other_car_ID]->X;
othercar_y = pcar[other_car_ID]->Y;
Car ID is based on drivers[] array (pcar[0] is first car from drivers
array and so on, see drivers.cpp). It is also the same order that cars
appear on scoreboard.
See car.h: Class Car{public:} for other available variables.
>Also in this same area, is s.to_lft the distance from the center of my
>car to the left edge of the track or from the left edge of my car to
>the left edge of the track?
Center of car to edge of track. (s.to_lft + s.to_rgt = width)
However offroad (and damage) isn't set until your center goes off the track.
(s.to_lft < 0.0)
>Let's say the car width is 9 feet and s.nearby[x].rel_x gives back a
>value of 3.13. Am I in contact with that car? or is there 3.13 feet
>bewteen the right edge of my car and the left edge of his car?
Yes you are in contact, but the bumping algorithm isn't invoked if you're
moving apart.
>If I'm trying to go between two cars do I need there to be 9 feet
>between there respective s.nearby[x].rel_x or 18 feet (4.5 feet for
>each car - if s.nearby[x].rel_x is the center of the car and another 9
>feet for my car - a tight fit :))
You need 18 feet. You can get this once you know that rel_x, rel_y are
based on the centers of the cars. Currently, for my driver, I'm trying to
calculate the other car's to_rgt and to_lft to see if I should go inside or
outside of that car. With the rel_x and rel_y being based on velocity vector,
rather than a more fixed coordinate system, I'm having difficulties.
>Just to clarify, does this mean that s.nearby will hold ALL cars in front
>of my car, not just the nearest 5?
Currently just 5. This is defined by constant NEARBY_CARS in car.h
>And is there a maximum distance for the cars in front before they're dropped
>off the s.nearby list?
No, it works just like the previous version, the closest
three cars on your current segment or the next segment. "Closeness" is now
measured by position on the track, not distance from your car.
>> s.nearby[].alpha - The other car's current alpha.
> >Relative to what?
This is the same alpha as your car, the angle between the path of motion
and the angle of the body. You need it to determine the angle
of the other car's body wrt your car. This is related to the problem you were
relating about not knowing how much of the track the other car was blocking.
>> and what is "int braking "?
Set to 1 if the car.s is reducing its speed by more than 5 fps, 0 otherwise.
For other available variables for nearby cars see car.h: struct rel_state
> I am getting following error message. What's up?
> asin: Domain Error
> floating point error: Domain
> Abnormal program termination ...
> Our robot does use asin.
A domain error indicated that the input to the function is invalid.
For asin(x), x must satisfy -1 <= x <= 1. Either your car or
someone elses car is calling asin() with a bad value - possibly
a result of a not checking boundary conditions (i.e. what
happens at the extremes).My robot has a bug that reboots the system. I cannot find where is it.
>:)The rebooting problem is a killer. My usual method for this sort of
>:)thing is to narrow it down via printf's. If they go by too quick,
>:)then I try sounds. Different pitches at different points in the
>:)program. This should at least get you to within 5-10 lines of the
>:)problem spot, if you can't take it from there, try getting back to
>:)the list with your new found knowledge.
What I HAVE done, in the past, is to use fprintf's to dump my
debug data to a file and look at the result after the carnage flies.
The only thing you have to do for this method is:
setvbuf (file, 0, _IONBF, 0); This makes the stream unbuffered so
that each fprintf goes right to the file. Otherwise, the line you
are looking for may be in the buffer at crash time and you wouldn't
know it. To the best of my knowledge (and Borland's help file),
the line I gave is standard from stdio.h. - Christopher Lund
Torber writes:
I've had very good experiences with this little function
(transcribed from memory, actual syntax may vary):
void DEBUG(char *dumpstr) {
FILE *fp = fopen("dumpfile","ra");
if (fp) {
fprintf(fp, "%s\n", dumpstr);
fclose(fp);
};
};
// Use: DEBUG("Here we are"); A couple of points here...
It writes all your debugging messages into a file (here: "dumpfile"),
closing it after every write so that no messages are lost.
That's the thing I like about the setvbuf method I wrote of yesterday,
namely, you don't have to open and close the file for each write.
In any event, if you setup your function as: void DEBUG
(char *dumpstr,...) and then use vprintf in <stdarg.h>
(again, a function I believe is standard across platforms),
your debug function can be used to dump variables to the file as well,
easing the debugging further. - Christopher Lund10. Optimization of the car
Just a very simple and slow trial and error procedure:
A given racing line is modified slightly, then some laps are run.
If the car becomes faster, the modification is accepted.
This is repeated thousands of times until the car is very fast.
The racing lines are stored in strings that look like gene sequences,
but the algorithm is no GA according to the definition of GA that
someone posted to the list last year. HenningOther people have used Neural Networks, Genetic algorithms,
What is the simplest working robot?
In 1996 we had "midget" competition for cars less than 450 characters.
Some of the midget competitors are still available.
One example of short and efficient robot is here:
#include "car.h" con_vec hk(situation&s)
{ my_name_is("hk");
con_vec r={(40-s.to_rgt-s.vn)/9, s.dead_ahead?.9*s.vc:60+s.to_end/4}; stuck(s.backward,s.v,s.vn,s.to_lft,s.to_rgt,&r.alpha,&r.vc);
return r;
}
Actually I used 3 copies of the same robot on that race day.
The only differences were the names and some whitespace
added so they could run in all three size classes. You can
use it as a demo robot. It demonstrates how easy it is to win
a race with a very simple robot. On adelaid2 the triple won
place 1, 2 and 3 and on brazil place 2, 3 and 4! ;-) Henning
11. RARS WISHLIST
1. Zoom or more realistic 3D view from inside the car.
2. 4-wheel driving car, with suspension and gearbox.
2. Timelimit for each robot to make it's calculations.
3. Various improvements in reality of track and car setup.
4. Realistic weather conditions