Создание собственной системы стабилизации
SLAM перспективная вещь, но требует серьезных мощностей для вычисления в реальном времени. Жду с нетерпением, когда появятся оптические сенсоры адекватных размеров и энергопотребления, на выходе которых можно снимать хотя бы 3D координаты, а вместе с ними и 3D карту окружения. Тот кто первый сделает, сорвет банк 😃
Ну вот хотя бы habrahabr.ru/article/304762/
В основе технологии – точное соединение данных от всех сенсоров и их быстрая обработка. Данные устройство получает от инфракрасных датчиков, нескольких фотокамер, точных акселерометров, гироскопов и барометров. Все вместе это позволяет создать точную трехмерную картину мира вокруг устройства, обновлять в режиме реального времени, определять положение внутри нее, передавать эти данные всем приложениям, и накладывать слои с информацией поверх. Можно сказать, что в одном смартфоне у вас совмещены сразу два подхода – сканер трехмерного окружающего пространства и пульт управления, отслеживающий движения в нем.
Project tango - проект для смартфонов. Да, он содержит достаточно серьезные сесноры, но все же оптимизирован для интерфейса с пользователем, дополненной реальности. Зачем мне батарея, корпус, экран? Для робототехники и других прикладных применений нужен голый сенсор, желательно компактный и мало кушающий.
сканер трехмерного окружающего пространства
Интересен принцип указанного сканирования. стереокамеры ? (как расстояние до объекта определяется?)
Интересен принцип указанного сканирования. стереокамеры ? (как расстояние до объекта определяется?)
Mono SLAM. Вот еще пример:
Как и обещал запили пару тестов:
Как и обещал запили пару тестов:
Впечатляет. Игнорирование магнита особенно. Можно исходники? Попробую применить в INAV.
Как и обещал запили пару тестов:
Качественная работа, насчет Махони отметил - чрезвычайно низкий коэф. усиления для акселя, в реальном полете, даже на самоле, его приходится увеличивать… (а тогда результат ещё печальней)…
UKF - впечатлил, однако…
(пробую щас просто отключать аксель из коррекции при обнаружении линейных ускорений по осям, может и UKF не понадобится…)
пробую щас просто отключать аксель из коррекции при обнаружении линейных ускорений по осям, может и UKF не понадобится…
У меня сейчас сделано так: если |A-G| < 0.15*G (если то что намерил акселерометр отличается от гравитации не более чем на 15%), то аксель принимается во внимание в MARG, иначе отбрасывается.
Естественно, аксель должен быть калиброван - скомпенсированы смещения нуля и масштабы.
У меня сейчас сделано так: если |A-G| < 0.15*G
коптер ?
коптер ?
И коптер и самолет. Только у самолета до этой проверки из намеренного акселерометром убирается центростремительное ускорение v*omega (если GPS присутствует и работает).
и самолет.
У меня на самоле, при затяжных виражах (с отключенным аксом) уплывает гира сильно… надо с вибрациями наверно бороться, или фильтрами играть… пока в раздумьях…
Как и обещал запили пару тестов
А алгоритмы вы сами с нуля писали, или брали чтото готовое за базу?
Ядро UKF взял с проекта Autoquad
Mono SLAM.
если я правильно понял, камера используется только для определения маршрута следования, о 3D ориентации речь не идет, и “3D сканировании пространства” тоже…
Как и обещал запили пару тестов:
стенд ништяк! просто и надежно!
Попробую применить в INAV.
Я как понимаю, основная фишка INAV в том, что стабилизация остается четкой как на гоночных квадах. Не убьет ли эту основную особенность применение других алгоритмов вычисления положения?
Я как понимаю, основная фишка INAV в том, что стабилизация остается четкой как на гоночных квадах. Не убьет ли эту основную особенность применение других алгоритмов вычисления положения?
Основная фишка INAV в том, что у нее выше точность навигации по GPS, имеется полет по точкам, более умный возврат домой. Стабилизация как на гоночных квадах - побочный эффект борьбы за точность навигации - без четкого контроля за ориентацией коптера супер-точное вычисление позиции не даст преимуществ.
без четкого контроля за ориентацией коптера супер-точное вычисление позиции не даст преимуществ.
Так и я об этом. Если отказываться от родных алгоритмов контроля ориентации в клинфлайте и переходить на чтото другое, то и основной посыл разработки теряется. Это уже будет совсем другой проект, мало относящийся к клинфлайту.
Так и я об этом. Если отказываться от родных алгоритмов контроля ориентации в клинфлайте и переходить на чтото другое, то и основной посыл разработки теряется. Это уже будет совсем другой проект, мало относящийся к клинфлайту.
Почему будет же другой? Он уже другой. Вычисление позиции в Клинфлайт перекочевало из INAV, PID-контроллеры в INAV свои (возможно скоро сблизятся с Бетафлайтом) 😃
Другие алгоритмы не значит что мелкие гоночные коптеры станут хуже летать, а если станут - нафиг-нафиг такие алгоритмы 😁
ненужен клинфлайту инав, тяжелые алгоритмы просадят производительность, гоночному коптеру не нужно четко держать точку по жпс, ему нужно уметь вернуться с полукилометра в сторону точки старта с точностью 10м и это даже с избытком.
логику можно применить самолетную даем питч вперед, по ролу -левел, и сравниваем курс по жпс и азимут, рулим явом
ненужен клинфлайту инав, тяжелые алгоритмы просадят производительность, гоночному коптеру не нужно четко держать точку по жпс, ему нужно уметь вернуться с полукилометра в сторону точки старта с точностью 10м и это даже с избытком.
INAV и на 210-й мелочи летает отлично. В том числе в навигационных режимах. В разработке кое-какие идеи по улучшению полетных характеристик с меньшей загрузкой процессора.
Гоночные коптеры на полкилометра не летают. А если летают - то это уже не гоночные, а что-то другое.