roboforum.ru

[EdGull]

ок, а тогда можно по подробней про вот это?

видеобуфера (правда камеру нужно перевернуть ) чтобы первой считываласьстрока, которая ближе к камере)

[repository]

А для ламеров на вроде меня можно схему и прошивку?
Страшно захотелось повторить!

[Michael_K]

ок, а тогда можно по подробней про вот это?

видеобуфера (правда камеру нужно перевернуть),
чтобы первой считываласьстрока, которая ближе к камере)

Алгоритм предполагает, что робот уже стоит "примерно на линии".
Поэтому рядом с роботом линия в камере широкая и ее хорошо видно.
Алгоритм находит ее центр, потом ищет "продолжение" этой линии в следующей строке и т.д.

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

А для ламеров на вроде меня можно схему и прошивку?
Страшно захотелось повторить!

Еще подумаю Может avr123 продам или кто тут у вас микроботами торгует

На самом деле, во-первых, все это "сыро" пока, во-вторых,
алгоритм эмпиричеси заточен под конкретные искажения
(угол обзора камеры, высоту над полом, угол наклона камеры и т.д.)

Вообще меня иногда пробивает на "выкладывать" (см. например myavr.narod.ru),
но занятие это неблагодарное, как показывает мой опыт

[blindman]

Какой смысл тогда было создавать этот топик? Если хотели, чтобы это было кому-то полезно, выложили бы исходники. Если для "продать", так довели бы до ума сначала.

[Michael_K]

Про продать - это шутка, конечно.
(Я думал, смайлики натолкнут вас на эту мысль )

Какой смысл? Показать возможности ПРОСТЫХ решений.
Направить творческую мысль.

Знаете, почему я написал, что "выкладывать" - занятие неблагодарное?
Потому что прилетает куча писем типа: "а у меня компилятор это не ест",
"а я перепутал питание - что делать", "не могли бы вы переделать, чтобы было
"с блэкджеком и шлюхами", "перепишите все на паскале" и т.д.

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

А вам только готовое подавай... Грустно.


Когда поставлю на шасси и вылижу алгоритмы, то оценю повторяемость.
Если (ЕСЛИ!) повторяемость будет хорошей, то выложу. Иначе смысла нет.

[blindman]

Лично мне не интересен Ваш исходный код.

Не вижу смысла публиковать идею, если не готовы отвечать на вопросы.

[yak-40]

А как информация из девайса в компьютер поступает. Судя по фотографиям через ЮСБ?

[Michael_K]

Для тех, кто не ждет готовых решений:

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

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


Примерно так.

Получается, что выборки в кадре размещены более-менее равномерно.
Для компьютерной программки из четырех строк формируется одна "широкая".
Для обработки на проце этого не требуется.

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

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

Я на умные вопросы как раз готов отвечать. Только они тонут в массе других -
"А можно я вместо атмеги впаяю микросхему от телевизора - у нее ног столько же?"

Дело в том что "Дайте!" - это даже не вопрос.

А как информация из девайса в компьютер поступает. Судя по фотографиям через ЮСБ?

Да. Через вот такую приблуду:
http://hardcoder.ru/projects6#usb

[blindman]

Я на умные вопросы как раз готов отвечать. Только они тонут в массе других -
"А можно я вместо атмеги впаяю микросхему от телевизора - у нее ног столько же?"

Если дать неполную информацию - глупых вопросов, что, меньше станет? Просто не отвечайте на них А если опубликуете полную информацию - умных вопросов, у тех, кто способен их задать, станет меньше. Ещё, глядишь, и умные предложения появятся

[Michael_K]

А если опубликуете полную информацию - умных вопросов,
у тех, кто способен их задать, станет меньше.

Тут вы правы, безусловно.
Умных вопросов станет меньше, а вот количество неумных
вырастет как снежный ком. Оно мене надо?

[blindman]

Не стану спорить. Имеете полное право делать так, как удобнее Вам, а не всем остальным.

[Michael_K]

Алгоритм поиска линии:
Алгоритм предполагает, что линия расположена вертикально и начинается ближе к центру камеры.
(не в том смысле что "строго вертикально", а в том, что "не горизонтально" )

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

В следующем кадре центр первого "колокола" для первой кривой располагаем, исходя из информации о том,
где была найдена линия в предыдущем кадре.

Как видим, алгоритм не требует видеобуфера. При приеме очередной точки, выполняются только умножения
и сложения, ну и некоторые расчеты в конце строки. Исходные видеоданные не хранятся.

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

...а не всем остальным.

Это вы смело сейчас за всех ответили

Информации, по-моему, выдал достаточно для повторения.

[contr]

Алгоритм, как я понимаю может быть и такой:
ловим компаратором кадровый строб,
80 раз оцифровываем строку //быстрее не успеваем,
ищем максимум и запоминаем номер отсчета,
и т.д. 60 раз.
*время ADC подогнано под строку, а весь цикл под кадр.
**между кадрами сшиваем отсчеты

Решение красивое, поскольку любой глазок и МК можно использовать

[Michael_K]

Алгоритм описал.

80 раз оцифровываем строку //быстрее не успеваем,

У меня только 20 раз получилось.
80 раз за 50 микросекнд - это больше мегагерца.
ATmega88 так не умеет.

В реальном железе планирую перейти на ATxmega32
- вот там и развернусь. Там штатная частота АЦП - 2МГц при 12 битах.

[contr]

Вы в начале топика говорите о 80*60, но это не принципиально
По ходу оцифровки строки можно запоминать лишь максимум. Это даст правый край широкой линии.
На второй строке по уже имеющемуся значению можно попробовать отловить левый.
А на анализ направления линии есть куча времени между кадрами.

Правда для трасера больше мышиный сенсор подходит, а для распознавалки мобильный или глазок с dsh к матрице.
А вот простой датчик движения в кадре на этом принципе сделать можно.