Robotic Applications In Erlang

问题:

I want to use Erlang for implementing a Robotic Application. Most current real world applications implemented in Erlang are web based. Robot implemented by Prof. corrado didn't utilize concurrency of Erlang which is the heart of Erlang and concentrated on Artificial intelligence more(according to my understanding of that project).

Some ideas come to my mind are like Soccor Robots, Multiple robots cleaning a room but in such systems Robots can be programmed in C (or any other programming language) which can be controlled using MATLAB. MATLAB helps in image processing(vision system) and solving complex array calculations, so what is the point of using Erlang?.(please correct me if I am wrong)

Can somebody suggest me some Robotic Application which can utilize Erlang's feature especially concurrency and one can argue that Erlang is best suited for such application over other languages.

Little bit detailed answer would help me a lot.

回答1:

But Erlang might not be the best approach to any robot application at all. But you can go for the less ambitious thesis of demonstrating that Erlang supports a computing model that is important in many robotics applications. The points of using Erlang for robotics include

• concurrency to model and monitor a concurrent world;
• distribution of sensor, actuator and computing resources;
• state machines to tie the behaviors together; and
• supervisors for fault tolerance.

Anything can be done in any language, but Erlang makes some things convenient, particularly on the architectural level.

Chapter 14 in Concurrent Programming in Erlang for example models a lift control system by one process for each lift and one for each floor, and later discusses the process structure for a satellite control system. Lifts or satellites maybe aren't very robot-like, but the principles are the same.

The Erlang & Robotics work by Corrado Santoro et al. makes plenty use of concurrency. Their 2007 mobile robot project has bunch of different (concurrent) OTP behaviors that range from low level I/O to high level planning. Teaching Erlang using robotics and player/stage is another recent work.

Your Robot Soccer or Cleaning Robot ideas are fine and have plenty of scope for concurrency and inter-robot communication. But you don't just do an arbitrary robot application of that size. Either you have a team and some specific robots to work on, or you get yourself a simulator (get a simulator either way).

Try simulating a number of robots that steer towards each other until they all collide, each robot running a process of its own. When that is working, replace the task and add processes that (pretend to) control motors, feel walls, see the environment, understand user commands, break down, etc., and exchange messages with other robots and planning processes.

Read up on robotic systems architectures to understand that such designs are common and why. Did Erlang facilitate this type of programming?

回答2:

the only way to understand where erlang is best and when it's best, is to program in erlang for awhile. It's not about what erlang does best, it's more about understanding how a functional design pattern using erlang's small spawns and otp compares to trying to solve the same problems in a imperative language. A short bulleted pros and cons list will not do justice. Google's go routines and channels, haskell and D can act similarly without any problem. Erlang is particularly good at being distributed. In newer concurrent languages you don't really have to work too hard to make things concurrent. In erlang in particular, if you're making your spawns evenly do the cpu intensive tasks you are using concurrency. You won't find much information on erlang for robotics, but you'll find 3 books with lots of examples on making things distributed and concurrent which tackle many of the same problems. The other concurrent languages don't usually specialize in such a way. Many useful primitives are built into erlang.

A lot of posts have been made about doing similar things in other languages but sticking with erlang saves a lot of work.

http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=%22erlang+style%22+%22(concurrency|message+passing)%22 http://groups.google.com/group/golang-dev/browse_thread/thread/e120a586441b9b24/806eab93bd5281a0?#806eab93bd5281a0