Проект Мегапират на самик!
на нем буду заливать,
заливать можно, насколько я знаю, на любой машине. только кодевижон дурит под х64, до версии 2.04
Поставь себе последнюю версию, может, проканает?
юзаю 1.25.3 с 2007 года. Попытки перейти на более новые версии приводят к изменению скорости выполнения в ту или иную сторону.
Эм… не вылезет чудес?
ты же не собрался автопилот с нуля писать? 😉
а лампочкой поморгать и так сойдет.
А я буду выкладывать сразу “православные” НЕХы.
Ну, и код по желанию.
Ну рано или поздно захочется и от себя что нить впендюрить 😉
ха, вообще красота! 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 калмана? 😉