Создание собственной системы стабилизации
F4BY можно допилить драйвер GPS что бы он писал на SD все поступающие данные.
что-то крутящееся в фоне слушающее порт и пишущее отдельный лог 5 раз в секунду - где-то в недрах NuttX? блин мне антенна нада, запустил бы навиа - посмотрел, а то на 3329 у меня ошибок нет…
ЖПС данные, глитч, ничего, фикс глитча и опять жпс данные. если бы между ERR, 11, 2 ERR, 11, 0 была строчка с жпс данными - тогда нормально.
Макс выкинь преобразователь уровней и диод по питанию на GPS закороти - оно нам не надо…
что-то крутящееся в фоне слушающее порт и пишущее отдельный лог 5 раз в секунду - где-то в недрах NuttX? блин мне антенна нада, запустил бы навиа - посмотрел, а то на 3329 у меня ошибок нет…
Да не, просто в драйвере GPS самого арду, писать в лог, все что он получает на входе (грубо говоря, получил байт - записал его в лог и отдал парсеру). Ну или например какой нить хук повесить на сериал порт в Nuttx - не знаю, возможно ли такое.
блин мне антенна нада
Какая?
патч на GPS/Glonass - где-то в Минске видел контору недалеко от ЦУМа, а название забыл…придётся у китайцев покупать…
Макс выкинь преобразователь уровней и диод по питанию на GPS закороти - оно нам не надо…
Оно и не мешает. Я поднял питание до 6 вольт.
патч на GPS/Glonass
Ну, на ГПС нашел бы, а на Глонас - не уверен:)
Дринкер получил микрухи для цветной осд. Себестоимость аж 10баксов. Сможет ли он набрацца терпения запаять обвес?
Есть прогресс? И что за микрухи?
поБЕДА - serVICE
мысли вслух о вечном (хотелке мелкоплаты)
Тут как раз рекламка от Стшников пришла, 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 смещается хотя аппарат находиться в горизонте, по сей причине “плывут” углы и горизонт рассчитывается неправильно, я нарисовал картинку простую, дабы было понятно о чём речь, и фильтр тут не поможет, тут как-то нужно из инерциалки отслеживать собственные (горизонтальные обзавём “инерциальная составляющая”) ускорения и корректировать по ним вектор: грубо мы можем (да оно впринципе и есть уже рассчитанное ) отнять от горизонтальной составляющей вектора инерциальную составляющую тем самым увидим приближенный к горизонтали вектор?
А может просто разделить понятие акробатику и вялые полеты с камерой, и уже в зависимости от человека задавать чувствительности гирика?
В погоне за универсальностью приходится всегда чем то жертвовать, Для акробатики и быстрых полетов по моему всякая инерциалка и гпс нафиг не нужны, там главное вообще тока чтоб гирик работал хорошо.