Optical Flow + MultiWii
Снимаю шляпу очень интересно ,а на какой меге виий?
Алексей, снимаю шляпу! 😃
Когда теория срастается с практикой с первых попыток, особенно в таких вещах, то это уже что то сродни гениальности 😉
з.ы. простите за глупый вопрос… а что датчик отдает? скорость перемещения в относительных точках в единицу времени? т.е. чем больше высота, тем больше размер точки и меньше точность?
и как правильно настроить линзу?
Спасибо, не ожидал такой реакции 😃 Мод написан just fo fun, пользы не очень много. Локалные данные о положении точнее GPS, но нужно быть реалистом - работать он будет не везде и очень зависит от освещения и качества поверхности.
Распиновка согласно датащиту (www.avagotech.com/docs/AV02-1045EN) Нужны выходы SCLK, SDIO, NCS - можно вешать на любые ноги и прописать в config.h. На NRESET я кинул на +5в, чтобы не заводить его на ардуину.
Кстати можно взять и готовый модуль store.diydrones.com/ProductDetails.asp?ProductCode… по показателям должен работать лучше и оптика получше стоит… Но под него надо код считывания допилить, т.к. возможно и регистры другие и SPI у него по четырем проводам а не по трем.
Код крутится на стандартной ATMEGA 328P (Crius Hobby MWC).
Для настройки линзы я написал тестовый скетч - он делает дамп сенсора и выводит в программку mousecam (не помню где скачал), которую слегка модифицировал для ADNS-5050. Оба во вложении.
з.ы. простите за глупый вопрос… а что датчик отдает? скорость перемещения в относительных точках в единицу времени? т.е. чем больше высота, тем больше размер точки и меньше точность?
и как правильно настроить линзу?
Датчик отслеживает перемещение картинки по его сенсору и увеличивает счетчик в 8-ми битовом регистре. Реальное перемещение определеяется, зная текущее разрешение (750CPI - отсчетов на дюйм), оптическую силу линзы и расстояние до поверхности. Собственно, вот тут все наглядно: code.google.com/p/arducopter/wiki/AC2_OptFlow.
Как настроить - по картинке с камеры… я выложил выше прогу. Можно попробовать и другие фокусные, чем шире - тем большие детали рельефа будут прниматься в рассчет. Потом в кончиге можно подкрутить, я вынес параметр.
работать он будет не везде и очень зависит от освещения и качества поверхности.
ну с засветами бороться понятно некак, а вот с недосветом думаю банально взять и сделать как в мышах втолкать туда несколько светодиодов с хорошей фокусировкой в точку, на высоте до пары метров думаю будет достаточно, лазером наверно было бы лучше, но слабее значительно и скорее всего из-за того что там эффект кристализации что-ли ( как мелкие точки при рассеивании) будет думать что стоит на месте , если конечно сенсор способен реагировать на такие детали.
смотрю тут store.diydrones.com/ProductDetails.asp?ProductCode…
А модуль объектива от обычной cctv камеры подойдет? там же сток 3,6 мм , чего вполне достаточно должно быть, но есть и шире, по ссылке вроде как оно и есть
upd ))) прочитал
-Includes an 8mm lens which can be replaced, depending on the use requirements
-Standard M12 x 0.5 lens mount
если конечно сенсор способен реагировать на такие детали.
Вот с таким разрешением видит сенсор мышки
Вот с таким разрешением видит сенсор мышки
а как сенсор “видит” траву/асфальта и прочие вещи? просто интересно =) мышей дохлых много (механика полетела, а сенсор то живой), прилепить что ли тоже
В мышках подсветка под сильным углом, и там даже на белой бумаге хорошо работает - выделяется тенями струкутра. В нашем случае подсветка поможет не так сильно, теней не будет от нее… И надо учитывать, что сенсор очень слепой: например поверхность освещенную лампой 60Вт с расстояния 1 м он почти не видит. Есть светодиодные прожекторы мощные, вот типа такого надо ставить и фокусировать линзой в то же пятно что видит сенсор (это примерно 5 на 5 см на расстоянии в 1 метр)
С лазером интересная идея, его можно очень точно сфокусировать. Можно ИК поставить из DVD, он очень мощный. Но, блин, опасно будет с таким коптером рядом находиться 😃
а как сенсор “видит” траву/асфальта и прочие вещи? просто интересно =) мышей дохлых много (механика полетела, а сенсор то живой), прилепить что ли тоже
На траве думаю будет лучше всего - там много неоднородностей разного размера, так что на любой высоте есть на что “посмореть” 😃 Асфальт с большой высоты уже сольется.
Асфальт с большой высоты уже сольется.
смотря какой =)) много где технологические отверстия в виде ям, так что и с высоты будет неоднородно 😉)
И надо учитывать, что сенсор очень слепой
Нужно оптику более светлую. Мелкие линзочки очень мало света пропускают.
прилепить что ли тоже
блин… ну прям хоть ты работу кидай… столко всего хочется покрутить попробовать, а времени зеро…
в ADNS-5050 разрешение выше чем в опт. мышах нижней-средней ценовой категории? И сколько там доставка если брать по ссылке из первого поста?
в ADNS-5050 разрешение выше чем в опт. мышах нижней-средней ценовой категории? И сколько там доставка если брать по ссылке из первого поста?
Этих сенсоров навыпускали очень много, ключевые параметры - размер матрицы, поддерживаемые скорости и ускорения. Но большинство на 3.3В работают, 5-ти вольтовых я всего несколько нашел. Вероятность что в мыше будет стоять именно такой как надо очень мала - поэтому заказал в инете у компании Элитан. Что то около 500 р за пару штук с доставкой. Есть и за бугром но там доставка безумная.
А как он у вас высоту классно держит, завидую белой завистью! Кролик так не могЁт.
Ну так то по сонару, чтож не держать если погрешность измерений 0.3см 😃 Ставлю сильный PID и висит как на веревочке.
Но большинство на 3.3В работают
если разница только в питании, думаю не страшно если 3.3в, его можно взять с ардуины или платы сенсоров, а LLC на шину желателен, но не обязателен как показала практика работы с I2C датчиками…
другое дело что ADNS-5050 “улучшенный” по параметрам, потому желательно именно его по идее:
- Отслеживание высокоскоростного движения при скорости до 30 дюймов в секунду и ускорении до 8 G
- Самонастраивающаяся кадровая частота для оптимальной производительности
- Встроенный генератор - не требуется вход синхронизации
- Настраиваемое разрешение от 125 до 1375 знаков на дюйм с шагом 125 знаков на дюйм
- Используются только 4 конденсатора без транзисторов
- твои первые тест-полеты действительно впечатлили!
другое дело что ADNS-5050 “улучшенный” по параметрам
Так эти “улучшения” давно стандарт де-факто 😃 В инете находил статью про эволюцию компьютерных мышей, такие параметры средненькие. Почитайте датащиты от других сенсоров ADNS-XX - там в каждом какие-то преимущества описаны. Но вот по минимуму обвеса и простоте подключения этот пожалуй что лучший.
Если 3в есть и не пугает LLC - то смело можно расковыривать любую мышь, но обратите внимание что у AVAGO каждый сенсор имеет свой протокол - читал несколько датащитов, работа сильно отличается
Так эти “улучшения” давно стандарт де-факто 😃 В инете находил статью про эволюцию компьютерных мышей, такие параметры средненькие. Почитайте датащиты от других сенсоров ADNS-XX - там в каждом какие-то преимущества описаны. Но вот по минимуму обвеса и простоте подключения этот пожалуй что лучший.
Если 3в есть и не пугает LLC - то смело можно расковыривать любую мышь, но обратите внимание что у AVAGO каждый сенсор имеет свой протокол - читал несколько датащитов, работа сильно отличается
если грабли с llc могу выложить отдельно разводку платки для pca9307 или как он там зовется , паял, вроде не страшно, все под односторонний текстолит, могу и спаркановскую версию, есть и то и другое, и работает, правда та что на транзисорах у меня на 300 попугаев поднимает цикл, ( с 2950 до 3300 примерно)
паяется все паяльником,без фена и прочего колдовства
Посмотрел код на днях. Аксель наше все! 😃
- В основном все понятно, но есть очевидный скользкий момент в расчете горизонтальной скорости в CF. К примеру если накопилась ошибка интегрирования + качество поверхности для OF сенсора низкое (освещение, либо отсутствие деталей), то непонятно как и по чем будет корректироваться скорость. В итоге коптер понесет в не известном направлении…
// Apply ACC-OF complementary filter
vel[axis] = ((vel[axis] + EstHAcc[axis]*accVelScale*dTime)*OF_ACC_FACTOR + vel_of[axis])/(1+OF_ACC_FACTOR);
- Проверил много раз. Походу нашел ошибочку. vel_of получился в метрах в секунду, а не см/сек.
// remove shift in position due to inclination: delta_angle * PI / 180 * 100
// mm/sec(10m) * cm / us -> cm / sec
vel_of[axis] = ((int32_t)(optflow_pos[axis] + (angle[axis] - prevAngle[axis]) * 17 )) * alt / dTime;
/* displacment (in mm*10 on height 1m) */
данные с сенсора в мм*10 => нужно в см => (мм*10)/100
alt в см => нужно в метрах => alt/100
dTime в микросек. => нужно в сек. => dTime/1000000
в итоге числитель должен быть в 100 раз больше если результат в см/сек., т.е.
vel_of[axis] = ((int32_t)(optflow_pos[axis] + (angle[axis] - prevAngle[axis]) * 17 )) * alt * 100 / dTime ;
Либо если перекинуть эту сотню в CF, то OF_ACC_FACTOR был 1000! Т.е. если я не ошибся, то алгоритм на видео считай летал на одном акселе 😃 и видимо он был очень хорошо откалиброван у тебя по всем осям… И зачем нам OF?! 😃
-
И кстати почему мы верим больше акселю чем OF сенсору (OF_ACC_FACTOR = 10)? Даже если качество картинки/потока хорошее (optflow_squal), все равно большая погрешность с OF сенсора? Т.е. по идее можно подстраивать коэф. CF в соот-ии с optflow_squal если данные довольно точные…
-
Почему высота более 2-х метров режется? Ведь это считай коэф. для расчета пробега по OF сенсору.
alt = constrain((uint16_t)EstAlt, 30, 200) * 100;
по второму пункту: увидел наконец свой косяк 😃
высота в мм*10, а привык что везде в ИМУ и в конечном ПИД она в см…
alt = constrain((uint16_t)EstAlt, 30, 200) * 100;
- Есть идея: Когда стики в нуле и коптер притормозил (т.е. когда скорость меньше заданного N), считать пройденную дистанцию/смещение по х,у и использовать его в ПИД регуле для возврата в точку удержания (х=0, у=0). Т.е. ввести доп. стабилизацию по смещению (когда коптер почти в покое), а не только по скорости…
Тогда по идее фиксация в точке будет более точной. Тут уже основную роль сыграет OF сенсор (качество поверхности, освещение, контрастность текстуры поверхности и т.д.).
К примеру если накопилась ошибка интегрирования + качество поверхности для OF сенсора низкое (освещение, либо отсутствие деталей), то непонятно как и по чем будет корректироваться скорость. В итоге коптер понесет в не известном направлении…
Если качество поверхности низкое, то скорость по сенсору зануляется и вычисленная по ускорению скорость уводится в ноль. Если нет движения, то аксель в любом случае 0 покажет, т.к. это примитивно разница с гирой, а гира под него подстроится (вспомни свою последнюю идею с altHold). Когда ошибка интегрирования перестанет возрастать, скорость быстро уводится в 0 комплементарным фильтром.
Проверил много раз. Походу нашел ошибочку. vel_of получился в метрах в секунду, а не см/сек
Я размерности кидаю туда-сюда, чтобы остаться в рамках int16_t по возможности, поэтому все запутано. Но я проверял по ГУИ, выводя проинтегрированную скорость с акселя и с сенсора - они совпадают примернр, так что ошибки в 10 раз быть не может 😃
И вообще, то что меряет сенсор после нормализации, и то что меряет аксель, может сильно не совпадать (например из-за неотрегулированного коэффициента для учета FOV линзы). Мне кажется это все не страшно, т.к. есть комплементарный фильтр.
И кстати почему мы верим больше акселю чем OF сенсору (OF_ACC_FACTOR = 10)? Даже если качество картинки/потока хорошее (optflow_squal), все равно большая погрешность с OF сенсора? Т.е. по идее можно подстраивать коэф. CF в соот-ии с optflow_squal если данные довольно точные…
Согласен, тут тоже можно учесть качество поверхности. Я тестировал в плохом освещении, и тогда сенсор выдает пилу вместо ровнй линии. А с акселем *10 более-менее ровно получается. Ещё не забывай, что аксель интегрируется, и после этого шумит очень мало, так что он хорошо сглаживает шум OF-сенсора.
Но все равно, даже с последующим фильтром НЧ, коптер слегка подергивает.
- Почему высота более 2-х метров режется? Ведь это считай коэф. для расчета пробега по OF сенсору.
Чем больше высота, тем меньше доверия сенсору и надо ослаблять его влияние. Так как выход алгоритма прямо пропорционален высоте - можно в этом месте обрезать. (Мы же выдаем скорость, а не абсолютное перемещение). Т.е. скорость выше двух метров начнет снижаться - а вместе с ней и регулирование.
Я уже поменял эту часть немного - высоту увеличил до 3-х метров и умножил на качество поверхности вместо 100, чтобы сила регулирования зависела от качества.
Но тут остается проблема - акселерометр по прежнему считает скорость без учета обрезания высоты. Эту часть надо потестить. Можно оставить так или также делить на коэффициент. Пока так оставил, надо полетать побольше.
- Есть идея: Когда стики в нуле и коптер притормозил (т.е. когда скорость меньше заданного N), считать пройденную дистанцию/смещение по х,у и использовать его в ПИД регуле для возврата в точку удержания (х=0, у=0). Т.е. ввести доп. стабилизацию по смещению (когда коптер почти в покое), а не только по скорости…
Тогда по идее фиксация в точке будет более точной. Тут уже основную роль сыграет OF сенсор (качество поверхности, освещение, контрастность текстуры поверхности и т.д.).
Примерно это и получается в PID-регуляторе. Именно иcходя из того, что у нас будет I-составляющая, я выбрал в качестве стабилизируемой величины скорость. В моих тестах четко видно - когда бросили стики в движении - коптер начинает тормозить (P-часть) и пролетает пару метров. В этот момент идет интегрирование I-части. После полной остановки, начинает рабоать I-часть и коптер возвращается туда, где бросили стики. Нужно просто правилно подобрать P и I.
При полной неподвижности, считать отдельно смещение нет смысла. Оно будет плыть из-за ошибок. В общем, в текщей версии I-часть как раз то и делает и вроде работает как надо - в конце концов гасит любые попытки куда-то уплыть.
Но если поверхность плохая, то уплывать будет в любом случае, при любых алгоритмах.
Если качество поверхности низкое, то скорость по сенсору зануляется и вычисленная по ускорению скорость уводится в ноль. Если нет движения, то аксель в любом случае 0 покажет, т.к. это примитивно разница с гирой, а гира под него подстроится (вспомни свою последнюю идею с altHold). Когда ошибка интегрирования перестанет возрастать, скорость быстро уводится в 0 комплементарным фильтром.
Блин, точно! дампенинг скорости будет vel[axis]/OF_ACC_FACTOR в каждой итерации…
Прикольно! Используя этот эффект (дампенинг в компл. фильтре), без ОФ сенсора (т.е. на одном акселе), можно добиться практически полного торможения коптера при отпускании стиков. Идеально в точку не станет (и будет плыть болше чем без ОФ) ну и ветер держать не будет (т.к. I также будет душиться при дампенинге), но томожение близкое к нулю даст… Только фактор фильтра поднять надо будет для более мягкой корректировки в ноль…
A возможно для эффективного торможения достаточно будет лишь горизонтального ускорения в ПИД регуле… профит огромный, a математики зеро 😃
Но все равно, даже с последующим фильтром НЧ, коптер слегка подергивает.
коптер может подергивать из-за провалов во времени цикла, когда на некоторые из итераций ложится много математики (был опыт такой). В ГУИ по цифрам ты этого можешь и не заметить, но если вывести на чарт в ГУИ то будет видно…
Чем больше высота, тем меньше доверия сенсору и надо ослаблять его влияние. Так как выход алгоритма прямо пропорционален высоте - можно в этом месте обрезать. (Мы же выдаем скорость, а не абсолютное перемещение). Т.е. скорость выше двух метров начнет снижаться - а вместе с ней и регулирование. Я уже поменял эту часть немного - высоту увеличил до 3-х метров и умножил на качество поверхности вместо 100, чтобы сила регулирования зависела от качества. Но тут остается проблема - акселерометр по прежнему считает скорость без учета обрезания высоты. Эту часть надо потестить. Можно оставить так или также делить на коэффициент. Пока так оставил, надо полетать побольше.
Если глубина резкости 30см=>бесконечность, то с увеличением высоты, проблему вижу только в малом количестве деталей поверхности, что отразится в уменьшении оптического потока (или кволити потока?)…
Т.е. более правильно мне кажется регулировать коэф. компл. фильтра, опираясь на кволити данных ОФ сенсора (и высоту, если кволити не отражает реалной картины). Тогда и (“акселерометр по прежнему считает скорость без учета обрезания высоты”) проблемы не будет + получим линейную зависимость влияния “чИстоты” данных ОФ сенсора на результат выхода компл. фильтра, а не просто “обрубание” после определенной высоты.
Примерно это и получается в PID-регуляторе. Именно иcходя из того, что у нас будет I-составляющая, я выбрал в качестве стабилизируемой величины скорость. В моих тестах четко видно - когда бросили стики в движении - коптер начинает тормозить (P-часть) и пролетает пару метров. В этот момент идет интегрирование I-части. После полной остановки, начинает рабоать I-часть и коптер возвращается туда, где бросили стики. Нужно просто правилно подобрать P и I.
Согласен. После интегрирования скорости в ПИД регуле (I-часть), получаем как бы усредненную скорость, что равносильно пройденному растоянию (в безразмерной величине), НО т.к. тут не учитывается время цикла (а оно не постоянно из за нарастающего изобилия математики 😃 ), то будет накапливаться дополнительная ошибка, что наверное не критично всеже, но будет отдалять от точки где кинули стики…