Wie lässt sich die Wirksamkeit von Erlang bei der Programmierung von Robotern nachweisen?

Question

Ich mache zur Zeit einen Master in Embedded und für meine Diplomarbeit muss ich die Effektivität von Erlang für die Programmierung von Robotern untersuchen. AFAIK Die deklarative Natur von Erlang und die Gleichzeitigkeit können wirksam sein Deshalb habe ich einen Erlang-Code für "Adaptive cruise control" erstellt, der übernimmt Sensorwerte aus C-Programm (da Erlang die Sensoren nicht direkt auslesen kann), dann eine Berechnung durchführen und ein Steuersignal an das C-Programm zurücksenden. Aber der Code sieht ziemlich groß in Größe (Zeilen). Warum kann ich die deklarative Natur nicht nutzen? oder gibt es ein anderes Problem? Hier ist mein Code-Schnipsel.

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

Dieser Code sieht eher wie ein C-Code aus.

• Ist meine Art der Implementierung falsch (insbesondere IF...end) oder ist das Problem selbst klein (nur 2 Prozesse)

Bitte schlagen Sie mir vor, wie ich die Wirksamkeit von Erlang bei der Programmierung von Robotern zeigen kann. Alle Vorschläge sind willkommen.

Danke.

Quelle: Ich stimme mit @cthulahoops überein, dass dieses Problem nicht ausreicht, um die Wirksamkeit von Erlang zu zeigen . Kann jemand eine Robotik-Anwendung vorschlagen, die ich in Erlang implementieren kann?

Answer 1

Nun, zunächst einmal würde ich sagen, dass dies nicht nach einem sehr guten Projekt klingt, um die Effektivität von Erlang zu zeigen.

Das erste, was mir in den Sinn kommt, um den Code deklarativer zu gestalten, ist die Aufteilung der if-Funktion in eine separate Funktion wie diese:

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.

Dadurch wird die Erklärung, wie auf Sensoren zu reagieren ist, von der chaotischen Angelegenheit der Schleifenbildung und des Sendens von Nachrichten usw. getrennt. Die Rückgabe von Atomen anstelle der kryptischen ganzen Zahlen erspart es außerdem, diese Informationen in die Kommentare aufzunehmen. (Die Philosophie der Kommentare zeigt Ihnen, wo Sie den Code präzisieren müssen).

Answer 2

Beispiel: Wenn Sie mehrere Roboter hätten, die in irgendeiner Weise interagieren würden und jeder seine eigene Logik hätte, die von einem zentralen Erlang-Server gesteuert würde.

Normalerweise würde man eine große Schleife machen und die Logik aller Elemente in jedem Zyklus durchlaufen lassen, mit hässlichen Dingen wie Shared Memory und Mutexes, wenn man Standard-Threads verwendet. In Erlang kann man das natürlicher kodieren und Funktionen erzeugen, die nur wenig Platz verschwenden, und sie über Message Passing kommunizieren lassen. Mit OTP können Sie generische Strukturen erstellen, die die lästigen nicht-funktionalen Aspekte gängiger Probleme behandeln und mit Überwachungsbäumen zur Fehlertoleranz beitragen. Am Ende hat man einen viel leichter zu lesenden Code und eine viel effizientere und robustere Struktur für die Entwicklung.

Das ist die Stärke von Erlang.

Answer 3

Wenn Sie einige Entscheidungen auf der Grundlage einiger Variablen (rechts, links, etc.) berechnen müssen, werden Sie dies natürlich nicht vermeiden können. Die Frage ist, wie man von der Verwendung von Erlang profitieren kann.

Was mir hier in den Sinn kommt, ist die Implementierung eines der OTP-Verhaltensweisen - gen_fsm (finite state machine). Also, die Logik wäre (vielleicht/wahrscheinlich?): Receive Left -> warte nur auf Right oder Center und so weiter. Dies würde Ihren Code sehr klar machen und Ihnen die Möglichkeit geben, viele Aktionen auf der Grundlage des aktuellen Zustands auszulösen, was zu einem asynchronen System führen würde, das vollständig unter Ihrer Kontrolle steht.

Answer 4

Ich habe den Eindruck, dass Erlang besonders gut für Roboterschwärme geeignet ist. Da jedes Mitglied des Schwarms rpc:abcast Nachrichten an alle anderen Mitglieder zu senden, ist eine fantastische Alternative zu dem üblichen UDP-Boilerplate-Mist, mit dem man sich in einer prozeduralen Sprache herumschlagen muss. Es gibt keine Bindung an Ports, keine Angabe eines Binärformats für Ihre Nachrichten, keine Serialisierung von Objekten, usw.

Solange Sie die Entdeckung anderer Knoten in Ihrer Umgebung in den Griff bekommen, scheint ein dezentraler/verteilter Erlang-Schwarm ein großartiges Projekt zu sein.