roboforum.ru

Всё классно, а зачем тогда начинать с колокола? Может первые несколько строк начинать не с колокола по крайней мере по строкам? по кадру то понятно что лучше с колокола. И вообще - к чему такие сложности? Много левого в кадр попадает?

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Да - особенно на дальнем плане.

Камеру пришлось градусов под 45 в пол мордой наклонить и она стоит на высоте
сантиметров 10 от пола.

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

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

Кстати, по поводу "размазывает в движении". Да, размазывает, но при таком разрешении
это вообще никак не влияет на картинку. Тестил на скорости около метра в секунду
на расстоянии около 20-30 сантиметров от "объекта" (расчертил лист квадратами маркером).
К тому же можно взять более чувствительную камеру
(у меня чуть ли не самая плохая - порядка 3 люкс) - выдержка будет гораздо меньше.

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

Она у Вас исходно уже такая – это огибающая уровней строки.

Т.е. просто подгоняете результат под статическую картинку, выхватывая из 20 точек строки еще меньшее кол-во.

Но, это мелочи. Вы приводите скин РС программы. Зеленая линия тоньше пиксела камеры, т.е. ее явно не МК "на лету" рисовал.
Поясните, пожалуйста, механизм появления картинки на экране РС.

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

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

жуть, как все запущенно.


Вы немного не поняли и перепутали результат и исходные данные. А если не пояснять "так заумно" то почему бы не просто "МК ищет направление линии по изображению с камеры."? Вам и такой заумности не хватило...

Что если МК передает только вычесленные координаты линии - а ПК их хоть в 3Д отображает - это тоже незачет автономности??

Добавлено спустя 4 минуты 7 секунд:
а что если попробовать контрастность пользовать. контрастыне края брать с весовым коэффициентом Х , а чередующиеся фронты / и \ например 2Х - тогда всякие плавные переходы, тени уйдут на второй план.

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

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

Впрочем сейчас уже все немножко лучше.

Зигзаг совершенно не ясно как удаётся получить - может просто отсечку делать в этом диапазоне, а не умножать на колокол? Колокол конкретно смещает центр линии там, где мы могли его найти точно.

Добавлено спустя 14 секунд:
Точнее ясно как - не ясно зачем

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

затем чтобы если гдето сбоку черная клякса стоит локально - чтобы он сканируя очередную строку не решил что линия теперь совсем не там где была.

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

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

Но это все недельки через две - работа, мать ее

Так я и пытаюсь выяснить почему результат не соответствует исходным данным.
Зачем введены коэффициенты я понял. Значительно проще сразу ткнуть МК в нужные места конкретной картинки. Если правильно ввести эти коэффициенты, то даже камера не понадобится

contr: Вы какую-то фигню несете.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

нужно использовать контрастность и чередование ее знака как дополнительную информацию.

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

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

наверно какую-то смешную фигню.

Вам, как специалистам конечно виднее, но я хочу выяснить непонятки у автора темы

Из алгоритма автора темы однозначно следует, что без камеры вы такое не получите.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Элементарно! Вы видимо в алгоритме не разобрались Михаил накладывает размытую картинку - "ожидание" на реальную строчку. Если накладывать более четкий трафарет строки или просто "ожидание" на серое поле, то поимеем картинку там, где ее отродясь не было