Fail-Safe - Автопилот для полетов по камере
Это понятно, но нет смысла делать период выдачи координат меньше, чем задержка в вычислениях. Смысл теряется. Поэтому так и не делают. Я об этом говорил. По моему, это очевидно.
только это не “задержка в вычислениях.”, а переходной процесс фильтра
( по данным serj задержка достигает 7сек, понятно что настраивать выдаче NMEA на самолете на 8-10сек неприемлемо )
смысл вовсе не теряется:
пока мы летим “в рамках” встроеной в GPS модели погрешность получаемых с приемника координат -просто шум, как только мы вышли за эти рамки погрешность начинает коррелировать с параметрами движения, и если у нас есть более точная матмодель движения(для оценки этих параметров) то можно повысить итоговую точность определения координат.
пока мы летим “в рамках” встроеной в GPS модели погрешность получаемых с приемника координат -просто шум, как только мы вышли за эти рамки погрешность начинает коррелировать с параметрами движения, и если у нас есть более точная матмодель движения(для оценки этих параметров) то можно повысить итоговую точность определения координат.
Насколько я понял из фирменного описания u-blox там модель проста до безобразия - прямолинейное движение. Ширина полосы пропускания фильтрации Кальмана, в рамках которой отрабатывается криволинейное движение, предустановками задается четыре ступени, в зависимости от ускорения объекта на виражах. Соответственно, меняется шум фильтрации на отступлении от модели - чем шире полоса пропускания, тем больше шум координат на вираже. Если вираж делается с бОльшим ускорением, чем полоса пропускания фильтра Кальмана - происходит потеря положения. Я это регулярно наблюдаю на старте с лебедки - планер отпускается из рук, когда усилие леера больше 10 кГ - это при весе планера в 2 кГ дает ускорение больше 5g. Очень часто на записи логгера в момент старта есть потеря положения GPS-вычислителя. Еще такое бывает на кивке динамостарта с лебедки. Но гораздо реже.
Реальные опыты с автопилотом RCAP на местности показали неплохую точность наведения на цель даже с GPS-приемником eTrex, который выдает координаты раз в 2 секунды. Мне кажется, что для полетов моделей планеров и самолетов проблема точности GPS не стоит вообще.
Проблема - написать код. 😃
Реальные опыты с автопилотом RCAP на местности показали неплохую точность наведения на цель даже с GPS-приемником eTrex, который выдает координаты раз в 2 секунды. Мне кажется, что для полетов моделей планеров и самолетов проблема точности GPS не стоит вообще.
Спасибо за исследования, эта инфа для меня важна!
Спасибо за исследования, эта инфа для меня важна!
Вселяет надежду.
Если будете браться, то просьба, ориентироваться на формат NMEA сообщение $GPRMC . В нем есть и текущие координаты и текущий курс модели. Надо только добавить расчет курса на цель.
Почему такая просьба? - Для живучести решения во времени. Как показывает жизнь - эта сфера очень подвижна, вчерашние фавориты можно завтра уже не найти на рынке средств GPS. Поэтому привязка к самому расхорошему, но собственному стандарту производителя через 3 года может стать недоступной для повторения. А самое ценное решение - свободное для повторения любым желающим.
Готов помочь во всем, что потребуется.
А реально ли, скажем, в Москве купить в розницу какой-нибудь OEM GPS модуль с документированной системой команд и форматом данных? Если да, то где, как и сколько это ориентировочно будет стоить?
Пробую приобрести ЕМ-406 в геопарке, обещают 2 неделю, что должны появиться, пока ждемс, как появятся могу свиснуть или взять на Вашу долю, у них доставка по Москве, потом заберете, как удобно будет, цена на сайте 55 баксов. Документация довольно скудна, но лежит на сайте На англицком не менее краткое описание тоже можно найти на Глобалсатовском сайте, кроме NMEA еще могет общаться собственным протоколом чипсета, возможности протоколов пока не сравнивал. Собственно файлы с описаловкой:
Вовик так и не ответил, оценивал ли он динамические характеристики (запаздывание) у антариса 😃
Ну да ладно. Придется выяснять в реальных полетах 😃.
А на планере плавно летающем только по gps задержки скореее всего не превысят 2с- там ускорения невелики 😃.
Вселяет надежду.
Если будете браться, то просьба, ориентироваться на формат NMEA сообщение $GPRMC .
Так и делаю 😃
Вовик так и не ответил, оценивал ли он динамические характеристики (запаздывание) у антариса 😃
Ну да ладно. Придется выяснять в реальных полетах 😃.
А на планере плавно летающем только по gps задержки скореее всего не превысят 2с- там ускорения невелики 😃.
От себя могу подтвердить задержку между визуальным положением ЛА и положением ГПС выданным еТрексом ( прохождение желаемой точки приземления парапрыгеров)
Задержку оцениваю около 2-5 секунд, что для парапрыгеров не существенно. При оценке полёт прямолинейный, воздушная 130-160 (АН-2 родимый), по земле от ветра, без ощущаемых перегрузок.
И ещё у меня есть предположение, что ГПС вертикаль и грави вертикаль не соосны.
Ну то есть точность/ошибка ГПС при проходе над целью высота 100 метров визуальный угол на цель меньше, чем когда на 2000 метров - тогда ГПС сильнее в бок уводит. Хотя опять же для парапрыгеров с бортовым интеллектом и самонаведением на цель енто тоже весьма не существенно - отличие гораздо менее 10 градусов и его вообще можно списать на глюки визуальной оценки пилота ЛА, который на ентом ЛА ближайшие лет 20 заходы для парапрыгеров и делает. А вот для прицельного бомбометания ну никак не годится.
В еТрексе использовал экран Направление/Расстояние до точки. Более Половины неба экранировались кабиной АН-2, спутников 5-6 с хорошим сигналом, только они меняются быстро.
Ну вот, редактирование в течение часа:
“Обнаружена ошибка:
У вас нет прав редактирования этого сообщения
Данные сообщения успешно сохранены!”
А если у меня сложное редактирование ? Короче, пришлось вторую мессагу в догонку:
Прикольно, коды. Правда, код СРР не особо применим в данном случае, насколько я понимаю.
Потому как для ентих МК Си по проще будет, для примера студенческая 60 дней версия Си для 18 ПИКов ну и документация к нему.
Ну и MPLAB с сайта Микрочип тоже пригодится для исследований.
Когда осилю Пик - перепишу на пикбейсике
Да ПИК как таковой осиливать особо и не нужно - надо, что-бы код на функции на Си хоть какую-либо компиляцию проходил как проектик в МпЛабе для отсутствия несоответствий синтаксиса. А обращения к аппаратным ресурсам надо в других местах/прогах делать или оно уже в бэйсике есть. В бэйсике нету обратной тригонометрии и нормальной точности, зато она есть в библиотеках для ПикСи18.
А на входе в Си функцию как я уже говорил можно две пары координат иметь - стартовую и текущую (например прямо в тексте NMEA), а на выходе быть может - байт курса на цель (360 градусов= 0 градусов = 256 = 0) и пара байт расстояния до цели в метрах.
Хотя с параметрами функции быть может Вовик подскажет/уточнит, на что там в RCAP упор делается - на какие параметры бэйсик расчитывает и в какой они форме.
А на входе в Си функцию как я уже говорил можно две пары координат иметь - стартовую и текущую (например прямо в тексте NMEA), а на выходе быть может - байт курса на цель (360 градусов= 0 градусов = 256 = 0) и пара байт расстояния до цели в метрах.
Хотя с параметрами функции быть может Вовик подскажет/уточнит, на что там в RCAP упор делается - на какие параметры бэйсик расчитывает и в какой они форме.
Я, собственно, так и предполагал. В текст существующей программы добавить несколько строк, которые ожидают после включения автопилота когда появяться достоверные координаты точки старта, после этого эти координаты запоминаются как точка возврата на все время полета.
Функция вычисления азимута по координатам, хорошо если бы на входе имела бы четыре символьних последовательности формата ГГ.ММ,МММ - т.е. градусы, минуты с точностью до тысячных долей долготы и широты точки возврата и текущие значения координат. По умолчанию все координаты отнесены к северной широте и восточной долготе. На выходе иметь двухбайтное слово, численно равное азимуту на точку возврата в градусах. Тогда такую отлаженную функцию можно было бы вставить в имеющийся текст программы.
Там будет еще нюанс по использованию оперативки подпрограммой расчета данной функции. Оперативка там регистровая и маленькая. Какие то регистры уже задействованы компилятором исходной программы. Впрочем - в этом я уже слабовато разбираюсь. 😊
Пробую приобрести ЕМ-406 в геопарке, обещают 2 неделю, что должны появиться, пока ждемс
Сегодня взял у них ЕМ-406
Гы… сервис у них, однако, позвонил, заказик мой уже посеяли 😦, правда обещали завтра подвезти 😃 .
Оперативка вроде в сей микрухе не только регистровая, да еще 256 байт ЕЕПРОМ, таблицу с тригонометрией туды можно запихнуть, хотя ПИКи для меня темный лес.
В текст существующей программы добавить несколько строк
Ну немного и я за себя взялся - хоть поставил ентот ПикБасицПро, подвязал его к МпЛабу и скомпилил RCAP.
Прикольно - высокий уровень языка - я уже и забыл что енто такое.
Когда для смены проца нужно лишь тип проца и поменять.
А хекс уже другой построится.
Оперативка там регистровая и маленькая.
Ну вот для ентого и прикола ради перекомпилил под пик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 используется насколько я понял ?
Тем более есть повод в свою макетку залить енто дело.
Ну немного конечно подправить пришлось асм обработчик прерывания в Servo.Inc
В исходном обработчике есть ошибка - там после записи новых коэффициентов деления надо в управляющем регистре таймера установить младший бит. Автор же загоняет в регистр единицу - в результате предделитель таймера паузы сбрасывается (старшие биты регистра). Практически в работе аппарата это вызывает дрожание-дрейф сервомашинки. Я этот трабл две недели выискивал в прошлом году - потом устранил. 😎
Я мечтаю, чтоб хоть и на 0.5гц, но чтобы эта сволочь не тормозила по 6-7 а иногда и 10с в поворотах на скоростях 130-150км/ч, а то блин такие вилюшки получаются… в окружность 70м с трудом наводится, в 50м уже промахивается с первого раза., это ежели до точки меньше 350м и надо повернуть на 110 градусов и больше…
Серж - ты уже достаточно взрослый, пора уже и мечтать по взрослому.
Ну то есть насколько я своим дилетантским взглядом понимаю положение вещей - пора уже браться за внутренности ГПС вычислений, без ентого любые скоростные (с высоким центростремительным ускорением) эволюции сопровождаются потерей позиции из-за фильтрации ВНУТРИ ГПС - он то думает, что НА ЗЕМЛЕ возможны ускорения не более 0,5 Г с резиной по асфальту. Вот и фильтрует базар как следует. А если фильтрацию перенастраивать в зависимости от показаний бортового датчика ускорений ну и быть могет барометрического альтиметра при 3D навигации - могет получится совсем другое дело.
Хотя енто как я понял ну совершенно другая история - многосторонняя увязка инерциалки с низко уровневыми ГПС данными. Простора для мозга хоть отбавляй.
p.s. Опять жру пиво - стиль изложения соответственный.
2 Вовик - чего-то мне с первого взгляда ентот Бэйсик проект не особо понравился - своей реализацией ППМ ввода/вывода как минимум. Ну и тем, что рулит одним каналом. Хотя как всегда - лучшее - враг хорошего.
Однако Если привлекать аппаратуру 18ф4431, вполне можно 3-5 каналов весьма точно вводить и пару или десять весьма точно выводить - в зависимости от того, способен ли Power Control модуль полноценно PPM формировать - я его структуры в деталях так и не понял, хотя неоднократно пытался.
С отладочным ЛЦД я насколько понимаю ошибся - там один отладочный выход, на который инфа льётся во внешний терминал в асинхронном виде.
В макетку пока не залил.
Цель замышляемого дела - модифицировать софт так, чтобы он смог работать с любой GPS-головкой.
Я заткнулся на том, что не смог написать расчет азимута на цель по известным координатам на Пикбейсике без библиотек функций. Ну, не программист я. 😊
Может кто возьмется помоч ?
Написал код (пока для проверки на MatLab’e) без библиотечных функций
Вход:
широта и долгота точки цели в формате NMEA GGA , т.е. GGMM.MMMM (LAT) и GGGMM.MMMM (LON)
широта и долгота текущей точки (в том же формате)
Выход:
азимут на цель
расстояние до цели
Ошибка порядка 0.1%
Вот только от плавучки не смог отказаться и числа в формате double
To: vovic
Володь, проверь пожалуйста, может влезет библиотека для плавающей точки.
Вот только от плавучки не смог отказаться и числа в формате double
Все легко сделать в целочисленной арифметике. Если кому-то нужно, могу рассказать, как. Но кодировать в Пикбейсике не хочу.
Лучше всего использовать fixed point. Нужно только быстрое умножение и деление больших целых чисел.
Все легко сделать в целочисленной арифметике. Если кому-то нужно, могу рассказать, как.
Мне нужно. Кодировать буду на ассемблере.
Володь, проверь пожалуйста, может влезет библиотека для плавающей точки.
На днях попробую. Если до НГ не успею (конец года - как всегда) то на каникулах рождественских точно выясню.
Мне нужно. Кодировать буду на ассемблере.
Начнем с конца, т.е. с арктангенса. Пусть есть разность широт dY и долгот dX. Они целые, в каких-то одинаковых единицах. Делаем таблицу арктангенса для аргументов 0-0.5 включительно (т.е углы от 0 до 45). Количество элементов в таблице зависит от требуемой точности. Лучше, если это количество равно степени 2 плюс 1. Тогда в будущем умножение можно заменить на сдвиг. Вот к примеру таблица из 33 значений дает точность не хуже 2х градусов
const char atnTab[33] =
{0, 2, 4, 5, 7, 9, 11, 12, 14, 16, 17, 19, 21, 22, 24, 25,
27, 28, 29, 31, 32, 33, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45};
short atn; // результат
Дальше обрабатываем единственную неопределенность
if(dX == 0 && dy == 0){
atn = 0; // Но это неопределенность!!
}
Если неопределенности нет, то начинаем бить на октанты и в каждом октанте вычисляем арктангенс по-своему
if(dX >= 0 && dY >= 0){
if(dX <= dY)
atn = atnTab[dX*32/dY];
else
atn = 90 - atnTab[dY*32/dX];
}
else if(dX >= 0 && dY <= 0){
if (dx > -dY)
atn = 90 + atnTab[-dY*32/dX];
else
atn = 180 - atnTab[dX*32/(-dY)];
}
else if(…
и так еще 4 октанта
Видно, что при таком подходе:
-только одна операция деления
-деления на 0 быть не может
-результат деления всегда от 0 до 32
-результат арктангенса получается однозначным от 0 до 359
Важно, чтобы не было переполнения при умножении на 32. Т.е. либо для результата умножения использовать бОльшую разрядность, либо быть уверенным, что в dX и dY пять старших разрядов свободны.
Вроде можно и без ассемблера обойтись.
Посмотрите набросал куски кода в ПИКБейсике, там считывание полей с координатами и засовывание их в две двухбайтных переменных и вычитание двухбайтных переменных цели и текущей позиции. Код только в виде примера, не уверен что правильно, но мож пригодится.
Посмотрите набросал куски кода в ПИКБейсике, там считывание полей с координатами и засовывание их в две двухбайтных переменных и
Нельзя координату в двухбайтную переменную засовывать. Это неприемлемая потеря точности. Двухбайтное представление годится только для разности текущей позиции и цели.
Дык там так и сделано… педполагается, что далеко улетать никто не будет 😃
но на мой взгляд эта кактавасия не совсем корректна.
У меня 3 байта для представления координат. и штатный сишный арктангенс. на 16 мгц считается за 40 мкс.
но пользуюсь арктангенсом не часто, 301 раз в секунду, поэтому времени на другие вычисления- вагон.
У меня 3 байта для представления координат.
serj, если GPS выдает координаты в десятичном формате ddmm.mmmm и dddmm.mmmm, то 3х байтов вроде как мало, если не отбрасывать младшую цифру. Напрашиваются 32 бита. Или делать вычитание с координатами в десятичном виде.
Библиотеку Си vovic-у пристегнуть может быть проблематично. Проще действительно в ассемблере.
Пардон, мож муторно написал, одна координата запихивается в 2 слова, в одно целая часть в минутах(естественно градусы не откидываются), во второе дробная часть минут, разница укладывается в двубайтное. Последняя цифирь действительно откидывается, если ее GPS вообще выдает. Предпологается, что с данным агрегатом никто не будет улетать далее расстояния в 32 минуты от точки возврата. Насчет ассемблера еще не известно как он там с асемблером общается, этот куцый бейсик, наверное самый простой вариант все таки подцепить библиотеку с плавающей точкой на том же бейсике, благо она существует.