roboforum.ru

AndreiSk писал(а):Знают же некоторые товарищи как найти проблемы

Собсно не вижу проблемы. Я захотел сделать с нуля - я сделал с нуля. А сопрягать камеру по вайфаю/эзернету/юсби неинтересно. Всё равно что купить новую видюху для компа и вкрутить её в системник. Дрова поставил - всё, я крутой.

и как бы ты ее к avr прикрутил бы?

и как бы ты ее к avr прикрутил бы?

А толку???
Кому нужна камера с FPS 0.25 кадров в секунду??

По уарту шлёшь команду DF\r [dump frame]
камера отвечает ACK\r и шлёт в ответ пакеты с горизонтальными строками в формате

0x0B, n, R1, G1, B1,...,R174, G174, B174, 0x0F

где 0x0B - маркер начала пакета, n - номер строки, Rn, Gn, Bn - компоненты n-го пиксела, 0x0F - маркер конца пакета.

Для включения режима слежения шлётся команда ET\r [enable tracking]
камера отвечает ACK\r и шлёт в ответ пакеты с наблюдаемыми объектами в формате

0x0A, n, M1, UX1, UY1, LX1, LY1,...,Mn, UXn, UYn, LXn, LYn, 0xFF

где 0x0A - маркер начала пакета, n - количество объектов в пакете, Mn - номер цвета n-го объекта, UXn,UYn,LXn,LYn - соответственно X и Y координаты верхнего левого и нижнего правого угла рамки, обрамляющей объект n, 0xFF - маркер конца пакета

Или тебя интересует как снимается кадр непосредственно с матрицы?

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

1) Поймать начало кадра по растущему фронту кадрового синхроимпульса (например по прерыванию или ожидая его в коротком цикле). Перед этим или после этого нужно сбросить счётчик строк и пикселов в строке.

2) Поймать начало строки также по растущему фронту.

3) Поймать растущий фронт пиксельного фронта, и положить байт, находящийся в данный момент на шине данных в память. Увеличить счётчик пикселов на единицу (или сдвинуть указатель)

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

5) После окончания приёма строки увеличить счётчик строк на единицу, сбросить счётчик пикселов, перейти на шаг 2 и начать приём следующей строки.

6) После приёма последней строки (также можно захардкодить или поймать по кадровому импульсу) мы имеем в памяти полный кадр. После этого нужно переправить полученный дамп в комп по любому доступному интерфейсу (UART, USB, Bluetooth, Wi-Fi etc.)

На каждом из этих шагов есть куча места где может зарыться собака . В основном это связано с жёсткими временными интервалами между импульсами, и (как в моём случае) ограничениями памяти используемого проца. Если нет желания реализовывать всё это программно, можно переложить эту операцию на плечи хардвары. В качестве иллюстрации такого подхода можно привести в пример камеру CMUCam3. Там проц только ждёт кадровый синхроимпульс (шаг 1) после чего разрешает работу хардварного FIFO буфера, в который матрица складывает картинку полностью в автоматическом режиме без участия проца. Потом проц может забрать готовую картинку из буфера в любое удобное ему время.

А что хочешь то и делай с этими данными. Можешь натравить на них алгоритм распознавания-чего-нибудь, можешь просто в окошке показать. С моей матрицы пикселы шли в формате RGB (фильтр Байера). Делаешь SetPixel(RGB) в цикле и рисуешь картинку в окошке.

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

К какому процу цеплять камеры будешь?

У меги16 памяти на кадр не хватит, придётся бить кадр на части, например дождался начала кадра, снял 1-ю и 2-ю строку, отправил их на комп. Матрица естессно ждать не будет, так что на оставшуюся часть кадра (и вполне вероятно пару следующих кадров) смело забиваем. После передачи опять ждём начало кадра, пропускаем 1-ю и 2-ю строки и сохраняем 3-ю и 4-ю. Отправляем в комп. Со следующего кадра снимаем 5-ю и 6-ю и так далее пока не наберём количество строк в кадре. Минус такого подхода - строки полученного изображения принадлежат на самом деле разным кадрам. Но если перед объективом никто не бегает, то ничего страшного. Плюс этого подхода - это единственный способ снять картинку с камеры с помощью авр-ки
8 МГц конечно не ахти. Можно попробовать брать не каждый пиксел в строке, а, скажем, каждый второй или даже каждый четвёртый (строки конечно тоже нужно будет тогда пропускать чтобы сохранялось отношение сторон кадра). Разрешение результирующей картинки соответственно уменьшится в такое же количество раз. Но зато время на сохранение пиксела возрастёт соотв. в 2-4 раза.
Да, и кип ин майнд, так сказать, что если камера передаёт в формате Bayer RGB, то строки сохранять/пропускать можно только парами, ибо каждая нечётная строка содержит только зелёные составляющие пикселов, а чётные - голубые и красные составляющие. Так что если выкинуть все чётные строки, то получится сильно зелёная картинка