Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>But Erlang might not be <em>the</em> best approach to <em>any</em> robot application at all. But you can go for the less ambitious thesis of demonstrating that <strong>Erlang supports a computing model that is important in many robotics applications</strong>. The points of using Erlang for robotics include</p> <ul> <li><strong>concurrency</strong> to model and monitor a concurrent world; </li> <li><strong>distribution</strong> of sensor, actuator and computing resources; </li> <li><strong>state machines</strong> to tie the behaviors together; and</li> <li><strong>supervisors</strong> for fault tolerance.</li> </ul> <p>Anything can be done in any language, but Erlang makes some things convenient, particularly on the architectural level.</p> <p>Chapter 14 in <a href="https://rads.stackoverflow.com/amzn/click/013508301X" rel="nofollow noreferrer">Concurrent Programming in Erlang</a> 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.</p> <p><a href="http://skillsmatter.com/podcast/home/erlang-robotics-the-rosen-framework-at-the-eurobot-2008-competion" rel="nofollow noreferrer">The Erlang &amp; Robotics</a> work by Corrado Santoro et al. makes plenty use of concurrency. Their <a href="http://erlang.org/workshop/2007/proceedings/11santor.pdf" rel="nofollow noreferrer">2007 mobile robot project</a> has bunch of different (concurrent) OTP behaviors that range from low level I/O to high level planning. <a href="http://portal.acm.org/citation.cfm?id=1596606" rel="nofollow noreferrer">Teaching Erlang using robotics and player/stage</a> is another recent work.</p> <p>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). </p> <p>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. </p> <p>Read up on <a href="http://www.springerlink.com/content/m21v48513731j065/" rel="nofollow noreferrer">robotic systems architectures</a> to understand that such designs are common and why. Did Erlang facilitate this type of programming?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload