Raspberry PI 3 + OpenCV + Arduino UNO + ......(поледнее решение и вопрос в последнем сообщении)

Подключил свою панель к RS232, не заработала со своим кодом. Где-то вылез за границу какого-то массива или ошибся в ссылках, пол часа отдал не нашел, а голова уже не работает, оставил на потом.

Запустил Ваш код, а он шлет ошибки, оказывается у Вас еще нужно попасть в адрес. В начале получал ILLEGAL DATA ADDRESS. Каких-то проблем в коде не увидел, надо его конечно погонять и внимательнее глянуть. Завтра в командировку, поэтому уже не сегодня.

Но в общем кроме того, что есть 2 функции CRC, много дублирующего кода, который лучше вынести до определения команд разборки данных, чего-то режущего глаз не увидел. Это уже мелочи, так же, если будут проблемы, добавил бы, проверку на паузу сообщения, о той которой Вы говорили, у меня она равна 5мс.

Теперь о максимальном времени цикла, когда оно не большое Вы можете с большей периодичностью делать опрос, который не завязан на прерываниях. Конечно это максимальное время (среднее обычно меньше), но по нему можно ориентироваться на кол-во операций выборок данных и т.д.

О таймерах на millis, micros, это просто замер времени и сравнение. Следовательно они будут вызываться лишь, когда выполнение дойдет до проверки, поэтому сравнивают >= (равно скорее, для очистки совести, но может и совпасть). Точность получаемых значений millis, micros равно 4 мс и 4 мкс для micros.

Все нормально.

Вы делаете данный проект, я так по вечерам иногда (когда есть время) вставляю свои 5-копеек. Причина, мой проект со стороны Ардуино имеет много пересечений, тот же Modbus, хотя реализации разные (свою уже Вам скидывал).

 

В принципе всё работает - в тестировании уже несколько часов! Ещё несколько проверок и ход дальше - доведение до конца псевдопоиска - "ткнул" мышкой на изображкнии.... там проходит регистрация гистограммы фрагмента, поворот камеры, чтобы фрагмент стал по центру изображения,... если дальше поворачивать некуда, то поворот платформы... ну и так далее - следование к объекту и т.п.
Вот это пункты для управления железкой.
arbot.zip
r1_uno_plus.zip
То что касается видео.... и некоторой работой с ним было ранее (последнее выложено)... включая поворот камеры с "поиском" фрагмента по выделению кликом.
Что касается ВМЕСТЕ это и значит, что не один и вопросы могут затрагивать множество тем и каждый тоже найдёт какое-то решение и в общей теме.
Мне тоже надо применять дальномер совместно с камерой... хотя видел примеры с двумя камерами.

 

Доброго времени суток!
На текущий момент пока никаких телодвижений с управлением не предвидится.
Но... доработка управления по клику на изображении, передаваемого с камеры через малину (испытание на ПК с Linux):
1) при клике определяем координаты собственно клика по отношению начала координат на картинке камеры;
2) регистрируем гистограмму по этим координатам в квадрате 70х70 пикселей, где наши координаты в центре этого квадрата;
3) сверяем принадлежность этой гистограммы к центру экрана(по допустимым границам), в случае принадлежности к центру переходим к пункту 8;
4) даём команду управления на поворот камеры в зависимости от отклонения от центра экрана;
5) ожидаем поворот камеры;
6) производим поиск фрагмента изображения по гистограмме для квадрата 70х70 по всему изображению;
7) переходим к пункту 3;
8) позиционирование на выделенный объект завершено.
Аналогично вполне можно производить позиционирование на какие либо определённые простые элементы. Сейчас стоит вопрос про ускорение поиска. Сейчас поиск после поворота камеры от центра изображения в предполагаемом направлении. Может есть у кого соображения на эту тему.
Заранее спасибо!
С глубоким уважением!

 

Не совсем понятно для чего производится поиск фрагмента изображения на кадре. Относительных углов направления на цель недостаточно? Или в перспективе сопровождение подвижной цели?

 

В перспективе движение к "выбранной цели"... перед этим перенос отработанного в малину... и организация на ней управления. Пока делаю не в OpenCV - требуется сначала отработать.
Решит проблемы поиска.

 

Вот пока придумать ничего и не могу пока... пока медленно и решил частично применить OpenCV на малине. Переделал как сервер, так и тестовую программу. Сервер предполагает несколько подключенных клиентов и каждый должен получать то, что ему нужно. В тестовой программе пока применяю только два только "режима". Это преобразованное из цветного в чёрно-белое 8 бит. В OpenCV:

Код (C++):

//gray
                cv::Mat gray;
                cv::cvtColor(src, gray, CV_BGR2GRAY);
 

в ComboBox выбираем gray. Сам метод поиска пока не проработан.


Адаптивное преобразование (я так назвал эту бинаризацию) в OpenCV:

Код (C++):

//adaptive
                cv::Mat adapt = cv::Mat::zeros(markers.size(), CV_8UC3);
                cv::adaptiveThreshold(gray, adapt, 255, CV_ADAPTIVE_THRESH_MEAN_C, CV_THRESH_BINARY, 11, 1);
 

Тот же самый участок. Выбирается программой клиентом, а сервер соответственно передаёт согласно запросу. В ComboBox выбрано adapt. Методом поиска по гистограмме пока очень не быстро. Да и в самом сервере возможно существенно увеличилась временная задержка, но на одном подключенном клиенте не видно. Сервер должен не только выдавать но и делать некоторые операции самостоятельно.

 

Так может дело в математике анализа изображений? Как то лет пять - семь назад, когда занимался диссером, натыкался на методы анализа изображений с помощью MathLab. Для моей темы было не актуально - прошел мимо. Там вроде бы есть пакет для этого. Сейчас уж и не вспомню как называется. Студенты-аспиранты (или преподы, научные руководители) смогут подсказать. Или нагуглить можно. Например первое, что выдал поисковик.
Понятно, что Mathlab на малине не пойдет, но можно заимствовать алгорИтмы, идею. А может и наработки какие в инете найдутся. Народ смотрю даже распознавалки автомобильных номеров делает.

 

Сильно не вдавался в Ваш алгоритм оцифровки изображения, поэтому интересуюсь - сжатие какое-то применяете?

 

Никогда не обращал внимания на MathLab... посмотрел вашу ссылку и увидел, что многое из того есть и в OpenCV. Буду копать! Спасибо за информацию! Пока доделаю "скелет" сервера камеры.

 

Сжатия никакого - предназначено для других программных модулей на других малинах... или линукс машинах. Там придётся "разжимать" - потому напрямую. Сейчас все данные от/в одной/у малины/у по WIFI и управление приводами и видеоданные.

 

Я к чему про сжатие. Есть ли смысл в запомненном участке 70х70 использовать информацию о каждом пикселе? Определиться со значением яркости основной площади прилегающего фона (допустим "рамка" толщиной еще сколько-то пикселей) и заводить в массив только параметры яркости тех пикселей, которые отличаются от установленного значения относительно прилегающего фона. И прилеплять к нам флаг. Возможно еще один массив понадобится для хранения адресов непустых элементов массива.
Потом следует выборка из по флагам с выдачей адресов флагов. Сравнение, допустим, если поиск камерой слева на право - то совпадение с левыми столбцами массива. Если сверху вниз, то с верхними строками.
Сумбурно... к сожалению в написании кода я не помощник для Вас...

 

Это пробная часть... потому и не доделал. Испытывал поиск по всему изображению... но это долго. С уменьшением размера квадрата конечно быстрее. Всё изображение по данному методу наверное не годится. После перемещения камеры картинка меняется... и соответственно весь набор строк или столбцов... я имею ввиду выбирать не квадрат, а столбец и строку. Весь набор меняется. Единственное, что пришло в голову это некоторая зависимость (допустим по строке) интенсивности между пикселями на каком-то выбранном участке. Выбрал пока квадрат. Но ещё наверное есть возможность давать координаты серверу, в котором реализация модуля на основе библиотеки OpenCV, который сможет... допустим "заполнить" замкнутый контур, найти его условный "весовой" центр координат и вернуть разницу координат выделенного места и этого центра. Кроме того он должен повторно позже найти этот-же контур и проделать то же самое после перемещения. Ну это я фантазирую конечно. Вы правы велосипед не нужен! Уже кто-то делал это. Пока читаю... и вникаю - курю одним словом.

 

Перед дальнейшими действиями решено сначала подготовить данные для работы. Саму программу camserver можно запускать и в тестовом режиме... собственно на основе этого и делал испытание. В работу сервера и тестовой программы клиента внесены изменения, а именно определены три типа запросов от клиента, на которые должен соответственно он и получить ответы:

Код (C++):

#define _vtype_scr8             0x01            //тип обращения - указывает, что от OpenCV картинка чёрно-белая 8 бит
#define _vtype_scr_at        0x02        //adaptive - адаптивная бинаризация
#define _vtype_scr_ap        0x03        //gray & adapt - логическое И чёрно-белого изображения и результата бинаризации

Соответственно сервер многопоточный и данные не "мешают" друг другу для каждого из запросов. Он в состоянии обслужить до 10 соединений(клиентов). Кроме этого передаются некоторые параметры для режима "обработки".
Исходная картинка:

бинаризация с минимальными значениями параметров - два маленьких вертикальных позунка:

результирующая картинка:

параметры бинаризации и результирующей картинки соответственно после некоторой игры с параметрами с помощью ползунков:

Таким образом требуется выбрать параметры для упрощения поиска на картинке.
Подопытные:
Сервер камеры с добавлением режимов (для малины):
camserver.zip
Тестовая программа с добавлением режимов на ПК:
qtarpi.zip
Это попытка увеличения функциональности сервера камеры

 

Вариант алгоритма поиска фрагмента на изображении.
Из фрагмента берем один центральный столбец. Получаем некую комбинацию значений. Далее эту комбинацию ищем в столбцах пикселей нового кадра.
То же самое делаем с одной строкой.
Чем сложнее кадр, тем выше вероятность того, что пересечение найденного столбца с найденной строкой является центром искомого фрагмента.
И еще. На мой непросвещенный взгляд, оцифровка параметра яркости приведет к ошибкам при поиске фрагмента в кадре, снятом с другого ракурса. Или внезапном изменении освещенности сцены. Думаю логичнее оперировать дельтой яркости соседних пикселей.
Надеюсь мои соображения будут полезны.
С уважением

 

К какому значению оптимальнее привязаться? К первому по счёту? Эта дельта так же меняется с изменением параметра освещённости.

Изображения беру от веб-камеры. Как "взвесить" лучше значения для устранения эффекта изменения освещённости - при смене ракурса камера непрерывно авторегулирует свои параметры... и данные принятые за искомые становятся не действительны. Это важно! Потому в первых опытах при поиске регистрировал новые значения... даже думал находить "огибающую" гистограммы. Хотя наверное от гистограммы надо уходить.

 

Думаю, что к разнице пикселей-соседей. В том порядке, в котором потом будет "попиксельный обход" при поиске совпадений (сверху вниз или снизу вверх для столбца). Допустим разница между 1-м и 2-м пикселем равна 4. Между вторым и третьим 2. Между третьим и четвертым 3. Вот и комбинация 4-2-3.
При обходе столбца нового кадра сначала вычисляем такие же разницы по такому же алгоритму. Создаем массив с дельтами. А далее ищем в нем совпадения комбинаций. Возможно с использованием мажоритарности.
Столбцы или строки - экспериментируйте. Что быстрее обрабатывать. Меньшее количество длинных строк массива или большее количество коротких.

 

Вообще интеллектуальная обработка видео - задача далеко не тривиальная. Реально работающие (в т.ч. и на государство) алгоритмы, патентуются и защищены авторским правом. А в некоторых системах - под гостайной.

 

попробую уже сегодня не успею... завтра отъезжаю на сутки... по поводу прав авторских и секретности - это не ко мне. решения они и в африке решения! Работаю...

 

Доброго времени суток!
Собственно основные испытания прошли успешно, если не считать упомянутого "поиска" фрагмента, испытание которого частично успешны. Отсюда вывод:
1 сделать управление и приём данных картинки одним сервером с разделением типов;
2 реализовать "ключевой" обмен данными между клиентами (взаимодействие двух малин между собой, одного ПК(Debian) и одной Moxa UC-7112-plus прошли успешно), где малина 3, организующая сеть (DHCP). В качестве второй малины выступали по очереди по ETHERNET RPi3 и RPi B+. Одновременное подключение не производилось по причине отсутствия материальных возможностей.
"Ключевой" обмен разработан ранее и применён на предприятии - в распределённой системе управления:
взаимодействие 4-х отдельно запущенных программ на одном устройстве либо на разных устройствах, взаимодействующих через этот сервер:
ServConn.zip
В данную "схему" будет заложен не только доступ к источнику данных, но и взаимодействие клиентов между собой.
Совсем не упомянул о дальномере (который не приобретён пока) и возможно о манипуляторе на сервомашинках.
Так же интересен опыт эксплуатации альтернатив Raspberry, таких как Orange и т.п.
Очень нужна помощь в разработке протокола обмена. Причём с "видео" более менее ясно. Очень надоело делать программы "на выброс" хоть они и для испытаний - ведь переделывать приходится не одну, а несколько сразу.
Эскиз протокола:
Основные определения при обмене:
- размер данных - 4 байта в прошлом случае было 2 байта, что не достаточно для передачи картинки.
- идентификатор кода(программы) который послал запрос. идентификатор должен определять и функциональное назначение.
- идентификатор кода для которого ответ на запрос, так же содержит функциональное назначение этого кода.
- тип данных (управление по Modbus, управление логическое устройствами(приводами и т.д.), видео в форме картинки, видео в форме представления в OpenCV без преобразования, описание пространства (карты), описание состояний (положений) элементов устройства в описании пространства)
.........

Код (C++):

/*
********************
* для всех пакетов *
********************
*/
//заголовок пакета - распределение адресов
//размер данных - описание из 4-х байт
#define _vtcp_sz0               0x0000          //младший байт размера
#define _vtcp_sz1               0x0001          //
#define _vtcp_sz2               0x0002          //
#define _vtcp_sz3               0x0003          //
//идентификатор типа входящего 2 байта
#define _id_tin0        0x0004        //идентификатор типа
#define _id_tin1        0x0005
//идентификатор номера входящего 2 байта
#define _id_nin0        0x0006
#define _id_nin1        0x0007              
//идентификатор типа исходящего 2 байта
#define _id_tout0        0x0008        //идентификатор типа
#define _id_tout1        0x0009
//идентификатор номера исходящего 2 байта
#define _id_nout0        0x000A
#define _id_nout1        0x000B
//общие определения для идентификаторов  
#define _type            0x000C          //тип обращения - выбор режима для выбранного идентификатора
#define _vcop                   0x000D          //код операции для идентификатора
//идентификатор времени
#define _mtime0            0x000E
#define _mtime1            0x000F
//начало данных - формат для идентификаторов свой
#define _vdaddr                 0x0010          //начало данных
 

1 - клиент делает запрос на сервер по идентификатор. Если ИД соответствует серверу, то сервер исполняет этот запрос. Иначе запрос в виде ответа передаётся другому клиенту с этим ИД.
2 - клиент получивший ответ от сервера в виде запроса со своим ИД отвечает серверу для запросившего ИД в виде своего нового запроса, после подтверждения ответа на который делает свой новый запрос для своих целей с необходимым ИД.
И т.д. Необходимо так же предусмотреть исключительные ситуации, как со стороны клиентов, так и со стороны сервера. Сервер по умолчанию рассчитан на одновременное поддержание десяти соединений(клиентов) по TCP.
.........
Заранее благодарен за предложения!
С Глубоким Уважением!
С Наступающим Новым Годом!

 

Столкнулся с проблемой компиляции... не на каждом устройстве предусматривается установленная библиотека OpenCV. Потому возникла необходимость в "автоматической" работе make... ну или "автоматическое" подключение ключей например -lopencv_core в Makefile если применяются компоненты OpenCV. Может у кого есть такой опыт? Или делать всё таки bash скрипт конфигурации.
Заранее спасибо!
С Глубоким Уважением!