roboforum.ru

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

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

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

EdGull писал(а):ок, а тогда можно по подробней про вот это?

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

blindman писал(а):...а не всем остальным.

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

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

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

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

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

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

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

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

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

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