roboforum.ru

Возьми нормальную камеру и проц, и занимайтесь алгоритмами без аппаратных мучений

Ага. Еще хорошо взять готовую библиотеку функций, как это здесь, видимо, принято.

Неинтересно

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

На хорошем железе - не фокус. Этого добра я еще на работе нагляделся
И камеры по 30тысяч кадров в секунду со встроенными процами на каждую
строку изображения в руках держал...
Там совсем другие задачи и другие приоритеты.

Тут же фишка такая - сделать конфетку из... из чего под руку подвернется

Поделитесь ссылками на такое железо,
некоторым неохота собирать компы с нуля,
интересно их использовать

На работе пользовали в основном SICK IVP
(раньше Шведы делали IVP, потом их SICK купил)

Конкретные модели сейчас не вспомню.
Там довольно большая линейка - есть специализированные камеры, например для сканирования,
есть со встроенными процами и гигабитным ethernet-ом. Причем алгоритмы можно свои загружать
или конфигурять "стандартные" из комплекта.
Цены какие-то безумные, помню )

Добавлено спустя 7 минут 8 секунд:
Еще вспомнил
National Instruments делает камеры со встроенными
процами заточенными под реалтайм-обработку.

Michael_K писал(а):Красные точки - тупое квадратное окно.
Зеленые - мой алгоритм.

Тупое - это одинаковое для всех строк? Если да, то я не это имел в виду - смещать то окно всё равно надо в зависимости от найденного ниже положения линии

2 Michael_K: А если линия будет не плавная а под прямым углом в сторону уйдет? Не потеряет ее МК? Есть же на трассах лайн-трейсерных углы?

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

Да. Равное ширине кадра. А как вы хотели оценивать ширину вашего квадрата?
Зато нету никакого "исскуственного повышения значимости" ))

А если линия будет не плавная

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

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

Алгоритм явно можно и нужно улучшать - это факт.
Вам это интересно? Есть идеи? - Вперед!
За вас этого НИКТО не сделает.

2Michael: Я имел в виду сдвиг окна в зависимости от предыдущего кадра и предыдущей строки Блин, столько букав, а всего-то высказал идею замены плавной функции кусочно-постоянной

Добавлено спустя 1 минуту 22 секунды:
А проверять особо мою модель не надо - я и так знаю как примерно она должна работать, и знаю, что реализовать её вам - 3-5 минут

Добавлено спустя 2 минуты 53 секунды:
Хотя в показанном ролике конечно ваш алгоритм получше будет - но я не совсем понимаю - откуда вблизи столько посторонних тёмных участков. Вдалеке еще ясно. Кстати - по мере подъёма по кадру - область поиска можно сужать, чтобы таким образом отыгрывать перспективу - у вас это реализовано?

Я имел в виду сдвиг окна

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

откуда вблизи столько посторонних тёмных участков

Угол обзора максимизировал - для этого глазок и нужен.
Центр объектива стоял на высоте 65 мм от пола при этом она видела
примерно миллиметров 200 в ширину прямо под собой (ширина листа A4).

Линия нарисована маркером на A4 - можете оценить размеры по картинке.
Ширина линии миллиметров 20.

по мере подъёма по кадру - область поиска можно сужать, чтобы таким образом отыгрывать перспективу - у вас это реализовано?

Да, смотрите исходники.

Исходник пробовал понять - не читабельно , можно ли снабдить формулы типа abs комментом, что там происходит?

Или хотя-бы использовать ДлинныеМнемоническиеИдентификаторы?

Добавлено спустя 1 минуту 9 секунд:
Двигать границу окна по тому же принципу, что вы колокол двигаете

Ну или как-то просто ломанной этот колокол аппроксимировать что-ли - не потянет имхо МК этот колокол, если его еще и масштабировать...

Там строчка после абса - это кусок косинуса от -Пи до +Пи
Он смасштабирован так, чтобы был не в диапазоне -1 - +1, а чтобы был в диапазоне 0 - +1.
Аргумент косинуса выбран так чтобы колокол занимал всю нижнюю строку целиком, а на последующих
строках становился уже в соответствии с перспективой (на глаз прикинуто) по ширине картинки.

А строка, где абс в условии - это "если аргумент выходит за пределы -Пи - Пи",
то считать кривую равной нулю". Реально не ноль взят, а 0.01 - иначе иногда возникает деление на ноль ))

Вы глубоко заблуждаетесь насчет вычислительной мощности МК.
Вспомните, еще лет 20 назад компьютеры такими же были примерно по производительности.
И ничего так - текстуры во всяких вольфенштейнах масштабировали и крутили в 3D
Например, я делал на AVR интерполяцию двумерных дуг со скоростью 40000 точек в секунду
с 24-х битной точностью - без проблем.
А тут и вообще просто - задать кривые таблично и с нужным шагом выбрать
(нагуглите Direct Digital Synthesis, например).

Не люблю, когда проц бездельничает

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

Реально надо бы Гауссиану брать, имхо, а не косинус,
но формулы было лень писать, а косинус - стандартная функция

Ну это понятно - гауссиан еще и ненулевой по краям как раз, так что вообще всё красиво с ним будет.