roboforum.ru

Хм...
Ну будем считать, что я тоже описал
"принципиальные отличия от типового подхода"
Можете начинать "использовать или рожать свое".

Извините, но Вы просто оцифровали сигнал с оверклоком. Это не новость и используется в скопе bodja, моем показометре и многих других проектах. Эта часть, лично для меня, интереса не представляет

contr писал(а):На станок и пр. можно взглянуть здесь http://klev.borda.ru

Блин, это дежа-вю или я гдето уже видел этот сайт по другому адресу?...

Добавлено спустя 5 минут 10 секунд:
Бгг, адрес другой, а аффтар тот же)

contr писал(а):...Вы просто оцифровали сигнал с оверклоком...

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

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

Просто у contr'a ничего хорошего видимо у самого не получается, вот он и ходит по чужим проектам, рассказывает, что ничего нового никто не делает

Я описал способ получения более высокого горизонтального разрешения

Разрешение у Вас ограничено скоростью ADC. От того, что вторая строка уехала пикселов больше не стало. Вот обработка МК интересна, только не строки, а кадра.
В реальном времени этого не сделать, скорости даже на приличную оцифровку не хватает. Да и бот не ракета, можно не спешить.

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

...пикселов больше не стало...

Да, больше стало разрешение по горизонтали.
Считываемые пиксели равномернее расположены на площади экрана.

только не строки, а кадра.

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

...чтобы "велосипед" не изобретать.

У меня хобби такое - изобретать "велосипеды".
Вот кто-то получает удовольствие, повторяя чужих БИМов,
а я - изобретая "велосипеды"

-----------------------------------------------------
- Почему нельзя заниматься сексом на Красной площади?
- Советами замучат.

Разницы никакой нет.

Ошибаетесь! Выхватить "белый" пиксел строки не сложно, трассеры это парой фотодиодов делают. А вот оценить кадр для обнаружения пятна/фигуры или направления линии, или предстоящий поворот – это уже алгоритм. Вполне посильный МК, но релизов не попадалось.

У меня хобби такое - изобретать "велосипеды"

Классика – анализ уже имеющихся решений по теме, а уже потом тратим время создание своего, если ничего подходящего не нашли.

Выхватить "белый" пиксел строки не сложно, трассеры это парой фотодиодов делают.

Ну и, как показал мой опыт, выхватить 4800 пикселей с камеры равномерно расположенных в поле зрения
и обработать их с частотой 60 кадров в секунду - тоже не очень сложно

Вы говорили

Получается порядка 20 точек на строку

Это растр 20*20=400pxl. По вертикали можно сделать и больше, но это ничего не дает. С равномерностью тоже вопросы, поскольку строки не синхронизированы. Потому я и предложил мышу.
Обработкой Вы видимо считаете выхватывание по уровню, то что умеет любой компаратор. Единственный интересный здесь момент, это возможность хранения лишь контура в памяти МК. Но этого, как и распознования у Вас пока нет.
Я обработкой считаю анализ кадра и управление чем-нибудь на основании этой информации.

2Michael_K: Сейчас как обработка выстроена? Определяется среднее положение линии в кадре (координата Х) или в какой-то 1 строке?

Определяется среднее положение линии в кадре (координата Х) или в какой-то 1 строке?

Определяется положение линии в каждой строке на основе предыдущих строк.
Описание здесь:
http://roboforum.ru/viewtopic.php?f=68&t=6760&start=15#p123677

Результаты - в первом сообщении темы.

Сейчас уже немножко получше,
поигрался с коэффициентами - избавился от "зигзага" на широком участке линии.
(на картинке - зеленая линия в нижней части кадра)

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

Только руки пока не доходят - их всего две

Про колокол - вообще не понял

Добавлено спустя 56 секунд:
Типа адаптивный поиск линии чтоли, считая, что она проходит через центр или как?

Определяется положение линии в каждой строке на основе предыдущих строк.

Если "на лету" то строки.
Берите центр между двумя "черными" отсчетами в строке и сравнивайте с предыдущим и последующим. Тогда гулять будет в пределах пиксела. Большие/широкие поля можно программно из кадра удалить. Тогда стартовой привязки к середине/углу кадра не будет.

Хм... Сейчас попробую объяснить.

Берем одну строку пусть это будет ряд столбиков -
где цвет больше похож на цвет линии - столбик выше,
где менее похож - столбик ниже.
Можно найти общий центр тяжести ряда таких столбиков
- это будет усредненное положение "похожих на линию" пикселей.

Поиск центра тяжести - совершенно стандартная процедура
в машинном зрении.

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

Это тоже совершенно стандартный способ.

В результате получаем колоколообразную кривую.
В центре (в максимуме этого колокола) вероятность обнаружения линии
будет больше, а чем дальше от максимума - тем меньше, соответственно.

Я изменяю ширину и положение центра такого "колокола" в зависимости
от уже известных данных (найденной линии в предыдущей строке и в предыдущем кадре)
и перспективы (чем дальше от нас - тем линия уже).