roboforum.ru

То есть на то, что его "ожидание" зависит от предыдущей строки (в кадре, а не по времени), вы видимо не обратили внимание?

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

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

И кроме того, непонятно как идентифицировать найденные объекты.
Хотя какие-то ключевые параметры (высота-ширина,площадь-периметр)
можно довольно просто найти - то есть шарик отличить от линии можно.

А можно попробовать тупой поиск с ограничением диапазона? Вроде должно лучше колокола работать и только прощать надо будет.

Я не очень понял о чем вы говорите.
Но попробовать - можете

Проще всего на компе смоделировать обработчик "на лету".
Картинок можно нащелкать фотиком и ужать до нужных размеров,
например, 80х60 пикселей.

Я добивался хоть какой-то толерантности к освещению.

Вместо колокола использовать обычный график состоящий всего из 3 участков - 0 - 1 - 0.
Тогда оно не будет смещать линию и не будет зигзагов. Вам это попробовать - 5 минут, а мне всё с нуля писать

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

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

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

…вы видимо не обратили внимание?

Больше обратил внимание на то, что РС картинка крайне загадочная. Вот и предположил, что центр не МК "на лету" ищет, а РС. Что собственно в итоге и оказалось.

Проще всего на компе смоделировать обработчик "на лету".
Картинок можно нащелкать фотиком и ужать до нужных размеров,
например, 80х60 пикселей.

Теперь ясно почему в строке 80 пикселей, хотя оцифровывается лишь 20.

То есть на то, что его "ожидание" зависит от предыдущей строки (в кадре, а не по времени),…

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

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

Это при условии синхронизации глазка с МК тем или иным (3 варианта) способом.

При чем тут МК или РС? Речь шла про то, что получить это без камеры.

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

contr писал(а):Прикидка, если таки поняли, идет не в кадре, а относительно строки

Что за новая терминология и понятия? Просто у него линия притягивается к центру внизу и всё, а дальше выравнивается по линии, если цепляется.

=DeaD= писал(а):Вместо колокола использовать обычный график состоящий всего из 3 участков - 0 - 1 - 0.
Тогда оно не будет смещать линию и не будет зигзагов.

Это неправильно принципиально.
Колокол в хороших условиях найдет линию в любом месте поля. А ваше 010 - только в "области интереса".
А в плохих условиях (например много грязи) - колокол более склонен ошибаться в сторону центра,
Тем не менее он обрабатывает все поле и, возможно, постепенно придет к правильному решению.

Можно считать, что колокол - это цифровой НЧ фильтр с конечной импульсной характеристикой.

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

почему бы? 0-1-0 как и колокол найдёт линию только если она была в середине кстати, в обратную сторону логика работает? Т.е. если внизу кадра линия в левом углу, а только в центре проходит через середину экрана - оно найдёт её?

Кстати, а есть написанная на ПК программка? Если есть - на чем? Я бы побаловался, если не с нуля писать.

Картинка специально для bo.. ой, contr`a.
Конечно если перед камерой поставить лист белой бумаги он найдет линию в центре и поедет прямо. Но человек же должен быть умнее робота.

=DeaD= писал(а):0-1-0 как и колокол найдёт линию только если она была в середине

Колокол находит ее везде, если грязи нет - он достаточно широкий.


Программка есть. Вижул-БейсеГ. Хм... она данные (картинки) из виртуального ком-порта берет
Сама обработка вот:
Комментарии воткнул кое-какие

Код: Выделить всё

            m = 40  ' Положение центра колокола в первой строке
            For j = 23 To 0 Step -1 ' До компа долетает только 24 строки, хотя проц ловит 60.
                                    ' Считаем снизу вверх
            Sum = 0: Sum2 = 0:
            For i = 0 To 79         ' 80 пикселей в строке
           
                If Abs((3.1415929 * 2) * (i - m) * ((23 - j) + 12) / 800) > 3.14159 Then
                    k = 0.01
                Else
                    k = ((Cos((3.1415929 * 2) * (i - m) * ((23 - j) + 12) / 800) + 1) / 2)
                    ' тут в качестве колокола используется кусок косинуса
                    ' в проце можно задать таблично
                End If
                 Sum = Sum + k * (15 - pic(i, j)) * i
                 Sum2 = Sum2 + k * (15 - pic(i, j))
                 ' pic(i,j) - это пиксель - 0=черный, 15=белый.
                 ' (15-pic) - потому что ищем черное на белом.
                 
            Next i
           
            i = Sum / Sum2: m = 1.5 * i - 0.5 * m
            If j = 23 Then
                Picture1.PSet (i + 0.5, j + 0.5), RGB(0, 256, 0)
            Else
                Picture1.Line -(i + 0.5, j + 0.5), RGB(0, 256, 0)
            End If
           
            Next j


Как видите все просто.

Колокол – ИСКУСТВЕННОЕ повышение значимости заранее выбранного участка строки. Т.е. из несчастных 20 точек остаются 2..3. А чтобы не потерять линию этот колокол с каждой строкой сдвигается в сторону ПРЕДПОЛАГАЕМОГО положения линии. Это уже не алгоритм поиска, а принудительный сдвиг сторону объекта. А если линия не влево, как планировалось, а вправо ушла?
Контрастная линия элементарно обнаруживается без всяких колоколов, тут компа и синусов по модулю косинуса не надо. Только программ к РС и так навалом.
Это больше похоже на лохотрон, чем заявленную тему топика.

=DeaD= писал(а):Вам это попробовать - 5 минут, а мне всё с нуля писать

По просьбам трудящихся:



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

P.S.
И зачем я этим занимаюсь... Лучше бы поспал нормально

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