Insects and Entropy
tomayko.com
tomayko.com
Me and my friend implemented a very simple algorithm. All the sensors measured distances to objects, and to every reading we would assign a vector whose direction oppose the one of the sensor and length, inversely "proportional" to the distance. Add all the vectors and move in this direction with a speed proportional to the length.
This turned out to work very well to avoid static obstacles and other robots. Most students implemented finite state machines. They crashed quite a lot and their movement was very clumsy, which I suppose was due to the fact that the transition of states was not very smooth.
To be fair, our success was a combination of luck and laziness too. If we had more time, we would have implemented a FSM too.
All that being said, I can appreciate the core of this story. I spent my final year implementing, testing, and optimizing D-Lite for a robot (basically a fancy incremental version of A), only to find out that in the end, given our sensor performance, the stock A* planner that came with it did almost nearly as well. Oops.
Grim tit-for-tat, that keep punishing after the first transgression, and a tit-for-tat variant that starts out malevolent in the very first move (but then copies the opponent) did markedly worse than straight up tit-for-tat.
(See https://alliance.seas.upenn.edu/~plclub/cgi-bin/contest/resu... .)
(The winning entry was elegant, complicated, and effective. I was Busman Holiday Club in that contest. I was reasonably pleased with my moderately complicated moderately effective entry, but even allowing for small team and shorter lightning-division timescale, the performance of my design falls rather short of theirs, and the junkyard rat design aesthetic of my entry falls rather short of the ballerina-by-day-ninja-by-night polish of that team's work.)
- An excerpt from "Stranger" by Albert Camus
Think about it.