Pregunta

Actualmente estoy cursando Maestría en Embedded y para mi tesis tengo que estudiar la eficacia de Erlang para la programación del robot. AFAIK naturaleza y concurrencia declarativa de Erlang pueden ser eficaces , así que hice un código de Erlang para el "control de crucero adaptativo", que toma valores de los sensores de programa C (sensores porque Erlang no puede leer directamente) a continuación, realizar el cálculo y enviar de vuelta señal de control al programa C. Sin embargo, el código es bastante grande en tamaño (líneas). ¿Por qué no soy capaz de usar la naturaleza declarativa o hay algún otro problema? Aquí está mi fragmentos de código.

 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).

Este código se parece más a un código C.

  • Es mi forma de aplicación equivocada? (Especialmente si ... final) o problema en sí es pequeño (sólo 2 procesos)

Por favor, me sugieren cómo mostrar la efectividad de Erlang en la programación de los robots. Todas las sugerencias son bienvenidos.

Gracias ..

Bien Estoy de acuerdo con @cthulahoops que este problema no es suficiente para demostrar la eficacia de Erlang . ¿Alguien puede sugerir alguna aplicación robótica que puedo aplicar en Erlang ??

¿Fue útil?

Solución

Bueno, en primer lugar me gustaría decir que esto no suena como un proyecto muy bueno para mostrar la eficacia de Erlang.

La primera cosa que viene a la mente para hacer el código más declarativa es dividir el si fuera en una función separada de esta manera:

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.

Lo que separa a la declaración de cómo responder a los sensores del negocio sucio de bucle y enviar mensajes, etc. También, volviendo átomos en lugar de los números enteros crípticos evita tener que poner esa información en los comentarios. (Siguiendo la filosofía de comentarios le dirá dónde tiene que aclarar el código.)

Otros consejos

ejemplo:. Si tenía múltiples robots que interactúan con alguna manera y cada uno tenía su propia lógica controlada por un servidor central de Erlang

Lo normal sería hacer una gran bucle y poner la lógica de todos los elementos a través de cada ciclo, con cosas feas como la memoria y el mutex compartida si utiliza las roscas estándar. En Erlang se puede codificar de forma más natural y las funciones de regeneración, que desperdicio de espacio mínimo y tienen que comunicarse a través de paso de mensajes. Con OTP se puede hacer estructuras genéricas que se ocupan de los aspectos funcionales no más molestos para los problemas comunes y ayudar a que sea tolerante a fallos con árboles de supervisión. Se termina con mucho más fácil leer el código y estructura mucho más eficiente y robusto para desarrollar en.

Ese es el poder de Erlang.

Si es necesario calcular algunas decisiones basándose en variables pareja (derecha, izquierda, etc ..) que, obviamente, no evitarlo. La cuestión es cómo beneficiarse del uso de Erlang.

A continuación, lo que viene a la mente, está llevando a cabo uno de los comportamientos OTP - gen_fsm (máquina de estados finitos). Por lo tanto, la lógica sería (tal vez / probablemente?): Recibe Izquierda -> espera sólo para la derecha o centro, y así sucesivamente. Esto haría que su código muy claro y le dará la posibilidad de una gran cantidad de regeneración de las acciones basándose en el estado actual, lo que resultaría en un sistema asíncrono totalmente bajo su control.

Me parece que Erlang es particularmente bien adaptado para enjambres robóticos. Teniendo cada miembro de los mensajes rpc:abcast enjambre a todos los demás miembros es una fantástica alternativa a la habitual basura UDP repetitivo que habría que tratar en un lenguaje de procedimientos. No hay unión a los puertos, sin especificar un formato binario para sus mensajes, sin serialización de objetos, etc.

Mientras se puede ordenar a cabo el descubrimiento de otros nodos en su área, parece como un enjambre descentralizada / distribuida Erlang sería un gran proyecto.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top