Форум » » Странная работа камер Sony SRG по UDP » Ответить

Странная работа камер Sony SRG по UDP

CEA: Добрый день! Может кто в курсе. Есть две камеры - Sony SRG-300H и 120DH. Переключатели снизу установлены в режим LAN (не serial). Подключены через компоненты UDP, порт 52381. Так вот управляются они как-то странно. При вращении могут сами продолжать движение, до упора, когда кнопка в интерфейсе уже отпущена. В основном приходится ряботать короткими нажатиями. И еще, судя по всему, пресеты запоминаются один раз на 10 попыток, не меньше. Появляется фидбек, что камера в режиме сохранения пресета, выбираем пресет, фидбек гаснет. При вызове пресета камера переходит в какое-то другое положение, похоже, "Hоме". Пробовал модуль с маркета - Sony SRG-300SE IP v1.0. Если я правильно понял, стандартные команды Visca здесь не работают. Т.е. нельзя просто их взять и перенаправить на TCP и порт 1259, как для камер Minnray например. Во всяком случае, Sony с стандартным модулем Visca не заработала.

Ответов - 17

Igor: Надо проверять как в драйвере обрабатываются события нажатия (push) и отпускания (release). Первому обычно сопоставляется команда начала движения камеры по наклону/повороту, второму - остановка. Не закрывается ли подключение по UDP после отработки события push? Что же касается обратной связи (feedback) о нахождении камеры в режиме сохранения preset, то во всех известных мне драйверах камер она эмулируется.

Вячеслав: Смутно припоминаю, коллега тоже говорил что модуль с маркета не заработал. Пришлось допиливать, так как команды отличались немного (не хватало какого то параметра) То что не стопится при команде остановки отправляемой по релизу, это болезнь какая я то IP камер (с панасом такая же фигня бывает). Пробуйте дублировать команду останова, тем более что UDP

Игорь K.: Никогда не было проблем с управлением камерами такого типа. Проверьте настройки, ping, загрузку коммутатора. Скрин настроек рабочей программы ниже. Модуль без изменений из Appmarket.


CEA: Спасибо за ответы. Пока сбоит, к сожалению. Позиционирование работает более или менее нормально. А вот пресеты - как повезет. Просто не записыватся, как правило. Сам склоняюсь, что нужно сеть проверить для начала. IP модули камер подключены к общему модулю наведения камер. Сначала выдается импульс (0.15 сек), который переводит IP-модуль нужной камеры в режим сохранения пресета. А потом подается такой же примерно импульс на вход нужного пресета этого же модуля. Фидбек режима сохранения пресета тут же выключается. Вроде все штатно. Пробовал менять длительность импульсов в неких пределах, но явно не этом дело. Описанная логика до этого работала с другими Visca камерами годами. Драйвер камеры был, конечно, другой.

Admin: O la-la, а попробуйте для каждой камеры свой драйвер, как в примере выше. Пресеты сохраняются внутри камеры.

CEA: Вероятно, я не совсем подробно объяснил. Драйверов - три. По числу камер. Каждый драйвер подключен через индивидуальный компонент UDP со своим адресом. А модуль наведения - просто коммутатор сигналов Вверх, Вниз... и пресетов. После него управляющие воздействия попадают на драйвер нужной камеры. Пробовал кстати на UDP делать Enable=1 - не помогает. Выше была интересная версия, что разрывается соединение.

Admin: По UDP нет никаких соединений. Отправили цепочку данных по адресу и порту и все, что на том конце - нас не волнует. СКорее всего, не соблюдаются таймауты или сетевые настройки мешают.

PG: С проблемой при сохранении пресетов я сталкивался, модуль запрашивает сначала позицию по наклону и повороту, а после получения ответа мгновенно запрашивает зум. Нужно добавить небольшую задержку на запрос зума и все заработает.

PG: Вот так:

Admin: PG, у вас про классическую VISCA история, справедливо ли такое решение для UDP?

PG: Admin пишет: PG, у вас про классическую VISCA история, справедливо ли такое решение для UDP? На скриншоте модуль Sony SRG-300SE IP v1.0.umc. Пока не добавил задержку камера не отвечала на запрос по зуму, а без этого модуль соответственно не сохранял пресет.

CEA: PG пишет: а после получения ответа мгновенно запрашивает зум Вот спасибо! А я еще с утра сохранил вот этот кусочек из лога, но ничего подозрительного не заметил.: 00:00:01.625 \x01\x00\x00\x05\x00\x00\x00\x38\x81\x09\x06\x12\xFF To_Cam_2 00:00:01.625 \x01\x11\x00\x0B\x00\x00\x00\x38\x90\x50\x0F\x0E\x00\x00\x00\x02\x07\x07\xFF From_Cam_2 00:00:01.625 \x01\x00\x00\x05\x00\x00\x00\x39\x81\x09\x04\x47\xFF To_Cam_2 00:00:01.641 \x01\x11\x00\x07\x00\x00\x00\x39\x90\x50\x00\x00\x00\x00\xFF From_Cam_2 Камера вроде отвечает. Но возможно ответ не правильный! Сейчас для начала попробую задержку.

Игорь K.: Вполне возможно, на обычной Visca величина задержек оговаривается особо перед описанием протокола. Камера должна успевать переваривать запросы, отвечать и отчитываться о готовности приёма следующей команды. Проблема тайминга

CEA: Добавил задержку от PG - заработало. Спасибо! Хотя причина мне пока до конца не ясна. Камера же отвечала? Отвечала. Но первые три посылки (на камеру, от камеры, и опять на камеру) происходили по отладчику практически "в один момент времени" Модуль, что ли, не успевал обработать первый или второй возврат от камеры....

PG: В моем случае ответа на второй запрос не было вообще: 00:01:47.203: ZAL_SNY_Cam_tx$ -> \x01\x00\x00\x05\x00\x00\x00\x0E\x81\x09\x06\x12\xFF //pan-tilp pos inq 00:01:47.219: ZAL_SNY_Cam_rx$ -> \x01\x11\x00\x0B\x00\x00\x00\x0E\x90\x50\x00\x08\x0E\x05\x00\x00\x00\x00\xFF //pan-tilt pos 00:01:47.219: ZAL_SNY_Cam_tx$ -> \x01\x00\x00\x05\x00\x00\x00\x0F\x81\x09\x04\x47\xFF //zoom pos inq У вас ответ приходит, но с нулевыми координатами: \x90\x50\x00\x00\x00\x00\xFF From_Cam_2 - они должны быть тут вместо нулей.

Admin: Много лет назад, когда еще небыло камер с управлением по http & UDP занимался VISCA, со шлейфовым включением. При доводке драйвера внимание пришлось уделять: 1. Ожиданию ответов от камер на выдачу команды от контроллера, пока не приходило два ответа ACK/Completion Messages (правильности команды и ее исполнения). если подавать следующую команду до приема этих ответов приходила ошибка и команда не исполнялась. 2. Минимальная пауза для отправки команды после получения всех подтверждений от камеры - 20 msec (указано в Timing Chart разделе описания) Это значит, что ко времени отработки камеры прибавляются еще эти 20 msec, если модуль не отрабатывает прием ответов камеры и получает ошибку или пустой ответ. Наиболее вероятно, в нашем случае происходит именно это - в модуле с Appmarket не обрабатываются ответы от камеры и тайминг не соблюдается на 100% В случае с UDP скорость работы не намного выше, и камера не успевает сформировать ответ с данными о текущем zoom-e.

Viacheslav Alekseev: Подтверждаю вышесказанное. Недавно писал модуль для VISCA Over IP под Иридиум, как раз глядя на этот модуль с апп-маркета. Логика в нем заложена, в целом, верная, но очень "оптимистичная". Нет вообще никаких задержек между командами. Автор думал, что сетевая карта и камера сами разрулят. Например в режиме "Proportional Pan-Tilt" вместе с каждой командой Pan-Tilt отправляется команда Inquiry Zoom для получения текущего зума и расчёта скорости Pan-Tilt. И между ними никакой задержки. Мало того, что камера может не успеть обработать эти команды, так более того, сетевая карта процессора вообще может отбросить один из UDP-пакетов, если их отправляется одновременно несколько. Я, кажется, даже сталкивался с таким именно на Крестроне. Это же UDP - нет никакой гарантии доставки. Никто не обязан разруливать коллизии. Можно просто выкинуть пакет. Поэтому я, когда писал свой модуль, во-первых, делал задержки, а, во-вторых, команды Inquiry Zoom отправлял не перед каждым Pan Tilt, чтобы не "засорять эфир", а только после изменения Zoom-а.



полная версия страницы