Erlang & Robotics

Francesco Cesarini (Erlang Consulting) francesco@REDACTED
Mon Mar 10 08:54:00 CET 2003


http://www.robotics.com/arobot/andy.html

was built as a Master's thesis project using Erlang and a Lego robot. I 
never got my hands on the thesis,  as the page containing it was taken 
down. But from the above page, you find out that Andy Allen used a 
486SLC2-50 with 16 Meg of Ram running off of batteries with the help of 
DC/DC converters. Real Time Linux, Erlang, and Improv comprise the 
software, along with low level parallel port drivers. The 486 
communicates with the ARobot's Basic Stamp through an RS-232 connection. 
The 486 is simply a vision coprocessor, subordinate to the Basic Stamp. 
This basic system of an x86 on top can be used for many other tasks as well.

Cheers,
Francesco
--
http://www.erlang-consulting.com

Ulf Wiger wrote:

>On Sun, 9 Mar 2003, david wallin wrote:
>
>  
>
>>I've been interested in doing something with robotics, and
>>would hate to give up on Erlang because of that. I know
>>there's been others who has shared this interest in the
>>past and hoped to make the Erlang runtime small enough for
>>the processors (+memory) found in these devices (in the
>>affordable segment of the market. Think Lego Mindstorms).
>>    
>>
>
>I've figured that the Erlang programming model would be
>ideal for robotics programming.
>
>  
>
>>Did anyone succeed in doing this ? Could Erlang be 'pruned'
>>of some of it's features to make this happen (Erlang
>>Lite?), and in that case, what would that be ?
>>
>>Another fundamentally different approach would be "Erlang
>>Mindstorms":  A programmable brick using the almost
>>existing Erlang processor combined with Bluetooth. This
>>would be extremely exciting stuff, unfortunately, I fear
>>this won't be realized. (Feel free to prove me wrong).
>>    
>>
>
>The Erlang Processor was certainly aimed at environments
>similar to this: where you'd need a dirt cheap, low-power(*)
>chip with a very lightweight "device OS" (like the Erlang
>kernel). Another plus should be the garbage collection
>design, which relied on sub-instructions to
>increment/decrement references, and where the actual release
>of garbage didn't steal CPU cycles from the application
>(i.e. no GC freezes).
>
>/Uffe
>
>(*) The Erlang Process used about 30x fewer machine
>instructions than BEAM to run an average Erlang program.
>This can be used either to speed up execution, or to build
>simpler (=cheaper) chips.
>  
>





More information about the erlang-questions mailing list