Но, возможно, мой опыт (и исходники) окажутся кому ни будь полезными.
Мысль о том, что нужно сделать видео наблюдение в квартире, возникала после того как сосед сказал, что кто-то копался в замке двери.
Первое что было сделано на скорую руку – это установка известной программы motion на Raspberry pi zero c камерой v1.3. В принципе, задачу решает. Если устраивает оповещение через почту и fps=4-5.
Но это показалось не интересным. Под рукой была платформа с колесами и обвязкой от старых экспериментов и аккумуляторы 18650 от старых ноутов.
В результате получилась забавная смесь мобильного видеонаблюдения и детектора движения.
Поскольку у меня есть арендованный VPS, то проблем доступом извне (домашняя сетка за NAT) не было. Время автономной работы около 4-х суток если не злоупотреблять ездой и фарой.
Можно поездить по квартире, удаленно управляя как камерой, так и платформой и оставить в режиме «сторож» (motion detect) в любом нужном месте.
Hardware
Все «железо» можно разделить на две части, первая из которых от второй не зависит и может использоваться отдельно:
Модуль видео наблюдения
- Raspberry pi zero
- USB WiFi Dongle
- Raspberry pi camera v1.3
- 2x stepper motors 28BYJ-48 + ULN2003 driver
Мобильная платформа, управляемая через SPI от малины
- 4S 16x18650 Li-ion + 4S 30A Li-ion 18650 (BMS) board + DC-DC зарядка со стабилизацией тока и напряжения
- dc-dc step down converter (15v ->5v).
- stm32f103c8t6 board
- 4x gear motors + L298N board
- 12v LED lamp (фара) + управление на IRF3205 (+smd pnp и npn)
Образ Raspbian был настроен в режим read only. В такой конфигурации, малина легко переживает неожиданные выключения питания, поскольку SD карт на запись не использует вообще.
Программное обеспечение
ПО состоит из 3-х отдельных компонент.
Android приложение (проверено на LG6 Oreo и старом Samsung S5 Lollipop)
Режим FPV
- Показ видеопотока H.264 с камеры в указанном разрешении и bitrate
- Элементы управление камерой и платформой
- Запись видео и фото с потока.
Режим Android service
- Опрос хоста (с указанной периодичность)
- Загрузка фото событий «движение» в кадре по событию.
Хост Raspberry pi на python (picamera + spidev + RPi.GPIO)
Режим FPV
- Трансляция H.264 потока (с указанными Android приложением параметрами)
- прием управляющих команд для шаговых двигателей и управление ими.
- Трансляция управляющих команд по SPI (если включен режим)
Режим отслеживания движение в кадре.
- Детектирование движения в кадре (по указанным Android приложением параметрам)
- Прием запросов «а нет ли движения в кадре» и выгрузка фото по запросу
- Отправка на хост (не зависимо от приложения) фото движений в кадре.
Простейшая прошивка на stm32f103
- Прием команд по SPI
- Управление направлением вращения колес и ШИМ двигателей.
- Управление включением фары.
Отслеживание движения
Отслеживание по векторам h.264 оказалось весьма капризным и склонным к ложным срабатывания. В сети гуляют очень мало вариантов реализации детектирования движения для H.264. Я перепробовал их всех.
Самый примитивный вариант – это подсчет количества векторов длинна которых превышает некое пороговое значение. И если каких векторов больше порогового, то это сигнал, что в кадре есть движение.
Увы. Этот вариант годится только для демонстрации принципа. Ошибочных срабатываний слишком много. Особенно на поверхностях однородного цвета и текстуры.
Все остальные варианты либо то же дают слишком много ошибочных срабатываний, либо просто не проходят критерий по производительности: «должно обработаться за время кадра».
В результате выбрал свой вариант. Он хоть практически не дает ложных срабатываний, но требует движения в нескольких кадрах подряд. Но лучше уж так, чем ложные тревоги несколько раз в день из за изменения освещенности или вообще по непонятным «движениям» в кадре по «решению» камеры. Тема алгоритмов надежного детектирования по mv Н.264 вообще отдельная сложная тема. Алгоритмы требуют много времени на практическую отладку и имею жестки лимиты на время выполнения.
Пример векторов движения (служебные режимы snapshot):
По событиям «движение в кадре» порождаются нотификации.
в принципе, для моих целей оказалось достаточно гарантированного срабатывание при движении фигуры человека (>15% кадра) в течении минимум 2-х сек. При таком загрублении чувствительности, ложных срабатываний просто не видел вообще.
Управление движением.
Управление платформой «по тракторному». Т.е. управление ШИМ и направлением вращения левой и правой стороны. Управляющие элементы (полоски) под большими пальцами обеих рук. Это оказалось наиболее естественным для меня.
Управление камерой – две полоски касание которых выдает команду повернуться на определенный угол (чем дальше от центра полоски – тем больше угол). Непрерывное управление как для моторов оказалось неудобным (опять же субъективно для меня).
Лаги FPV
Лаги видео оказались относительно небольшими (<1 сек).
Для управления колесной платформой с максимальной скоростью 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 телефона не работает.
Стоит заметить, что это в очень «RF зашумленной» среде многоквартирных домов, с множеством WiFi сетей в округе.
Удивил меня результат в конфигурации «Роутер WiFi -> провайдер по витой паре -> VPS -> MTC 4G на телефоне» через ssh port forwarding c малины на VPS.
Типичный лаг оказался даже чуть лучше, чем через локальный WiFi (!)
Даже на ходу в машине или рядом с крупным гипермаркетом лаг всего 300ms.
Однако, иногда (довольно редко и не предсказуемо), лаг становился до нескольких секунд. Помогает переконект. Наверное, это какие-то особенности 4G/МТС/провайдеров в цепочке и т.д.
После того как все заработало, появилось желание подключить звуковой канал в обе стороны. Технически это возможно и даже не очень сложно. Но возится с паяльником уже не хочется.
Если бы не было под рукой “лишнего” Rasberry pi, то вместо него проще было бы использовать старый телефон в качестве хоста видеонаблюдения и управления платформой. Единственное преимущество малины перед старым телефоном – меньший вес. И, может быть, меньшее энергопотребление (не сравнивал).
Все исходники
Комментарии (22)
mmMike Автор
24.09.2018 09:27В принципе, я же написал… python host (библиотека picamera).
А практически все скриншоты с параметрами по умолчанию: bitrate 500000. разрешение /2 экрана телефона, fps=15.
bitrate 100% определяет трафик, а разрешение + fps — определяет сколько будет артефактов при быстром движении в кадре. Это же h.264… а не mjpeg
defecator
24.09.2018 09:31А если к малинке подключить по USB обычную веб-камеру?
Может быть, сама Pi camera тормознутая?mmMike Автор
24.09.2018 09:36Да же не знаю как и про комментировать.
С одной стороны Вы говорите про то что пишете под raw железо (что само по себе весьма не тривиально без глубоко знания периферии)..
Отвечу коротко: Нет. USB вариант это медленней, чем интегрированная камера + GPU
defecator
24.09.2018 09:46Я с камерами на Малинке не работал никогда, я их для сети и GPIO использую, ну и как вычислительную ноду
Sly_tom_cat
24.09.2018 10:51Хотя бы один видосик (проезд + поворот камеры) — совсем бы не повредил статье.
Оно понятно — таких видосиков как грязи, но вот не хватает именно в этом описании видоса с разработанного девайса. Без него — как-то нет ощущения полноты картины, ИМХО.mmMike Автор
24.09.2018 11:43Как машинка ездит — у меня было видео (https://youtu.be/iq8M-esM4QQ) давно. Собственно, та же платформа. Только манипулятор с нее снял и датчики. Валялась несколько лет, пока под новую тему не приспособил.
А снимать… решил не захламлять youtube.
Изображение нормальное при правильном подборе соотношения fpv, bitrate и размера.
Экспериментальным путем (сейчас стоит) fps = 15. bitrate = 500000, 960x480.
borv
24.09.2018 22:10Спасибо за пост и исходники.
У меня была задумка собрать telepresence робота, чтобы не мотаться в офис лишний раз. Все, к сожалению, уперлось в неудачный выбор платформы. У меня под рукой в тот момент была только румба (которая, кстати, довольно неплохо справляется с тем, чтобы нести "вешалку" с планшетом), плюс там есть возможность запитаться от выводов на пылесос. Но потом выяснилось, что она больно шумная и раздражает людей, так что пришлось отказаться от затеи. Как с шумностью у вашей платформы? Не попадалось ли вам вариантов автономной зарядки?
mmMike Автор
25.09.2018 05:03Как шумит румба без включенного пылесоса — не слышал. А с пылесосом она безобразно шумная.
Моторы, поскольку с редуктором, то жужжат. но не слишком громко. В соседней комнате уже не слышно.
Автономная зарядка? Это как?
я планирую перед отпуском просто два контакта на корпус вывести и подгонять к ним, когда уровень заряда упадет. А так почти на неделю хватает автонома… За ночь заряжается.borv
25.09.2018 17:37Шумит редутор, причем довольно мерзко. С отключенным пылесосом и сопутствующими шестернями слышно на весь этаж (чертов опенспейс).
Автономная зарядка (еще один довод был в пользу румбовой платформы) — это док станция с маяком. Достаточно подрулить к доку и дать команду заряжаться. Робот сам разворачивается к маяку, попадает на контакты (три раза пытается). С учетом того, что попасть туда у него получается не всегда даже с трех попыток, видимо это не так просто как кажется. Для коммуникационного бота это актуально, т.к. там планшет который часто со включенным экраном и звуком. Подзаряжать прийдется часто.
Источником вдохновения был хак Джонни Чанга (http://procrastineering.blogspot.com/2011/02/low-cost-video-chat-robot.html). Он использовал док станцию с двумя здоровыми контактными пластинами, на которые выведено 110 вольт. Очевидно не совсем годная для офиса конструкция. Можно, разумеется, вместо сети выводить туда сразу постоянные 5В 2А и напрямую заряжать планшет, но контакт будет плохой и зарядка нестабильной. В общем я забросил это дело до лучших времен, пока ваш пост не навеял...
mmMike Автор
25.09.2018 10:46Потому что motion detect — это совершенно не зависимо от поездить с FPV
MaybeTM
25.09.2018 10:46Зачем делать систему на шасси, когда можно было просто ограничиться парой камер с датчиком движения в комнате. Просто было интересно с малинкой поиграться?
blacksoul000
25.09.2018 10:46Что использовалось для передачи видео? какое разрешение? какие настройки кодирования?
igorkozinov
25.09.2018 14:51Был ли подключен пулемет к системе?
Что стало с злоумышленником?
Куда дели труп?
Короче, тема не раскрыта!
defecator
А не рассматривали вариант декодировать видеопоток в битмапы, потом сравнивать кадры и накапливать ошибку для сработки детектора движения?
В таком режиме и изменение освещённости можно учитывать, и ещё массу всего.
mmMike Автор
Вектора считает не CPU… поэтому и энергопотребление и нагрузка небольшие в этом режиме.
количество векторов это: width*height кадра/ 4 /4
Каждый вектор: 1 байт X + 1 байт Y + 2 байта (short int) на SAD.
А сравнение кадров это программа motion на fps=4 максимум и чип на raspberry pi горячий.
Объем вычислений не сопоставим.
defecator
какие там вычисления-то? Сравнение двух кусков памяти, да и в Малинке четыре ядра.
Другое дело, что все эти ядра используются неэффективно операционкой.
По хорошему, нужно писать софт для Малинки baremetal, вот тогда можно будет выжать из Малинки всё, на что она способна.
А пока используется софт-паразит в виде Линукса, о быстродействии можно забыть
Имхо
mmMike Автор
Это не та задача, которую я решал для себя.
А то, о чем Вы говорите — это github.com/Motion-Project/motion
Я его и упоминал. Сравнение кадров там вполне оптимально на "C".
но максимальный fpv = 4 при практически 100% загрузке проца. И… потребление на 40mA больше чем через анализ векторов.
arcman
Похоже у вас камера mjpeg отдавала и распаковка сжирала все ресурсы.
Ну и больше 1-2 fps для детекции движения и не нужно.
defecator
Я для Малинки использую проект Ultibo, который как раз позволяет писать код на FreePascal сразу по железу Малинки, без прослоек в виде ОС.
ultibo.org
me21
У автора одноядерная Малина Зеро.