Создание собственной системы стабилизации
мысли вслух о вечном (хотелке мелкоплаты)
Тут как раз рекламка от Стшников пришла, STM32f301 в безногом корпусе.
STM32f301 в безногом корпусе
Там “безНОГ” мало.
ну мне тоже пришла, тут как бы хотелка не успевает за “конкурентами” Макс скинул ссыл на vr brain micro - 37Х37 и 100 лапый проц, будем бить функционалом, на 64-х лапом проце: 8 выходов, 1 вход (всё в одном) 1 порт gps 2 телеметрийеых не считая фрискин, i2c наружу, can - бездельник пока… RTC - можно делать/не делать, да, влазит сонар на этот раз хоть таймер, хоть прерывание, хоть ацп(а надо он вообще?)… пискун на таймере, 4 входа ацп, бомба 😃
только вот spi наружу нету ну и фиг с ним… в раздумьях - что влепить sd-шка мне одним нравиться: при убитом контроллере можно предсмертную записку прочитать без изобретения isp читальщика и выпаивания флеши…
Там “безНОГ” мало.
оно какбы хватает, но у них частота 72 и vdd 1.8 vdda, 1.6-3.3 лишний болезнь на задницу…
координаты могли скакануть метров на 200 (и больше).
По моим наблюдениям (практическим) у разных GPS чипов имеются различия в формате выходных сообщений, например в количестве цифр некоторых полей, а иногда это количество вообще “плавает” в зависимости от характера данных, таким образом сотворить универсальный парсер - дело очень непростое… , поэтому нет никакой гарантии что какая то прошивка будет работать с любой моделью GPS. (доверяй но проверяй).
глитчи GPS это аппаратная проблема или проблема в коде APM
С учетом того что в GPS чипе тупо работает такая же “прошивка”, причем может попасться разная у одинаковых моделей, запросто может быть чисто проблема модуля… Я тут, например, с SIM68 позанимался и понял что если углубляться в его внутренние настройки то ЭТО целая тема… в основном, как я понял, никто в эти дебри не лезет (?)…
ИТОГ: “Чёрная звезда”
не поделитесь алгоритмом удержания высоты по барометру?
А может ещё ключи от квартиры? (с)
всё просто: смешиваем с акселем в нужных пропорциях и пишем pid на газ, в вие, в арду - везде есть 😃
можно новичку ссылку где можно прочитать, зачем с аксеелм смешиваемся?
наверное для направленяи движения?
короче в краткой перспективе изменения такие как скорость (1 интегрирование) и изменение высоты - путь (2 интегрирование) берутся с акселя - да не есть хорошо, примешиваем через ab к ним тоже самое с баро - в долгосрочной перспективе и получаем как-бы что-то похожее на правду
int getEstimatedAltitude(void)
{
static int32_t baroGroundPressure;
static uint32_t previousT;
uint32_t currentT = micros();
uint32_t dTime;
int16_t error16;
int16_t baroVel;
int16_t accZ;
static int16_t accZoffset = 0;
static float vel = 0.0f;
static int32_t lastBaroAlt;
int16_t vel_tmp;
dTime = currentT - previousT;
if (dTime < UPDATE_INTERVAL)
return 0;
previousT = currentT;
if (calibratingB > 0) {
baroGroundPressure = baroPressureSum / (cfg.baro_tab_size - 1);
calibratingB--;
}
// pressure relative to ground pressure with temperature compensation (fast!)
// baroGroundPressure is not supposed to be 0 here
// see:
BaroAlt = logf(baroGroundPressure * (cfg.baro_tab_size - 1) / (float)baroPressureSum) * (baroTemperature + 27315) * 29.271267f; // in cemtimeter
EstAlt = (EstAlt * 6 + BaroAlt * 2) >> 3; // additional LPF to reduce baro noise
//P
error16 = constrain(AltHold - EstAlt, -300, 300);
error16 = applyDeadband(error16, 10); // remove small P parametr to reduce noise near zero position
BaroPID = constrain((cfg.P8[PIDALT] * error16 >> 7), -150, +150);
//I
errorAltitudeI += cfg.I8[PIDALT] * error16 >> 6;
errorAltitudeI = constrain(errorAltitudeI, -30000, 30000);
BaroPID += errorAltitudeI >> 9; // I in range +/-60
// projection of ACC vector to global Z, with 1G subtructed
// Math: accZ = A * G / |G| - 1G (invG is calculated in getEstimatedAttitude)
accZ = (accSmooth[ROLL] * EstG.V.X + accSmooth[PITCH] * EstG.V.Y + accSmooth[YAW] * EstG.V.Z) * invG;
if (!f.ARMED) {
accZoffset -= accZoffset >> 3;
accZoffset += accZ;
}
accZ -= accZoffset >> 3;
accZ = applyDeadband(accZ, cfg.accz_deadband);
// Integrator - velocity, cm/sec
vel += accZ * accVelScale * dTime;
baroVel = (EstAlt - lastBaroAlt) * 1000000.0f / dTime;
lastBaroAlt = EstAlt;
baroVel = constrain(baroVel, -300, 300); // constrain baro velocity +/- 300cm/s
baroVel = applyDeadband(baroVel, 10); // to reduce noise near zero
// apply Complimentary Filter to keep the calculated velocity based on baro velocity (i.e. near real velocity).
// By using CF it's possible to correct the drift of integrated accZ (velocity) without loosing the phase, i.e without delay
vel = vel * 0.985f + baroVel * 0.015f;
// D
vel_tmp = vel;
vel_tmp = applyDeadband(vel_tmp, 5);
vario = vel_tmp;
BaroPID -= constrain(cfg.D8[PIDALT] * vel_tmp >> 4, -150, 150);
return 1;
}
#endif /* BARO */
по вопросу реализации системы стабилизации - инерциалки,
от меня такое предложние
от ардупилота взять базовые библиотеки
AHRS DCM INS
из AHRS выкинуть существующую коррекцию центробежных ускорений по аирспиду и компасу, заменив их проекциями ускорений от INS на горизонт
в качестве контрольно - дублирующей системы, в плане эксперимента поробовать проекцию вектора 3д компаса на плоскости рола и питча для контроля “завала” основной системы
с гироскопами видится такая проблема если брать любимые mpu6000/6050 то если ставить чуйку побольше (вроде 600 град в сек) то при резких маневрах случается его зашкаливание, если ставить 2000 то измерения становятся грубые.
если говорить о разработке своей системы и программной и аппаратной по идее 6050 сейчас копейки стоят , можно и два и три штуки поставить и использовать их кластером и в режимах с разной чувствительностью.
причем под mPU есть два варианта использования - второй использование встроенного в MPU процессора ориентации (типа аппаратное ускорение)
команда разработчиков ардупилота отказалась от DMP алгоритма мотивируя это тем что при этом они не могут реализовать инерциалку, возможно наличие второго процессора позволило бы использовать прелести двух систем.
применительно к ардупилоту подключив через I2C вместо (или вместе) внешнего компаса дешевый сенсор от бесколекторного подвеса (MPU6050) вогнать его в режим DMP и если у него в этом алгоритме горизонт не валится при центробежных или линейных ускорениях - брать готовый горизонт и тянуть к нему горизонт основной системы, задействованной в решении инерциальной задачи.
Почему именно DCM? Вроде арду уже переориентируется на EKF -конечно не на APM а на Pixhawke…
to alexeykozin надо было с другого конца начать 😃
Попростому при длительных ускорениях >0.3g по осям X Y имеет место завал горизонта акселем, что и не мудрено т.к. вектор g смещается хотя аппарат находиться в горизонте, по сей причине “плывут” углы и горизонт рассчитывается неправильно, я нарисовал картинку простую, дабы было понятно о чём речь, и фильтр тут не поможет, тут как-то нужно из инерциалки отслеживать собственные (горизонтальные обзавём “инерциальная составляющая”) ускорения и корректировать по ним вектор: грубо мы можем (да оно впринципе и есть уже рассчитанное ) отнять от горизонтальной составляющей вектора инерциальную составляющую тем самым увидим приближенный к горизонтали вектор?
А может просто разделить понятие акробатику и вялые полеты с камерой, и уже в зависимости от человека задавать чувствительности гирика?
В погоне за универсальностью приходится всегда чем то жертвовать, Для акробатики и быстрых полетов по моему всякая инерциалка и гпс нафиг не нужны, там главное вообще тока чтоб гирик работал хорошо.
Дим тут как-бы на коптерах это не так выражено(в длительных пролётах только и то не забываем, что коптер наклоняется), а вот на самолях беда…
Ну я про что и говорю, например сделать какой нибудь предконфигуратор прошивки, для самика собирать отдельно с такими то параметрами датчиков, для верта и квадрика собирать с совершенно другими в зависимости от типов полетов. То есть подгонять датчики под конфиг, а потом уже прошивку прошивать и конфигурить на планере.
Открою страшную тайну: нет никакой ложки нет у нас гироскопов, у нас есть датчики угловых скоростей и акселерометр из которых с помощью комплиментарника или магии Калман и какой-то матери мы получаем что-то ооочень отдалённо напоминающее гироскоп 😦
Америку мне сейчас ты не открыл)))) Речь сейчас не об этом была, а о том что в каждом конкретном случае можно подстроить настройки датчиков под конкретный конфиг коптера, самолета, вертолета. Можно конечно по навешать кучу датчиков, усреднять. Но перед этим надо понять а надо ли оно? и зачем, для каких целей вообще? за буржуями гнаться, А стоит ли?
А как ты не настраивай датчики - это проблемы не решит 😦 углы рассчитанные с ДУС-ов всегда будут плыть (шум + интегрирование = ошибка)
коррекция по акселю - это когда висишь хорошо, а когда аппарат имеет собственные ускорения - трындец - в долгосрочной перспективе завал обеспечен 😦
А вопрос.Ведь существуют какие то спец точные гирофиговины,в военных ракетах типа Игла что стоит?
Вроде слышал что какой то лазерный супергироскоп.Может задуматься сотворить что то подобное?
Я предлагал поставить курсовертикаль механическую с электроприводом кг этак на 5-10 )))))))) в плату не лезет зараза)))
Да смешного тут мало - на рынке сейчас преобладают mems и со страшным Калманом - вопрос, а нет у них таких болячек? - Ответ: скорей всего есть:(
А вопрос.Ведь существуют какие то спец точные гирофиговины,в военных ракетах типа Игла что стоит? Вроде слышал что какой то лазерный супергироскоп.Может задуматься сотворить что то подобное?
Я когда то работал с лазерным гироскопом, хрень та еще.