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 тактов чего?

Добавлено спустя 19 секунд:
Между пикселями, на строку или что?

50 тактов на пиксель.
(АЦП выдает результат каждые 56 тактов, если быть точным)
Между строками, естественно, паузы большие.
Между кадрами - совсем большие.

Есть идея локального позиционирования недорогого по аналогии с системой North Star коммерческой.

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

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

Добавлено спустя 1 минуту 58 секунд:
Центр тяжести считается элементарно - к общему весу добавляем 1 от каждого яркого пикселя, а к суммовым координатам его координаты, потом делим координаты суммовые на вес и получаем центр тяжести. Останется посчитать ориентацию. Её можно считать скажем складывая квадраты векторов от центра тяжести предыдущего кадра (считаем, что между кадрами не сильно смещаемся).

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

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

Код: Выделить всё

            ;Такты
===================================================
lds   a,ADCH      ;2 Взяли в a из АЦП
neg   a      ;1 Ищем черное на белом
===================================================
lpm   k,Z      ;3 Берем коэффициент из кривой

mul   a,k      ;2 Умножаем k*a
add   sum1_l,r1   ;1 Добавляем к сумме1 старший байт произведения
adc   sum1_h,zero   ;1

mul   r1,x_coord   ;2 Умножаем k*a*x
add   sum2_l      ;1 Добавляем к сумме2 старший байт произведения
adc   sum2_h,zero   ;1

add   rem,delta   ;1 Двигаем указатель на кривую
brcc   .+1      ;1
inc    ZL      ;1

inc    x_coord      ;1 Двигаем x координату
===================================================


Здесь все переменные - регистры.
Код исполняется (вместе с чтением из АЦП и инвертированием) за 18 тактов.
(остается еще 38)
В конце строки считаем ЦТ, деля одну сумму на другую.

Добавлено спустя 2 минуты 45 секунд:

Есть идея локального позиционирования

Уже неплохо Спасибо.

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

Добавлено спустя 2 минуты 11 секунд:
Точку отсечения находим из упрощенной гистограммы предыдущего кадра.

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

Добавлено спустя 35 секунд:
А еще можно гистограмму вокруг предыдущего отсечения только считать, а дальше грубо, чтобы она адаптивная типа была но это уже круче

тупо складываем по отсечению

Я понял, я привел пример для "лайн-трейсера" из соседней ветки,
а ваше сообщение уже после этого увидел

=DeaD= писал(а):Взять прожектор с трафаретом, рисующим на потолке это геометрическое тело.

А если взять инфракрасный прожектор? Тогда его не видно будет. А с камеры снять инфракрасный фильтр.
Или я не прав?

Да, разумеется, в системе North-Star так и сделано еще у меня есть подозрение, что хороший мощный ИК-прожектор позволит не выключать основное освещение, но это надо проверять.

а может начнем с простейшего и обсудим датчик препятствий?

Можем - предлагай, что для этого надо сделать за 50 тактов!

PS: По моему локальное позиционирование проще - которое я описал, т.к. есть полное техническое решение + уверенность, что в 50 тактов оно уложится

а я откуда знаю что для этого надо сделать?
я думал датчик препятствий проще...

Michael_K в архиве первого поста в файле main.c комментарии в кракозябрах

Добавлено спустя 2 минуты 38 секунд:
хотя если его открывать в опере, то всё ок.

IMHO, в данном случае датчик препятствия сложней, т.к. прожектором мы формируем простое изображение, которое знаем как эффективно распознавать, а препятствия фиг знает как выглядят.

Добавлено спустя 36 секунд:
Но! Если будет лазерная линия - можно обсудить как с ней сделать эффективный датчик препятствий

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

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

вот на картинке белая линия это вероятный след лазера на "препятствии"
зелёная это прямоугольник который сразу определяем как "препятствие" и передаём его координаты. нам же в принципе не надо знать точную форму препятствия, просто знать что оно есть там а вокруг свободно

2Myp: Типа в дверные проёмы мы принципиально не поедем? Уж если делать детектор, то возвращать серию расстояний по всему рассматриваемому сектору.

Добавлено спустя 25 секунд:
Правда проще наверное будет повернуть камеру но там поле зрения сузится.