roboforum.ru

Цель:
1)Полное управление роботом с компа. На микропроцессоре только простейшии функции, требующие немедленного вмешательства.
2)Установка на робота видеокамеры.
3)Создание программы тех-зрения.
4)Передвижение по местности, постройка карты местности, поиск объектов.
Конечная цель – робот должен помогать моей девушки собирать пазлы ))))) (там деталей больше 1000, да и для собственного удовольствия и самообразования.)
Протокол управления сервами описан в http://robot.watch.impress.co.jp/cda/co ... 8/731.html
Робота разобрал, проверил осциллографом – всё так.
В кратце:
на серве 4 провода, сервы соеденены параллельно (3 на руке, 5 на ноге)

Красный провод: питание для серводвигателей
Оранжевый провод: Питание микропроцессора на борту сервы (3.3V)
Зеленый провод: сигнальная линия (последовательный асинхронный 2400бит/сек, без проверки четности, 1 стоповый бит, нет контроля потока)
Голубой провод: GND

8 байт в 8 битном пакете.
Порядок и назначение:
[255] [5] [1 серво] [серво 2] [3 серво] [серво 4] [5 серво] [Checksum]

Checksum - контрольная сумма, суммирует все предыдущие значения с переполнением 255.
Для начала решил попробовать управление на 1 ноге. На плате FTDIшный мезонин DLP-USB232M на FT232BM, 2 стабилизатора на 3.3В( один на Серводвигатели, 1 на микропр. серв), Atmega32(не подключена).


Пишу программу подключения и отправки на СОМ данных.

По 1 пункту задачи:
Пока вижу это так - есть набор кнопок, при нажимании на которые программа читает из файла построчно и передает роботу. Набор файлов – набор действий, записанных заранее.

Ну и как успехи?

Программа по юсб через мезонин передает набор команд для серв на атмегу32, там реализовать программно 4 выхода юсарта через прерывание по таймеру.
Когда 1 пункт закончю, Поставлю камеру. Вот тут и начинается самое интересное..... Предполагаю, что поставлю ВайФай камеру ахис. К ней есть СДК. На ней линукс, На проце есть свободные порты.

Добавлено спустя 2 минуты 25 секунд:
Re: i-sobot: управление с компа

galex1981 писал(а):Ну и как успехи?

))) Пишу программу управления с компа. Думаю, через пару часов закончу.

Предложения и идеи, особенно на счет камеры - приветствуются.

А как камера будет с мегой связана? Или просто по WiFi передавать изображение будет

galex1981 писал(а):А как камера будет с мегой связана? Или просто по WiFi передавать изображение будет

Как я уже говорил, на проце камеры есть свободные порты. И здесь 2 варианта:
1) Посадить юсарт проца камеры на юсарт меги(извините за тофтологию). Плюс - на меге уже будет готовая прошивка для преобразования переданной строки в команды для серв. можно на мегу еще чтонибуть подцепить. Минус - наличие меги...
2) Использовать 1 цифровой порт для эмуляци 4 выходов юсатр.Минус - количество свободных портов - ограничено.

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

Программу управления для компа написал,

пора заняться атмегой32. Программатор под джитагу есть, нет ЛПТ порта )))). Надо купить переходник... Нда, а в эридане я буду только завтра вечером. Хм.. Мож у кого есть наброски программы под АВР?

Программатор под джитагу есть, нет ЛПТ порта )))). Надо купить переходник...

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

Идеи по поводу камеры расширяются. Ставлю AXIS M1031-W. Параллельно камере - красную лазерную указку(Как синхронизировать????) с обрезком стеклянного стержня( потом поставлю инфракрасный лазер из ДВД - он невиден и мощности поболе...). По идее, луч должен преломляться в одной плоскости. Получим очень широкий в одной плоскости луч( совсем слабый, хватит ли чувствительности камеры??) Камера один кадр снимает с лучом - второй без. В камере есть память для запоминания предыдущих снимков, может удастся делать снимки попарно, с более высокой скоростью между пар(???), а передавать со стандартной. жать H.264, без потерь. Попиксельно вычесть из одного када другой. Там, где явное увиличение красных пикселей, при нуле в остальных цветах - там мой широкий луч. Скелетезируем красную полосу, дорисовываем разрывы, если есть. А, да, полоса - горизонтальная. Дистанция до точки - это растояние между красным пикселем и точки из горизонтальной линии центра кадра.

Добавлено спустя 2 минуты 4 секунды:
Re: i-sobot: управление с компа

citizen писал(а):

Программатор под джитагу есть, нет ЛПТ порта )))). Надо купить переходник...

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

Хуже.. Спасибо, что предупредили. Значит контроллер поставлю на комп, гдето я его видел.

Если ты имеешь ввиду контроллер PCI-LPT то они также не все поддерживают необходимые режимы. У меня все 3 платы расширения не пошли (нужно подбирать)...

galex1981 писал(а):Если ты имеешь ввиду контроллер PCI-LPT то они также не все поддерживают необходимые режимы. У меня все 3 платы расширения не пошли (нужно подбирать)...

Там бывает, что проблема не в платах, а в софте, который не понимает других адресов лпт-порта, кроме 0x378 и 0x278. А PCI плате обычно выдают автоматом какой-нить 0xa000 и фиг поменяешь. Но если софт умеет работать с таким адресом - то сама плата несет совершенно стандартный порт, у него те же 8 регистров, с теми же битами, абсолютно стандартная железяка, такая же, как на материнке в составе чипсета. Сам ковырял Идой один проприетарный драйвер, на предмет найти место, где поменять в нем 0x278 на 0xa000 - помогло, завелся (это был TI-шный JTAG XDS510)

boez, спасибо. Собираюсь использовать CodeVisionAVR, но если что, поменяю.

Первые пробы с камерой( пока не нашел плату расширения лпт),и пока с фотиком. Если идея погибнет, не хочу тратить деньги на камеру…
Цель:
1) (Однозначная??) идентификация твердых цветных объектов со сложной текстурой.
Можно использовать для ориентации в пространстве, нахождении предметов. В частности, идентификация части рисунка и его местоположение на рисунке, если известен весь рисунок.

Для начала (и простоты) буду идентифицировать только плоские предметы.Все можно разбить на плоскости ))).
Для того, чтобы более-менее идентифицировать предмет в разных условиях, надо определить, какие условия могут измениться.
1) Яркость и спектр освещения.
2) Угол обзора предмета.
3) Дальность до предмета(масштаб).
4) Ещё что-нибудь???

Чтобы уйти от зависимости интенсивности освещения, буду записывать цвет не в RGB, а в виде отношения цветов и яркости( R:G:B = RG,GB и Яркость). Правда, если не использовать яркость, мы не отличим белое от черного. Но здесь можно чего-нибудь придумать, учесть в алгоритме… Спектр – здесь сложнее. Можно записывать в виде отношения рядом находящихся цветов. Тогда, даже если включат красную лампу, в спектре рядом находящихся площадей разного цвета будет усиление этого цвета почти одинаковой пропорции. Это «почти» можно учесть (потребуется ???), если знать место нахождения источника излучения и его направленность и ... или использовать погрешность.

Вот, пришел к тому, то надо сравнивать рядом находящиеся площади.
ИДЕЯ!! Отношение площадей разного цвета – тоже параметр. Он почти не изменяется от угла наблюдения и совсем не изменяется от масштаба (учитывая ограниченность камеры в разрешении – от масштаба в разумных пределах). Это «почти» - можно учесть, если знать дистанцию до предмета. Или опять погрешность.

Пришел к векторной 3х мерной карте. Наверное, делать надо в виде таблицы с индексами.
Например, так:

1)Координата точки по осям. Это центр площади. Наверное, центр массы.
2)Направление – перпендикуляр к площади.
3)Отношения к рядом находящимся площадям по площади ,цвету, ( дистанции???, Расложение(Ид соседних плошадей)).
4) Еще что нибудь….

Идеи? Предложения?

Предложение - заглянуть в ВИКУ в раздел технического зрения

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

VinsentAoki писал(а):ИДЕЯ!! Отношение площадей разного цвета – тоже параметр. Он почти не изменяется от угла наблюдения и совсем не изменяется от масштаба...

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

Digit, если вы внимательно посмотрите на вариант хранения данных, то поймёте, что блик здесь не является проблемой. Если бы камера была идеальной. Блик на плоскости от точечного источника излучения (такие у меня дома) является проблемой из - за несовершенства камер, а точнее перенасыщения пикселя в матрице камеры. Кстати, блики и нам мешают. Но не настолько, чтобы мы не могли собрать пазл.( вспомнилось про зеркальные лабиринты…) К сожалению, часть рисунка действительно будет засвечена, если блик сильный, но остальная часть будет видна а при моем алгоритме этого хватит. И при смешении можно засвеченною область восстановить. Вообщем, блик - не проблема. По поводу OpenCV - спасибо, давно присматриваюсь к ней. И часть функций возьму с неё.
Вообщем, буду пробовать.

VinsentAoki писал(а):Блик на плоскости от точечного источника излучения (такие у меня дома) является проблемой из - за несовершенства камер, а точнее перенасыщения пикселя в матрице камеры.

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

VinsentAoki писал(а):По поводу OpenCV - спасибо, давно присматриваюсь к ней. И часть функций возьму с неё.

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