It seems like the generation could be stopped after both vehicles hit an obstacle in the first second. The other 16 seconds are helpful how?
Show HN: Self-Parking Car Evolution
11–20 of 45 posts
Re: Show HN: Self-Parking Car Evolution
#12> Whenever the sensor doesn't see any obstacles it reports the value of 0. On the contrary, if the value of the sensor is small but not zero (i.e. 0.01m) it would mean that the obstacle is close. I would guess that mapping ”nothing here” to a value that is higher than the others would give better results. The software wouldn’t have to learn that weird inversion where the safest value is very close to the least safe o…
That was my first approach actually.
The mental model is like this: if sensor says 4 - it means the obstacle is 4 meters away. If obstacle is far away, then sensor may say… hm… 5 meters? 10 meters? Infinity meters? So I went with something a bit higher than max sensor distance limit of 4 meters. And, for linear equation this didn’t work for me. Cars were straggling to learn.
So I’ve switched to another mental model: if sensors says 0 - it means we just turn the sensor of, the sensor is not important. Let’s say you want to learn how to drive forward if the obstacle is behind you. Then you don’t care about the side sensors, you may just cancel them with zero variables. And with this setup, the cars started to learn much faster.
I think the correct approach depends on the brain “model”. For linear equation, canceling the sensor with the zero value of the sensor.
But if you would manage to train the cars well with the different approach - it would be really interesting to try
Re: Show HN: Self-Parking Car Evolution
#13It seems like the generation could be stopped after both vehicles hit an obstacle in the first second. The other 16 seconds are helpful how?
That’s a good idea.
However, there is an issue right now (https://github.com/trekhleb/self-parking-car-evolution/issue...), that the cars are not “punished” for hitting another cars (they are allowed to create the road accidents). That’s why if both cars have hit another cars they may continue driving and approaching the parking lot (only approaching matters so far). That’s not good, agree. But the app is in proof-of-concept stage, so it has the issues like this.
Re: Show HN: Self-Parking Car Evolution
#14> Whenever the sensor doesn't see any obstacles it reports the value of 0. On the contrary, if the value of the sensor is small but not zero (i.e. 0.01m) it would mean that the obstacle is close. I would guess that mapping ”nothing here” to a value that is higher than the others would give better results. The software wouldn’t have to learn that weird inversion where the safest value is very close to the least safe o…
That was my first approach actually. The mental model is like this: if sensor says 4 - it means the obstacle is 4 meters away. If obstacle is far away, then sensor may say… hm… 5 meters? 10 meters? Infinity meters? So I went with something a bit higher than max sensor distance limit of 4 meters. And, for linear equation this didn’t work for me. Cars were straggling to learn. So I’ve switched to another mental model:…
I would go for “4 meters and a tiny bit”. When driving in a thick fog that limits vision to 4 meters, a sane driver interprets “don’t see anything” as “there’s at least 4 meters of room”, not as “5 meters” or “10 meters”.
That also makes sense if you interpret “sensor says 3” not as “obstacle is 3 meters away”, but as “there’s 3 meters of room”.
But then, I didn’t try to see what works better. I find the result surprising, though.
Re: Show HN: Self-Parking Car Evolution
#15Manual Parking:
Space to brake behaves... erratically.
Re: Show HN: Self-Parking Car Evolution
#16This is cute, but am I missing some way to make it run faster? It seems to only happen in real time. Group sizes of any more than about 10 make my machine slow to a crawl. Using the suggested population size of 500, then means it takes running 50 groups to pass 1 generation. With the suggested time of 17s, that's about 15 minutes per generation. The recommended 50 generations would therefore take over 12 hours. And t…
Yes, currently the simulation performance is one of the biggest issues ( https://github.com/trekhleb/self-parking-car-evolution/issue... ). You may try to check the “Performance boost” checkbox that simplifies the geometry. It should give you approx x1.5 performance increase. But even with x1.5 boost the performance is still an issue, yes
Have you thought about a native version? I get the appeal of writing for the browser but it's so damned slow compared to what you could get natively.
Re: Show HN: Self-Parking Car Evolution
#17I've got "Component has crashed" on mobile Firefox, not very optimistic :)
Re: Show HN: Self-Parking Car Evolution
#18This is cute, but am I missing some way to make it run faster? It seems to only happen in real time. Group sizes of any more than about 10 make my machine slow to a crawl. Using the suggested population size of 500, then means it takes running 50 groups to pass 1 generation. With the suggested time of 17s, that's about 15 minutes per generation. The recommended 50 generations would therefore take over 12 hours. And t…
Indeed, the simulation should not be done in real time.
The 3D world could be a cute way for users to change the parking scenario and then let the algorithm run in background and show the winners every 1000 cycles.
Re: Show HN: Self-Parking Car Evolution
#19[deleted]
Re: Show HN: Self-Parking Car Evolution
#20This is pretty cool, kudos to the author. However, I'm curious about why would you want to use a genetic algorithm (GA) for what is clearly a relatively straightforward computer vision (CV) problem. I would argue that the GA-based evolutionary solution is no simpler and, more importantly, will not only never outperform the CV-based one in terms of accuracy and speed, but will be orders of magnitude slower.