Проект Мегапират на самик!
нифига не понял…
Не парься! Это я пытаюсь быть типо полезным…
Все кто с Вортексом на Мегапирате летал - проблему с переключением режимов АП уже решили (надеюсь…), поэтому эта идея не актуальна…
Тормознул…
Блокировку движка сразу в код заложи, а то запарился я контакты от движка каждый раз отстегивать…
Пока Олег строит АП с нуля, продолжаю мучать 26 прошивку 😃 Кто нибудь летал в режиме FBW-B??? У меня в этом режиме РВ работает в инверте 😃 Ручку на себя, самуль вниз движка в минимум, ручку от себя самуль вверх газ добавляет 😃 Пытаюсь понять где крутнуть, чтот мутно как то усе…
Причем в режиме FBW-А есть следующая строчка:
nav_pitch = g.channel_pitch.norm_input() * (-1) * g.pitch_limit_min;
В режиме FBW-B она вот такая:
altitude_error = g.channel_pitch.norm_input() * g.pitch_limit_min;
Полагаю в этом и есть проблема? Вставка (-1) = инверт которого почему то не хватает в FBW-B…
Кто подскажет где кусок кода отвечающий за выполнение условия прохождения точки? Хочу туда добавить обязательное условие “высоты полета”, сейчас АП пофиг, хоть там 500м стоит, нужные координаты пролетел, и считает что точка пройдена…
static bool verify_nav_wp()
{
hold_course = -1;
update_crosstrack();
if ((wp_distance > 0) && (wp_distance <= g.waypoint_radius)) {
gcs_send_text_fmt(PSTR(“Reached Waypoint #%i”),nav_command_index);
return true;
}
// add in a more complex case
// Doug to do
if(loiter_sum > 300){
gcs_send_text_P(SEVERITY_MEDIUM,PSTR(“Missed WP”));
return true;
}
return false;
}
Оно?
Сделал порт DCM алгоритма от Мегапирата в свой проект на STM32. Поисследовал результаты в графиках и цифрах. Когда плавно изменяю положения платформы, то вообщем-то вопросов нет. Однако если взять плату потрясти поделать восьмерок в воздухе с переворотами и перегрузками, а потом резко положить в горизонт, то возникает однозначно воспроизводимая жопская картина. Горизонт сбит градусов на 30 и медленно ползет к нулю, затем уходит в другую сторону градусов на 20 затем медленно идет назад но до нуля никогда не доходит. чтобы заставить встать горизонт на место нужно слегка покачать плату, тогда горизонт медленно приходит в ноль. После прохождения дебаггером и отслеживания значений переменных я вижу почему такое происходит.
Олег (или кто-то, кто близко к исходникам), скажи, ты код компиляешь для реальных полетов именно с такими коэффициентами коррекции, как в исходниках установлены ???
#define Kp_ROLLPITCH 0.05967
#define Ki_ROLLPITCH 0.00001278
Оно же с такими значениями не дает алгоритму по акселю нормально откорректироваться. А может оно для вертолетов такое выставлено? Для коптеров, когда необходимо висеть и плавно двигаться, оно как раз в тему.
Я вот поигрался всяко разно и пришел к варианту:
#define Kp_ROLLPITCH 0.85967
#define Ki_ROLLPITCH 0.01001278
Оно по крайней мере дает алгортму в течение первой секунды горизонт поставить на место с погрешностью до 15 градусов по окончании любых расколбасов платформы. Да возникает эффект Roll раскачки, но он СУЩЕСТВЕННО меньше, чем при дефолтных коэффициентах и проходит в течение второй секунды, а дальше четко в ноль встает.
Есть еще вариант интегральный коэффициент вообще отключить.
Собственно, если сможешь проясни ситуацию, а я пока Кальмана реализую для живого сравнения с DCM.
Однако если взять плату потрясти поделать восьмерок в воздухе с переворотами и перегрузками, а потом резко положить в горизонт, то возникает однозначно воспроизводимая жопская картина. Горизонт сбит градусов на 30 и медленно ползет к нулю, затем уходит в другую сторону градусов на 20 затем медленно идет назад но до нуля никогда не доходит. чтобы заставить встать горизонт на место нужно слегка покачать плату, тогда горизонт медленно приходит в ноль
Вот - вот!
Такой эффект я и наблюдал два раза на полетах: если летать блинчиком и без порывов ветра - све работало отлично… Но стоило “покалбасится” в борьбе за модель - горизонт уплывал безбожно !
Я тогда еще писал об этом и версия была в том, что превыщены перегрузки для акселя… оказывается что и код мог быть виной!
В FPV надо летать медленно и печально рассматривая сверху интересности, а не крутить 3Д 😃 Хотя на 26 прошивке при ветре почти равной скорости самолета, у меня не чего ни куда не уплывало, самуль вполне не плохо держался 😃
но же с такими значениями не дает алгоритму по акселю нормально откорректироваться. А может оно для вертолетов такое выставлено?
Медленное выравнивание для того и задумано, чтобы не давать акселю сильно косячить на центробежных перегрузках. Помимо этого, имеется треугольная функция - корректировка “веса” акселерометра, если длина его вектора отличается от 1G.
“дикая колбасня” обязательно собъет горизонт в том случае, если он несколько раз проскочит через точки gimbal lock - сингулярность (или полюс), где один из компонентов матрицы лезет в бесконечность.
А вот уходить в другую сторону после корректировки он не должен. Возможно, интегральный в твоей реализации надо действительно отключить.
Как показывают полеты на “реальном” самике, оптимальной является конвергенция от 5 до 7 секунд с углом ошибки 90 град по любой из осей. При этом динамический вес акселя линейно сводится к нулю при изменении длины вектора на 35-40% в любую сторону.
А еще надо аксель на 16G переводить, т.к. 3G в оригинале - даже муху не отгонишь.
И еще, раз у тебя STM и тактов валом, выставь скорость обновления гиры 1 кГц.
Покажешь потом код IMU калмана? 😉
И еще, раз у тебя STM и тактов валом, выставь скорость обновления гиры 1 кГц.
сейчас 400Hz частота итераций. Выше смысла нет, я пробовал на 800Hz ставить. Улучшений не много получил. 400 это примерно оптимально.
“дикая колбасня” обязательно собъет горизонт в том случае, если он несколько раз проскочит через точки gimbal lock - сингулярность (или полюс), где один из компонентов матрицы лезет в бесконечность.
Я, когда с EKF закончу, поставлю брейкпоинтов в этом месте в DCM, чтобы убедиться. Но насколько помню, ни разу туда не заваливался алгоритм, хотя целенаправленно я не мониторил это место.
Возможно, интегральный в твоей реализации надо действительно отключить.
Вот-вот. Я так понимаю 400 Гц это достаточно быстро. Поэтому такие задержки сходимости приводят как раз к отрицательному эффекту. Совсем выключать интегральную составляющую, тоже как-то не очень, там тогда другие интересные краевые эффекты наблюдаю. Ну ладно, я к этому еще вернусь. Чуть позже, когда можно будет в риалтайме сравнить DCM и EKF.
А еще надо аксель на 16G переводить, т.к. 3G в оригинале - даже муху не отгонишь.
Сейчас я пока на 4G поставил, а максимум у меня 8G. Ну для экстрима на столе и 4G за глаза…
Покажешь потом код IMU калмана?
В личной переписке, когда реально отлажу и испытаю на стенде - да, покажу, но не для того чтобы выставить на всеобщее обозрение. Я слишком много времени на разбор физики происходящего потратил и на чтение буржуйских диссертаций, чтобы так просто слить наработанное. Я прикидывал можно ли такое всандалить под Мегу твою, но скорее всего - саляви 😦. Там очень много float перемножений. Для меня это решается подключением аппаратного FPU ядра и компилятор дальше сам строит правильный код, для тебя - даже не представляю, если только умножать все на 1000 и далее все int32_t.
оказывается что и код мог быть виной!
Это не код виной. Это ограничения алгоритма. Он в принципе для спокойных полетов вполне себе годится.
Я вот еще вспомнил. Если очень быстро платформу верх-вниз швырять, то при смене направления вектора тяжести, оно переворачивает все вверх тормашками в тот момент, когда модуль вектора становится точно в окрестности 1G, причем поскольку коэффициенты я другие поставил, то я этого легко добиваюсь и мне не надо для этого прилагать много усилий. И дело тут не в перегрузке акселя, а совсем наоборот. Длинное время конвергенции в принципе и призвано сгладить такую фигню.
В принципе, как я уже сказал, позже вернусь к этому и табличные логи изменения углов с наглядной визуализацией выложу. Может даже Олегу пользу принесу исследованиями на эту тему.
Гы, походу поползновения в кодах ардупилота уже никому не интересны 😉))))))
Гы, походу поползновения в кодах ардупилота уже никому не интересны ))))))
Лёнь, а откуда ж усё “грабится”. Видишь, человек даже на STM32 перенёс ДЦМку из пилота.
Ну а по теме – сорри, пока времени нету – на работе завалец случился, надо разобрать. 😦
Вторая превьюшка. Составлен крайне быстрый бинарный пакетный протокол базовой станции и нарисована часть ее самой.
Прошу не ржать над попыткой сделать авиагоризонт 😃 Тем более, вращение текстур еще ниасилил.
Сама плата понимает команду “level”, в ответ шлет attitude и тайминг основного цикла.
Кому интересно, шить тем же бат-ником с avrdude.
По поводу возможностей протокола скажу, что те же данныe IMU можно отправлять со скоростью 50Hz через АРС на скорости 9600 (сейчас 5Гц), и при этом останется еще столько же полосы на полудуплекс обратно, т.е. джойстиком управлять уже не проблема. Если разбавлять данными GPS и навигации, то 25 Гц. Все равно практически реалтайм.
За основу взят протокол обмена с Megapirate OSD, переделанный на переменную длину. Сами команды выложу попозже.
Ну а по теме – сорри, пока времени нету – на работе завалец случился, надо разобрать.
Бывает 😃
Да я вроде уже сам разобрался, код внедрил, вывел в планер вместо скорости “ошибку высоты” осталось только испытать 😃
Олег, в архив выкладывай сразу и библиотеки, при запуске пишет отсутствует BORLNDMM.DLL
ах ты ж…
вот dl.dropbox.com/u/63786348/Borlndmm.dll
у меня на каждой машине борланд стоит, так что был не в курсе 😃
Что еще попросит, пиши
Далее хочет еще cc3250mt.dll, ну и на последок грит что нет ему счастья без файла AH_bottom.bmp 😃
dl.dropbox.com/u/63786348/mpx_preview2.rar
обновил архив, перекачай
Авиагоризонт - круть 😉
Олег, выложи еще чем ты базовую станцию компилишь, влом мне перенастраивать блютус модуль, а он на скорости 115кбит 😃 Поменял бы циферу в коде чтоб тебя не мучать 😃
Да к стати в архиве еще батника не хватает для заливки в мозг хекса, так сказать уж до кучи чтоб было все вместе 😃
на, ковыряй… только в прошиве тоже 57600 стоит
Пунятна 😃 ты вроде говорил про 9600 😃?
Траблы продолжаются, при попытке залить код в мегу… нужна библиотека libusb0.dll
Олег, бяда бяда страшная!!! 😃
Нашел твою первую прошивку чтоб извлечь от туда батник, ну и запустил сразу его для проверки, усе прошилось проверилось и тд тп, НО! Новым хексомо оно больше не шьется, да и старым в общем то то же…
C:\Users\Leon\Desktop\MegaPiratePlane2.26_new\MegaPirateX>avrdude -Cavrdude.conf
-patmega2560 -cstk500v1 -P\\.\COM6 -b57600 -D -Uflash:w:MegaPirateX.hex:i
avrdude: stk500_getsync(): not in sync: resp=0x00
Чито делать однако?
За то в терминале весело бегут цифери 😃
Не хочет он со мной больше разговаривать… Решил обнулить, залил обратно 26 прошивку, но как не бился залить пиратХ так и не смог…
Заработало 😃 Видимо подвисла библиотека… после перезагрузки усе залилось 😃
А что клевый такой горизонт вышел 😃 Забавно смотреть в терминале что шлет платко, клевая лесенка выходит 😃
Олег а откуда беруться данные? С акселей или с гироскопов? Смотрю и ось YAW уже есть, компас или гирик?
Я тут тоже маленько выложу линку на шоу-версию альтернативной ГУЙни настройки и управления различными(ха-ха) АП. Смотреть лучше в полном экране.
Пока только общий концепт и несколько доступных приборов-индикаторов. Приборы накиданы как попало, только для того, чтоб показать их возможности. Запущен сценарий-симулятор. В реальности планирую подсистему, которая позволит в визуальном режиме пользователю связывать различные данные от Автопилота с нужными для пользователя приборами-индикаторами.
Выкладывать смысла нет никакого, ибо доступна только реализация тестового протокола, да и нет ещё реализованной вышеупомянутой подсистемы для связи inbound данных с индикаторами.