roboforum.ru

Проект все еще жив И даже обзавелся респектабельным обличием, теперь это лабораторная установка.
Метизы письмом не дошли (слава Почте России, очередной ик ей от меня), щас пойдут, как положено, ценной бандеролью. Видеокамеру (из SFE) я сломал сдури (припаялся к ней проводами и отломал пины, впрочем, наверное, она от перегрева паяльником быстрее сдохла ), тоже новый экземпляр уже летит.
Пока что побаловался сервами. Подцепил мегу к HXT900 и к комповому usb через нокиевский кабель (не ожидал я найти готовый USB-UART в такой области ) и поуправлял с компа ею. Долго мучался с аппаратным ШИМом, оказалось, диапазон у нее в 2 раза шире, чем в стандарте де-факто.
Т.к. время жмет, то программатор-отладчик для ARM я не буду мастерить, а заказал Signalyzer LITE.

мог бы из SFE заказать USB->UART,
это же обычные платки типа http://www.sparkfun.com/commerce/produc ... ts_id=8551

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

Разобрал механическую мышку, там энкодеры с разрешением 50. Есть идеи, как поставить их на OR-LC-xARM-v1 ?



Еще вариант: сделать самодельный энкодер, напечатать полоски на задней поверхности качалки сервы и там установить диод и 2 спозиционированных транзистора. Но как это сделать для такой разрешающей способности ? (Причем я непротив еще большей )

А куда поставить то? Положения серв что ли замерять?

да. а то в такой конструкции к ним не подступиться ни спереди, ни сзади...

Т.е. 1 провод лишний с потенциометра сервы извлечь наружу вы не желаете?

Уже извлек. ну их нафик, эти энкодеры

Всем внимание, кто собрался покупать OR-LC-xARM-v1 ! Кинематическая схема не такая простая, как кажется. Звенья немного смещены относительно оси поворотной платформы. Другими словами, если смотреть сверху, то все звенья НЕ будут лежать на одной линии.

Как это? Брак чтоли? Или собрал криво?

Ни то, ни другое. Просто спроектирован манипулятор таким образом. Я описал, как устранить это смещение вот тут

Составил математическую модель и вывел вычисления для самой сложной фазы работы манипулятора (когда он следит за обнаруженным объектом, стремясь занять такое положение, из которого рывком к объекту можно будет его схватить). Вся сложность заключается в том, что на эти вычисления отведено очень мало процессорного времени, т.к. около 90% его занято приемом и обработкой изображения с видеокамеры. Я на глаз сравнил, как прост алгоритм обработки изображения и как мало обрабатывается пикселей, и какие тяжелые вычисления (синусы, косинусы, арккосинусы, корни) предстоят ему далее, боюсь, что в оставшиеся 10% не уложиться
Вот моя "модель" и оптимизированные вычисления. Распишу как-нить позже

Теперь запрограммирую это и посмотрю в протеусе, сколько на это уходит тактов и времени...

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

Синусы-косинусы через таблицы аппроксимациями. Арктангенсы/арксинусы всякие думаю тоже через таблицы неплохо должны работать.

Добавлено спустя 2 минуты 15 секунд:
Кстати, я не понял, клешня в модель не входит пока?

Angel71, у меня ARMовский LPC2103, работающий на частоте 60 МГц. мне Intel Quad что ли уже добавить туда ? а оптимизировать в плане математических сокращений уже больше некуда. как вариант, сам напишу тригонометрические функции с заданной минимальной необходимой точностью, которая определяется точностью позиционирования серв или разрешением видеокамеры (худшее из них)
=DeaD=, памяти всего 8 кб, в нее влезут настолько приближенные значения, что их и вычислить времени хватит. а клешня не изображена, изображена лишь точка А, в которой должен оказаться объект. а как ее учитывать и зачем ?