Comments 19
очень круто! если ещё скрестить это со спутниковыми изображениями и информацией о высотах то получится прямо универсальное решение для автономного ориентирования!
Какая аппаратная платформа использовалась для демо?
А может, всего навсего, прекратить действия когда надо глушить gps?
В статье приведено техническое решение для ситуации отсутствия gps, зачем тащить сюда политику? Спутниковая группировка вышла из строя из-за солнечной вспышки - что нам в такой ситуации прекратить, Солнце или жить в целом?
А в смысле прекратить, чем? Конвенциями, которыми все подтираются с года введения? "Нижняя подсветка вкл" теперь с нами, хотите вы этого или нет. И все больше робототехники пойдет туда, я гарантирую это, клепать из китайских запчастей летающие фугасы дешевле и быстрее, чем крафтить маткой 9 месяцев и потом доращивать до совершеннолетия носителей легкого стрелкового оружия.
Я удивлен, что GPS изначально нельзя или не стали отключать или спуфить на уровне самой группировки спутников, вот где был бы хаос.
В реальной жизни работать не будет. Feature Detection и Feature Tracking это вероятностный процесс и зависит от условий полета. Feature Detection это процесс узнавания, который давно традиционными алгоритмами не решается в силу их малой робастности. Сделайте две фотографии со смещением и попробуйте их правильно склеить используя Feature Detection из коробки (алгоритмами OpenCV). Для этого попросите Дипсик написать на Питоне код с исп. OpenCV. Результат проверьте в Колабе (гугла). Все они в основе будут иметь какой то из известных и реализованных в OpenCV алгоритмов поиска визуальных признаков. Сейчас есть стандарт: если в колабе нет кода, подтверждающего заявленное в статье, то статья прямиком отправляется в урну, даже без чтения. Исключения их этого правила бывают, но только для очень немногих. В целом же технология наземных станций, распространяющих навигационный сигналы любой разумной мощности, гарантировано большей сигналов помех, за счет использования диаграмм направленности антенн, как на источнике, так и на приемнике, давно отработана и используется, другое дело, что это прерогатива гос. органов - создавать устойчивые к помехам и подменам навигационные поля сигналов.
Ну если статью в гугол не принимают, то всё, расходимся:)
На самом деле вполне работает и лет 20+ применяется в реальных аппаратах, как правило в паре с картами-эталонами на основе спутниковых снимков и часто - высотометрами.
К сожалению (только) в оптическом диапазоне оно на практике чаще не работает (ночь, осадки, снег выпал и т.д.)
Не нашел описания аппаратной части проекта необходимые для тестирования компоненты и схему соединений
Под какой компаньен компьютер рассчитан код, какой контроллер в качестве иму и какой программный код для иму
Дрон я собирал самостоятельно, это кастомная сборка. Используется Raspberry Pi в качестве микропроцессора. В качестве контроллера используется MPU6050. IMU подключен по шине I2C, используется порт /dev/i2c-1 на Raspberry Pi. Стандартное подключение: SDA - GPIO 2, SCL - GPIO 3, питание 3.3V.
Я не использовал готовые тяжелые библиотеки. Драйвер для IMU написан мной на C++ и встроен прямо в проект (RpiSource.cpp). Он работает напрямую с Linux-интерфейсом I2C <linux/i2c-dev.h>, ioctl, инициализирует сенсор по адресу 0x68 и вычитывает сырые данные акселерометра и гироскопа.
Благодарю за разъяснения, с подключением сенсора теперь понятно (сенсор и интерфейс конечно совсем не самый лучший для 2026 года с точки зрения надежности и точности), но тем сложнее задача для системы оптической привязки, собственно буквально вчера состоялся разговор с поставщиком дорогих промышленных инерциальных сенсоров и оптоволоконных гироскопов что сенсор который стоит в сотни раз дороже добавляет считанные проценты в накоплении ошибки вычисления инерциальной позиции без ее коррекции по системе привязки. Хотелось бы еще уточнить как в вашем случае реализованы функции полетного контроллера, функции управления моторами и пвм сервоприводов, пид регуляторы, контроллер стабилизации, функции навигации и управления режимом полета также реализованы без внешних полетных контроллеров - все реализовано внутри малинки?
Малинка выступает исключительно для вычисления VIO, обработкой изображений и расчетом состояния. Управлением моторами, PID-регуляторами, сигналы на сервоприводы и стабилизацией занимается Pixhawk. По поводу сенсора согласен. Изначально планировал читать данные IMU напрямую с полетного контроллера по протоколу MAVLink, но стандартная частота телеметрии в MAVLink обычно ограничена 4-10 Гц или 50.
если интересно :
https://mavlink.io/en/messages/common.html#ODOMETRY
с i2c тут тоже скорости может не хватить. Тот же MPU6050 к малине можно подключить через SPI.
Хотя, для планера это не так критично, как для коптера, наверное.
А зачем такая сложная конструкция с цепным приводом? Почему просто не перевернуть серву и шестеренками зацепиться? (ну и программно инвертировать)
Отличная статья! Подскажите, при каких параметрах была получена приложенная гифка? Скачал себе датасет и запустил код с дефолтным конфигом. Получаю совсем непохожую траекторию
Спасибо! Думаю что, дело в версиях библиотек. В репозитории есть Dockerfile. Он базируется на Ubuntu 24.04, где версии библиотек подтягиваются корректно, так что рекомендую запускать через Docker. Насчет траектории, то камера работает в своей системе координат, где Z это оптическая ось, смотрящая вперед, а мы привыкли к графикам в ENU. Чтобы получить вид как на гифке, я делаю маппинг: x_plot = x; y_plot = -z. Для высоты лучше использовать обычный барометр, у него нет накопительной ошибки.
Это бы ещё в машину встроить вместо датчика GPS, чтобы всякие андроид авто устройства, в которых запускается я-н и другие программные навигаторы, могли водить по маршруту. Дроны сейчас применяются в основном сами знаете где и эта технология востребована в основном там. А автовладельцев миллионы, и все сейчас блуждают по незнакомой местности, если там глушат.
Мне понравилась статья. Хотелось бы по подробнее узнать про ESKF . На русском я ничего не нашел.
Cистема визуально-инерциальной навигации для дрона на C++