I have a similar story to tell. As an undergrad in a course of robotics, we had to program a wheeled robot and all the robots would be place in an environment with obstacles. The robot should avoid crashing with the obstacles and the other robots. Extra points if the robots moved smoothly.
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.
Weird so many people went for FSMs. You would have thought that a simple literature search would have brought up all sorts useful nuggets. Given the scenario you describe - no goal other than avoid collisions, the scheme you implemented is basically a simplified potential field approach.
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.
The story is not that far fetched. Decades ago (I think) there was a computer simulated game designed to play out what is called the Prisoner's Dilemma hosted by professor Axelrod. And the winning program? It was the simplest one, which the author had named Tit-for-Tat.
Very true. It won because it tapped into a simple but persuasive idea about interpersonal dynamics -- only be benevolent if your opponent is benevolent. It succeeded with this simple strategy against much more complex schemes.
Oh, just the opposite: tit-for-tat starts out benevolent and only retaliates when the opponent `cheats'. And tit-for-that is also quick to forgive.
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.
I do not deny the importance of the KISS moral of this story. However, there is also an important meta-moral from putting this story in a larger context: what lessons about feasible complexity you draw from your insect-themed programming contests may depend strongly on whether people like the dunkosmiloomump team happen to be participating.
(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.)
The evil that is in the world always comes of ignorance, and good intentions may do as much harm as malevolence, if they lack understanding. On the whole men are more good than bad; that, however, isn’t the real point. But they are more or less ignorant, and it is this that we call vice or virtue; the most incorrigible vice being that of an ignorance which fancies it knows everything and therefore claims for itself the right to kill. The soul of the murderer is blind; and there can be no true goodness nor true love without the utmost clear-sightedness.
Yeah I understand how it was meant. But it's completely useless to use a mathematical/physical term with a very well defined meaning which does not apply in that context. It would have been better to use "complexity" instead. I feel "entropy" was only used for link bait reasons.
Occam's razor at work. The simpler the logic, the more likely it is that it does not contain unexpected faults than a system which has more complex logic.
I think the moral is that in this case reliability wins. (And in this case, strapping a shell loop around your program that restarts it every n seconds would have worked.)
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.