views:

123

answers:

3

Hi all, I am currently pursuing Masters in Embedded and for my thesis I have to study the effectiveness of Erlang for programming Robot. AFAIK Erlang's declarative nature and concurrency can be effective, so I made an Erlang code for "Adaptive cruise control" which takes sensor values from C program(because Erlang can not read sensors directly) then perform computation and send back control signal to C program. But the code looks quite big in size(lines). Why am I not able to use declarative nature or there is some other problem? Here is my code snippets.

 start() -> 
    spawn( cr, read_sensor, []),
    spawn(cr, take_decision, []),
    sleep_infinite().
% this will make it to run infinitely 
sleep_infinite() -> 
    receive
        after infinity ->
            true
    end.

read_sensor() -> 
    register(read, self()),
    Port = open_port({spawn , "./cr_cpgm" }, [{packet, 2}]),
    Port ! {self(),{command, [49]}},% for executing read sensor fun in C pgm
    read_reply(Port).

read_reply(Port) -> 
    receive 
        read_sensor -> 
            Port ! { self(), { command, [49]}};

        {Port, {data, Data}} -> 
            [Left,Center,Right,Distance] = Data, % stored values of sensors into variables for further computation
            io:format("value of Left: ~w and Center: ~w and Right: ~w and Distance: ~w~n",[Left,Center,Right,Distance]),

        if         Distance =< 100 -> decision ! {1, out}; % Distance shows the value returned by front sharp sensor
                ((Left > 25) and (Center > 25) and (Right > 25)) -> decision ! {2, out}; % stop robot
                        Center < 25 -> decision ! {3, out}; % move forward
                   ((Left > 25) and (Center > 25)) -> decision ! {4, out}; % turn right
                 ((Right > 25) and (Center > 25)) -> decision ! {5, out}; % turn left
                          true ->   decision ! {6, out}   % no match stop robot  
        end
    end,
    read_reply(Port).

take_decision() ->
    register(decision, self()),
    Port = open_port({spawn , "./cr_cpgm" }, [{packet, 2}]),
    decision_reply(Port).

decision_reply(Port) ->
    receive
        {A, out} ->
            Port ! {self(), {command, [50,A]}};

        {Port,{data, Data}} ->
        if
            Data == [102] ->  read ! read_sensor %
        end
    end,
    decision_reply(Port).

This code looks more like a C code.

  • Is my way of implementation wrong?(especially IF...end) or problem itself is small(only 2 processes)

Please suggest me how to show the effectiveness of Erlang in programming robots. All suggestions are welcome.

Thanks..

Well I am agree with @cthulahoops that this problem is not enough to show the effectiveness of Erlang. Can anybody suggest some Robotic application which I can implement in Erlang??

+1  A: 

If you need to calculate some decisions basing on couple variables (Right, Left, etc..) you obviously will not avoid it. The question is how to benefit from using erlang.

Here, what comes to my mind, is implementing one of OTP behaviours - gen_fsm (finite state machine). So, the logic would be (maybe/probably?): Receive Left -> wait only for Right or Center and so on. This would make your code very clear and give you possibility to spawn lots of actions basing on current state, which would result in asynchronous system totally under your control.

+2  A: 

Well, firstly I'd say that this doesn't sound like a very good project for showing the effectiveness of Erlang.

The first thing that comes to mind to make the code more declarative is to split the if out into a separate function like this:

choice(Distance, _Left, _Center, _Right) when Distance =< 100 -> something_you_didnt_say_what;
choice(_Distance, Left, Center, Right) when Left > 25, Center > 25, Right > 25 -> stop;
choice(_Distance, Left, _Center, _Right) when Center < 25 -> forward;
choice(_Distance, Left, Center, _Right) when Center > 25, Left > 25 -> right;
choice(_Distance, _Left, Center, Right) when Center > 25, Right > 25 -> left.

Which separates the declaration of how to respond to sensors from the messy business of looping and sending messages, etc. Also, returning atoms rather than the cryptic integers avoids having to put that information into comments. (Following the philosophy of comments tell you where you need to clarify the code.)

cthulahoops
Actually this problem is just for start up...and I am searching for a robotic application where I can certainly say that Erlang is better choice than other language.... can u suggest me something better?
Dinesh
+1  A: 

example: If you had multiple robots which would interact with some way and each had their own logic controlled by a central erlang server.

Normally you'd make a big loop and put the logic of all the elements each cycle through, with ugly stuff like shared memory and mutexes if you utilise standard threads. In erlang you can code it more naturally and spawn functions which waste minimal space and have them communicate via message passing. With OTP you can make generic structures which handle the more annoying non functional aspects to common problems and help make it fault tolerant with supervision trees. You end up with much easier to read code and much more efficient and robust structure to develop in.

That's the power of erlang.

Jimmy Ruska