Comments 134
Вероятнее всего с помощью стерео камеры. Как вариант использую для этого Stereo Pi с модулем CM4 когда он выйдет. Средствами Open CV карту глубины можно превратить в облако точек, эти точки по UTP отправятся на Tinker Board. Далее средствами OpenGL ES создам графическое приложение где эти точки будут отрисовываться в виде кубов относительно объекта который будет считаться самолётом в виртуальном пространстве, объект будет напрямую связан с ИНС и повторять все движения самолёта. Кубы как уже стало понятно и есть препятствия измеряя расстояние от кубов до объекта в этой программе можно будет уходить от препятствий и вероятно даже огибать ландшафт если измерения от камеры будут достаточно точными. Но это пока только планы возможно на этот год.
В текущей реализации (на одноплатнике TinkerBoard) вариант со стереокамерами вряд ли себя оправдает. Дело в том, что алгоритмы построения карты глубин весьма сложны в вычислительном плане.
Для работы в режиме реального времени годятся только т.н. локальные алгоритмы поиска соответствий, такие как Block Mathing и Semi-Global Block Matching, которые имеют свою реализацию в библиотеках OpenCV.
Но при этом Block Matching весьма неточен. И хотя он даст довольно высокий FPS (порядка 25-35 кадров в секунду при разрешении 480x320 точек), на карте глубин будет очень много артефактов, которые неизбежно станут приводить к ложным срабатываниям при определении препятствий. Плюс добавить к этому тряску от ветра и вибрацию от мотора при полёте, которые будут смазывать изображение.
Semi-Global Block Matching даст результаты получше в плане качества. Но при этом он гораздо сложнее по вычислениям. При аналогичном разрешении входных изображений (480x320 точек), частота кадров едва ли будет больше 5-6 FPS.
При статичных испытаниях этого, возможно, покажется достаточно, но при реальном полёте на скорости 40-50 км/ч такой частоты кадров будет очень мало. FPS можно, конечно, увеличить, занизив разрешение входной стереопары, но опять же, это сильно ударит и по качеству карты глубин.
Мне кажется шансы есть нужны эксперименты.

Быстродействие:

ИМХО сейчас Stereo Pi с 4х ядерным процессором А53 1.2ГГц и памятью DDR2 может строить карту глубины 640х240 точек со скоростью 17 фпс. Я полагаю что модуль CM4 с DDR4 и более мощным А72 процессором 1.5ГГц даст прирост в 2раза в основном за счёт новой динамической памяти. При этом карта глубины стандартно загружает 2а ядра надеюсь остальных 2х ядер должно хватить для построения карты в облако точек.

Алгоритмы:

Касательно работы StereoBM тут вы правы всё что перечисли имеет место быть, но DJI как-то поставили стереозрение на фантом и мавик значит можно. Skydio 2 американский на Nvidia Xarier обрабатывает в SLAM информацию одновременно с 12ти камер, SLAM обновляет 1 миллион точек в секунду, говорят даже в лесу может летать, тоже получается можно.
Артефакты можно попробовать убрать медианным фильтром. Кстати я нарыл (украл) исходники других интересны алгоритмов для карты глубины уже расправленных и более стабильных и продуктивных (алгоритмы тут а тут статья) судя по описанию они даже шустрее чем обычное вычисление блоков.

Итог:

Задача сложная и нужны эксперименты. Варианты такие: TOF камеры на улице вообще не работают, лидары не работают на скорости да и на улице тоже плохо, радары страдают от механической развёртки или АФАР но это-же не истребитель. Что остаётся? Пока только стереокамера.
Шансы есть, конечно, но повозиться придётся основательно.

Насчёт Mavic'a — мне как-то попадалась инфа, что стереозрение реализовано у него на основе FPGA-микросхем. Тот же Semi-Global Block Matching вполне позволяет пернести вычисление карты глубин на FPGA и это даст просто колоссальный прирост производительности. Но это уже другой класс устройств и нужно, конечно, уметь с ними работать.

Ну а Nvidia Xarier специально оптимизирован под обработку больших массивов данных в реалтайме. Там один GPU с его 512 ядрами чего стоит, на которых можно распараллелить расчёт диспаратностей для карты глубин, если алгоритм позволяет это сделать.

Поэтому, если решите экспериментировать со стереозрением, мне кажется, стоит сразу искать алгоритмы, которые дадут приемлемое соотношение между качеством и производительностью.
Да возможно что и FPGA иначе бы они батарейку быстрее кушали. В общем тут не паханное поле работы и экспериментов но есть результаты других компаний значит шансы тоже есть. Может в будущем китайцы продадут готовый FPGA уже с алгоритмами))).

У вас же самолёт. О каких препятствиях речь?
Наверно это могут быть:


  • Высокие деревья — надо лететь выше, это гораздо надёжнее.
  • ЛЭП — провода трудно разглядеть на скорости, хорошо бы тоже лететь заведомо выше. Хотя можно научить ЛА "бояться" таких аномалий, но в качестве стереопары можно брать изображение с одной камеры, снятое в разное время. Всё, что двигается на изображении быстрее ландшафта, — опасно. Обходить это нужно сверху.
  • самолёты, птицы и другие мелкие ЛА. Мне кажется плотная кажется стая птиц — самое большой зло для вашего аппарата. Её как аномалию можно попробовать "засечь" издалека и уйти на круг пока не рассосётся. Остальное крайне маловероятно, незаметно и слишком быстро летит, чтобы на него реально было среагировать с помощью датчиков разумного разрешения и компа разумной производительности.
  • Горы. Пожалуй нужно учитывать карту высот. Давление вам не покажет высоту от поверхности. Может быт тоже попробовать мерять скорость "пролетания" ландшафта под самолётом на изображении?

Мне кажется с той стерео-базой, которую вы можете достичь на своём ЛА (скажем, расставив камеры на концах крыльев), вы не добьётесь приемлемого качества распознавания глубины на расстояниях, достаточных для реагирования.

Главные препятствия это высотные здания, башни, рельеф местности и то что вы описали.

Касательно стерео пары на крыльях, я тоже об этом думал но крылья изменяют свою геометрию во время полёта калибровка нарушится. Лучше закрепить стерео пару на корпусе в 2х составном телескопическом корпусе тогда внутренний прочный корпус не будет подвержен внешним воздействиям и к нему можно закрепить камеры смотреться это будет не очень как акула молот но зато калибровка не сбросится))). Ну и камеры конечно с объективами без искажений и с дальним фокусом. Пока это всё планы может окажется что стерео-камера вообще не сможет работать на ЛА например из-за вибраций т.к. они будут размывать картинку.

Просто камеры, как мне кажется, и сложность обработки изображения с них выводит ваш проект далеко за уровень PET-проекта. Вы, кажется, не сказали для каких целей планируете использовать дрон. Возможно максимально простым решением было бы просто задрать крейсерскую высоту до уровня заведомо превышающего ожидаемые препятствия.


Вообще, меня пугает задача даже с помощью стереопары облетать здания или деревья или какие-нибудь скальные уступы. да что угодно. Нужно слишком много про них понимать, чтобы, хотя бы, выбрать с какой стороны облетать препятствие. даи какой сысл вообще облетать, если в нештатном случае эффективнее просто задрать высоту до заведомо безопасной, а в штатных просто поточнее лететь по чекпоинтам. Можно нарисованный маршрут анализирвоать на бэкенде выдавая алерты в случае наличия ЛЭП, рельефа и прочего в зоне полёта на малых высотах. Сейчас поверхность земли довольно точно картографирована, а высоты зданий детектируются даже со спутника за счёт перспективного сдвига крыши относительно стен до основания.

В основном ради академического интереса. Можно просто поставить дальномер вниз для измерения земли на ToF лидар 180м и пытаться предсказывать повышение уровня земли по его показанием тем более вы верно сказали показания уровня земли есть. Можно даже взять и купить готовую систему и вообще не мучится. У это всего есть минусы это не так интересно и эффективно а так будет повод научится делать SLAM.

А какие ТТХ сейчас и какие планируются у вашего дрона?
Дальность автономного полёта, грузоподъёмность, практический потолок, оптимальная высота полёта.


Была у меня как-то идея для мультикоптерных дронов разработать захват, который позволил бы дрону как птичке садиться на провод и заряжаться от него снимая ЭДС индуктивной петлёй в лапах.

Ну пока у меня нет конкретных ТТХ, 30 мин полёта, на низкой высоте (50-100м лучше меньше) с препятствиями. Кстати о ЛЭП я тоже раньше думал (в мечтах) пролетел так 2-3 км в доль линии зарядил батарею полетел дальше))). Так можно наверно камчатку улететь))).

Не, просто так налету индуктивно не снять и миллиампера. Надо садиться, цепляться…
Пол часа, конечно, маловато для такой автономности. Вон коптеры и по часу летают, а у вас крыло, оно заведомо эффективнее.


А не думали медленный но дальнобойный и автономный от сотовой связи радиоканал вроде LoRa прикрутить?

На TinkerBoard можно подключить любой Ethernet совместимый модуль, думал, когда ЛА планировался по больше хотел ставить ubiquiti Rocket M2 (кстати удивился когда узнал что её ставят на наши боевые роботы Нерехта) но сюда она не поместится нужно что-то другое. И после испытаний когда летать будет нормально.
Spi а как потом TCP к нему прикрутить? И на ноутбук тоже SPI ставить получается? Тогда и свой протокол обмена писать по радио с контролем суммы. Мне кажется Ethernet будет проще только если выигрыш большой в дальности тогда SPI, но LORA это вроде 30 км ubiquiti Rocket M2 50км как-бы его пока нет.

Зачем TCP? Зачем WIFI?!
Ваш этот рокет — из пушки по воробьям. Вам для вашего дрона достаточно канала в считанные десятки байт в секунду, чтобы передать ему обновлённую цепочку координат и принять телеметрию. Благодаря низкой скорости можно сделать транспондер очень энергоэффективным, пробивным (за счет более длинноволновых диапазонов) и помехозащищенным.


На ноуте USB-Uart + направленная антенна.
Плюс за счет дешевизны и энергоэффективности устройств можно наделать скрытых ретрансляторов на местности.


Данные можно слать AT-командами через какой-нибудь Telnet.

А кстати я не говорил Rocket был нужен чтобы водить данные VNS, видеть как работает SLAM, что он там рисует.

А если только маршрут можно но тогда протокол придётся писать самому, TCP ведь гарантирует доставку. В прочем это не дальнолёт Wi fi пока хватает, на 1км ловит. В приоритете замена регуляторов вот тут мне бы понадобилась помощь.
TCP ведь гарантирует доставку

=))))
А мужики-то не знают!
TCP гарантирует целостность пакета, если долетели все его куски. В тяжелых условиях, вроде работы на беспилотнике, лучше принять битый пакет, но быстро, чем целый, но не пойми когда и медленно. К тому же пакеты будут компактные бинарные с большой избыточностью для коррекции ошибок.
Так-то понятно, что WIFI и TCP проще юзать. Но если от этого зависит целостность недешевой железки, нужно иметь запасной план и на TCP с WIFI я бы совсем не полагался. Не для того они.

Что сказать согласен, но пока Wi-fi меня устраивает а улучшать можно что-то бесконечно и сделать потом истребитель))). Со временем доберусь и до сети, может вообще поставлю 4G модем будет везде ловить))).

Лора и сотовая связь — все таки разные вещи. Автору может подойти готовый проект ultimate lrs, его несложно построить. Я использую проект qczek, но он рассчитан только на прямое РУ управление и обратную одностороннюю телеметрию.


И ещё, мне думается, в этом проекте было бы разумнее использовать готовый автопилот на базе полетника на F4/F7 под ардупилотом/ардукоптером и направлять его по мавлинк, он это умеет.

Можно было-бы управлять любым АП с помощью ШИМ сигнала т.к. все они подключаются к радио аппаратуре. Можно даже взять железо из квадрокоптера уже со стереокамерой и научится им управлять, но стоит ли?

В этой индустрии есть уже давно прижившиеся протоколы, методы, на которые все ориентируются. Тот же мавлинк.
Зачем изобретать велосипед, если ваша задача — стереовидение и автопилот по нему?
Это отдельный блок, модуль, как хотите назовите. А так вы погрязнете, повторяя работу по "механике", которую десятки лет пилят десятки людей в открытом доступе.
И вторая команда пилит inav, к нему ваша управлялка по протоколу msp может цепляться и творить с ним что угодно.
Полетник стоят копейки, сотни задач решены, очень много разных железок поддерживается. В общем, вам бы в пару хоббиста, который на этом скушал много собак… вы бы пару лет сэкономили )

Говорю как человек, который полгода планировал пилить простенький автопилот для крыла, а потом увидел inav.

Не теперь я не могу вот так взять и всё бросить. Ну и мне кажется вы не правы вот делают DJI свой фантом и думают а давайте туда Pixawk воткнём он-же уже всё умеет поставим туда только стереозрение получится норм квадрик))).
Нужно-ли говорить что причины здесь не только коммерческие но и технические. Если-бы мне был нужен ЛА для конкретной задачи тогда вы были-бы правы, что например INAV всё решено он дешевле и лучше для этого подходит, но задача в том и состоит сделать не типичный автопилот. К тому-же стереозрение тоже может быть связанно с датчиками автопилота и если АП не даст к ним прямой доступ придётся эти элементы дублировать. Тоже самое законы управления коммерческий АП может летать только на том что решает производитель и только так как хочет производитель с тем набором датчиков который предусмотрел производитель и т.д.

dji работает десятки лет десятками специалистов на зарплате, врядле вы такое выдюжите. Все данные с датчиков доступны по мавлинк, включая обработанные, отфильтрованные и при этом по проверенным всем миром алгоритмам.
Бросите вы все равно, не разорветесь же. И в итоге ни там ни там толку не будет, а очень жаль. Автопилот по стереовиденью — этого нет. А очень хочется)
Надумаете идти как я предложил — пишите, помогу чем смогу. Врядле много чем, я с трудом понимаю как работает тот же пид регулятор, но есть и опыт кое какой с протоколами (парсинг и вытаскивание данных), и с железками. И выход на наиболее опытную верхушку сообщества, которая ради такого дела вам поможет всем, чем возможно, и тестинг тоже. Сейчас цифровой линк сообща пилится в ней, смежная тема.

>>Stereo PI с модулем CM4
Последния версия Jetson Nano(от февраля 2020) поддерживает 2 CSI MIPI входа(но только с RPi cam V2) — там и производительность CPU близка к RPi4/TinkerBoard(ядра медленнее, но память быстрее) + GPU есть с очень немалой производительностью (но программировать лучше через CUDA модули OpenCV(они в extras находятся), а то OpenCL(для core OpenCV) родного там нет, а только через pocl и медленнее).

За чуть большую цену/вес и потребление(до 9Вт проти 6.5Вт) получите раз в 10 больше вычислительной мощи — и для карты глубины, для чего-нибудь ещё.

PS: пример использования Jetson для дрона: news.developer.nvidia.com/skydio-2-jetson-tx2-drone

Хорошая новость, Open CV есть вариант использовать SteroBM вместе с CUDA вот только плата эта не влезет в текущий планер но как вариант на будущее. Ну и я полагаю GPU будет сильно загружен картой поэтому всё равно лучше передать на TinkerBoard и там засунуть в Open GL всё таки там тоже 80 Гфлопс (у Nvidia вроде 500 Гфлопс).

З.Ы. Я полагал там 1 csi и второй порт для экрана.
З.Ы.Ы. Хороший дрон я тоже рассказывал про него в верху.
Ставить Jetson в пару к TinkerBoard врядли целесообразно — это скорее информация для версии 2.0 вашего самолёта :) Может, к тому времени и I/O платы поменьше физически (ближе по размеру к StereoPi) появятся для Jetson Nano Compute Module.

500GFlop у Jetson Nano — это для int для CNN — для float32 меньше. Впрочем, как и 90 для Tinker Board;) Но разница в производительности в 5-10 раз между платами обычно остаётся.

PS: оставлю для других читающих — новая версия jetson nano с 2мя CSI MIPI входами — B01 (старая с 1м — A02)
Это классная вещь она для CNN(нейронных сетей) и классификации/распознования объектов, но в процессе построения карты глубины со стерео-камер она не учавствует.

Т.е. может сильно разгрузить обычную систему со стерео-камерами или помогать в работе с камерой ToF, лидаром или же интеловскими стерео-камерами ( www.intelrealsense.com/compare-depth-cameras — в них карта глубины считается внутри камеры )

исходники
ссылка на ya.disk

А не хотите перенести в github/gitlab?
Во-первых, преимущества DVCS (рпспределённой системы хранения версий),
во-вторых, возможность получать фидбек и предложения правок кода от пользоваталей :D


P.S. идея проекта — крайне хороша, я, вот, всё тоже мечтаю о чём-то подобном, но времени, увы, нет...


// впрочем, лично я бы писал ядро не на Qt (оставив его только для UI), а на C. Да и "скетчи" ардуиновые бы проверял бы под микроскопом.
Много раз сталкивался там с таким говнокодом, что аж дар речи пропадает...

К сожалению я пока не знаю как пользоваться гидхаб т.к. профессионально с программированием не связан но попробую. Qt мне просто больше нравится и я более менее с ним знаком. Если бы проект был коммерческим вероятно всё так и пришлось делать как вы говорите но т.к. это всё ради академического интереса изменения вносятся по мере необходимости))).
Гит очень не удобный, но кажется получилось туда что-то поместить. Спасибо за идею.
ого, как много напихано всего. По хорошему из вычислителей нужен только 84 МГц, 32bit ARM Cortex-M3 мощи у него хватит за глаза.

Вообще ПД регуляторы мне кажутся не стабильными и хочется заменить их чем-то более надёжным ...

В автопилотах обычно используют ПИ (пропорционально интегральные). Дифференцирование в цифровых САУ — довольно шумная штука, поэтому стараются обходиться без нее.
Да, зачастую в коммерческих решениях стараются сделать всё на МК там это обусловлено бюджетом готового изделия, в моём случае таких ограничений нет и одноплатный ПК используется для будущих решений.
Касательно ПИ мне не понятно как в этом случае самолёт гасит автоколебания ведь интегральное звено вносит дисбаланс а дифференциальное для гашения инерции вообще отсутствует?
Да, зачастую в коммерческих решениях стараются сделать всё на МК там это обусловлено бюджетом готового изделия, в моём случае таких ограничений нет и одноплатный ПК используется для будущих решений.

Обычно борятся за вес, чем меньше весит конструкция тем дальше можно улететь.
Касаемо одноплатного ПК — нужен только если планируется делать на борту что то тяжолое — например обработку видео в реальном времени.

Касательно ПИ мне не понятно как в этом случае самолёт гасит автоколебания ведь интегральное звено вносит дисбаланс а дифференциальное для гашения инерции вообще отсутствует?

Интегральное звено не вносит дисбаланс а убирает статическую ошибку, естественно при правильно подобранных коэффициентах. Что такое гашение инерции честно говоря понять не могу.
Немного о проектировании автопилотов БПЛА — тут можно посмотреть структуру стабилизации каналов тангажа, крена и рыска, как правило везде стоят ПИ регуляторы.
Обычно борятся за вес, чем меньше весит конструкция тем дальше можно улететь.Касаемо одноплатного ПК — нужен только если планируется делать на борту что то тяжолое — например обработку видео в реальном времени.

В моём случае возможна обработка информации от датчиков обнаружения препятствий.

Интегральное звено не вносит дисбаланс а убирает статическую ошибку, естественно при правильно подобранных коэффициентах. Что такое гашение инерции честно говоря понять не могу.
Немного о проектировании автопилотов БПЛА — тут можно посмотреть структуру стабилизации каналов тангажа, крена и рыска, как правило везде стоят ПИ регуляторы.


Инерция возникает в момент работы пропорционального звена поскольку при повороте возникает угловая скорость которую пропорциональное звено не учитывает в момент когда поворот корпуса уже достиг заданного значения рули принимают исходное положение но инерция продолжает поворачивать самолёт, пропорциональное звено начинает сопротивляться и этот процесс продолжает бесконечно (автоколебания) без дифференциального звена, либо ЛА за счёт свойств своего планера постепенно гасит эти автоколебания. Конечно у моего MiniTalon весом всего 1.6 кг инерция очень мала но она есть. Интегральное звено создаёт дисбаланс потому-что очень медленно реагирует на изменения и мешает дифференциальному вовремя гасить колебания. Логичнее всего было-бы добавить интеграл в ПИД высоты что-бы убрать там статическую ошибку, возможно позже сделаю когда настрою текущие регуляторы. Спасибо за материал, посмотрю на досуге.
В моём случае возможна обработка информации от датчиков обнаружения препятствий.

Ну тогда логичнее перестроить систему: на кортексе — реализовать стабилизацию и ИНС (с корректорами от измерителей высоты и GPS), а на SBC реализовать формирователь полетного задания (с учетом введенных данных и обнаруженых препядствий).

… при повороте возникает угловая скорость которую пропорциональное звено не учитывает ...

Кстати в статью надо бы добавить реализованные у Вас схемы стабилизации (а то обсуждаем сейчас некую картину которая у каждого в голове своя), ну и сравнить с теми что приводятся в учебниках.
Ну тогда логичнее перестроить систему: на кортексе — реализовать стабилизацию и ИНС (с корректорами от измерителей высоты и GPS), а на SBC реализовать формирователь полетного задания (с учетом введенных данных и обнаруженых препядствий).


Я тоже так думал но, для OpenGL приложения (SLAM) тоже нужны данные ориентации а передавать их через UART от МК к SBC будут задержки да и в целом сильно загрузит UART, поэтому решил пока так, тем более GPS тоже на стороне SBC а ИНС нужна периодическая синхронизация + в будущем поправки от SLAM тоже будут.

Кстати в статью надо бы добавить реализованные у Вас схемы стабилизации (а то обсуждаем сейчас некую картину которая у каждого в голове своя), ну и сравнить с теми что приводятся в учебниках.


Да тут я привёл всё очень кратко, много материала мне казалось будет не слишком интересно читать. Мне кажется лучше сделать по методам стабилизации отдельную статью вот только там будет много и вопросов да и кроме ПИД я пока ничего пробовал а интересная статья должна содержать аналитическое решение и главу с экспериментами.
Я тоже так думал но, для OpenGL приложения (SLAM) тоже нужны данные ориентации а передавать их через UART от МК к SBC будут задержки

Какие задержки? 1...10мс? Ну и на сколько динамичен пенопластовый верхнеплан? за это время он и на градус не успеет провернутся, боюсь этими задержками можно принебречь.

да и в целом сильно загрузит UART, поэтому решил пока так, тем более GPS тоже на стороне SBC

Тоже проблем не вижу — заведите вектор состояния автопилота с широтой, долготой, высотой, углами ориентации и угловыми скоростями и шлите его 20...100 раз в секунду, если требуются вычисления в промежуточные времена — считайте интерполяцией на стороне SBC.

а ИНС нужна периодическая синхронизация + в будущем поправки от SLAM тоже будут.

Что есть синхронизация ИНС? имеется ввиду корректировка ИНС (по координатам, скоростям и углам) по данным от внешних источников (GPS/высотомеры/SLAM)?
Тоже проблем не вижу, насчитал SBC вектор поправок — выплюнул его по тому же UARTу в ARM. В этом случае ARM вполне логично выступает как автопилот+навигационный комп, т.е. в него напрямую стекается информация со всех датчиков (ИНС/GPS/SLAM/высотомеры) по которой он обсчитывает свои координаты, скорости, угловое положение, он же реализует расчет и выдачу на сервы управляющие сигналы.
да и кроме ПИД я пока ничего пробовал

Кроме него собсно можно ничего и не пробовать, главное правильно спроектировать системы стабилизации и коэффициенты определить :)
Какие задержки? 1...10мс? Ну и на сколько динамичен пенопластовый верхнеплан? за это время он и на градус не успеет провернутся, боюсь этими задержками можно принебречь.


Хотя там не только повороты но и расстояния от ИНС но согласен, тут вы правы.

Тоже проблем не вижу — заведите вектор состояния автопилота с широтой, долготой, высотой, углами ориентации и угловыми скоростями и шлите его 20...100 раз в секунду, если требуются вычисления в промежуточные времена — считайте интерполяцией на стороне SBC.


Я бы отправил структуру но это тоже вариант.

Что есть синхронизация ИНС? имеется ввиду корректировка ИНС (по координатам, скоростям и углам) по данным от внешних источников (GPS/высотомеры/SLAM)?
Тоже проблем не вижу, насчитал SBC вектор поправок — выплюнул его по тому же UARTу в ARM. В этом случае ARM вполне логично выступает как автопилот+навигационный комп, т.е. в него напрямую стекается информация со всех датчиков (ИНС/GPS/SLAM/высотомеры) по которой он обсчитывает свои координаты, скорости, угловое положение, он же реализует расчет и выдачу на сервы управляющие сигналы.


В публикации я описывал синхронизацию когда в программной части рассказывал про ядро если в кратце показания локальной системы координат ИНС пересчитываются в глобальные GPS т.е. широту и долготу от начальной точки которую даёт GPS. Потом эти показания как обычно пересчитываются в азимут на цель.

Давайте взвесим преимущества и недостатки:

Сейчас роль каждого устройства чётко определена МК стабилизация, SBC навигация.
Вы предлагаете эту границу разрушить т.к. ИНС это уже навигация и теперь она будет на МК это кажется логично там-же есть IMU датчик а я предлагаю использовать для SBC отдельный. Но сама по себе ИНС на МК не нужна маршрут и все расчёты пути находятся SBC (перенос вычислений маршрута полёта по сути потребует полный перенос всех вычислений SBC и датчиков на DUE и SBC превратится в ретранслятор TCP to DUE) и по этому в ИНС нужно отправлять данные для синхронизации широту, долготу и принимать от неё абсолютную ориентацию и растояние (потому, что SLAM нужна ориентация для вращения виртуальной модели и расстояние в локальной системе координат для её премещения, полярная от GPS тут не нужна лучше получить её из расстояния на SBC и потом посчитать азимут). К тому-же SBC работает очень быстро и для него это не сложно, DUE медленнее и будет тратить время на приём/передачу + вычисления, понятно, что не много, но выигрыша в быстродействии тут нет.

Какой итог получается:

+ Экономится датчик

— Нагрузка на UART + небольшие задержки
— Нагрузка на DUE + сам по себе ИНС на DUE не нужен, это усложняет программу и размывает границы.

В принципе минусы получаются в основном эстетические но и экономия датчика не такой сильный повод. Я оставлю как есть потому-что всё равно хочу поработать в будущем с датчиком BNO 080 если он окажется более точным дополнительным + станет и точность ИНС.
Но сама по себе ИНС на МК не нужна

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

Вы так написали будто я имею в виду что она совсем не нужна. Она не нужна на DUE потому-что там её данными нельзя воспользоваться маршрут ведь хранится на SBC но ИНС то всё равно будет, вот пример:

1) Программа построения маршрута -> SBC -> Датчик BNO 080.
2) Программа построения маршрута -> SBC -> DUE -> Датчик BNO 050

Ну ведь лишнее звено в 1м варианте не эстетично))).
Она не нужна на DUE потому-что там её данными нельзя воспользоваться маршрут ведь хранится на SBC

хм, а какая связь между инс и маршрутом? или все таки какие то данные по маршруту (подозреваю что хотя бы следующую/текущую дугу пути) sbc будет слать в arm с целью выполнения маневра и полета по маршруту?

Соберитесь, ИНС пересчитывает свои показания в широту и долготу а они используются для азимута. Азимут рассчитывается по 2м точкам: маршрутной и местоположение ЛА. Далее: маршрутные точки у нас есть мы их получили от спутниковой карты они хранятся в SBC, местоположение мы получаем от GPS либо от ИНС теперь можно рассчитывать азимут и потом вносить поправки в курс.

Вывод: Для расчёта азимута нужен маршрут а его на DUE нет он на SBC, GPS и SLAM для корректировки тоже на SBC и весит маршрут много у меня это вектор из структур следовательно логичнее расчёт маршрута и ИНС сделать на SBC.

Странное у Вас понимание ИНС. Обычно ИНС рассчитывает местоположение (пусть будет широта, долгота, высота) и угловое положение ("азимут", крен, тангаж) объекта в пространстве путем интегрирования векторов угловых скоростей и перегрузок.

Так и есть вы не собрались до конца смотрите:

1) И так ИНС что она даёт, датчик может выдавать угловую скорость и линейное ускорении проинтегрировав эти значения можно получить вектор направления, вектор скорости.

2) Получив вектора, нужно пересчитать скорость в расстояние а для этого нужно-же знать откуда мы летим, начальную точку, откуда считать, можно конечно в ручную ткнуть её на карте а можно от GPS. Но GPS ведь считает не расстояние как ИНС а широту и долготу + маршрут тоже так рассчитывается, значит нужно пересчитать расстояние ИНС в широту и долготу тогда можно будет считать маршрут как обычно + пользоваться для синхронизации GPS. Точку получили начали отсчёт от неё.

3) Погрешность ИНС накапливается со временем как это решить? Нужно как-то проверить реальное местоположение а оно есть только у GPS значит нужно его и использовать заменив текущие показания ИНС на показания GPS вот так просто.

— Решения уязвимость от GPS Spoffing подмены сигнала но достоверно проверить её наличие не так-то просто.
+ Простота и решение для глушения сигнала или отсутствия оного что и было заявлено.
Решения уязвимость от GPS Spoffing подмены сигнала но достоверно проверить её наличие не так-то просто.

Погрешность ИНС конечно накапливается, но она имеет вполне понятные определённые характеристики.
GPS Spoffing можно детектировать, если эта ошибка стала расти каким-то необычным способом.
Для этого нужно смоделировать характер возможных ошибок (ветер, влажность, обледенение, неисправности датчиков). Каждую из причин можно так или иначе диагностировать и учитывать:


  • ветер можно учитывать специальным датчиком или сделав небольшую петлю на маршруте в ходе которой контролировать параметры полёта;
  • влажность и обледенение легко детектировать дешевыми и лёгкими датчиками влажности и температуры;
  • датчики тоже можно проверять или иметь запасной комплект.

Если есть предпосылки к спуфингу, можно лететь из эпицентра по показаниям ИНС пока спутник не станет выдавать более правдоподобные данные.

Как вы определи что ошибка стала расти?

Это можно определить с помощью машинного зрения находя ключевые токи на изображении по которым и будет проходить синхронизация либо какие-нибудь радио маяки но это просто очередной GPS. Всё остальное по сути лишь уменьшает погрешность но не убивает её.
Как вы определи что ошибка стала расти?
У вас есть штатные параметры случайных величин ошибок всех датчиков: барометр, акселерометр, гироскоп, GPS-координаты, GPS-высота.
Вычисленные значения координат и прочих параметров полёта тоже имеют свою ошибку, параметры которой можно получить перемножением параметров ошибок датчиков в соответствии с использованными формулами.
Координаты ЛА можно посчитать без GPS и параметры ошибки (которая будет прогрессировать) этого вычисления можно рассчитать.

Так вот, если ошибка позиционирования относительно GPS растёт, то нужно поверить датчики, продиагностировать наличие ветра с помощью петли, и т.д.


Когда происходит GPS Spoofing, обычно дороговато адресно учитывать параметры каждого ЛА и генерировать под конкретно его допуски и алгоритмы поток поддельных сигналов спутников. Очевидно, что проблема обнаружения спуфинга решается учетом погрешностей, а вот что делать когда спуфинг обнаружен — это большой вопрос.

Если Спуфинг GPS вас обманывает ему доверять нельзя, ИНС тоже накапливает ошибку её доверять нельзя. Нужен ещё один альтернативный способ навигации пусть машинное зрение тогда всё по правилу большинства: ИНС говорит летим верно, CV говорит тоже верно, GPS не верно. Вывод GPS врёт летим дальше.

Или относительно простой способ проверить Spoffing это снимать информацию о спутниках и их положении в надежде, что в момент подмены что-то там поменяется и тогда не использовать его данные для синхронизации ИНС на 10 мин, но это временно в надежде, что через например 10мин покинем зону помех.

Ничему в нашем мире доверять нельзя. Всё даёт ошибку или врёт. Для того, чтобы как-то жить, "боженька"=) дал нам фильтр калмана и матан. Строим модель нашего ЛА, стоим модель наших датчиков, контролируем и оцениваем погрешности. Если погрешность того или иного узла начала слишком расти по отношению к другим узлам, значит этот узел дискредитирован.
У нас должны быть предусмотрены модели вероятных нештатных ситуаций. Поломки и нарушения работы датчиков, а также спуфинг среди них. Детектировать нужно сценарий проблемы и действовать исходя из обстановки.
Так-то можно и оптические сенсоры лазером засветить. Что ж теперь. падать сразу?

По GPS спуфингу пишут много научных работ тема сложная, в моём случае решение должно быть простое, да и задачи как таковой нет этож не крылатая ракеты или ударный дрон. CV который делает фото с геокоординатами я ещё допускаю это просто ну и я думаю достаточно, за 10 мин полёта ИНС далеко не улетит и пару фото для синхронизации он найдёт наверное))).
1) И так ИНС что она даёт, датчик может выдавать угловую скорость и линейное ускорении проинтегрировав эти значения можно получить вектор направления, вектор скорости.

ИНС дает вектор местоположения, вектор скорости и три угла в некоторой системе координат.


2) Получив вектора, нужно пересчитать скорость в расстояние а для этого нужно-же

1) начальную точку (откуда летим) и конечную точку (куда летим)
2) пересчитать данные от ИНС в текущее положение на маршруте (задан в п.1)
3) сформировать управляющие воздействия на рулевые органы для списания отклонений от маршрута


3) Погрешность ИНС накапливается со временем как это решить?

Пересчитать показания GPS в систему координат ИНС, далее поправить в ИНС координаты, скорости, углы. Серьезные автопилоты работают именно так.


есть только у GPS значит нужно его и использовать заменив текущие показания ИНС на показания GPS вот так просто.

ну да, собсно в игрушках, где ИНС нет так и делают.

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

Моя задача пролететь автономно 100-200м пока восстановится сигнал, без сигнала он летать не будет или нужен совсем другой АП и другой набор датчиков.
но то что вы написали это уже совсем другой автопилот с другой архитектурой

Угу, с другой программной архитектурой, из доработок железа там только один провод от GPS перекинуть с sbc на arm.

другой набор датчиков.

Вы неповерите но все датчики для реализации полноценной ИНС у Вас уже есть.
Ну тогда, буду делать ИНС сделаю отдельную статью соберу больше инфы и сравню несколько подходов включая изложенный, и уже тогда будет видно.
По хорошему из вычислителей нужен только 84 МГц, 32bit ARM Cortex-M3 мощи у него хватит за глаза.

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


Я, конечно, диванный эксперт в этом вопросе, но и так дофига сложный проект получается. Зачем усложнять его экономией веса на лишней "ардуинкие" за счёт сильного усложнения программной части?

Да тут даже не ардуинка а датчик 1грам 5х5мм. Экономия тут в цене ставить 2 датчика по сути одинаковых в жертву архитектуре или один но усложнение программы. Для меня вариант с 2мя датчиками кажется самым логичным.

Производную можно восстановить с помощью фильтра, по информации о координате. Если подобрать модель для построения фильтра, вектор состояния которой отвечает требованиям наблюдаемости

причем тут Калман? есть параметр пусть будет x(t), естественно с шумом. Так вот при расчете производной выйдет x'(t) + производная от шума. Последняя может быть больше полезного сигнала x'(t). А дальше что бы помеху от шума убрать ставят фильтр, который естественно вносит задержку -> ухудшает динамику системы.

Калман не причем. Я его вообще и не использую. Можно фильтр Люэнбергера. А можно использовать эвристические фильтры на базе колебательного звена или апериодического второго порядка. И уже извлечь восстановленную фильтровальную производную. По крайней мере, для управления кораблями с их динамикой это хорошее решение. Думаю и для ЛА можно попробовать

Проблемы-нет получить производную, датчик выдаёт уже отфильтрованные данные фильтром Калмона есть конечно погрешности датчика но их уже можно сразу считать за флуктуационный шум т.к. алгоритм фильтрации датчика «чёрный ящик». Либо считывать сырые данные и фильтровать их самому но врятли удастся добиться результата лучше чем на фирменном алгоритме который проходит настройку и калибровку в заводских условиях.
Не в моём случае, я уже описывал в статье как я пытался использовать фильтр Маджевика и что получил, самому реализовать аналогичный фильтр мне не хватит знаний, да и оборудование для этого должно быть не наколенке же делать.
Такое впечатление, что из военнки все «профессора» собрались сложную математику и сразу самому. Этот фильтр не какое нибудь скользящее среднее + линейно квадратичный регулятор метаматематика там гораздо сложнее. Например в фильтре Маджевика применяется градиентный спуск до этого я знал лишь одно применение градиентному спуску в ML или перцептрона.

Конечно это ваше творчество и вы поступаете как удобнее вам. Я просто черные ящики не люблю, чего там налепят разработчики. Я сам делаю

Почему не iNav или ArduPilot.
Делать все с нуля — это, конечно, интересно и позновательно, но не лучше ли внести вклад в проект, который как-бы стандарт.

Как аппарат управляется? только по GSM или WiFi? как без пульта радиоуправления хотябы на взлете? Такие аппараты нужно запускать как можно дальше от людей и построек, т.к. он летучий и при потере связи или сбое автопилота может улететь довольно далеко, даже без двигателя. А в таких местах может не быть покрытия GSM.
Ради академического интереса конечно.
Аппарат управляется по Wi-Fi, GSM нужна для поиска в случае потери телеметрии. Пульт не нужен всё на ноутбуке либо десктопе. Я запускаю в леске рядом с Верхнерусским селом это довольно далеко от города 20-30км никого нет, покрытие там везде есть даже в лесу.
А как управляете? Кнопками на клавиатуре?
И на сколько хватает радиуса действия Wi-Fi модуля?
Примерно на 1км хватает Wi-Fi но кнопками я не управляю ЛА летает на автопилоте, кнопки нужны лишь для поправок в момент полёта (при посадке) и для проверки работы рулей т.е. прямо летать на них будет не комфортно. В первую очередь из-за «залипания» которое почему-то всё никак не лечится.
А как взлёт происходит, вы руками его бросаете или с земли (шасси/трава)?
Как автопилот определяет, в какой момент включать газ (при взлёте) и когда его следует полностью выключить (при посадке)?
Взлёт происходит с руки, бросать не нужно если двигатель имеет тягу больше 1:1 просто отпускаете самолёт, он немного потеряет высоты и полетит (если конечно регуляторы будут настроены) зато не разобьётся. Посадка происходит на автопилоте нахожу «полосу» желательно 100-200м пустого пространства прокладываю маршрут таким образом что-бы последние 100м он летел на высоте 1м параллельно земле потом плавно убавляю тягу самолёт сваливается и садится. Газ управляется вручную с помощью слайдера автомата тяги нет т.к. пока мне не пришёл датчик воздушной скорости, включаю газ сразу full throttle потом уменьшаю где-то до половины. На последних испытаниях добавил на Left Shift полное отключение газа на случай аварийной посадки.
Знаю такую штуку код там хитросплетённый и плохо читается мне трудно от-туда что-то использовать там всё сложно взаимосвязано.

Интересный проект. По поводу огибания препятствий — может раскруить сначала тему режима огибания рельефа, которая используется на самолетах типа Су-24?… хотя я даже не представляю где нарыть такое описание.

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

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

Испытаний пока не проводил, так закон управления на ПИД регулятор не стабильно работает на 180 град поворот приводит к крашу нужно что-то менять например делать на кватернионах в компьютерных моделях кватернионный пид очень чётко поворачивает даже вот видео. Т.ч. это вы вперёд пока забегаете.
ПИД регулятор не стабильно работает на 180 град поворот приводит к крашу

а управление маневрами есть какое нибудь? или просто рассогласование по курсу через ПИД на «руль направления» заведено?
Как вы угадали, пока так и есть только ещё перекрёстная связь в крен))). Да это лютый костыль но на испытаниях ЛА летал по прямой да и заменять же ПИД собрался по этому я его не трогал, только смотрел на него и каждый раз чертыхался))).
Как вы угадали

Ну это самое первое что в голову приходит, а по хорошему:
1) Надо реализовать несколько петель обратной связи, по угловой скорости и по углу;
2) Надо реализовывать логику «блока управления маневрами», который будет формировать заданные углы крена, рыска и тангажа в зависимости от того что делаем (летим на точку, либо поворачиваем крен-поворотом или скольжением).

Ну а если совсем лень делать по уму, то хотя бы на начало маневра запомнить куда поворачиваем и пока рассогласование курса по модулю больше 150-120 направление маневра не менять (полюбому колбасит изза шума по курсу) и ввести ограничение на выходе ПИД регулятора.

Это вами надо сделать склейку по курсу, тогда проблема перехода +180 -180 или 0 360 исчезнет

Да но это костыль будет, кватернионы не имеют переходов вообще и при расчётах используют сферу а не плоскость, сфера лучше отражает вращение. К сожалению на тему законов управления самолётом маловато свежего материала в основном всё старое ПД регуляторы вектора, иногда используют проекцию угловой скорости:
float Omega_x = Delta_Roll + Delta_Yaw * sin(Error_Pitch); //Сразу с прекрёстным сигналом

 float Omega_y = Delta_Yaw  * cos(Error_Pitch) * cos(Error_Roll) + Delta_Pitch * sin(Error_Roll);

 float Omega_z = -Delta_Yaw * cos(Error_Pitch) * sin(Error_Roll) + Delta_Pitch * cos(Error_Roll);

Но как-то всё это не даёт должного эффекта либо у меня не хватает знаний.
Рассогласование Error_Pitch, разность заданного значения от текущего.

int16_t Error_Pitch = set_point_pitch - pitch;


Дельта естественно производная этой разности т.е.

Delta_Yaw = (Error_Yaw - LastError_yaw) / Delta_time;


Обычная производная в общем.

Эм, так у Вас ошибка, т.к. формулы пересчета производные угла -> угловые скорости оперируют углами и производными углов.

Почему ошибка производная ведь берётся от текущего рассогласования а оно в свою очередь и оперирует углами. Производная в данном случае вычисляется относительно рассогласования это и логично я-же хочу что-бы самолёт летел с заданным углом допустим 30 град тогда на 30град производная должна быть равна нулю т.к. рассогласование будет равно нулю.

З.Ы. Я это всё в симуляторе KSP (с kOS) проверял всё летало!))).

что Вы вычисляете? угловые скорости вокруг осей ЛА? или у omega_X,Y,Z какой то другой смысл?

Это просто пример он не используется, в нём вычисляются проекции угловой скорости на связанную систему координат.
Надеюсь связанная система это вот это?

тогда вопрос, почему это по Вашим формулам:
float Omega_x = Delta_Roll + Delta_Yaw * sin(Error_Pitch);

 float Omega_y = Delta_Yaw  * cos(Error_Pitch) * cos(Error_Roll) + Delta_Pitch * sin(Error_Roll);

 float Omega_z = -Delta_Yaw * cos(Error_Pitch) * sin(Error_Roll) + Delta_Pitch * cos(Error_Roll);
//Delta_ - производные
//Error_ - Рассогласование - разность заданного значения от текущего.

получается так что угловые скорости вокруг осей ЛА зависят не только от углов ориентации ЛА и их производных относительно земной системы координат, но и от того куда Вам захотелось лететь (от заданного курса, тангажа, рыска)?
Да это та самая система конкордат. Более подробно можно прочитать тут.
получается так что угловые скорости вокруг осей ЛА зависят не только от углов ориентации ЛА и их производных относительно земной системы координат, но и от того куда Вам захотелось лететь (от заданного курса, тангажа, рыска)?


Похоже что так но в симуляторе это не подтвердилось может KSP хреновая физика))).
Более подробно можно прочитать тут.

Вы сами то читали что под этой формулой написано на л.139?

в симуляторе это не подтвердилось

Дык и не подтвердится, ибо противоречит здравому смыслу.
Да читал и нашёл как её применяли на страницах книги 270, 271, 272 тут (формулы 12.1, 12.2, 12.3) можно увидеть что она используется во всех законах для тогажа крена и рысканья. Ну и я говорил, что преимуществ она не дала но и хуже не стало с ней всё работала как и прежде т.е. расчёт для рулей был верный.

Сейчас смотрю снова, похоже я там действительно запутался. Ну в прочем и не важно значит это будет неудачный пример.
получается так что угловые скорости вокруг осей ЛА зависят не только от углов ориентации ЛА и их производных относительно земной системы координат, но и от того куда Вам захотелось лететь (от заданного курса, тангажа, рыска)?


Эта формула должна была решать другую задачу. Задача такая: Если самолёт имеет тонгаж 90 градусов нельзя измерить крен но при этом рысканье начинает работать как крен. Если крен 90 то тонгаж начинает показывать рысканье а рысканье крен и т.д. Я полагал, что формула определяет проекцию угловых скоростей т.е. более точно измеряет ориентацию т.к. использует например для измерения тонгажа данные от других осей т.к. чем ближе тонгаж к 90 град тем хуже измеряется крен и возможно его можно как-то корректировать с помощью рысканья и она работала но ничего не меняла т.к. Fusion алгоритм IMU датчиков уже это делал сам насколько это возможно.
Эта формула должна была решать другую задачу.

Вот прямо под этими формулами в учебнике написано что они считают и как.


Я полагал, что формула определяет проекцию угловых скоростей

читайте


тонгажа

больше читайте

Нет всё правильно у меня так и есть заданный отнимается от текущего иначе рули будут не в ту сторону поворачиваться.

Этот не костыль, а обычный алгоритмический прием, используемый при разработке САУ подвижных объектов (канал управления курсом ). И если у вас выделен отдельный регулятор курса, то лучше сделать так. Этот прием в вычислительном плане эффективен. Нормировка текущего курса и заданного курса к одному диапазону (0… 360) или (-180...+180), вычисление ошибки (или невязки ) по курсу (текущий и заданный) и соответствующее выражение склейки и нормировки. Далее фильтруете уже саму ошибку и сразу подаете ее в регулятор. То есть работаете с ошибкой по курсу

Допустим в моём случае используется диапазон +180/-180 ошибку мы вычислили теперь переходим к склейке. Тут становится вопрос в том, что по сути 180 делит направление движения на 2е половины и делит довольно рационально таким образом что-бы разворот был ближе и тут мне непонятно, что именно тут нужно склеивать, сам порог +180 -180? Мне кажется убрать не возможно не сделаю же я так что есть вариант развернутся от -179 до 0 а я буду поворачивать в другую строну это будет странно. Другое дело просто ограничить его как писал FGV и это сделает разворот более плавным это мне понятно.

А если БЛА будет в полёте переходить через 180градусов, регулятор прыгнет и канал курса развалится. Работать надо по ошибке, ее фильтровать и сразу фильтрованную заводить в регулятор
Склейка:
1) нормируем Fi и Fizad в диапазон (-180, 180);
2) DeltaFi = Fi — Fizad;
3) Если fabs(DeltaFi) > pi
DeltaFi = — fabs(2×pi — fabs(DeltaFi)) ×sign(DeltaFi)

Склейка обеспечивает плавную безразрывную обработку курса, и поворот будет по ошибке по кратчайшему расстоянию. Я так и делаю и проблем нет, и все так делают

Сейчас я закину это формулу в онлайн компилятор хочу затестить pi это 3.14 зачем она тут? Смысл проверять размер производной на число Pi? Оформляйте формулы как код не ленитесь одну ещё ладно но у вас их 4ре.

Pi это 3.14. Там не производная сравнивается с 3.14, а ошибка по курсу. Шаг 3 — это нормировка этой ошибки чтобы она была в диапазоне (-180, 180). Она же Склейка. Шаг 3 этот считай код и есть

Т.е. по сути склейка это градиент где 90 наибольшее значение а 0 или 180 наименьшее значение причём со стороны 180 град градиент нарастает быстрее чем со стороны 0. И таким образом пороги просто расставлены на расстояние друг от друга и сглажены градиентом.

Мне кажется логичным поместить её после ПИД и предварительно обрезать выходной сигнал +180 -180 щас забью её в kOS.

Нет. Склейка — это просто гладкая непрерывная ошибка по курсу, которая не прыгает со 180 на -179 при переходе 180 по часовой стрелке (или наоборот). Забыл указать, что курс, заданный курс и ошибка разумеется в радианах если мы с pi сравниваем. Именно эта ошибка должна идти в фильтр, ну а если у вас курс отдельным фильтром фильтруется, то этот расчет после фильтра и перед ПИД. В регулятор ошибка идет

Проверил эту формулу в KSP и получилось так если поворот приходится в переднюю полусферу летит по курсу а если в заднюю то противоположно курсу похоже знак где-то теряется.
SET YAW_VAL TO - abs( 2 * PI - abs(YAW_VAL)) * sin(YAW_VAL). // сама формула

Формула точная. YAW_VAL = курс текущий — курс заданный, каждый в диапазоне (-pi, +pi). Тут не sin, а sign — функция знака от (YAW_VAL), то есть +1 если аргумент >=0.0, -1 если аргумент<0.0

Я предлагаю переместится в ЛС что-бы не засорять комментарии т.к. врятли это кому-то сильно поможет а скорее будет только мешать.

Лучше использовать алгоритм LOS (line of sight) для таких задач, когда курс определяется какой-либо промежуточной точкой на линии заданного пути впереди по ходу. Иностранцы на БПЛА так и делают. Это для формирования заданного курса. А там можно ПИД использовать (если точность следования по маршруту не важна) или лучше ПИД. Ну а в приложениях где нужна большая точность следования по маршруту, особенно при маневрироаании — ПИД и ПИ не прокатит.

Наверное нет. LOS формирует заданный курс на воображаемую точку впереди по ходу, которая лежит на линии маршрута. И таким образом объект будет стремиться к линии маршрута и списывать отклонение от нее. Ну а выбор точки это уже наука, правда не очень сложная. Точка эта движется, например находится впереди всегда на 100 метров, это я упрощаю, для примера

На ультразвуковых или ик датчиках не получится реализовать? Просто свою схемотехнику создать, чувствительный приемник, чтобы метров от 50ти вылавливал препятствие. Или это слишком просто и хочется заморочиться с машинным зрением и в будущем выхватить какой-нибудь грант?)

Грант? В институте мне знаете что сказали за эту работу? Я постесняюсь это написать здесь в ЛС заходите если хотите это обсудить. А ультразвук сразу отметается и вот почему:

Помехи от скорости ветра в микрофон.
Расстояние даже без помех максимум 30м и это очень хороший сонар 50 это фантастика.
Диаграмма направленности очень широкая.
Развёртку сонара вероятно придётся делать механическую а это очень медленно и сам механизм получится довольно большой.
Если делать с механической развёрткой проще сделать с лидаром там встречаются модели с дальность 200м, где 100 точно будет. Но стоят они как 10 таких самолётов, стереокамеры так-то дешевле будут.

А лазерные датчики? Я только не видел, чтобы их кто-то программировал, но если у них есть вменяемый токовый выход, то почему бы и нет. На али есть какие-то микромодули, но в подробности не вдавался.
А на счет проекта в целом, возможно ведь, что это уже военная тематика, и в массы никто не хочет пускать разработки такого уровня.

А датчики и не надо программировать, надо прочитать даташит понять протокол обмена и пользовать датчик. Можно с ebay или али, хотя с али сейчас проблемы мне до сих пор идут датчики.
Не согласен насчёт военной тематики любой может купить готовый АП лучше моего то-же Pixawk там есть всё что есть у меня но лучше.
Имеет смысл присмотреться к проектам, чтобы не изобретать велосипед, если его уже сделали до вас, т.е. взять наработки из данных проектов
www.dronecode.org

Лучше изобретать велосипед. Это хороший способ во всем разобраться. Тем более, иногда можно предложить то, что еще никто не сделал.

не вникал, но для данного чипа производитель выкладывает SDK, поэтому не так всё печально :)

кстати, думали ли вы про навигацию посредством топографических карт, например полет вдоль автомобильных или жд дорог. Один из плюсов полета над этими дорогами, что впереди нету высоких препятствий, в виде деревьев, зданий, гор (тоннели исключение)? ЖД дороги вообще для CV сплошная радость, т.к. можно считать шпалы, считать столбы, т.к. расстояние между ними стандартизировано, расположение ЖД станций также известно.

Загрузили топографические карты, отметили маршрут, и в случае отсутствия GPS, продолжаете навигацию по ключевым точкам, например по уникальным топографическим точкам, которые распознает computer vision и исходя из этого вычислит примерные координаты.
В принципе это возможно если есть источник топографических карт его можно загрузить в карту и использовать. Касательно computer vision нужны фотографии текущей местности (время года) и с нужного ракурса, желательно с самолёта если он там уже летал и синхронизировать их геокоординаты с ИНС. В теории конечно.
Сколько потратили на всё дело(пропустил наверно не суть)!
в скулково за 5 лярдов не смогли бпл сделать ;-)
Only those users with full accounts are able to leave comments. Log in, please.