roboforum.ru

EdGull писал(а):DeaD нехочешь с ARM9 и камерой от мобилки поиграться?
ато у меня тут одна платка не нужная завалялась...

Так а смысл? Будут алгоритмы - будем оценивать их сложность и решать на чем крутить. Например тупой алгоритм выделения объекта нужного цвета на кадре с учетом того, что он там один у нас уже есть, но он понятно что на ARM9 влезет, хотя по идее он нафиг такой не нужен на практике, разве что в футбол розовым мячиком играть

Сергей писал(а):Вы для начала хотяб в фубол розовым мячиком поиграйте)

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

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

согласен.
Чем могу помочь?

могу с самой дешевой аналоговой камеры сделать покадровый захват ТВ-тюнером
не естественно в фотошопе подм разрешение подрезать если чё
пойдет?

EdGull писал(а):Кстати, еще можно легко и не принужденно сделать дальномер в паре камера + генератор лазерной линии

А можно чуточку поподробнее? Так, чтобы для чайников?

Сдал вчера проект на работе - решил отдохнуть на выходных, пописать сюда свои соображения.
Хотелось бы все-таки направить обсуждение в более практическое русло.

Что можно выжать из видеокамеры с помощью МК....

У МК - ограниченные вычислительные ресурсы,
поэтому, по-моему, тут нужно упрощать УСЛОВИЯ задач,
а не пытаться решать их в общем виде.

Например, мы можем говорить о видеокамере на роботе,
а не о видеокамере вообще.

Мы можем ввести предположения о геометрии пространства.
Ну, например, пол плоский и ровный, угол камеры относительно плоскости пола
известен и не меняется, Интересующие нас объекты имеют грани, перпендикулярно
пересекающие плоскость пола и т.д.

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

Эти простые (и, на мой взгляд, вполне правдоподобные)
предположения резко снизят объем вычислений.

Добавлено спустя 8 минут 51 секунду:
Например, совершенно тупой способ построения "карты препятствий"
может выглядеть так:

1. Снимаем кадр
2. Снимаем тот же кадр с подсветкой параллельной полу.
3. Вычитаем, фильтруем.
4. Определяем нижние границы подсвеченных объектов.
5. Зная геометрию пола и перспективу, определяем расстояние
и направления на препятствия.

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



На кадре - на переднем плане игрушечный "шипастый" мячик,
слева вдали - коробка от бумаги, справа - деревянный брусок.
Камера - на высоте 120мм от пола.
Расстояние от камеры до шарика - около 300 мм.
До коробки - около 600 мм.
Снимал телефоном. Подсветка - лампа "переноска" 25 ватт
ненаправленная, расположенная позади и чуть справа от камеры.

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

Добавлено спустя 1 час 57 минут 49 секунд:
В предложенных упрощениях интересно будет, например, наблюдать
за линией горизонта.

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

В этом случае информации не так много (одна или несколько строк кадра),
поэтому можно работать с практически "одномерной картинкой"

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

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

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

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

Добавлено спустя 11 минут 44 секунды:
Можно снижать объем обрабатываемой информации
просто по разному фильтруя картинку для разных областей.
Например "линию горизонта" можно выбрать с максимальным разрешением,
а область "у робота под ногами" зафильтровать и снизить разрешение
(или даже тупо проредить, надеясь, что расфокусировка сработает "антиалиасинговым" фильтром )