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 тактов хочется поместить и что туда удастся поместить?


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

наверняка кто-то что-то такое ковырял для слабых МК
надо только найти =)
мне лень)

ЗЫ
я тут подумал ещё чуть чуть
обычная видеокамера обладает встроенным АРУ
достаточно тормозным, видимо он использует общую яркость последних неск кадров для того чтобы снизить выходной сигнал немного, если всё равно есть пересвет то ещё чуть снижает уровень
и так плавно пока не попадём в нормальную экспозицию.

уровень там меняется многократно
с увеличением шумов и ухудшением цветности с понижением общей освещённости

если ей под нос дать шим 50% фонариком она скорей всего настроится на некий средний уровень за последнюю секунду-полторы.
соответственно кадр без фонарика будет недосвечен, кадр с фонариком пересвечен

_________________
<telepathmode>На вопросы отвечает Бригадир Телепатов!</telepathmode>
Всё уже придумано до нас!

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

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

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


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


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

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

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

это уже второй вопрос, хотя на первый ответа не получил

О каких 30Гц постоянно идет речь, если у дверного глазка кадровая 50Гц?

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

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Ну значит автор поста первый, кому удалось

Написаны же были все цифры:
Частота сэмплинга - 384.6 ksps (2.6 мкс на сэмпл)
20 сэмплов на строку (52 мкс из 64 - остальное - невидимая часть строки, поля там и синхроимпульс)
строк по видимому 240 (хотя в другом посте 280 - это нам Michael_K прояснит я думаю).

За счет смещения сэмплов из растра 20х240 получаем 80х60 - примерно так же, как в обычном ТВ из 300 с чем-то строк на 50 Гц получается 625 на 25 - там чересстрочность 1:2, тут "чересстолбцовость" 1:4. Не надо только сразу заявлять, что это "обман" и пикселей 20. В бытовом 4-мпиксельном цифровом фотоаппарате при разрешении картинки 2304х1728 в каждой строке тоже 1152 пикселя одного цвета - и ничего, никто не жалуется, остальные вообще программно придумывают

Добавлено спустя 30 секунд:

Я думаю о вебкамере

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

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

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

Ничего не знаю, на моей камере было написано: "стандарт 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, вы знаете, что такое оффтопик?

С чего вы это взяли?

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

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

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

шахматное смещение на второй строке приведет к тому, что по половинке линии окажется в соседних оцифровываемых пикселах.
Реальное разрешение камеры в данном случае ограничено скоростью оцифровки и искусственное раздувание размера картинки ничего не дает.

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

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

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

Спасибо! Теперь дошло! Что АЦП выхватывает уровень и только потом его цифрует не подумал
Получается, что строки должны быть сдвинуты на 1/4, а не в шахматном, если уж учетверять.