Комментарии 26
В таком режиме и изменение освещённости можно учитывать, и ещё массу всего.
Вектора считает не CPU… поэтому и энергопотребление и нагрузка небольшие в этом режиме.
количество векторов это: width*height кадра/ 4 /4
Каждый вектор: 1 байт X + 1 байт Y + 2 байта (short int) на SAD.
А сравнение кадров это программа motion на fps=4 максимум и чип на raspberry pi горячий.
Объем вычислений не сопоставим.
Другое дело, что все эти ядра используются неэффективно операционкой.
По хорошему, нужно писать софт для Малинки baremetal, вот тогда можно будет выжать из Малинки всё, на что она способна.
А пока используется софт-паразит в виде Линукса, о быстродействии можно забыть
Имхо
Это не та задача, которую я решал для себя.
А то, о чем Вы говорите — это github.com/Motion-Project/motion
Я его и упоминал. Сравнение кадров там вполне оптимально на "C".
но максимальный fpv = 4 при практически 100% загрузке проца. И… потребление на 40mA больше чем через анализ векторов.
ultibo.org
У автора одноядерная Малина Зеро.
В принципе, я же написал… python host (библиотека picamera).
А практически все скриншоты с параметрами по умолчанию: bitrate 500000. разрешение /2 экрана телефона, fps=15.
bitrate 100% определяет трафик, а разрешение + fps — определяет сколько будет артефактов при быстром движении в кадре. Это же h.264… а не mjpeg
Может быть, сама Pi camera тормознутая?
Оно понятно — таких видосиков как грязи, но вот не хватает именно в этом описании видоса с разработанного девайса. Без него — как-то нет ощущения полноты картины, ИМХО.
Как машинка ездит — у меня было видео (https://youtu.be/iq8M-esM4QQ) давно. Собственно, та же платформа. Только манипулятор с нее снял и датчики. Валялась несколько лет, пока под новую тему не приспособил.
А снимать… решил не захламлять youtube.
Изображение нормальное при правильном подборе соотношения fpv, bitrate и размера.
Экспериментальным путем (сейчас стоит) fps = 15. bitrate = 500000, 960x480.
Спасибо за пост и исходники.
У меня была задумка собрать telepresence робота, чтобы не мотаться в офис лишний раз. Все, к сожалению, уперлось в неудачный выбор платформы. У меня под рукой в тот момент была только румба (которая, кстати, довольно неплохо справляется с тем, чтобы нести "вешалку" с планшетом), плюс там есть возможность запитаться от выводов на пылесос. Но потом выяснилось, что она больно шумная и раздражает людей, так что пришлось отказаться от затеи. Как с шумностью у вашей платформы? Не попадалось ли вам вариантов автономной зарядки?
Как шумит румба без включенного пылесоса — не слышал. А с пылесосом она безобразно шумная.
Моторы, поскольку с редуктором, то жужжат. но не слишком громко. В соседней комнате уже не слышно.
Автономная зарядка? Это как?
я планирую перед отпуском просто два контакта на корпус вывести и подгонять к ним, когда уровень заряда упадет. А так почти на неделю хватает автонома… За ночь заряжается.
Шумит редутор, причем довольно мерзко. С отключенным пылесосом и сопутствующими шестернями слышно на весь этаж (чертов опенспейс).
Автономная зарядка (еще один довод был в пользу румбовой платформы) — это док станция с маяком. Достаточно подрулить к доку и дать команду заряжаться. Робот сам разворачивается к маяку, попадает на контакты (три раза пытается). С учетом того, что попасть туда у него получается не всегда даже с трех попыток, видимо это не так просто как кажется. Для коммуникационного бота это актуально, т.к. там планшет который часто со включенным экраном и звуком. Подзаряжать прийдется часто.
Источником вдохновения был хак Джонни Чанга (http://procrastineering.blogspot.com/2011/02/low-cost-video-chat-robot.html). Он использовал док станцию с двумя здоровыми контактными пластинами, на которые выведено 110 вольт. Очевидно не совсем годная для офиса конструкция. Можно, разумеется, вместо сети выводить туда сразу постоянные 5В 2А и напрямую заряжать планшет, но контакт будет плохой и зарядка нестабильной. В общем я забросил это дело до лучших времен, пока ваш пост не навеял...
Потому что motion detect — это совершенно не зависимо от поездить с FPV
Что стало с злоумышленником?
Короче, тема не раскрыта!
Raspberry Pi не справится. Без вариантов. Даже с выделением человека на кадре, на более менее нормальной FPS, для последующей обработки (ну разве что последние старшие модели).
Да и вообще, задача ну не слишком тривиальна, если брать общий случай, а не группировать по упрощенному алгоритму (например совпадение цветов одежды на выделенном под кадре/силуэте).
А какие тогда возможны варианты?
С ходу не отвечу. Это нужно покопать. Не 5..10 минут.
Но у меня сейчас работы полно и эта темой я заниматься не могу.
Уж извините :)
Хотя… Если чисто побаловаться, то лично я бы взял для экспериментов смартфон. Android. Но это мои предпочтения (есть под рукой старый телефон и умею писать на Java|Kotlin, C++).
Мобильный сторож на Raspberry pi (h.264)