Проект Мегапират на самик!
ха, вообще красота! codevision 2.05 вообще неправильно компилирует!
в проге при вызове ahrs происходит повреждение стека и ребут. на 1.25.3 все в норме.
Что и требовалось. Больше туда ни ногой.
ха, вообще красота! codevision 2.05 вообще неправильно компилирует!
в проге при вызове ahrs происходит повреждение стека и ребут. на 1.25.3 все в норме.Что и требовалось. Больше туда ни ногой.
Олег, а 1.25.3 знает про атМегу 2560?
П.С. Прикольно, если уже есть ahrs – значить ты достаточно давно начал тайный прожект ухода с Ардуино на КодеВижн? 😉
знает.
В любом случае, 1280 и 2560 полностью совместимы до 128 кБ
Кстати, с AHRS весь проект занимает 16кБ. Самая крупная часть после всего будет базовый протокол. 128кБ хватит с верхом.
Что самое противное, в ардупелоте после AP_ADC опять же оси датчиков перехреначены. Приходится “на глаз” заново настраивать.
“тайный уход” я начал, когда запостил тут, так что это целых 2 дня 😃
=======================================
Ну, вот как бы первый промежуточный этап окончен.
Что это:
- это “костяк” нашего автопилота в виде секвенсора процессов, обменник с КОМ-портом и инерциалка.
Что умеет: - в окне терминала на 57600 выводит roll pitch yaw и тайминг основного цикла в микросекундах
Как пользовать: - залить HEX, запустив avrdude.bat, поправив в файле номер ком-порта. можно колупнуть исходник на тему вывода чего-нибудь другого.
- важно при запуске держать плату ровно, т.к. калибровка акселя проходит каждый запуск (за неимением базы на компе)
- сконнектить терминал на 57600 (ардуинский, ардупланер, putty или из кодевижена) и смотреть.
dl.dropbox.com/u/63786348/mpx_preview.rar
Через пару дней ссылка будет недоступна.
- в окне терминала на 57600 выводит roll pitch yaw и тайминг основного цикла в микросекундах
Костя, накрапаешь на яве оболочку аля авиагоризонт для визуализации 😃?
погоди, тут прОтокол нужен
погоди, тут прОтокол нужен
Мавлинк 😄
Что думаешь по сие поводу? Что то стандартное, или самим просто договориться, что за чем передается?
мавлинк FUUUUU
у меня есть пара быстрых протоколов с самосинхронизацией в заначке 😉 распишу команды и можно делать.
Так… За неимением нужных познаний - я вам пока ничем помочь не могу… Сижу только читаю и мечтаю…
Ждем-с…
Олег.
Вопросик - АРС2хх поддерживаться будет? И Е-осд (а то коробочка так и не появилась - видать пипец ей приснился на бескрайних просторах Почтовой связи…)?
Кстати - управление АП будет как и раньше на одном канале с задаными цифрами мс? Может кол-во исполняемых команд на канал уменьшить с возможностью быстрой смены команд? типо - на трехпозиционнике три команды : стабилизация, РТФ, мануал… (через наземку меняем на другие три…). - это я о тех у кого нет пакетника на канале (у меня есть…).
П.С. Могу кидать идеи!!! может и банальные, но вдруг что прокатит😍…
Ну чем еще помочь???
Вопросик - АРС2хх поддерживаться будет? И Е-осд
конечно
Может кол-во исполняемых команд на канал уменьшить с возможностью быстрой смены команд? типо - на трехпозиционнике три команды : стабилизация, РТФ, мануал… (через наземку меняем на другие три…)
нифига не понял… впрочем, до команд еще далеко.
нифига не понял…
Не парься! Это я пытаюсь быть типо полезным…
Все кто с Вортексом на Мегапирате летал - проблему с переключением режимов АП уже решили (надеюсь…), поэтому эта идея не актуальна…
Тормознул…
Блокировку движка сразу в код заложи, а то запарился я контакты от движка каждый раз отстегивать…
Пока Олег строит АП с нуля, продолжаю мучать 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, переделанный на переменную длину. Сами команды выложу попозже.