Автор | Сообщение |
---|---|
admin | |
Темы использования Raspberry pi для FPV управления и мониторинг движения в кадре по векторам H.264 не новы. Разработка не претендует на оригинальность, да и времени на нее было потрачено относительно не много (с июля по выходным. иногда.). Но, возможно, мой опыт (и исходники) окажутся кому ни будь полезными. Мысль о том, что нужно сделать видео наблюдение в квартире, возникала после того как сосед сказал, что кто-то копался в замке двери. Первое что было сделано на скорую руку – это установка известной программы motion на Raspberry pi zero c камерой v1.3. В принципе, задачу решает. Если устраивает оповещение через почту и fps=4-5. Но это показалось не интересным. Под рукой была платформа с колесами и обвязкой от старых экспериментов и аккумуляторы 18650 от старых ноутов. В результате получилась забавная смесь мобильного видеонаблюдения и детектора движения. Можно поездить по квартире, удаленно управляя как камерой, так и платформой и оставить в режиме «сторож» (motion detect) в любом нужном месте. Hardware Модуль видео наблюдения
Мобильная платформа, управляемая через SPI от малины
Образ Raspbian был настроен в режим read only. В такой конфигурации, малина легко переживает неожиданные выключения питания, поскольку SD карт на запись не использует вообще. Программное обеспечение Android приложение (проверено на LG6 Oreo и старом Samsung S5 Lollipop)
Режим Android service
Хост Raspberry pi на python (picamera + spidev + RPi.GPIO)
Режим отслеживания движение в кадре.
Простейшая прошивка на stm32f103
Отслеживание движения Самый примитивный вариант – это подсчет количества векторов длинна которых превышает некое пороговое значение. И если каких векторов больше порогового, то это сигнал, что в кадре есть движение. Увы. Этот вариант годится только для демонстрации принципа. Ошибочных срабатываний слишком много. Особенно на поверхностях однородного цвета и текстуры. Все остальные варианты либо то же дают слишком много ошибочных срабатываний, либо просто не проходят критерий по производительности: «должно обработаться за время кадра». В результате выбрал свой вариант. Он хоть практически не дает ложных срабатываний, но требует движения в нескольких кадрах подряд. Но лучше уж так, чем ложные тревоги несколько раз в день из за изменения освещенности или вообще по непонятным «движениям» в кадре по «решению» камеры. Тема алгоритмов надежного детектирования по mv Н.264 вообще отдельная сложная тема. Алгоритмы требуют много времени на практическую отладку и имею жестки лимиты на время выполнения. Пример векторов движения (служебные режимы snapshot): По событиям «движение в кадре» порождаются нотификации. в принципе, для моих целей оказалось достаточно гарантированного срабатывание при движении фигуры человека (>15% кадра) в течении минимум 2-х сек. При таком загрублении чувствительности, ложных срабатываний просто не видел вообще. Управление движением. Управление камерой – две полоски касание которых выдает команду повернуться на определенный угол (чем дальше от центра полоски – тем больше угол). Непрерывное управление как для моторов оказалось неудобным (опять же субъективно для меня). Лаги FPV Для управления колесной платформой с максимальной скоростью 3-4 км/ч на 100% ШИМ лаг в 0.6 сек – это вполне нормально и почти не замечается. Однако, мне кажется, что даже 0.3 сек лага для, например, квадрокоптера — это много. Тесты показали, что реализация трансляции на python вносит в лаг где-то 50-70ms, по сравнение с выдачей такого же H.264 потока через rapivid. Для меня эти 70ms не принципиальны. Но если кто хочет выжать максимум, то должен это учитывать. При работе через «локальный WiFi» (телефон как access point) лаг составляет 350..600ms. Но не более 0.6 сек и стабильно в этом диапазоне. Хотя, 50-70 метров дальности на открытой местности — это только поиграться. А на большем расстоянии WiFi c телефона не работает. Удивил меня результат в конфигурации «Роутер WiFi -> провайдер по витой паре -> VPS -> MTC 4G на телефоне» через ssh port forwarding c малины на VPS. Однако, иногда (довольно редко и не предсказуемо), лаг становился до нескольких секунд. Помогает переконект. Наверное, это какие-то особенности 4G/МТС/провайдеров в цепочке и т.д. После того как все заработало, появилось желание подключить звуковой канал в обе стороны. Технически это возможно и даже не очень сложно. Но возится с паяльником уже не хочется. Если бы не было под рукой “лишнего” Rasberry pi, то вместо него проще было бы использовать старый телефон в качестве хоста видеонаблюдения и управления платформой. Единственное преимущество малины перед старым телефоном – меньший вес. И, может быть, меньшее энергопотребление (не сравнивал). Источник: https://habr.com/post/424191/ |
|
Сообщения: 463 |