Я работаю с роботом от производителя Kuka, и моя цель:
, чтобы раскрыть некоторые функции системы робота для удаленных клиентов через архитектуру прокси-клиентов .
Далее я приведу описание системы, которую хочу построить.А внизу есть мой вопрос (ы).
Описание робота
Робот состоит из Controller, размещенного в системе WIN XP embedded, работающей на стандартном ПК.,Controller управляет рычагом, гусеницей и шиной ввода / вывода.Он отвечает за запуск программ, написанных на языке роботов Kuka (KRL), и это предписанный способ взаимодействия с ячейкой робота.
Интерфейс XComm
Kuka предоставляет интерфейс XComm длявзаимодействовать с контроллером робота из WIN XP system.Он совместим с .Net Framework 4.0.Этот интерфейс разделен на сервисы, и каждый сервис представлен в двух вариантах: блокировка вызова и асинхронный вызов с обратным вызовом.
Например, сервис XComm.Var в основном предоставляет следующие интерфейсы синхронизации / асинхронности:
interface SyncVar
{
public string GetVar(string varName); // reads a variable
public void SetVar(string varName, string varValue); // changes a variable
}
interface AsyncVar
{
// reads a variable
public void GetVarAsync(string varName, AsyncCallback callback);
// changes a variable
public void SetVarAsync(string varName, string varValue, AsyncCallback callback);
// subscribe to varValueChanged event : callback will be invoked each time the monitored variable has changed
public void InfoVar_ON(string varName, AsyncCallback callback, Timespan ts);
// unsubscribe to varValueChanged event
public void InfoVar_OFF(string varName);
}
Существует дюжина таких услуг: XComm.Motion, XComm.IO, XComm.File, ...
Цели
Основная функция, с которой я сталкиваюсь - это взаимодействиеудаленно с роботом в качестве конечного автомата .То есть я хочу, чтобы удаленный клиент мог получить состояние некоторых переменных и потенциально изменить состояние некоторых переменных в любой момент.
Кроме того, мне было бы интересно (последнее) раскрыть другие XCommтакие службы, как XComm.File для загрузки программ KRL в робот и XComm.Module для запуска их с удаленного клиента.Поэтому мне нужно, чтобы моя архитектура была расширяемой для других XComm сервисов.
Функции
1) REQ-REP
Первый способ, которым я хотел бы, чтобы клиент общался сробот проходит через простой шаблон REQ-REP.Например:
C : Hey robot, what si the speed of your arm now ?
S : It is 10m/s
C : Ok, and what is the torque on your tool ?
S : It is 1000Nm
C : Oh, I see, the stone is harder than I expected, please reduce your speed now to 5m/s
...
Или:
C : Hey robot, please, move to x = 1000mm at speed 1000mm/s
S : Ok client, I will move to x = 1000mm
C (+250ms) : Hey robot, where are you now ?
S : I am at x = 230mm
C (+500ms) : Hey robot, where are you now ?
S : I am at x = 550mm
C (+750ms) : Hey robot, where are you now ?
S : I am at x = 800mm
C (+1000ms) : Hey robot, where are you now ?
S : I am at x = 1000mm
C : Ok, so now please move to y = -500mm at speed 250mm/s
...
2) PUSH-PULL
Второй способ, которым я бы хотел, чтобы клиент общался с роботом, - этопростой шаблон PUSH-PULL, в котором клиенты могут подписаться, чтобы получать уведомления об изменении значения переменной.Нечто похожее:
C : Hey robot, let me know when you move the arm on the track, but not more than every 50ms
S : Ok client, I will let you know
...
S : Hey client, I've just move the arm and the track an my position is now E1=4000mm
...
S : Hey client, I've just move the arm and the track an my position is now E1=4010mm
...
C : Hey robot, I'm done with all this, stop notifying my when you move the arm on the track.
S : Ok client, understood.
3) PUB-SUB
Третий способ, которым я бы хотел, чтобы клиент общался с роботом, - это простой шаблон PUB-SUB.Я хочу, чтобы клиент мог подписаться на некоторые заранее определенные каналы (например, motion, command, IO).Канал транслирует состояние набора связанных переменных как список пар ключ-значение.Эта трансляция происходит каждые 40 мс или около того и в основном предназначена для создания панелей мониторинга и обновления их со скоростью более или менее 25 кадров в секунду.Конфигурация каналов является статической, но может быть загружена из файла конфигурации при запуске прокси.
Производительность
Задержка
(Локальный) синхронный вызов службы XComm составляет около 5ms долго.Это нормально, но все же слишком много (от 5 до 10) для определенных приложений управления в реальном времени.Поэтому мне действительно нужно быть осторожным, чтобы выбранная архитектура не увеличивала эту задержку.Поэтому очевидно, что мне нужно, чтобы мои клиенты отправляли асинхронные запросы, чтобы не накапливать время прохождения по сети каждого цикла REQ-REP.
Возможно, отправка клиентских запросов через несколько XComm потребителей услуг с шаблоном балансировки нагрузки можетпомочь уменьшить задержку?
Пропускная способность
Когда речь идет о малой задержке, это всегда для сообщений с небольшими размерами для чтения и записи переменных состояний (макс. несколько сотен байт).Допустим, я хочу управлять роботом на скорости 1000 кадров в секунду.То есть:
2 ways * 256 bytes / msg * 1000 msgs/sec = 512kB/s = 4.096Mbs
Очевидно, что пропускная способность не является проблемой в базовой сети 1 Гбит / с.
Если мне нужно загрузить программу KRL на робота, я могу позволить себе немного подождать100 мс или сек для передачи файла.
Надежность
Мне нужно, чтобы мой шаблон REQ-REP был надежным при сбоях в сети, на сервере и в клиенте, а также для восстановления при ручном перезапуске сервера или клиента.Поэтому мне нужно, чтобы PING-PONG оставался в живых.
Возможно, мне нужна "Безопасная" версия службы переменных Get / Set, когда, например, я хочу передать позиции роботу, чтобы я мог возобновить свою потоковую передачу.в точке, где это остановилось.Что-то вроде титанического паттерна с постоянной очередью где-то на диске?
Архитектура / паттерн
Итак, моя первая ставка в том, что паттерн Majordomo будет адаптирован к моей ситуации.
1 Прокси-сервер, работающий на WIN XP
workers: каждый работник выступает в роли потребителя для отдельной услуги XComm.Он может использовать синхронизацию или асинхронность. broker: интерфейс router с бэкэндом dealer, который отправляет клиентские запросы работнику, а рабочий отвечает клиентам. discovery: служба для клиентов, которым известно, какие службы доступны через прокси-сервер, и их состояние.
N <10 Клиенты, работающие удаленно в той же локальной сети или через Интернет </h3> клиенты могут приходить и уходить в любое время клиент может получить / установить одну или несколько переменных с помощью одного запроса (возможно, с опцией safe) и со вкусом по своему выбору (sync /async). Для Async Get / Set var мне нужен механизм обратного вызова для каждого запроса: когда приходит ответ, обратный вызов вызывается, так что клиент как встроенный способ запуска и отправки действий должен быть выполненс ответами. клиент может подписываться / отменять подписку на мониторинг переменных (push-уведомления) клиент может подписываться / отменять подписку на предварительно определенный канал aклиент может обнаружить доступные сервисы через прокси и узнать их состояние клиент может узнать, какие клиенты подключены к прокси и их состояние Я хочу предоставить простой клиентский APIчто любое устройство должно быть реализовано, чтобы использовать сервисы от прокси. В идеале я хотел бы, чтобы один ZSocket на клиента и один ZSocket для внешнего интерфейса прокси имели более простой механизм поддержки активности пульса. Удаленная связь клиент-прокси будет TCP. Потенциально локальный клиент-прокси разрешен через inproc Связь прокси-работник будет inproc (быстрее, верно?). Вопросы Итак, я выделил 3 службы, которые мой прокси должен предоставлять клиентам: REQ-REPL для получения /Установите переменные робота PUSH-PULL для подписки / отмены подписки, чтобы получать уведомления об изменении определенной переменной PUB-SUB для получения (частичных) снимков состояния.т. е. робота с регулярными интервалами (ОБНАРУЖЕНИЕ), чтобы узнать о доступных службах => Так что мой вопрос в том, каков правильный шаблон для моих клиентов-прокси, чтобы они общались с каждымдругие потребляют (потенциально) 3 услуги одновременно? => Нужно ли предоставлять 3 внешних интерфейса / порты / конечные точки, по одной для каждой службы? => Могу ли я иметьуникальная отправка внешнего интерфейса для каждой службы и маршрутизация сообщений REQ / REP / PUSH / PULL / PUB / SUB нужным клиентам? Я чувствую, что предпочитаю иметь уникальный сокет внешнего интерфейса на моем прокси-сервере для общения с клиентами с уникальнымсокет тоже.Я чувствую, что таким способом будет легче управлять надежностью, чем если бы мне понадобился сокет для каждой услуги (3 такта PING / PONG).И мой клиент останется минимальным.Но я могу быть совершенно неправ.