Как показать эффективность Erlang для программирования роботов? - PullRequest
Новая
       22

Как показать эффективность Erlang для программирования роботов?

4 голосов
/ 21 августа 2010

В настоящее время я изучаю магистратуру по встраиваемым технологиям, и для моей диссертации я должен изучить эффективность Erlang для программирования робота.AFAIK Декларативный характер и параллелизм Erlang могут быть эффективными , поэтому я создал код Erlang для «Адаптивного круиз-контроля», который принимает значения датчиков из программы C (поскольку Erlang не может считывать датчики напрямую)затем выполнить вычисление и отправить обратно управляющий сигнал в программу C.Но код выглядит довольно большим по размеру (строки). Почему я не могу использовать декларативный характер или есть какая-то другая проблема?Вот мои фрагменты кода. 

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

Этот код больше похож на C-код.

  • Мой способ реализации неверен (особенно если IF ... end) или сама проблема небольшая (только 2 процесса)

Пожалуйста, предложите мне, как показать эффективность Erlang в программировании роботов. Все предложения приветствуются.

Спасибо ..

Ну Я согласен с @cthulahoops, чтоэтой проблемы недостаточно, чтобы показать эффективность Erlang .Кто-нибудь может предложить какое-нибудь приложение Robotic, которое я могу реализовать в Erlang ??

Ответы [ 4 ]

2 голосов
/ 21 августа 2010

Ну, во-первых, я бы сказал, что это не очень хороший проект для демонстрации эффективности Erlang.

Первое, что приходит на ум, чтобы сделать код более декларативным, это разделитьif в отдельной функции, подобной этой: 

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.

, которая отделяет декларацию о том, как реагировать на датчики, от грязного бизнеса зацикливания и отправки сообщений и т. д. Кроме того, возвращаются атомы, а не загадочные целыеИзбегает необходимости помещать эту информацию в комментарии.(Следуя философии комментариев, расскажу, где нужно уточнить код.)

2 голосов
/ 22 августа 2010

пример: если у вас было несколько роботов, которые каким-либо образом взаимодействовали, и у каждого была своя логика, управляемая центральным сервером erlang.

Обычно вы делаете большой цикл и размещаете логику всех элементов каждого цикла, с такими уродливыми вещами, как общая память и мьютексы, если вы используете стандартные потоки. В erlang вы можете кодировать его более естественно и порождать функции, которые тратят минимальное пространство и позволяют им общаться через передачу сообщений. С OTP вы можете создавать общие структуры, которые обрабатывают более раздражающие нефункциональные аспекты общих проблем и помогают сделать их отказоустойчивыми с помощью деревьев контроля. В итоге вы получите гораздо более легкий для чтения код и гораздо более эффективную и надежную структуру для разработки.

Это сила эрланга.

1 голос
/ 17 марта 2011

Меня удивляет, что Эрланг особенно хорошо подходит для роботов.Получение каждого члена сообщений swarm rpc:abcast для всех остальных участников является фантастической альтернативой обычному шаблонному дерьму UDP, с которым вам придется иметь дело на процедурном языке.Там нет привязки к портам, нет указания двоичного формата для ваших сообщений, нет сериализации объектов и т. Д.

Пока вы можете разобраться с обнаружением других узлов в вашем районе, это выглядит как децентрализованный /распределенный Erlang Swarm был бы отличным проектом.

1 голос
/ 21 августа 2010

Если вам необходимо рассчитать некоторые решения на основе пары переменных (справа, слева и т. Д.), Вы, очевидно, не избежите этого. Вопрос в том, как извлечь выгоду из использования Erlang.

Здесь, на мой взгляд, реализуется одно из поведений OTP - gen_fsm (конечный автомат). Таким образом, логика будет (возможно / вероятно?): Получить влево -> ждать только для право или центр и так далее. Это сделает ваш код очень понятным и даст вам возможность создавать множество действий в зависимости от текущего состояния, что приведет к тому, что асинхронная система будет полностью под вашим контролем.

...