 ICFP 2003
started 6/18/2003; 1:15:36 PM - last post 7/2/2003; 11:48:32 AM
|
|
andrew cooke - ICFP 2003 
6/18/2003; 1:15:36 PM (reads: 1680, responses: 7)
|
|
| ICFP 2003 |
|
Next weekend (that being the weekend after this weekend)!
For those who don't have that much free time, but do have a good supply of coffee, don't forget the 24 hour lightning division.
I did search, and was surprised to find no reference here on this year's contest, so apologies if I missed something
Is the picture a clue? Are Ferrari really sponsoring a competition to find a new AI for their lead driver?
Posted to fun by andrew cooke on 6/18/03; 1:21:32 PM
|
|
|
|
Chris Rathman - Re: ICFP 2003
6/18/2003; 9:04:01 PM (reads: 760, responses: 0)
|
|
|
Way off-topic but... :-)
Don't know about the pro-circuit, but I did work a little with a person that was developing embedded apps for amatuer drag racing. In that particular circuit, they don't allow digital controls - much less computer controls - pneumatic controls were the requirement. They did, however, allow an on-board computer to monitor the performance of the run but with no real-time telemetry. The drag racing cars had to be torn apart after each run - they have almost no oil left after the 5 seconds of track time. They'd use the data to tweak the cars in between runs.
|
|
Ehud Lamm - Re: ICFP 2003
6/29/2003; 2:23:06 AM (reads: 490, responses: 1)
|
|
|
The object of this year’s programming contest is to drive a simulated car around
a set of racing tracks as fast as possible.The solutions you submit will consist of
a trace of the commands you give to the car at each moment of the simulation.
We will run your commands on our simulator to determine your finishing time,
and the team with the best overall performance will be crowned the winners!
Since your submission is just a set of traces,we will not need to run your
program on our computers,which means you may use any programming language
for which you have an implementation.You may also,if you wish,write
an interactive program and “drive the car”yourself to construct the trace,al-though
it is unlikely this will beat a calculated or post-optimized trace.If you
have a super-computer available,you may use it.If you can harness a thousand
workstations to search for the fastest trace,good for you!You can even write
the trace by hand (although we don’t recommend it!).
|
|
andrew cooke - Re: ICFP 2003
6/29/2003; 5:07:17 AM (reads: 488, responses: 0)
|
|
|
the following link isn't going to help people, i suspect, since the simulation seems to have some restrictions (no turning while braking, for example, until you get to the rally circuit), but there's an interesting discussion of the physics of car racing at http://www.dur.ac.uk/r.g.bower/PoM/
incidentally the track format they're using is almost identical to the png image format - the conversion tool they provide must do no more than change r to "255 0 0" etc.
maybe it's because i've thought about how to do this in the past, but this doesn't seem as tricky as earlier problems.
i guess the "use a supercomputer if you want" approach is going to be controversial, since i'm sure that there must be some optimisation involved. it'll be interesting to see how hardware availability biases things.
|
|
andrew cooke - Re: ICFP 2003
6/29/2003; 5:09:34 AM (reads: 465, responses: 0)
|
|
|
i wonder if the oracle will become overloaded with automated submissions? if so, i don't see how they can fairly load balance.
|
|
Frank Atanassow - Re: ICFP 2003
7/2/2003; 10:23:20 AM (reads: 424, responses: 2)
|
|
|
We had a team of people here at the Utrecht Software Technology group involved. (I didn't participate.) They made a nice-looking GUI for choosing paths on the racing maps, using Daan Leijen's forthcoming wxHaskell, a wxWindows binding. I was a bit disappointed to learn that the program does very little motion-planning, though, which is a shame because our computational geometry group upstairs is well-known for their work on that subject. (None of them participated either.)
Apparently our team found some solutions with a shortest path algorithm and then used the GUI to `nudge' them manually towards (apparent) optimality. I wonder if any team used a pure computational motion-planning approach?
|
|
andrew cooke - Re: ICFP 2003
7/2/2003; 10:50:20 AM (reads: 433, responses: 0)
|
|
|
i'm surprised they attacked the problem that way round (computation first, then optimisation by eye) - i guessed that successful entries would have used a gui to find an initial solution and then optimised numerically (brains being good at identifying good general solutions, but poor at details). the tricky part, it seemed to me, was finding a way to parameterise the path so that the free variables were small in number and uncorrelated. the best parameterisation i can come up with is a set of "turns" where each "turn" is parameterised by strength, duration and centre point (over distance travelled, rather than time, to avoid correlations with equivalent functions that control acceleration/braking).
in other words, by default the car continues in a straight line, but when inside the parameters defined by a "turn", the car turns. once a gui is used to find an intitial set of those functions that get the car from start to finish they could be optimised in the usual way (hessian with 2nd dervis from 1st, cholesky etc etc).
i guess that solution seems obvious to me because it's almost exactly what i had to do for a job, once (calculating the shapes of cables towed in the water behind boats).
|
|
Daniel Yokomiso - Re: ICFP 2003
7/2/2003; 11:48:32 AM (reads: 431, responses: 0)
|
|
|
There are entries about some submissions available at: http://www.cs.chalmers.se/~een/icfp/
Some teams used a pure computational motion-planning approach, and they're the ones likely to win. Following the links one of the teams decided to follow a "trace all paths and choose the best" route, and his times are good.
Our team used a different strategy. We tried to find the best "straight" path (i.e. minimum distance and number of turns) to set control points for our driver algorithm to follow. Unfortunately we got some bugs in the driver code and missed the deadline.
We also tried to model the necessary turns and velocity changes as a kind of energy field, so through simple mechanics we could derivate the set of forces (in this case only accelerations and torques) with minimum time. But I, as the team's physicist, kept producing models that told our car to hit walls and run in circles :(
As usual it was a very challenging task to implement and probably a FPL using team will win again.
|
|
|
|