roboforum.ru

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

сделал. вот как выглядит
камера передает картинку при работе серв, друг другу не создают помех. теперь приступаю к кульминационной части работы: воссоединению всего этого в единый разум
P.S. кстати, еще не измерял обратный сигнал серв, и как он будет себя в динамике вести...

запасную камеру купил?

дорогое удовольствие. я зато эту защитил хорошенько.

а потом что будешь делать? в армию пойдешь?
там я слышал боевых человекоподобных роботов проектировать будут...

это в нашей то армии ? да даже если и будут хотя бы амебообразных роботов делать, я не собираюсь идти в армию

На данный момент результаты испытаний таковы:
У робота болезнь Паркинсона, бедняга Колебания сильно портят точность определения позиции (завожу сигнал с потенциометра сервы на АЦП МК), колебания даже на 7битном значении есть (я поажлуй ниже не буду опускать, может и так нормально будет). Изображение с камеры дерьмовенькое - с уменьшением яркости участка изображения повышается шум, даже отлично освещенный зеленый шарик по краям имеет шумы и надо делать поправку на освещение при определении размера объекта на изображении. Динамические характеристики камеры оказались не столь высоки - изображение смазанное на полном ходу при повороте платформы, поэтому зря я гнался за большим fps. Зато это (плюс еще одна особенность режима вывода изображения камеры) сильно увеличивают доступное для колор-трекинга процессорное время.
Я решил сделать свой алгоритм колор-трекинга и накидал кое-какие соображения. Для моего случая цветовые модели HSV и HSL подходят как нельзя лучше.

Color tracking, адаптированный для OV9650

Условия/ограничения:
- неточечное освещение со спины манипулятора, желательно снизу вверх (далее, подсветка)
- объект: круглый мячик/шарик
- с связи с маленьким разрешением изображения макс. дистанция видимости 0,5м

Положения:
Обработка построчная. Возможно хранить верхнюю и нижнюю строку, что в перспективе позволит улучшить алгоритм.
Цветовая модель HSV(HSB) или HSL. Разница между ними здесь играет очень большое значение,
т.к. наибольшее влияние оказывает яркость и светлота, пока я еще не определился с выбором.
Минимальная длина строки пикселей, принадлежащих объекту, 3, меньшие последовательности считаются шумом.
Диапазона цвета объекта нету как такового, есть разброс среднего значения цвета, который зависит от доверия цвету.
В режиме поиска зона доверия пониженная, а минимальная длина пикселей 2.

Оценочные зависимости:
- больше яркость пикселя -> больше доверия цвету, но есть верхний порог (~97%), после которого доверия вообще нет

Стратегия:
- сбор статистики по яркости, не включая пиксели объекта
если яркость маленькая
-> края объекта зашумлены, коэффициент увеличения размера k_size = f(яркость)
если большая, то скорее всего освещение распределенное
-> края объекта незашумлены, коэффициент увеличения размера k_size = 1.0,
-> фоновое изображение становиться ближе к зоне доверия, поднимаем зону доверия
если сильно большая, то камера неведена на яркий свет
-> условия очень плохие даже при подсветке, шансы на успех крайне малы
-> <поведение не определено>
- оценка формы объекта (пока что ничего определенного)

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

Вот образец при условиях "маленькой яркости":

чего то у тебя камера какая то... эээ... кривоватая, толи фокуса нет, толи выдержки.
вот гляди как бывает с OV9655:

это даташит по ней кривоватый... хотя возможно и камера... а вообще картинка в разрешении QQCIF (88x72), увеличена в 5 раз

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

Это наверное косяк обработки, а не матрицы, все-таки?

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

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

Может ты старшие биты откидываешь?

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

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

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

Не похоже это на битую матрицу.

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