Another Step Towards the Driverless Car 224
jtogel writes "At Essex, we have for some time been working on automatically learning how to race cars in simulation. It turns out that a combination of evolutionary algorithms and neural networks can learn how to beat all humans in racing games, and also come up with some quite interesting, novel behaviours, which might one day make their way into commercial racing games. While this is simulation, the race is now on for the real thing — we are setting up a competition for AI developers, where the goal is to win a race between model cars on real tracks. As the cars will be around half a meter long, the cost of participating will be a fraction of that for the famous DARPA Grand Challenge, whereas the challenges will be similar in terms of computer vision and AI."
The underlying research (Score:5, Informative)
Some of them are of course better than others. I can recommend this one [togelius.com], about evolving general and specific driving skills, this one [togelius.com] about co-evolution, this one [togelius.com] about different learning techniques, and this one [togelius.com] about modelling human driving and evolving tracks. There are several new ones, including one on physical cars, which are not on the website yet - mail me if you want a preprint!
All this assuming that anyone actually reads academic papers... sometimes it seems that not even the guy who writes the paper actually reads it. (Not true in my case, of course!)
Surpassed by TORCS (Score:2, Informative)
There have been several robots that use various learning techniques, though none to my knowledge have been full-blown AI/neural net solutions. To be honest, I query the advantages of doing it that way. A robot that has code to plan a smooth & optimal path around the track & calculates braking and steering accordingly will do much better (initially at least) than an AI robot that needs to learn this information. Perhaps bots that use a mix of the two (preplanning to begin with then learning to fine-tune any errors in the plan) would be the best solution.
Re:Aww, can't get to Starbucks? (Score:2, Informative)
Better Yet (Score:2, Informative)
I'm all in favor of robot contests and all but more important, from my point of view, is the ability to share resources (such as test environments, robot chassis, sensors, vision-processing code, etc.) outside of the competition itself.
The biggest unnecessary impediment to robotic research right now, as I see it, is the difficulty researchers have in making comparisons between systems. You demonstrate your racing code on your robot in your test environment. I demo my code on my bot on my test track. The results are different but what does that show? On the other hand, if we both have the opportunity to try out our code on the same robot in the same test environment and mine clobbers yours, then the whole world can clearly see that mine works better. (Or, I suppose it is logically possible that yours would outperform mine, but that seems pretty unlikely, now doesn't it?)
We can get some kind of head-to-head comparisons in competitions, to be sure, but even then it is often just the environment that is the same. Typically the contestants are still providing all of their own hardware and software (as in the DARPA Grand Challenge and TFA). Even if we provide contestants the same hardware (xor the same software), limiting our comparison time to a couple of days a year impedes progress. We should be able to test our systems year 'round.
What we should be doing is making our code and our hardware and our test environments available to one another on a daily basis. If I want to see if I can evolve a better neurocontroller for your race car than you did, you should allow me to download my code onto your race car to drive around your track next month. Want to see if your code does a good job of driving my FIDO-class planetary rover over a simulated Martian surface? Download it onto my bot and run it in our Mars room or our outdoor OK/Mars test site. If you want to see if your rover hardware design can outperform the classic rocker-bogey design, pack it in a crate and ship it to us and we'll run it around our test environments for you.
Of course, it isn't quite as easy as that since the labs with the coolest robots in the world (which cost a pretty penny) can't spend all of their time and resources running experiments for other people at no cost - they have to get something out of the deal too. But that issue is not insurmountable.
I do applaud the provision of the simulation version of the race, which gets us running the same (simulated) hardware in the same (simulated) environment. (Interested readers should see http://julian.togelius.com/cig2007competition/ [togelius.com] for the Java code. It is very simple and fun to try out.) The one question I have there, what is the license like for the simulator? I didn't see a README file or a note on the webpage. I didn't dig into individual source files or anything. Open source of some stripe would be nice, so that we can all improve it and share the improvements with one another.
Also, if anyone can suggest a more realistic racing simulation environment that could provide a better bridge to the real world competition that the simple 2D sim mentioned above, I'd appreciate it. An open interface is, of course, a must.
Dean
Re:Better Yet (Score:1, Informative)
http://playerstage.sourceforge.net/ [sourceforge.net]
Only works on wide roads (Score:4, Informative)
Notice that in all the examples, the road is much wider than the car. That's not by accident.
Driving using reactive behaviors is easy if you have plenty of room. On narrow roads, though, those approaches fail. You have to look ahead. In fact, to drive in the real world, you need a controller that plots at least an S-curve ahead. Otherwise, you'll end up in a tight spot pointed in a direction that won't get you through.
You don't necessarily have to "plan", in the AI sense, but you need a fairly good dynamics prediction capability, after which you can run a reactive controller on the prediction.
We went through this with our DARPA Grand Challenge vehicle. We started out with a reactive planner, but it just couldn't deal with tight spots. Most of the other teams ended up with S-curve planners, too. The reason you need S-curves is that you need to be able to achieve both a desired position and direction at a point ahead of the vehicle. So you need a curve with at least two degrees of freedom.
The predictor needs to know enough about the vehicle dynamics to make reasonable predictions. For example, predicted S-curves have to be built knowing how fast you can change the steering angle and how tightly you can turn given the current speed and ground bank.
If you need to do this stuff, read up on adaptive model-based feedforward control. The idea is that you have a system that learns how the system behaves as the inputs change and builds a model. Inverting the model gives you a predictor. Given a predictor, you can control.
A useful feature of that approach is that, while you're using one predictor, you can be training a better one safely. Predictors are trained by watching; they don't have to be in control. So you can start out with some dumb controller and work your way up to better ones, without crashing. This is probably how mammals learn motor skills.
Re:Only works on wide roads (Score:4, Informative)
In the case of our (admittedly simple) model, we have a limited line of sight, and I think a good reactive controller can perform optimally (however you define that, often optimality is just another buzzword) given the limited sensor data. We did try evolving reactive control on much narrower tracks with good results - see for example our papers on track evolution. What the controller learns is often just to slow down when coming up to a narrow passage.
Re:Safety vs. Freedom , again. (Score:3, Informative)
The page you listed showed figures of 43,354 people dies form injuries sustained ion a car crash. I have figure for 2003, or 2004. Assuming they are the same (and I don't believe the war deaths are counted because they are overseas and not in the US.) or similar in 2004, the totale number of deaths in the US was 2,398,343. This means that 2,354,989 Died from other causes. Thats a pretty big number compared to automobile accidents. 61,472 people died form the Influenza and Pneumonia alone in 2004. That is roughly 40% more then those who died from a car crash.
Do you realize how small of a number this is? When more people catch a bad cold, developer Influenza/Pneumonia and die from it is greater then the total number of deaths related to car accidents in 2000?
I'm not saying that those 43,354 people are insignificant or anything. I'm just saying we have better ways to spend out money. We have better places to concentrate on reducing deaths. Some day I would like to say less people dies from car accident but even less died from cancer or heart disease. Those two alone account for 1,204,362 deaths in 2004. That is about thirty times the amount of car accidents. And most car accidents deaths can be reduced if people simply followed the rules of the road and took caution during dangerous conditions.
Did you know you could be cited for speeding if you didn't even go the posted speed limit in most states? It is called too fast for road conditions and usually accompany a loss of control citation after an accident. According to this site [dekirby.net] the most common causes of accidents is driver not paying attention. This includes not following the posted speed limits or following to close and so on. Check it out.