roboforum.ru

Обсчет нужен в любом случае. Но он может делаться и внутри железки с датчиками (у мультивии на плате и датчики и ардуино), смотреть мое первое сообщение в этой ветке.

Спасибо, буду изучать.
https://github.com/ptrbrtz/razor-9dof-a ... i/Tutorial
просто наткнулся на подробный туториал)

правильно ли я понимаю, что этот малыш http://www.yeitechnology.com/productdis ... embedded-0
в состоянии сразу выдавать углы?
Orientation output absolute & relative quaternion, Euler angles, axis angle, rotation matrix, two vector

Вполне вероятно. Насколько точно и при каких условиях - неизвестно.

так с этим более или менее разобрались.

Спасибо.
Теперь следующий вопрос - одновременная обработка сигнала с нескольких энкодеров и подобной IMU - потянет ли ардуина?

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

"юзабельные данные", это что? ой.

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



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

Задача получение трекинг информации о положении камеры, расположенной на операторской кране. Соответственно, imu расположен на голове, рядом с камерой. Энкодеры должны выдавать данные по положению стрелы. Ардуино и планируется как просто точкa куда стекаются данные. Пока не очень понимаю как корректно решить вопрос расстояний и синхронизации данных. Задача -разведка перед выбором бакалавриатской дипломной работы.

Лично я бы в таком случае забил на IMU (ибо есть известная жесткая точка привязки на земле), который еще и от вибраций сходит с ума, и пользовался другими методами измерений.
Хоть тот же kinect с этим справится.
Но это если работать надо, а не диплом писать)

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

попробую довериться этому калькулятору http://2mb.ru/matematika/kalkulyatory/on-line-raschet-treugolnika/#
1 градус:
радиус 400см, а=6.98см
радиус 600см, а=10.47см
0.5 градуса:
радиус 400см, а=3.49см
радиус 600см, а=5.24см
0.1 градуса:
радиус 400см, а=0.7см
радиус 600см, а=1.05см
360/4096=0,087890625. это энкодеры в основании.

куда там камера будет "смотреть" и какая желаемая точность датчиков это уже другой вопрос. в итоге 2 сочленения со своими погрешностями. условия опять таки непонятные, т.е. как поведёт себя магнитометр остаётся загадкой. данные с датчиков в любом случае будут обрабатываться фильтром, но ошибки всё-равно будут накапливаться, причём могут накапливаться очень и очень быстро. т.е. погоня за супер-пупер точными датчиками легко может оказаться бессмысленной. +это только часть из того, что будет влиять на точность. нужно будет эпизодически калибровать данные с акселя/гиро или нет, пока непонятно - логичней сначала немного поэксперементировать и только потом при необходимости что-то ещё прикручивать (визуальные метки, радиомаячки,...) или вообще искать другое решение.
с синхронизацией всё просто - взяли данные о времени, взали данные с датчиков и отправили пакет в компьютер. для меток времени можно использовать тики микроконтроллера и/или внешних часов + можно эпизодически синхронизировать время, допустим с компьютером или gps. для обмена данными так и просится или что-нибудь из can`ов или что-нибудь беспроводное.
по отдельности каждая задача более-менее примитивная, а вот всё вместе соединить... есть непонятные моменты и хз, насколько всё будет весело. хотя если это нужно только для защиты диплома, то всё намного проще.
п.с. нужно "следить" за объектом или нужно знать где камера была и в какую точку "смотрела" - это "немного" разные алгоритмы.

Вот еще: http://robowell.ru/moduli/modul-izmeren ... teristiki/
Этой штукой можно горизонт определять, а энкодером положение стрелы.
У меня как-то тоже вставала задача стабилизации платформы с камерой на кране, только пришлось отказаться из-за недостатка времени.

Спасибо, это как раз считал и поэтому и решил использовать энкодеры в основании. Просто, объективно говоря, нужда в imu отсутствует, поскольку фактически все краны за счёт механики поддерживают угол камеры постоянным. Хотя этот самый начальный угол, который выставляется механически надо бы замерять.

Спасибо всем за помощь. Теперь пару вопросов по существу.
Существует много разновидностей ардуино. Клонов, да и вариантов оригинальной платы. Какой вариант оптимален, чтобы была возможность подключить 3 данных датчика(Imu + 2 энкодера)? Но если есть вопрос расположения энкодеров на расстоянии в несколько метров от IMU, то получается нужно заводить две ардуины и реализовывать передачу данных от одной к другой?

Кстати, вот еще интересное решение:
https://estore.ti.com/Tiva-C-LaunchPad.aspx
+
http://www.ti.com/tool/boostxl-senshub
Правда не могу найти как подключить энкодеры к этой плате, нужен ли какой-то переходник для SSI интерфейса?

сколько чего можно подключить начинается с прочтения даташитов на датчики. смотрите какие у них интерфейсы. потом открывается даташит на микроконтроллер, смотрится переферия + что выведено на конкретной плате. часть интерфейсов можно реализовывать программо, т.е. аппаратная поддерка не очень актуальна.
про i2c в некоторых даташитах написано, что работает до 10 метров, но это с феншуем. без феншуя легко можно и на паре метров отхватить полную невозможность передачи данных или передачу со слишком малым битрейтом. хотите прям на одной плате с микроконтроллером сделать, ройте в сторону i2c. но смысла в этом имхо не очень много. хотя... у каждого свои тараканы. c каном с одной стороны проще, с другой сложней. проще тем, что можно гарантированно хоть на десятки метров передавать данные. сложней, т.к. в контроллере должна быть поддержка кана, а если её нет, то ставить внешний драйвер. использовать для подключения к шине трансивер или нет, другой вопрос. берём 2х жильную витую пару (в отличии от 4х жильной легко можно найти тонкий гибкий кабель), одну пару используем для передачи данных, по второй питание. также делают в с системах видеонаблюдения - 2х или 4х жильная витая пара и никакой головной боли на десятки метров ни с передачей данных, ни с питанием. в варианте с каном есть много из чего можно выбрать + кроме кана есть куча других вещей. допустим можно взять одну дуню и один недорогой сетевой модуль, например на enc28j60. хватит у меги ресурсов и на опрос датчиков и на передачу данных по нужному протоколу + как именно poe в этом случае делать, хз. при желании можно и беспроводное сделать, выбор опять таки немалый.
из недорогих дунь самыми популярными на данный момент являются uno и nano/mini pro. +если локально трудно достать или цена не устраивате, то банально берётся макетная плата, нужная мега в дип корпусе, юсб-уарт переходник, программатор мег и делается своя дуня. на армах самые популярные - это stm discovery (много разных). +при выборе вообще есть 4 основных фактора:
- доставабельность
- цена
- наличие всякой документации, библиотек, примеров кода и открытых проектов
- к третьему в дополнение идёт среда разработки - есть ли бесплатная или лекарство к платной, наличие библиотек и кода под эту среду, примеров, с какими платами/контроллерами в ней можно работать
п. 3 и 4 для некоторых не имеет большого значения - даже по скудной документации и без всяктх готовых библиотек и примеров кода они очень быстро во всё вникнут и сделают. другие даже с кучей всяких полезностей будут месяцами мозг себе выносить.

спасибо. Покопался с этой платой - stellaris launchpad - интересная штука. Все выходы есть. Не нашел толковых примеров по приему SSI сигнала, но в даташите он указан. Равно как и CAN

неплохая платка, там даже на ней не очень дешевый mpu-9051 стоит. в даташите про работу с ssi модулем и режимы его работы более-менее нормально разжевано. на сайте ti можно поискать и доку и примеры, может что и найдётся, только примеры вам до одного места. это не телфон и не настольный компьютер, где за вас уже всё давно написали и подальше "зарыли" все эти низкоуровневые моменты с инициализцацией. на таких армах самое сложно - это с нуля реализовать, допустим мигание светодиодом. до того как собственно до мигания доберётесь, нужно хоть немного понять как он работает и как настраивать всяике частоты и переферию. пока хотя бы раз не настроите, толку от примеров кода работы с какой-то там переферией будет 0 - шаг вле/врпаво и легко будет или вообще не работать или будет работать, но не так как нужно.
с инициализацией намного проще с avr, если залить ардуиновский бутлоадер в какую мегу или сразу взять готовую ардуину, то будет ещё проще. но если выберете кан, тогда нужно будет "докинуть" кан контроллер и трансивер (вроде можно и без него при желании обойтись, но про это почти ничего не заню, не пробовал так делать. они копеечные, нет смысла мудрить). из достовабельного есть, допустим микрочиповские микросхемы. с энкодерами вроде не сильно сложно, при желании можно хоть программную реализацию сделать. погуглил, описаний как с ними работать предостаточно. http://www.megasensor.com/ugol-povorota/glossarij/absolyutnye-enkodery/posledovatelnyj-sinhronnyj-interfejs-SSI и т.д.