Стратегии технической поддержки для двунаправленной связи с внешними устройствами
Для linux, если вы root-пользователь, а затем скопируйте его в терминал
apt-get install python3-dev mercurial
apt-get install libsdl-image1.2-dev libsdl2-dev libsdl-ttf2.0-dev
apt-get install libsdl-mixer1.2-dev libportmidi-dev
apt-get install python-numpy
pip3 install --user hg+http://bitbucket.org/pygame/pygame
Если вы не используете пользователя root, используйте sudo перед началом каждой строки.
2 ответа
Любая конкретная причина, по которой вы хотите, чтобы SF размещал клиента, а не наоборот?
Выполняя то, что вы предлагаете, я думаю, вы столкнетесь с большими проблемами, чтобы заставить SF найти эти устройства в вашей сети и отслеживать их, например, межсетевой экран, IP-адреса, NAT, плановое обслуживание, сбои, проблемы с подключением, если вы не планируете делать это вручную.
Из краткого описания, которое я видел в документах, предоставленных вами о сервере rosbridge я мог понять, что вы должны размещать его на сервере (например, с сервисом службы), и ваши устройства будут подключаться к нему, в этом случае ваши устройства должны были установить ROS, чтобы сделать это сообщение.
Что касается вашей озабоченности в отношении связи, сервисные сервисные услуги - это просто исполняемые программы, которые вы обычно запускаете на своей локальной машине, если они работают, скорее всего, будут работать на среде с сервисом, исходя из предпосылки, беспокоиться о внешнем доступе к кластеру (если в лазури или сети ork) и обнаружение службы.
На мой взгляд, вы должны использовать SF в качестве центральной точки связи, и каждое устройство будет подключаться к службам SF. Другим подходом было бы использование Azure IoT Hub для соединения связи между ними. Существует хороший Iot Hub + Service Fabric Sample , который может быть подходящим для ваших нужд.
Поскольку вы хотите избежать Azure, вы могли бы в этом случае заменить концентратор IoT другой платформой обмена сообщениями или реализовать rosbridge в своей службе для обработки вызовов.
-
1До сих пор мое взаимодействие с rosbridge было случаем, когда сам робот запускает сервер rosbridge, и мои службы должны подключаться к нему как к клиенту. Моя компания является интегратором, поэтому мы не контролируем эти устройства - я согласен, что обнаружение устройств является проблемой, и было бы лучше, если бы SF мог слушать входящие соединения. В это время я готов управлять им с ручной регистрацией. – FolksymAndrew 16 July 2018 в 13:17
-
2В этом случае вы должны быть в порядке с SF. Единственная рекомендация, которую я вам даю, - это заботиться о планировании этих Statuful Services, потому что, поскольку вы знаете, что каждая служба может иметь несколько реплик и будет иметь только одну начальную, вторичная может быть повышена до первичной, и ваш код должен правильно ее обрабатывать. – Diego Mendes 16 July 2018 в 13:40
Надеюсь, я все понял правильно.
О препятствиях:
Я думаю, что главная проблема здесь заключается в том, что между service replica можно установить двунаправленное соединение и робота.
У этого есть две основные проблемы:
- Только первичная реплика имеет доступ на запись - то есть только одна реплика сможет изменить состояние. Эту проблему, следовательно, можно было бы смягчить, создав отдельный раздел для каждого робота (но помните, что вы не можете изменить количество разделов после создания службы) или путем создания отдельного экземпляра службы для каждого робота (это позволит вам динамически добавлять
- Реплика может быть завершена (завершена), перенесена на другой узел (завершение работы и запуск новой реплики) или даже понижен (первичная реплика понижен в сторону вторичной и другой вторичной реплики, получаемой до первичной) по разным причинам. Таким образом, код службы и код связи робота должны быть в состоянии справиться с этим.
О WebSockets
Это выглядит возможным, реализуя пользовательские ICommunicationListener и другие вещи с помощью WebSockets.
-
1Можете ли вы расширить свой вариант использования для
ICommunicationListener? SF в этой архитектуре будет размещать клиент websocket, а не слушатель (роботы будут слушать подключения от меня - я не могу контролировать это, как бы назад это не звучало). В этом случае, поскольку мне не нужно делать какие-либо URI, доступные для поиска службой именования, требуетсяICommunicationListener? Вот почему я думаю, что репликация не представляет проблемы. Если время жизни клиента управляется в методеRunAsyncслужбы состояния, робот должен видеть только серию закрытых и открытых соединений, если первичный движется. – FolksymAndrew 16 July 2018 в 13:50 -
2@FolksymAndrew выглядит так, будто я неправильно понял, кто является клиентом :) Да, в описанной вами архитектуре не понадобится
ICommunicationListener. Установление соединения вRunAsyncтакже звучит довольно разумно. Главное, чтобы обработать срок службы службы работоспособности , чтобы правильно открыть и закрыть соединение с роботом. – Oleg Karasik 16 July 2018 в 14:56