From: rars-d-request@lysator.liu.se Subject: rars-d Digest V97 #71 X-Loop: rars-d@lysator.liu.se X-Mailing-List: archive/volume97/71 Precedence: list MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----------------------------" To: rars-d@lysator.liu.se Reply-To: rars@lysator.liu.se (Rars mailing-list) ------------------------------ Content-Type: text/plain rars-d Digest Volume 97 : Issue 71 Today's Topics: Re: Intention Re: Intention Re: Intention Re: Intention Re: Intention Re: Intention Re: Intention Re: Intention Re: Intention ------------------------------ Date: Wed, 30 Jul 1997 09:58:30 -0400 From: Ralph Scott To: Rars mailing-list Subject: Re: Intention Message-ID: <33DF4886.5E81@netusa.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Krzysztof Langner wrote: > > Hi, I was going to wait for someone else to comment, but no one else did. My first comment, as always, is.... How come you aren't submitting your own robots for the tournaments?! > > Introduction > ========= > I would like to propose some changes to rars. But first I should explain > what is the main goal of this project (From my point of view). I think that > we should build a program (robot) which will be able to drive real car. It > means that: > 1. Robot should get this kind of information as real robot can get This will be a tricky one. > 2. Physic of the car should be model as closely as it is necessary for real > robots I don't think anyone will argue with this > 3. Robot should know how to behave in normal race (e.g. how and when go to > the pit etc). Nor this. > > Let me explain point 1 > ================ > To drive a car robot need to see the road, but we can't give him exact > information where he is (how to do this in real world?). My proposition is: What about a localized version of GPS? That is, we have 3 radio beacons on the outside of the track. They all transmit a signal simultaneously, our bot picks up each signal, figures out the order they arrived, and the time difference, and from that figures out its position. > We should put green flags on right side of the track and red on the left. We > can put flag every x meters (lets say x = 100). Of course we should put them > more on the corners than on the straights. The robot can get polar > coordinates of each visible flag. (In real world we can achieve the same > result with radar). In the same way robot need to get information about > others car (polar coordinate of the car with car number). To see what is > behind him robot needs mirrors. in mirrors he can see flags a > This information should be enough to calculate current position, direction > and rotation. But this is not all information we can give to robot. (more > on it in my next post) Ooch, this will be a tricky thing to do. I think most of us here have enough troubles WITHOUT having to go through this! > > Design thoughts > ============ > This simulation should be made in pure Java. No problem here, but I program in it at work. Others are not so lucky. > I know that it could be difficult for many people to program robots with > this kind of information. But I think that robot should be a class derived > from SimpleRobot class. This base class can drive car along the track. > Using virtual function we will be able to improve our own robots without > writing everything from scratch. (So this base class can have some useful > > function like areWeRotating() function). When I post my JavaRars, we can talk from there. Not that it is any good, but it gives us a starting point. > > We shouldn't build all at once. Instead we should prepare basic simulation > and later try to expand this (e.g.. Now we can don't care about tire type, > but we should be able to include them in next version) Fine. > > What I expect from my post? > ===================== > I think about preparing new rars version (can I use this name?). But on the The RARS name is public domain. > other hand I don't want many different version of this project. So If there > are other people which would like my support please feel free to contact me. > If you don't have time to participate in making rars simulator, but have > some comments you are welcome. I know that there are some people which are > involved in making rars simulation like Ralph (thanks for your message), if > you think that we can go together please let me I have no problems at all with this, except that one of my other concerns is to make Rars more popular. I'm not sure making it more difficult, which I see this doing, is going to help. ---ralph ------------------------------ Date: Wed, 30 Jul 1997 19:05:00 From: Maido Remm To: rars@lysator.liu.se (Rars mailing-list) Subject: Re: Intention Message-Id: <3.0.1.16.19970730190500.245791a8@tamm.ebc.ee> Content-Type: text/plain; charset="us-ascii" At 20:49 29.07.1997 +0200, you wrote: >Hi, > >Introduction >========= >I would like to propose some changes to rars. But first I should explain what is the main goal of this project (From my point of view). I think that we should build a program (robot) which will be able to drive real car. It means that: >1. Robot should get this kind of information as real robot can get >2. Physic of the car should be model as closely as it is necessary for real robots >3. Robot should know how to behave in normal race (e.g. how and when go to the pit etc). Really glad to see somebody to have energy to improve rars! As Ralph stated, our current main problem is rather low range of participants. In ligth of that I do not see any benefit from the GPS system. It is not realistic though (IMHO). The current description is OK and is more or less the same that human driver can see and feel with your back in the car (I mean acceleration etc.) The point three seems to be most urgent to me - realistic refueling and repair. If anybody will not do it before, I will take the code one day and will try to add there result.fuel and result.repair + pit lane that is defined in track file. Then everybody can decide themselves whether it needs to go to the pit for repair or refueling. The current system eliminates many unlucky drivers who accidentally are pushed out of track. Also, slow cars that deccelerate or accelerate before/after refueling cause often massive accidents. About point 2: I imagine that adding car setup option (gear ratios, wings suspension) would be neat, but has point ONLY IF WE HAVE RANDOM TRACK AND WHETHER CONDITIONS. Otherwise it takes simply a lot of computer power to compute best setup for each track. Unfortunately the simulation of realistic whether(rain starting and stopping, wind changing direction or speed, local temperature changes due to sun, mud on the track) has not been implemented in any game that I have seen so far and it seems rather difficult for current PC computers, if possible at all. Thus I do not see any benefit from setup option yet. Actually, I see enough work for everybody to get speeds up and passing code to work OK. For improving the RARS itself, some statistics would be good to show online while racing: last lap time, best lap time, track record lap time. Also, a ZOOM option to watch and follow a single car should not be that much difficult (Ralph has tried that in his Java version). If we have ZOOM option, then we can use more realistic car size and track width values. Cannot comment much about perspective of Java. I would be lucky to get RARS running on IRIX to do more optimization on SG 0200. Just my little thaugths, Maido P.S. And certainly try to submit a bot, the competition must go up! ------------------------------ Date: Wed, 30 Jul 1997 13:25:14 -0400 From: Ralph Scott To: Rars mailing-list Subject: Re: Intention Message-ID: <33DF78FA.668C@netusa.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maido Remm wrote: > The point three seems to be most urgent to me - realistic refueling and > repair. If anybody will not do it before, I will take the code one day and > will try to add there result.fuel and result.repair + pit lane that is > defined in track file. Then everybody can decide themselves whether it > needs to go to the pit for repair or refueling. The current system > eliminates many unlucky drivers who accidentally are pushed out of track. > Also, slow cars that deccelerate or accelerate before/after refueling cause > often massive accidents. These are my current thoughts on refueling/repair. 1) KISS. hopefully as simple as pit(fuelAmount, repairAmount); 2) Discourage repairing being a viable alternative to avoiding collisions. Perhaps by making pit time be some factor of repairAmount ^ 2. Possibly also by ruining the tires coefficient of friction. 3) Perhaps make pitting only work on the first segment? Where the pits usually are... 4) The cars are required to slow themselves down. The computer will automatically take over if the car is <60 while in segment #1. > > About point 2: I imagine that adding car setup option (gear ratios, wings > suspension) would be neat, but has point ONLY IF WE HAVE RANDOM TRACK AND > WHETHER CONDITIONS. Otherwise it takes simply a lot of computer power to You are probably correct. I just want to note that the slower cars can use higher downforce for curves, while the faster cars might want to use a lower downforce/less drag. The result might tighten up the races somewhat. But not nearly so much as accurate track widths. ---ralph ------------------------------ Date: Wed, 30 Jul 1997 18:12:46 -0400 (EDT) From: Daniel Brooks To: Rars mailing-list Subject: Re: Intention Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 30 Jul 1997, Maido Remm wrote: :)About point 2: I imagine that adding car setup option (gear ratios, wings :)suspension) would be neat, but has point ONLY IF WE HAVE RANDOM TRACK AND :)WHETHER CONDITIONS. Otherwise it takes simply a lot of computer power to :)compute best setup for each track. Unfortunately the simulation of :)realistic whether(rain starting and stopping, wind changing direction or :)speed, local temperature changes due to sun, mud on the track) has not been :)implemented in any game that I have seen so far and it seems rather :)difficult for current PC computers, if possible at all. Thus I do not see :)any benefit from setup option yet. Weather wouldn't be that hard. it would only be a matter of calling a function after every, say 5 cars, that would update the wind speed and direction, and the rain. Then, add a function to change the "wetness" of the track, and one to change the coefficiant of friction for the track. Also, you might want to have a flag that says how long it's been raining. then, when computing the new position for the current car, add a function to check the wind and make changes for that. True, it would slow the simulations down, but not that much. I can't see it adding more than 5-10 minutes to a set of two races. (or less, if someone has a new computer with a Pentium 2!) Considering how fast computers are becoming, maybe we could even add in the original sumlation for the movement of the pistons! :) :)Actually, I see enough work for everybody to get speeds up and passing :)code to work OK. For improving the RARS itself, some statistics would be :)good to show online while racing: last lap time, best lap time, track :)record lap time. Also, a ZOOM option to watch and follow a single car :)should not be that much difficult (Ralph has tried that in his Java :)version). If we have ZOOM option, then we can use more realistic car size :)and track width values. Yes, we definatly need better sized cars. 15 feet wide is a little large. Hey, maybe we could change the cars to normal size, and just display them bigger until we add the ZOOM stuff?! Would that work? :)P.S. And certainly try to submit a bot, the competition must go up! I would have already, but school ended, and I don't have a good enough computer to use RARS. Now if someone wanted to port it to support monochrome monitors, it would be a different story. I'd be glad to help program the weather stuff, but I deffinately can't fo it alone. TTYL, Daniel Brooks --- __ Daniel Brooks - d-brooks@usa.net, dbrooks@geocities.com / /\ http://www.geocities.com/SiliconValley/Vista/2083 / / \ / / /\ \ HANDLE WITH EXTREME CARE: This Product Contains Minute / / /\ \ \ Electrically Charged Particles Moving at Velocities in / / / \ \ \ Excess of Five Hundred Million Miles Per Hour. / /_/____\ \ \ /__________\ \ \ "We're very sorry, Mister Schrodinger, \_____________\/ but the cat refuses to go in the box." ------------------------------ Date: Wed, 30 Jul 1997 20:50:34 -0400 (EDT) From: Daniel Brooks To: Rars mailing-list Subject: Re: Intention Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 30 Jul 1997, Daniel Brooks wrote: :)On Wed, 30 Jul 1997, Maido Remm wrote: :) :):)About point 2: I imagine that adding car setup option (gear ratios, wings :):)suspension) would be neat, but has point ONLY IF WE HAVE RANDOM TRACK AND :):)WHETHER CONDITIONS. Otherwise it takes simply a lot of computer power to :):)compute best setup for each track. Unfortunately the simulation of :):)realistic whether(rain starting and stopping, wind changing direction or :):)speed, local temperature changes due to sun, mud on the track) has not been :):)implemented in any game that I have seen so far and it seems rather :):)difficult for current PC computers, if possible at all. Thus I do not see :):)any benefit from setup option yet. :) :)Weather wouldn't be that hard. it would only be a matter of calling a :)function after every, say 5 cars, that would update the wind speed and :)direction, and the rain. Then, add a function to change the "wetness" of :)the track, and one to change the coefficiant of friction for the track. :)Also, you might want to have a flag that says how long it's been raining. :)then, when computing the new position for the current car, add a function :)to check the wind and make changes for that. True, it would slow the :)simulations down, but not that much. I can't see it adding more than 5-10 :)minutes to a set of two races. (or less, if someone has a new computer :)with a Pentium 2!) Considering how fast computers are becoming, maybe we :)could even add in the original sumlation for the movement of the pisto Another thing I thought of: we would need to put something in the situation structure that would tell the robot if it was raining or not. That would be important, and a real driver would be able to tell if it was or not. We wouldn't have to do the same with the wind because what driver has his crew tell him which way the wind is from. He might know the starting direction, though. :):) :):)Actually, I see enough work for everybody to get speeds up and passing :):)code to work OK. For improving the RARS itself, some statistics would be :):)good to show online while racing: last lap time, best lap time, track :):)record lap time. Also, a ZOOM option to watch and follow a single car :):)should not be that much difficult (Ralph has tried that in his Java :):)version). If we have ZOOM option, then we can use more realistic car size :):)and track width values. :) :)Yes, we definatly need better sized cars. 15 feet wide is a little large. :)Hey, maybe we could change the cars to normal size, and just display them :)bigger until we add the ZOOM stuff?! Would that work? :) :):)P.S. And certainly try to submit a bot, the competition must go up! :) :)I would have already, but school ended, and I don't have a good enough :)computer to use RARS. Now if someone wanted to port it to support :)monochrome monitors, it would be a different story. :) :)I'd be glad to help program the weather stuff, but I deffinately can't fo :)it alone. :) :)TTYL, :)Daniel Brooks :) :)--- :) __ Daniel Brooks - d-brooks@usa.net, dbrooks@geocities.com :) / /\ http://www.geocities.com/SiliconValley/Vista/2083 :) / / \ :) / / /\ \ HANDLE WITH EXTREME CARE: This Product Contains Minute :) / / /\ \ \ Electrically Charged Particles Moving at Velocities in :) / / / \ \ \ Excess of Five Hundred Million Miles Per Hour. :) / /_/____\ \ \ :) /__________\ \ \ "We're very sorry, Mister Schrodinger, :) \_____________\/ but the cat refuses to go in the box." :) :) __ Daniel Brooks - d-brooks@usa.net, dbrooks@geocities.com / /\ http://www.geocities.com/SiliconValley/Vista/2083 / / \ / / /\ \ HANDLE WITH EXTREME CARE: This Product Contains Minute / / /\ \ \ Electrically Charged Particles Moving at Velocities in / / / \ \ \ Excess of Five Hundred Million Miles Per Hour. / /_/____\ \ \ /__________\ \ \ "We're very sorry, Mister Schrodinger, \_____________\/ but the cat refuses to go in the box." ------------------------------ Date: Thu, 31 Jul 1997 09:48:35 +0100 From: "marsh" To: rars@lysator.liu.se Subject: Re: Intention Message-ID: <19970731073826.AAA8117@sztpc04.iabg.de> Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT > Maido Remm wrote: > > > The point three seems to be most urgent to me - realistic refueling and > > repair. If anybody will not do it before, I will take the code one day and > > will try to add there result.fuel and result.repair + pit lane that is > > defined in track file. Then everybody can decide themselves whether it > > needs to go to the pit for repair or refueling. The current system > > eliminates many unlucky drivers who accidentally are pushed out of track. > > Also, slow cars that deccelerate or accelerate before/after refueling cause > > often massive accidents. > > These are my current thoughts on refueling/repair. > > 1) KISS. hopefully as simple as > pit(fuelAmount, repairAmount); Of course we are still going to have to be careful of cars speeding up/slowing down into the pits... > 2) Discourage repairing being a viable alternative to avoiding > collisions. > Perhaps by making pit time be some factor of repairAmount ^ 2. > Possibly > also by ruining the tires coefficient of friction. Exactly. The fact that repairing will take time should be a sufficient discouragement. > 3) Perhaps make pitting only work on the first segment? Where the pits > usually are... Is it necessary to make this limitation? Surely the extra compication to make it work on any segment is not too much? Matt ------------------------------------------------- Email: matt.marsh@bigfoot.com Webpage: http://asimov.flevel.co.uk/matt/ ------------------------------ Date: Thu, 31 Jul 1997 13:16:42 From: Maido Remm To: rars@lysator.liu.se Subject: Re: Intention Message-Id: <3.0.1.16.19970731131642.092f2648@tamm.ebc.ee> Content-Type: text/plain; charset="us-ascii" At 13:25 30.07.1997 -0400, you wrote: >2) Discourage repairing being a viable alternative to avoiding >collisions. > Perhaps by making pit time be some factor of repairAmount ^ 2. That IS an important point. >3) Perhaps make pitting only work on the first segment? Where the pits > usually are... One have to define more than 1 segment for that. I imagine it can be defined as pit start segment, end segment and radius - length pairs for pit lane to draw it in different color. This needs some repair to 50 track files we have so far. Then, if robot have requested pit stop, and locates in pit_start segment, it will be driven to the pit (or has to enter pit lane by itself and then is serviced by host program). Pit stops will add more strategy and tactic to the RARS. > I just want to note that the slower cars can >use higher downforce for curves, while the faster cars might want to >use a lower downforce/less drag. The result might tighten up the races >somewhat. I do not understand this. How can extra downforce help here? It slows the car down even more on straigths(where it is usually equal to others). I do not understand how downforce will help to gain speed for cars that choose improper lane in curves. An optimal downforce will be the same for slow as well as for quick cars. If I have misunderstood the point, could you please explain this deeper ? ------------------------------ Date: Thu, 31 Jul 1997 09:32:42 -0400 From: Ralph Scott To: Rars mailing-list Subject: Re: Intention Message-ID: <33E093FA.4732@netusa.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maido Remm wrote: > > At 13:25 30.07.1997 -0400, you wrote: > > >2) Discourage repairing being a viable alternative to avoiding > >collisions. > > Perhaps by making pit time be some factor of repairAmount ^ 2. > > That IS an important point. And to continue my thoughts... Pit time = max(repairAmount^2/1000000*Constant, fuelAmount*Constant) Forgetting tires for now. > >3) Perhaps make pitting only work on the first segment? Where the pits > > usually are... > > One have to define more than 1 segment for that. I imagine it can be > defined as pit start segment, end segment and radius - length pairs > for pit I don't see why we have to define more than one segment. > lane to draw it in different color. This needs some repair to 50 track > files we have so far. > Then, if robot have requested pit stop, and locates in pit_start > segment, > it will be driven to the pit (or has to enter pit lane by itself and > then > is serviced by host program). Pit stops will add more strategy and > tactic > to the RARS. Given that we have to define more than one segment, and perhaps fix all the tracks, I would rather just go with all segments being pit areas. Unless we really want to get fancy. > > > I just want to note that the slower cars can > >use higher downforce for curves, while the faster cars might want to > >use a lower downforce/less drag. The result might tighten up the races > >somewhat. > > I do not understand this. > How can extra downforce help here? It slows the car down even more on > straigths(where it is usually equal to others). I do not understand > how > downforce will help to gain speed for cars that choose improper lane > in > curves. An optimal downforce will be the same for slow as well as for > quick > cars. If I have misunderstood the point, could you please explain this > deeper ? Perhaps I don't understand the physics of downforce/drag. But my thinking was this. Not all cars reach the same top speed, the difference can be large. The higher the top speed, the less drag you want (I may be assuming that there is *not* a linear relation between drag and top speed). Some cars might want to swap high speed in the straights (of which they don't have anyhow), with faster cornering (via higher downforce). I will admit I am talking with 0 knowledge, just what I hear while watching the races. Perhaps someone with knowledge of physics can give us the real story??? Do we agree that the cars should slow themselves down? Can we find a way to make cars pulling out of the pits to be less of an obstacle? Knowing where the pit is can help someone right a routine to be extra cautious in that segment(s). ---ralph ------------------------------ Date: Thu, 31 Jul 1997 13:40:42 -0400 (EDT) From: Daniel Brooks To: rars@lysator.liu.se cc: rars@lysator.liu.se Subject: Re: Intention Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 31 Jul 1997, marsh wrote: :)> Maido Remm wrote: :)> :)> > The point three seems to be most urgent to me - realistic refueling and :)> > repair. If anybody will not do it before, I will take the code one day and :)> > will try to add there result.fuel and result.repair + pit lane that is :)> > defined in track file. Then everybody can decide themselves whether it :)> > needs to go to the pit for repair or refueling. The current system :)> > eliminates many unlucky drivers who accidentally are pushed out of track. :)> > Also, slow cars that deccelerate or accelerate before/after refueling cause :)> > often massive accidents. :)> :)> These are my current thoughts on refueling/repair. :)> :)> 1) KISS. hopefully as simple as :)> pit(fuelAmount, repairAmount); :) :)Of course we are still going to have to be careful of cars speeding :)up/slowing down into the pits... :) :)> 2) Discourage repairing being a viable alternative to avoiding :)> collisions. :)> Perhaps by making pit time be some factor of repairAmount ^ 2. :)> Possibly :)> also by ruining the tires coefficient of friction. :) :)Exactly. The fact that repairing will take time should be a :)sufficient discouragement. What units are we talking about, as far as time goes? Seconds? Milliseconds? What? :)> 3) Perhaps make pitting only work on the first segment? Where the pits :)> usually are... :) :)Is it necessary to make this limitation? Surely the extra compication :)to make it work on any segment is not too much? I think it is. We are striving for an element of realism, and a real driver can't just stop anywhere he wants and refuel. I also think the track files should include a couple of entries that define the pit area. YOu would include info like width, length, start coords, end coords, left or right side of the track, stuff like that. It would need to be drawn on the screen, and we might want to have individual stoping places that the pit() function goes to. (I would want it to calculate the fastest way to get there to, have the car smoothly deceleratet to a stop, the accelerate as fast as possible to leave, know what I mean?) We should maybe provide a bare bones pit() function, but use overloading to allow the robot to provide it's own, and have another function that repairs the car, refuels ect. That way it is done consistantly. Also, maybe the time could be a little more random, say 10s with a random amount up to 3-4s added on, because no pit stop takes exactally 12s. Then you would add on time for repairs, maybe repairAmount^2 or what ever, then with a small random amount added on, maybe an extra couple of seconds. TTYL, Daniel Brooks _______________________________________________________________________ __ Daniel Brooks - d-brooks@usa.net, dbrooks@geocities.com / /\ http://www.geocities.com/SiliconValley/Vista/2083 / / \ / / /\ \ HANDLE WITH EXTREME CARE: This Product Contains Minute / / /\ \ \ Electrically Charged Particles Moving at Velocities in / / / \ \ \ Excess of Five Hundred Million Miles Per Hour. / /_/____\ \ \ /__________\ \ \ "We're very sorry, Mister Schrodinger, \_____________\/ but the cat refuses to go in the box." -------------------------------- End of rars-d Digest V97 Issue #71 **********************************