Fail-Safe - Автопилот для полетов по камере

serj
vovic:

Да записи ж полетов выложены - можно самому посмотреть. Визуально погрешность координат не превышает размаха крыла планера. Про автомобили - это ж совсем другое дело. Планер в лесу и между зданиями никогда не летит. Над ним всегда чистое небо (в смысле - радиопрозрачное). Поэтому точность очень высокая. На виражах с ускорениями 2 - 3g потери точности нет. Скорости - до 200 км в час, не думаю, что машины ездят быстрее.

дык, по записям ничего не понятно, т.к там нету видео 😃 я имею в виду не пропадание позиции и потерю точности, а отставание по времени 😃,

Пример- , скорость воздушная 120, наземная пусть 160,(летим по ветру) , пошел разворот с угловой скоростью примерно 30- 40 градусов/с, то есть разворот на 180 градусов займет около 5-6 секунд. как при этом ведет себя gps относительно реального (визуально) положения планера ?

У нас при визуальном и “инерциальном” анализе поворота, в зависимости от ускорения в повороте идет отставание курса и позиции от реальной на 3-7с!

Косвенно это можно определить по “плотности” (равномерности распположения на треке) точек в поворотах- если воздушная и угловая скорость не менялась, а ветер составляет процентов 20-30 от скорости планера, то на треке поворот должен выглядеть почти идеальным яйцом (то бишь эллипсом.) 😃

При запаздавании курса и позиции (когда ускорение нарастает примерно до 1.5g) расстояние между точками идет неравномерно- по треку видны рывки скорости, а по логам с самого приемника их нету!

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

vovic
serj:

У нас при визуальном и “инерциальном” анализе поворота, в зависимости от ускорения в повороте идет отставание курса и позиции от реальной на 3-7с!

Трудно представить себе механизм запаздывания. Конечно, в GPS-приемнике есть конвеер вычислений, однако его время задержки не более цикла вычислений - т.е. при потоке отсчетов 1Гц время задержки не более секунды. Это по отношению к результату, выдаваемому по NMEA. Что же касается средств отображения на экране навигатора на карте - там такие задержки запросто возможны - но они нас мало волнуют. Автоматика будет получать свежие данные по NMEA. Где задержки нет. 😒

pdk
vovic:

Трудно представить себе механизм запаздывания.

Как раз ничего трудного - в GPS приемнике стоит фильтр калмана, он и дает запаздывание.
Кроме того в самом фильтре имеется некая модель системы, довольно простая, а следовательно обладающая большой погрешностью на сложных траекториях.
Идеальный вариант использовать в системе управления псевдодальности, да дешевые приемники их не выдают (про сложность математики лучше промолчу).

Фильтр Калмана для чайников
Еще можно почитать Wiley - Global Positioning Systems - Inertial Navigation And Integration
в сети нет, но могу поделится

vovic
pdk:

Как раз ничего трудного - в GPS приемнике стоит фильтр калмана, он и дает запаздывание.

Но не более чем на цикл. Одна секунда погоды не делает - планер на крейсерской скорости 80 км в час пролетит не на цель, а в 20 метрах от нее - ну и что? По моему - это не проблема для применения по названию этой темы.

pdk
vovic:

Но не более чем на цикл.

тактовая частота фильтра гораздо выше тех 1-5Гц с которыми приемник выдает данные
то что идет наружу это мнгновенное значение фильтрованного сигнала.

С циклом выдачи задержка никак не связанна, она определяется только реализацией фильтра, его “постоянной времени”

vovic
pdk:

С циклом выдачи задержка никак не связанна, она определяется только реализацией фильтра, его “постоянной времени”

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

pdk
vovic:

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

только это не “задержка в вычислениях.”, а переходной процесс фильтра
( по данным serj задержка достигает 7сек, понятно что настраивать выдаче NMEA на самолете на 8-10сек неприемлемо )

смысл вовсе не теряется:
пока мы летим “в рамках” встроеной в GPS модели погрешность получаемых с приемника координат -просто шум, как только мы вышли за эти рамки погрешность начинает коррелировать с параметрами движения, и если у нас есть более точная матмодель движения(для оценки этих параметров) то можно повысить итоговую точность определения координат.

vovic
pdk:

пока мы летим “в рамках” встроеной в GPS модели погрешность получаемых с приемника координат -просто шум, как только мы вышли за эти рамки погрешность начинает коррелировать с параметрами движения, и если у нас есть более точная матмодель движения(для оценки этих параметров) то можно повысить итоговую точность определения координат.

Насколько я понял из фирменного описания u-blox там модель проста до безобразия - прямолинейное движение. Ширина полосы пропускания фильтрации Кальмана, в рамках которой отрабатывается криволинейное движение, предустановками задается четыре ступени, в зависимости от ускорения объекта на виражах. Соответственно, меняется шум фильтрации на отступлении от модели - чем шире полоса пропускания, тем больше шум координат на вираже. Если вираж делается с бОльшим ускорением, чем полоса пропускания фильтра Кальмана - происходит потеря положения. Я это регулярно наблюдаю на старте с лебедки - планер отпускается из рук, когда усилие леера больше 10 кГ - это при весе планера в 2 кГ дает ускорение больше 5g. Очень часто на записи логгера в момент старта есть потеря положения GPS-вычислителя. Еще такое бывает на кивке динамостарта с лебедки. Но гораздо реже.
Реальные опыты с автопилотом RCAP на местности показали неплохую точность наведения на цель даже с GPS-приемником eTrex, который выдает координаты раз в 2 секунды. Мне кажется, что для полетов моделей планеров и самолетов проблема точности GPS не стоит вообще.
Проблема - написать код. 😃

Prikupets
vovic:

Реальные опыты с автопилотом RCAP на местности показали неплохую точность наведения на цель даже с GPS-приемником eTrex, который выдает координаты раз в 2 секунды. Мне кажется, что для полетов моделей планеров и самолетов проблема точности GPS не стоит вообще.

Спасибо за исследования, эта инфа для меня важна!

vovic
Prikupets:

Спасибо за исследования, эта инфа для меня важна!

Вселяет надежду.
Если будете браться, то просьба, ориентироваться на формат NMEA сообщение $GPRMC . В нем есть и текущие координаты и текущий курс модели. Надо только добавить расчет курса на цель.
Почему такая просьба? - Для живучести решения во времени. Как показывает жизнь - эта сфера очень подвижна, вчерашние фавориты можно завтра уже не найти на рынке средств GPS. Поэтому привязка к самому расхорошему, но собственному стандарту производителя через 3 года может стать недоступной для повторения. А самое ценное решение - свободное для повторения любым желающим.
Готов помочь во всем, что потребуется.

PigTail
Vad64:

А реально ли, скажем, в Москве купить в розницу какой-нибудь OEM GPS модуль с документированной системой команд и форматом данных? Если да, то где, как и сколько это ориентировочно будет стоить?

Пробую приобрести ЕМ-406 в геопарке, обещают 2 неделю, что должны появиться, пока ждемс, как появятся могу свиснуть или взять на Вашу долю, у них доставка по Москве, потом заберете, как удобно будет, цена на сайте 55 баксов. Документация довольно скудна, но лежит на сайте На англицком не менее краткое описание тоже можно найти на Глобалсатовском сайте, кроме NMEA еще могет общаться собственным протоколом чипсета, возможности протоколов пока не сравнивал. Собственно файлы с описаловкой:

serj

Вовик так и не ответил, оценивал ли он динамические характеристики (запаздывание) у антариса 😃

Ну да ладно. Придется выяснять в реальных полетах 😃.

А на планере плавно летающем только по gps задержки скореее всего не превысят 2с- там ускорения невелики 😃.

Prikupets
vovic:

Вселяет надежду.
Если будете браться, то просьба, ориентироваться на формат NMEA сообщение $GPRMC .

Так и делаю 😃

Psw
serj:

Вовик так и не ответил, оценивал ли он динамические характеристики (запаздывание) у антариса 😃

Ну да ладно. Придется выяснять в реальных полетах 😃.

А на планере плавно летающем только по gps задержки скореее всего не превысят 2с- там ускорения невелики 😃.

От себя могу подтвердить задержку между визуальным положением ЛА и положением ГПС выданным еТрексом ( прохождение желаемой точки приземления парапрыгеров)
Задержку оцениваю около 2-5 секунд, что для парапрыгеров не существенно. При оценке полёт прямолинейный, воздушная 130-160 (АН-2 родимый), по земле от ветра, без ощущаемых перегрузок.
И ещё у меня есть предположение, что ГПС вертикаль и грави вертикаль не соосны.
Ну то есть точность/ошибка ГПС при проходе над целью высота 100 метров визуальный угол на цель меньше, чем когда на 2000 метров - тогда ГПС сильнее в бок уводит. Хотя опять же для парапрыгеров с бортовым интеллектом и самонаведением на цель енто тоже весьма не существенно - отличие гораздо менее 10 градусов и его вообще можно списать на глюки визуальной оценки пилота ЛА, который на ентом ЛА ближайшие лет 20 заходы для парапрыгеров и делает. А вот для прицельного бомбометания ну никак не годится.
В еТрексе использовал экран Направление/Расстояние до точки. Более Половины неба экранировались кабиной АН-2, спутников 5-6 с хорошим сигналом, только они меняются быстро.

Psw

Ну вот, редактирование в течение часа:
“Обнаружена ошибка:
У вас нет прав редактирования этого сообщения
Данные сообщения успешно сохранены!”
А если у меня сложное редактирование ? Короче, пришлось вторую мессагу в догонку:

Unav:

Код на С++ вычисление азимуна и расстояние между точками.

Прикольно, коды. Правда, код СРР не особо применим в данном случае, насколько я понимаю.
Потому как для ентих МК Си по проще будет, для примера студенческая 60 дней версия Си для 18 ПИКов ну и документация к нему.
Ну и MPLAB с сайта Микрочип тоже пригодится для исследований.

Unav:

Когда осилю Пик - перепишу на пикбейсике

Да ПИК как таковой осиливать особо и не нужно - надо, что-бы код на функции на Си хоть какую-либо компиляцию проходил как проектик в МпЛабе для отсутствия несоответствий синтаксиса. А обращения к аппаратным ресурсам надо в других местах/прогах делать или оно уже в бэйсике есть. В бэйсике нету обратной тригонометрии и нормальной точности, зато она есть в библиотеках для ПикСи18.
А на входе в Си функцию как я уже говорил можно две пары координат иметь - стартовую и текущую (например прямо в тексте NMEA), а на выходе быть может - байт курса на цель (360 градусов= 0 градусов = 256 = 0) и пара байт расстояния до цели в метрах.
Хотя с параметрами функции быть может Вовик подскажет/уточнит, на что там в RCAP упор делается - на какие параметры бэйсик расчитывает и в какой они форме.

vovic
Psw:

А на входе в Си функцию как я уже говорил можно две пары координат иметь - стартовую и текущую (например прямо в тексте NMEA), а на выходе быть может - байт курса на цель (360 градусов= 0 градусов = 256 = 0) и пара байт расстояния до цели в метрах.
Хотя с параметрами функции быть может Вовик подскажет/уточнит, на что там в RCAP упор делается - на какие параметры бэйсик расчитывает и в какой они форме.

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

Функция вычисления азимута по координатам, хорошо если бы на входе имела бы четыре символьних последовательности формата ГГ.ММ,МММ - т.е. градусы, минуты с точностью до тысячных долей долготы и широты точки возврата и текущие значения координат. По умолчанию все координаты отнесены к северной широте и восточной долготе. На выходе иметь двухбайтное слово, численно равное азимуту на точку возврата в градусах. Тогда такую отлаженную функцию можно было бы вставить в имеющийся текст программы.

Там будет еще нюанс по использованию оперативки подпрограммой расчета данной функции. Оперативка там регистровая и маленькая. Какие то регистры уже задействованы компилятором исходной программы. Впрочем - в этом я уже слабовато разбираюсь. 😊

Vad64
PigTail:

Пробую приобрести ЕМ-406 в геопарке, обещают 2 неделю, что должны появиться, пока ждемс

Сегодня взял у них ЕМ-406

PigTail

Гы… сервис у них, однако, позвонил, заказик мой уже посеяли 😦, правда обещали завтра подвезти 😃 .

Оперативка вроде в сей микрухе не только регистровая, да еще 256 байт ЕЕПРОМ, таблицу с тригонометрией туды можно запихнуть, хотя ПИКи для меня темный лес.

Psw
vovic:

В текст существующей программы добавить несколько строк

Ну немного и я за себя взялся - хоть поставил ентот ПикБасицПро, подвязал его к МпЛабу и скомпилил RCAP.
Прикольно - высокий уровень языка - я уже и забыл что енто такое.
Когда для смены проца нужно лишь тип проца и поменять.
А хекс уже другой построится.

vovic:

Оперативка там регистровая и маленькая.

Ну вот для ентого и прикола ради перекомпилил под пик18 - у него ресурсов гораздо поболее.
Ну немного конечно подправить пришлось асм обработчик прерывания в Servo.Inc
Но скомпилил для 18Ф4431 без ошибок сейчас - сказалась обратная совместимость асма по мнемокодам.
Каталог проекта для пик16 и 18 прилагаю - вдруг кому интересно.
Использование ПЗУ -
Для пик18:
Program Memory Bytes Used: 7702
Program Memory Bytes Free: 8682
Для Пик16:
Program Memory Words Used: 4015
Program Memory Words Free: 4177
А вот про ОЗУ не знаю как узнать - сколько использовано/свободно.

Хотя не известно, заработает ли ? Надо прикола ради ентот хекс зашить в макетку.
Так а там для отладки ЛЦД на 44780 используется насколько я понял ?
Тем более есть повод в свою макетку залить енто дело.

vovic
Psw:

Ну немного конечно подправить пришлось асм обработчик прерывания в Servo.Inc

В исходном обработчике есть ошибка - там после записи новых коэффициентов деления надо в управляющем регистре таймера установить младший бит. Автор же загоняет в регистр единицу - в результате предделитель таймера паузы сбрасывается (старшие биты регистра). Практически в работе аппарата это вызывает дрожание-дрейф сервомашинки. Я этот трабл две недели выискивал в прошлом году - потом устранил. 😎

Psw
serj:

Я мечтаю, чтоб хоть и на 0.5гц, но чтобы эта сволочь не тормозила по 6-7 а иногда и 10с в поворотах на скоростях 130-150км/ч, а то блин такие вилюшки получаются… в окружность 70м с трудом наводится, в 50м уже промахивается с первого раза., это ежели до точки меньше 350м и надо повернуть на 110 градусов и больше…

Серж - ты уже достаточно взрослый, пора уже и мечтать по взрослому.
Ну то есть насколько я своим дилетантским взглядом понимаю положение вещей - пора уже браться за внутренности ГПС вычислений, без ентого любые скоростные (с высоким центростремительным ускорением) эволюции сопровождаются потерей позиции из-за фильтрации ВНУТРИ ГПС - он то думает, что НА ЗЕМЛЕ возможны ускорения не более 0,5 Г с резиной по асфальту. Вот и фильтрует базар как следует. А если фильтрацию перенастраивать в зависимости от показаний бортового датчика ускорений ну и быть могет барометрического альтиметра при 3D навигации - могет получится совсем другое дело.
Хотя енто как я понял ну совершенно другая история - многосторонняя увязка инерциалки с низко уровневыми ГПС данными. Простора для мозга хоть отбавляй.
p.s. Опять жру пиво - стиль изложения соответственный.
2 Вовик - чего-то мне с первого взгляда ентот Бэйсик проект не особо понравился - своей реализацией ППМ ввода/вывода как минимум. Ну и тем, что рулит одним каналом. Хотя как всегда - лучшее - враг хорошего.
Однако Если привлекать аппаратуру 18ф4431, вполне можно 3-5 каналов весьма точно вводить и пару или десять весьма точно выводить - в зависимости от того, способен ли Power Control модуль полноценно PPM формировать - я его структуры в деталях так и не понял, хотя неоднократно пытался.
С отладочным ЛЦД я насколько понимаю ошибся - там один отладочный выход, на который инфа льётся во внешний терминал в асинхронном виде.
В макетку пока не залил.