Comment montrer l'efficacité des Erlang pour la programmation de robots?

Question

Je poursuis actuellement une maîtrise en Embarqué et pour ma thèse que je dois étudier l'efficacité de Erlang pour la programmation de robot. AFAIK la nature et la concurrence déclarative de Erlang peuvent être efficaces , donc j'ai fait un code Erlang pour « régulateur de vitesse adaptatif » qui prend des valeurs de capteur du programme C (car Erlang ne peut pas lire des capteurs directement) puis effectuer des calculs et renvoyer le signal de commande au programme C. Mais le code semble assez grande taille (lignes). Pourquoi suis-je pas en mesure d'utiliser la nature déclarative ou il y a un autre problème? Voici mes extraits de code.

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

Ce code ressemble plus à un code C.

• est ma façon de mauvaise mise en œuvre? (Surtout si ... fin) ou le problème lui-même est petit (seulement 2 processus)

S'il vous plaît me suggérer comment montrer l'efficacité de Erlang dans la programmation de robots. Toutes les suggestions sont les bienvenues.

Merci ..

Bien Je suis d'accord avec @cthulahoops que ce problème ne suffit pas de montrer l'efficacité de Erlang . Quelqu'un peut-il suggérer une application robotique que je peux mettre en œuvre Erlang ??

Answer 1

Eh bien, tout d'abord je dirais que cela ne ressemble pas à un très bon projet pour montrer l'efficacité de Erlang.

La première chose qui vient à l'esprit pour rendre le code plus déclarative est de diviser le cas en dehors d'une fonction séparée comme ceci:

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.

Ce qui sépare la déclaration de la façon de répondre à des capteurs de l'entreprise en désordre de boucle et envoyer des messages, etc. De plus, les atomes de retour plutôt que les entiers cryptiques évite d'avoir à mettre cette information dans les commentaires. (Suite à la philosophie des commentaires que vous dire où vous devez préciser le code.)

Answer 2

exemple:. Si vous aviez plusieurs robots qui interagissent avec une certaine façon et avaient chacun leur propre logique contrôlée par un serveur central Erlang

Normalement, vous feriez une grande boucle et mettre la logique de tous les éléments de chaque cycle par, avec des choses laides comme la mémoire partagée et mutex si vous utilisez des fils standard. En Erlang vous pouvez coder plus naturellement des fonctions et spawn où les déchets un minimum d'espace et ont les communiquer via le passage de messages. Avec OTP, vous pouvez faire des structures génériques qui gèrent les aspects les plus gênants non fonctionnels à des problèmes communs et aider à le rendre tolérant aux pannes avec des arbres de supervision. Vous vous retrouvez avec beaucoup plus facile à lire le code et la structure beaucoup plus efficace et robuste pour développer.

C'est la puissance de Erlang.

Answer 3

Si vous avez besoin de calculer certaines décisions basant sur les variables couple (Droite, Gauche, etc ..) vous ne sera évidemment pas l'éviter. La question est de savoir comment bénéficier de l'utilisation Erlang.

Ici, ce qui vient à l'esprit, met en œuvre l'un des comportements OTP - gen_fsm (machine à états finis). Ainsi, la logique serait (peut-être / sans doute?): Recevoir gauche -> attente seulement pour droite ou au centre, et ainsi de suite. Cela rendrait votre code très clair et vous donner la possibilité de beaucoup d'actions spawn basant sur l'état actuel, ce qui se traduirait par système asynchrone totalement sous votre contrôle.

Answer 4

Il me semble que Erlang est particulièrement bien adapté pour les essaims robotiques. Ayant chaque membre de l'essaim des messages rpc:abcast à tous les autres membres est une excellente alternative à la merde habituelle boilerplate UDP que vous auriez à traiter dans un langage procédural. Il n'y a pas de liaison aux ports, en spécifiant pas un format binaire pour vos messages, pas sérialisation d'objets, etc.

Tant que vous pouvez trier la découverte d'autres noeuds dans votre région, il semble comme un essaim Erlang décentralisé / distribué serait un grand projet.