From: rars-d-request@lysator.liu.se Subject: rars-d Digest V97 #48 X-Loop: rars-d@lysator.liu.se X-Mailing-List: archive/volume97/48 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 48 Today's Topics: Re: problems. Surface Types Re: Surface Types Illegality Re: Illegality Re: NN link Re: problems Re: Surface Types Re: problems Re: problems. Re: problems. Re: problems Re: problems ------------------------------ Date: Tue, 22 Apr 1997 18:48:24 -0700 (PDT) From: Mike and Suzanne DeHaemer To: Rars mailing-list Subject: Re: problems. Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 22 Apr 1997, Daniel Brooks wrote: > Ok. Now it won't even run. ... > 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). Also may result from rounding errors. For example, at angles of 90 degrees, the hypotenuse and opposite side are equal; however, due to the order of calculations, etc. two numbers which appear identical (e.g. printf shows the same number) but are slightly different internally. Perhaps, one side of your triangle is represented internally as 99.9999999... and the other is 100.0000...1, or something like that, so that when you divide the result is 1.000000...1. I had a similar problem with RARS. I tracked it down by installing my own error handler for the math library. I don't remember the function name off the top of my head but it's something like matherr() (try looking at math.h). As you discovered, the default action of the error handler in the library is to print a cryptic error message and abort the program. But you can be more clever and print out the value of the argument asin was called with and with a little more effort even find out which car caused the problem (a global variable with the index of the currently executing car). As I recall, I found a problem with one of the cars that came with the RARS distribution. Another option is to put an if statement before your call to asin(x). Something like if (x > 1) x = 1; else if (x < -1) x = -1; a = asin(x); (a more obfuscated solution is left as an exercise for the reader). Or use assert(). Good luck. Drop me an e-mail if you need more help. Mike & Suzanne DeHaemer dehaemer@best.com ------------------------------ Date: Wed, 23 Apr 1997 12:39:43 +0100 From: "marsh" To: rars@lysator.liu.se Subject: Surface Types Message-ID: <19970423103833.AAA7464@sztpc04.iabg.de> Is there any way that my robot can detect which surface is being used? I would like to set various variables during initialisation depending on which of the surface types is being used. Am I safe to assume that most of the races will be held using the harder, s1, surface? Matt ------------------------------ Date: Wed, 23 Apr 1997 14:38:18 +-200 From: Torben Thellefsen To: "'rars@lysator.liu.se'" Subject: Re: Surface Types Message-ID: <01BC4FF4.0207A040@pc-5> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit > Is there any way that my robot can detect which surface is being > used? I would like to set various variables during initialisation > depending on which of the surface types is being used. This is something I'd like to do as well (eventually). To my knowledge, no other robot does it, so there's no current code to be "inspired from" :-) My idea is to determine the surface characteristics from the initial acceleration away from the starting grid - your acceleration depends on the grip of the surface. This initial "guess" at the grip can then be adjusted as you go along and try braking and steering. The better your initial guess, the less adjustments will be needed and the car will reach optimum performance sooner (which can be important during qualifying!). When adjusting during the race, there's a risk that your braking and steering will be affected by other cars bumping into you, which can e.g. lead you to assume that the surface gives less grip than it actually does, which makes you brake sooner and drive slower through the corners etc. It's hard to avoid, though, since our cars don't have mirrors... Would anyone else care to comment? > Am I safe to assume that most of the races will be held using the > harder, s1, surface? IMO yes. - Torben ------------------------------ Date: Wed, 23 Apr 1997 14:43:13 +0100 From: "marsh" To: rars@lysator.liu.se Subject: Illegality Message-ID: <19970423124203.AAA11806@sztpc04.iabg.de> Is it illegal to include other headers from the RARS package in your robot driver code, for example having a line such as: #include Also would it be illegal for robot driver programs to call the functions in the RARS package. I assume that both these things are illegal but I just wanted to check. Matt Matt Marsh IABG Ada Validation Facility Einsteinstr. 20 D-85521 Ottobrunn GERMANY Tel. +49 89 6088 3922 Fax. +49 89 6088 3418 ------------------------------ Date: Wed, 23 Apr 1997 15:31:11 +0100 From: "marsh" To: rars@lysator.liu.se Subject: Re: Illegality Message-ID: <19970423133001.AAA13734@sztpc04.iabg.de> On 23 Apr 97, Ralph Scott wrote: > I can't speak for Maido, but I would take it on a case by case > basis. Including os.h might cause a compilation error in any case. > I don't care what else you include. Calling other functions from the > rars package is most likely fine (for instance, the friction or power > functions). But deliberately trying to bomb the program or do other > suspicious activity is not legal. So, regarding my earlier question on surface types it should be relatively simple if I can call friction(), yes? Matt ------------------------------ Date: Wed, 23 Apr 1997 10:52:47 +0300 (EET DST) From: Maido Remm To: rars@lysator.liu.se Subject: Re: NN link Message-Id: <199704230752.KAA07647@ebc.ee> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > > > PS. Has anybody tried a neural network solution yet? I am planning to try to > > > implement a NN-driven car when I have produced my first "normal" car. > > > > I think there was/is a website that discusses this. Does anybody > > remember the URL? > Yeah, I should have reacted to this faster. Take a look at: > http://www.css.taylor.edu/~snelson/rars/index.html > > Kim > I added this link to my RARS web site (main page). Thanks Ralph, for suggestion. Maido ------------------------------ Date: Tue, 22 Apr 1997 10:32:31 -0400 (EDT) From: rscott@NetUSA.Net (Ralph Scott) To: rars@lysator.liu.se Subject: Re: problems Message-Id: Content-Type: text > Well, we fixed one problem only to run into another. After we added > MOVIE.CPP to our prj file, we modified it for our robot and compiled it. > At first we did Debug|Run to compile and run it, but that showed a rars > screen briefly and then the computer rebooted. Then we just compiled it > and went to DOS to run it. It ran fine, but when it went to exit after the > 2 races, the computer rebooted. What are we doing wrong? Surely it cant > have been this bad for every body?! The rebooting problem is a killer. My usual method for this sort of thing is to narrow it down via printfs. 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. ---ralph ------------------------------ Date: Wed, 23 Apr 1997 19:59:12 +0300 (EET DST) From: Maido Remm To: rars@lysator.liu.se Subject: Re: Surface Types Message-Id: <199704231659.TAA14307@ebc.ee> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > > Is there any way that my robot can detect which surface is being > > used? I would like to set various variables during initialisation > > depending on which of the surface types is being used. Try extern int surface; if(surface) do what you want; this worked even without include os.h. If you need, you can include os.h for my races, I don't believe there can be any trouble in compiling if you are getting only command line arguments from that header. I am using extern int lap_count and s.lap_to_go to determine which lap I am on, while optimizing (training) car. Another question was whether functions from carz.cpp can be accessed by driver. I think there was discussion about that when RARS started in 1995 and general consesus was that driver should use only situation structure described in car.h and command line arguments. Using values of randomized friction functions (I don't know how you can do that) would give you exact control over car movement which is unnormal for driver and was considered illegal for RARS driver. Of course it is our common decision to do. Correct me if I am wrong. Maido. ------------------------------ Date: Wed, 23 Apr 1997 18:08:38 -0400 (EDT) From: Daniel Brooks To: Rars mailing-list Subject: Re: problems Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 22 Apr 1997, Ralph Scott wrote: :)> Well, we fixed one problem only to run into another. After we added :)> MOVIE.CPP to our prj file, we modified it for our robot and compiled it. :)> At first we did Debug|Run to compile and run it, but that showed a rars :)> screen briefly and then the computer rebooted. Then we just compiled it :)> and went to DOS to run it. It ran fine, but when it went to exit after the :)> 2 races, the computer rebooted. What are we doing wrong? Surely it cant :)> have been this bad for every body?! :) :)The rebooting problem is a killer. My usual method for this sort of :)thing is to narrow it down via printfs. 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. I like the idea of sounds. I hadn't thought of that. I figure couts would go by to quickly. I did however, narrow it down to 1 of (or both) our cars. I had wipped together a REAL quick car to try an idea, and our class has one we are working on. If I run the race without our cars, it runs fine then reboots. If I have our cars, it locks up before I can begin the race. I didn't have time to figure out which car it was, thought it won't be hard. Also, I tried running it under Windows (grasping at straws), but still have it a DOS program. After it ran, I got an error message saying that the program had issued an invalid instruction, and to save all data and reboot. Well, I tried setting the compiler (Turbo C++ 3.0 for DOS) to compile only with 8088/8086 instructions via Options|Compiler|Advanced code generation. Still no luck. I believe the problem to be in the really quickly thrown together car. I hope I can solve the problem, but the invalid instruction bothers me a little. Thanks for you time, Daniel Brooks | Daniel Brooks -- Email: d-brooks@usa.net | | PGP key fingerprint - DB 10 E4 99 4C B5 86 11 3B 5A BC 56 34 37 57 18 | ------------------------------ Date: Wed, 23 Apr 1997 18:12:26 -0400 (EDT) From: Daniel Brooks To: Rars mailing-list Subject: Re: problems. Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 22 Apr 1997, Ralph Scott wrote: :)> Ok. Now it won't even run. It diplays the track and all the cars and then :)> freezes. This started happening about halfway though class today. Before :)> this started happening, we were testing our car, and sometimes it would :)> be hit from behind and we would get the error :)> :)> asin: Domain Error :)> floating point error: Domain :)> Abnormal program termination :) :)Well, assuming (yeah yeah) that you don't know what this means, i'll :)try to explain it, and hope the list doesn't hate me. :) :)Sine is a function that takes an angle and coverts it into a number from :)1 to -1. :) :)ArcSine is a function that works in reverse. It takes a number from 1 to :)-1 and converts it to an angle. :) :)ArcSine has a tendency to complain when you DON"T give it a number from 1 :)to -1. It looks a little like what you have up there. I had an idea about what it did, but I will check to be sure it gets good numbers for input. maybe that will help my problems. (yea right.) Thanks for all your help, Daniel Brooks | Daniel Brooks -- Email: d-brooks@usa.net | | PGP key fingerprint - DB 10 E4 99 4C B5 86 11 3B 5A BC 56 34 37 57 18 | ------------------------------ Date: Wed, 23 Apr 1997 18:17:02 -0400 (EDT) From: Daniel Brooks To: Rars mailing-list Subject: Re: problems. Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 22 Apr 1997, Mike and Suzanne DeHaemer wrote: :)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). Also may result :)from rounding errors. For example, at angles of 90 degrees, the hypotenuse :)and opposite side are equal; however, due to the order of calculations, :)etc. two numbers which appear identical (e.g. printf shows the same number) :)but are slightly different internally. Perhaps, one side of your triangle :)is represented internally as 99.9999999... and the other is 100.0000...1, :)or something like that, so that when you divide the result is 1.000000...1. Ok, my program uses a divide inside of an asine(). :)I had a similar problem with RARS. I tracked it down by installing my own :)error handler for the math library. I don't remember the function name off :)the top of my head but it's something like matherr() (try looking at :)math.h). As you discovered, the default action of the error handler in the :)library is to print a cryptic error message and abort the program. But you :)can be more clever and print out the value of the argument asin was called :)with and with a little more effort even find out which car caused the :)problem (a global variable with the index of the currently executing car). :) :)As I recall, I found a problem with one of the cars that came with the :)RARS distribution. :) :)Another option is to put an if statement before your call to asin(x). :)Something like :) :) if (x > 1) :) x = 1; :) else if (x < -1) :) x = -1; :) :) a = asin(x); :) :) (a more obfuscated solution is left as an exercise for the reader). :) :)Or use assert(). :) :)Good luck. Drop me an e-mail if you need more help. Ok, lots of really good info. I'll print it out and referback to it as I need, trying everthing there. Thanks for the help, Daniel Brooks | Daniel Brooks -- Email: d-brooks@usa.net | | PGP key fingerprint - DB 10 E4 99 4C B5 86 11 3B 5A BC 56 34 37 57 18 | ------------------------------ Date: Wed, 23 Apr 1997 16:06:32 -0700 From: Christopher D Lund To: rars@lysator.liu.se (Rars mailing-list) Subject: Re: problems Message-Id: <3.0.1.32.19970423160632.008c5c20@carlsbad.ucsd.edu> Content-Type: text/plain; charset="us-ascii" Daniel writes: >On Tue, 22 Apr 1997, Ralph Scott wrote: > >:)The rebooting problem is a killer. My usual method for this sort of >:)thing is to narrow it down via printfs. 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. > >I like the idea of sounds. I hadn't thought of that. I figure couts would >go by to quickly. I hadn't thought of using sounds either. What I HAVE done, in the past, is to use fprintf's to dumpmy 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 ------------------------------ Date: Wed, 23 Apr 1997 21:48:22 -0400 (EDT) From: rscott@NetUSA.Net (Ralph Scott) To: rars@lysator.liu.se Subject: Re: problems Message-Id: Content-Type: text > > > >I like the idea of sounds. I hadn't thought of that. I figure couts would > >go by to quickly. > > I hadn't thought of using sounds either. What I HAVE done, in the past, is > to use fprintf's to dumpmy 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. This is a good thing to know. I got the sound idea from one of the cars. It had code to beep when dead_ahead was set (honking?). Its best used when you can't see your printfs (like on a graphical screen). The file thing never worked too well for me because i didn't know the setvbuf trick. ---ralph -------------------------------- End of rars-d Digest V97 Issue #48 **********************************