roboforum.ru

По просьбе EdGull выкладываю для желающих поизгаляться...

Исходники и хекс для AVR на GCC (пользуюсь версией 20080512) - тупая хваталка с камеры 80х60 пикселей.
Посылает данные через FTDI на комп.
Исходники и экзешник для компа на VB - ловит данные и показывает.

Картинка:

Схема:


Питание 5 вольт.
Кварцы: на меге - 20Мгц, на FTDI - 6МГц.
Все конденсаторы - 0.1мкф
Резисторы слева направо 1.5к, 470, 470...
два делителя справа - у меня стоят подстроечники на 4к7

ОФФТОПИКОМ в этой теме будет считаться:
- зачем это надо автору,
- на чем и как это сделать будет лучше,
- обсуждение кривизны схемотехники и кода.
( Это я и так знаю - делал быстрый макет. )


Частота проца 20МГц, предделитель АЦП - 4.
Получаем оцифровку с периодом 2.6 микросекунды.
Строка видеосигнала - 64 микросекунды (видеоданных меньше)
Строк 252.
Получается порядка 20 точек на строку растра.
То есть, если подходить тупо, то можно получить разрешение
20(ширина кадра)x280(высота) - это неудобно.

Поэтому я делаю выборки по принципу "шахматной доски":
Выборки из строк выбираются со смещением относительно строба.



AVR-ка может выделить на обработку порядка пятидесяти тактов на каждый пиксель.

А вот узнать хотелось бы следующее:
- Что в эти 50 тактов хочется поместить и что туда удастся поместить?


На вопросы по схеме и исходникам отвечу.

Варианты применения и алгоритмы – это хорошо, но несколько не в тему.
Меня больше интересует техническая сторона вопроса

...тупая хваталка с камеры 80х60 пикселей.

Строка 64мкс, 80 точек это 64/80=0,8мкс или скорость оцифровки >1200ksps. Как удалось получить такой результат с АЦП, который выше 200ksps раньше разогнать никому не удавалось?

Myp писал(а):наверняка кто-то что-то такое ковырял для слабых МК

Я подчеркну еще раз - проблема ВОВСЕ НЕ в слабом МК, а в реалтайме.
Если вы возьмете ARM 100MHz и камеру 320х240 х 30Гц,
то получите еще меньше тактов на пиксель - посчитайте.
(А тут продвигаемые 1300х1000 х 15Гц - это вообще задача для специализированных ядер -
даже у гигагерцового пня будет всего 50 тактов на пиксель).

Myp писал(а):обычная видеокамера обладает встроенным АРУ

Да. И это можно использовать.

Myp писал(а):было бы интересно узнать вектор движения группы пикселей в кадре.

Ну это вы замечтались, конечно.
Тем более если речь идет о роботе, который сам по себе едет, поворачивает и колбасится.
Эту группу пикселей надо еще найти, сгруппировать,
она там будет не одна, и двигатся группы будут с разными скоростями.
Это, безусловно, сложная и не реалтаймовская задача _для таких условий_.

Но вот упростить задачу можно.
Давайте будем искать не "вектор движения группы пикселей",
а тупо - двигается ли что-то слева? Двигается ли что-то справа?
Или найти "центр чего-то движущегося". Думаю, и такая постановка
задачи может быть полезной и найдет применение.
Да, не везде и, конечно, не всегда - но ведь и это будет результатом!
Здесь сложность скорее в том, что у нас камера сама движется,
а не в самом детекторе движения.

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

contr: Вам бы тему сначала прочитать, чего и как Michael_K оцифровывает. У него то практика в активе, а у вас голословные рассуждения человека даже неудосужевшегося прочитать чего сделано на практике. Впрочем мне уже ясно к чему вы всё клоните - Michael_K конечно же великий фальсификатор, ничего этого он не мог сделать и всё врёт

строк по видимому 240 (хотя в другом посте 280 - это нам Michael_K прояснит я думаю).

Со строками экспериментировал.
В выложенных исходниках - 252
(меньше 256 - чтобы влезало в байт, и кратно 4-м, чтобы набрать из 4-х строк одну ).
Реальное разрешение, соответственно, 80х63.
На картинке на компе "пиксели" тоже расставлены в "шахматном" порядке
- можно заметить "гребенку" в верхней строке на скриншоте.

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

Добавлено спустя 5 минут 37 секунд:

у дверного глазка кадровая 50Гц?

Ничего не знаю, на моей камере было написано: "стандарт PAL".
Для ч.б. камеры думаю, что это значит что кадровая 60Гц, хотя не мерил.
Причем тут глазок - не понял.

У всяких телефонных и веб матриц обычно в мануалах указаны параметры для 15-30-60 Гц,
хотя понятно, что тактировать можно по-разному.

Добавлено спустя 18 минут 45 секунд:
2Contr:
Я уже про это писал и, более того, отвечал вам лично.
Только вы, очевидно, ответы не читаете.
Смысл-то вам отвечать?

PAL – система кодирования цвета, к кадрам не привязана. Зато 30Гц, вернее 30fps – прямое указание на цифровую камеру.
Глазком обзывают Ч/Б камеру с цифровым сенсором и аналоговым выходом.

Ладно, откуда взялись пикселы, сделавшие строку длиннее выяснил. Теперь прикинем, что дает искусственное увеличение размера. Допустим, имеется вертикальная линия шириной 1/20 строки. Фрагменты для двух строк будут такие
0-0-255-0-
-0-127-127-0
итоговый 0-0-0-127-255-127-0-0.
Да, размер удвоился, но информации больше не стало, скорее сами добавили шумов. И зачем?

Я думаю contr'у просто нечем заняться и он вам мозг парит

Заниматься техническим зрением он не будет никогда, проблему и её решение не понимает - какой смысл ему отвечать?

Вы были бы правы, если бы АЦП был интегрирующий.

Я снимаю с кадра 60х80 = 4800 точек. Реальных.
Равномерно расположенных на кадре.

Посмотрите на скриншот - видите вертикальную складку на майке?
Она шириной в один пиксель.