Создание собственной системы стабилизации
С помощью видеокамеры.
Да, это правильное направление … за этим, считаю, будущее систем позиционирования в пространстве (наконец то можно принципиально отказаться от корявого акселерометра и еще более корявого магнитометра), боюсь только что железо под такую систему не самое дешевое, да и софт нетривиальный, на хоббийном уровне такое потянуть сложно…
Да, это правильное направление … за этим, считаю, будущее систем позиционирования в пространстве (наконец то можно принципиально отказаться от корявого акселерометра и еще более корявого магнитометра)
Ну не то чтобы будущее, но однозначно эта тема нужна и будет развиваться. Железо сейчас становится мощнее и дешевле, так что особых проблем не вижу почему бы не сделать доступным такие датчики для уровня хобби в ближайшие пару лет.
С помощью видеокамеры.
Оптическое зрение для коптеров конечно интересно.
Только сразу бы хотелось знать ограничения по применению, скорости, аппаратные.
Ну про зал, лес и т.п. понятно. Может что-то еще уже ясно.
Может что-то еще уже ясно.
Судя по рекламному видеоролику (верхняя ссылка от Ильи) быстродействие не очень… и непонятно к тому же на каком железе это крутится, на сайте пишут что желательна видеокарта от Nvidia, но будет работать и без нее. В принципе и так понятно, что для вменяемого результата нужна топовая “обвязка”, видео-есть-видео однако… тут на гнилом железе ничего не выйдет…
Ну мощность для обработки видео зависит от количества пикселей. Если не гнаться за высоким разрешением, то можно и минимумом обойтись, конечно не до безобразия.
Вот только не понял Илья все на Ф4 сделал или еще есть сопроцессор.
да я еще ничего не сделал, хотел заняться если время позволит) на ф4 не потянет, то что я хочу и ф7 не потянет. Тут либо тот же i7 либо систему на кристалле типа zynq 7000. Но пока рано говорить, пока даже алгоритма нет.
Правда делает это с частотой 100 Гц максимум, короче аппаратный IMU…
В даташите на 9250 вскользь упоминается 200Гц. И возможность подключения внешнего магнитометра по i2c прямо к чипу. В принципе хорошее решение. Не забивается шина, освобождаются вычислитльные ресурсы.
В даташите на 9250 вскользь упоминается 200Гц. И возможность подключения внешнего магнитометра по i2c прямо к чипу.
он там внутри - раз, читать какой-то другой компас через i2c, когда датчик подключен по SPI, а тем паче использовать DMP с другим компасом - далеко не тривиальная задача (проверено на собственном опыте)…
ну и использование DMP без обратной связи (корректировка значений внешними датчиками GPS, optical flow и т.д.) смысла в жизнь не принесёт т.к. нарастающую ошибку DMP исправить не чем…
ну и использование DMP без обратной связи (корректировка значений внешними датчиками GPS, optical flow и т.д.) смысла в жизнь не принесёт т.к. нарастающую ошибку DMP исправить не чем…
Так всегда можно подкоректировать DMP внешним контроллером со своими датчиками, никто не спорит, просто делать это можно не часто в случае DMP. А так только по шине данные
гиро качать и считать кватернионы на ЦП.
В даташите на 9250 вскользь упоминается 200Гц.
Тут ситуация такая: гира и аксель читаются как и у других датчиков с частотой 2000 и 1000 Гц соответсятвенно… т.е. при желании цикл можно смело и килогерц сделать… (у меня работает на 500 гц), а вот с внутренним магнитометром, как всегда маленькая “засада” его чтение организовано очень “оригинально” через мост SPI-I2c,
т.е. физически внутри чипа магнитометр подключен по i2c а обращение к нему идет по SPI через подачу команд (скорость опроса соответственно 20 гц) …
Нафига такие костыли мне не понятно, наверно у производителей есть весские аргументы на этот счет…
т.е. физически внутри чипа магнитометр подключен по i2c а обращение к нему идет по SPI через подачу команд (скорость опроса соответственно 20 гц) …
Нафига такие костыли мне не понятно, наверно у производителей есть весские аргументы на этот счет…
Это ,наверное, чтобы можно было внешний магнитометр подключить по i2c не меняя логики построения, посмотри 4.4 Block Diagram датащита MPU-9250
Кстати нашёл, действительно DMP обновление 200Гц
#define MAX_DMP_SAMPLE_RATE 200 // Maximum sample rate for the DMP FIFO (200Hz)
не меняя логики построения
Да видимо так, к тому же, магнитометр вообще довольно низкоскоростное устройство, наверно из-за чисто физических свойств сенсора или его ацп, поэтому подключать его по SPI смысла мало…
Так всегда можно подкоректировать DMP внешним контроллером со своими датчиками, никто не спорит, просто делать это можно не часто в случае DMP. А так только по шине данные
гиро качать и считать кватернионы на ЦП.
Смысла нет корректировать выходные данные с ошибкой! Она будет только нарастать, надо корректировать, как бы по проще, сам алгоритм в самом начале ( например, для расчета скорости из ускорения, вместо предыдущей скорости, которую посчитал DMP надо подставлять уже скорректированную алгоритмом ЦП)…
По сей причине, в наших условиях жудких вибраций и общей болтанки, алгоритм DMP, мягко говоря - не применим
…
Да видимо так, к тому же, магнитометр вообще довольно низкоскоростное устройство, наверно из-за чисто физических свойств сенсора или его ацп, поэтому подключать его по SPI смысла мало…
То что мы будем делать выборку раз в час или 200 Раз в секунду - это не имеет никакого значения, скажу по секрету, для простых комплиментарников как в мультивие и всех его производных, шины i2c за глаза, недостаточная скорость шины - это от лукавого… Я сторонник SPI в плане надёжности, да её сложнее организовать аппаратно , в частности развести плату, ну тут как кому - хочешь дёшево и сердито выбирай i2c и если руки не кривые в плане кодятства, её вполне хватит!
То что мы будем делать выборку раз в час или 200 Раз в секунду - это не имеет никакого значения
Ну “раз в час” это конечно перебор ))), а так, по идее, регулирующее воздействие на аппарат должно соответствовать его физическим свойствам, таких как масса, инерция, другими словами - вряд ли квадрокоптер сможет “колебаться” в пространстве с частотой 100 Гц (ды даже 50) тогда какой смысл иметь данные для стабилизации чаще… к томуж сама винтомоторная группа не сможет эффективно компенсировать положение на таких частотах, опять же из за собственной суммарной инерционности…
Я себе сделал 500 гц цикл только в надежде на то, что сам алгоритм “слияния” будет более шустро корректировать углы по акселерометру и тогда “коэфициент доверия” к акселю можно занизить, и тем самым снизить влияние линейных ускорений на результат.
Вроде как лучше, но не факт, наверно чтоб получить ощутимый результат частоту надо поднять еще на порядок, а это невозможно…
Я про то, что шина не так важна для выборки датчиков, и то что i2c куда-то там не успеет…
Ещё один “секрет” простая аналоговая серва на ВИШ на 50гц. Сделает лучше и быстрее, то что 500гц. Регулятор насилующий мотор и батарею
Сами-то подумайте соотношение шаг винта/скорость вращения/ потребляемая мощность/тяга…
шина не так важна для выборки датчиков
Говорим, по моему, о минимальном времени цикла: чтение датчиков /обсчет данных /выдача управляющего сигнала (?)
В этой цепи шина имеет немалое значение всетаки SPI на порядок шустрее i2c…
А то что эффективней управление шагом или оборотами, это уже другой вопрос. (конечно серва+механика еффективней)
Привет всем, написал алгоритм калибровки компаса. Работает в реал-тайме, не требует сбора полной сферы магнитных векторов, дополнительно выдает магнитное склонение и наклонение в данной местности. Думается, что DJI используют аналогичный алгоритм, так как, я попробовал провести такие же манипуляции, и компас откалибровался.
Замечания: результатом алгоритма является только 3 коэффициента смещения, коэффициенты масштаба и взаимовлияния осей отсутствуют, но я думаю что этого достаточно, чтобы определить направление на север с точностью в несколько градусов.
В качестве датчиков: акселерометр, ДУС, магнитометр. Алгоритм основан угадайте на чем? правильно моем любимом UKF=) в принципе всего 6 перемнных сосотяния, не жрущий. полный цикл прогноза занимает 208 мкс, а цикл прогноза и коррекции вместе 500 мкс на STM32F407 с включенным FPU.
Видео:
Давно не интересовался как люди калибруют компас. Может я отстал от жизни и это прошлый век??
Может я отстал от жизни и это прошлый век??
По мне, так это скорей день завтрашний ))) А что дает такой подход ?
У меня примитивно находится пресловутая сфера при нескольких вращениях в “реальном времени” (фактически поиск максимумов и минимумов по осям, с последующим смещением) - в результате те же ~ 2-5 градусов точности обеспечены…
К тому же не понимаю: зачем для компаса нужен расчет магнитного склонения (?) лететь точно на северный полюс ?
как я понимаю для возврата домой можно обойтись и без “честного” севера.
А что дает такой подход ?
Ну примерно экономит время на калибровке компаса, провернул пару раз по осям, как у Dji - все готово.
(фактически поиск максимумов и минимумов по осям, с последующим смещением)
Чтобы попасть в максимумы и минимумы магнитной сферы - это надо знать как расположен магнитный вектор в данной местности, либо собрать кучу точек в предполагеамых областях максимумов/минимумов (а их целых 6 штук), отсеять выбросы, я бы сказал, что это сложнее, чем собрать полную сферу, хотя честно я не пробовал и могу ошибаться.
К тому же не понимаю: зачем для компаса нужен расчет магнитного склонения (?) лететь точно на северный полюс ?
Ну а как комплексировать данные с GPS? Тут в любом случае надо выставить виртуальные оси с реальными осями. Во многих случаев можно пренебречь магнитным склонением, так как оно 0-15 градусов и система использующая магнитометр и GPS будет на грани, но есть места на планете, где магнитное склонение достигает 120 градусов и 50, как можно это не учитывать? посмотрите карту магнитного склонения.
Да и написал я этот алгоритм как проверку концепции, не было конкретной цели.
Ну а как комплексировать данные с GPS?
Да, согласен, у меня просто все примитивно (хотя можно и так))…
алгоритм как проверку концепции
Интересная концепция. У меня проще сделано - при калибровке компаса выбирается минимум 6 более-менее ортогональных отсчетов и по ним аппроксимируется эллипсоид. Центр эллипсоида - есть магнитные смещения. Но самокалибровка в реальном времени - это же еще интереснее.