Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


You need spaces after each asterisk.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: