Вопросы по iNav
Пробывал Failsafe, что то не пошел. Пару секунд болтался в воздухе а потом резко в низ. В CLI были заданы параметры: rxfail 3 h
set failsafe_procedure = RTH
Может я что то забыл ?
Без лога трудно сказать. Похоже на активацию аварийной посадки. Возможно при Failsafe-RTH в двух случаях - или взлет с nav_extra_arming_safety=OFF до того как был пойман фикс (т.е. нет координат дома), или потеря GPS в полете в момент активации Failsafe-RTH
бсуждаем инерциалку тут rcopen.com/blogs/83206/21544
в том числе и лаги/задержки и т.д… возможно вам будет интересно…
и да если кратко, то задержка вырисовывается в 200-400мс…
Почитал, в целом интересно, но ничего особо нового в обсуждении не нашел. Откопал антикварную Crius SE, вроде живая. Как бы ваш код потестить?
Почитал, в целом интересно, но ничего особо нового в обсуждении не нашел.
В обсуждении там был момент, про raw вектор скорости от гпс и использование его в ИНС. Из описания пакетов НМЕА протокола можно получить только линейную скорость, но получать из нее вектор скорости по углу из IMU не оч. красиво т.к. это данные разных моментов времени (подробности тут).
У вас в коде вроде видел использование RAW вектора в ИНС, cоот-но вопрос откуда он? 😃 NEO-8 отдает вектор скорости?
Откопал антикварную Crius SE, вроде живая. Как бы ваш код потестить?
в этот контроллер не влезет… нужен контроллер (либо ардуина) с атмегой 1280/2560 + mpu6050 + ms5611…
это данные разных моментов времени
Совершенно верно, скорость отстает от координат секунд на 3-5. Скорость относительно земли мой position estimator не использует.
У вас в коде вроде видел использование RAW вектора в ИНС, cоот-но вопрос откуда он? NEO-8 отдает вектор скорости?
Отдает когда с ним “разговариваешь” используя двоичный протокол Ublox. Скорость есть в сообщениях NAV-VELNED (Neo6) или NAV-PVT (Neo7+). Задержки по отношению к координатам я не заметил, похоже это данные из одного момента времени.
в этот контроллер не влезет… нужен контроллер (либо ардуина) с атмегой 1280/2560 + mpu6050 + ms5611…
Есть Arduino Mega и плата с MPU6050 и BMP180 на борту. Заработает?
Отдает когда с ним “разговариваешь” используя двоичный протокол Ublox. Скорость есть в сообщениях NAV-VELNED (Neo6) или NAV-PVT (Neo7+). Задержки по отношению к координатам я не заметил, похоже это данные из одного момента времени.
Ну да, я и имел ввиду бинарный u-blox протокол когда про neo-8 спрашивал.
Полезная информация, спасибо. Жаль у меня u-blox модуля нет на данный момент что бы поиграться 😃
Есть Arduino Mega и плата с MPU6050 и BMP180 на борту. Заработает?
По идее запустить можно, но у BMP180 по паспорту точность почти в 10 раз ниже в сравнении с ms5611 на сколько помню. Соот-но удержание высоты будет не то + лаг в ИНС настроен на ms5611… но попробовать можно.
Скиньте мне в личку email
Ну да, я и имел ввиду бинарный u-blox протокол когда про neo-8 спрашивал.
Полезная информация, спасибо. Жаль у меня u-blox модуля нет на данный момент что бы поиграться
Данные скорости на Neo6/Neo7 у меня дают противоречивые результаты (может, потому что модули китай-клонированные), поэтому у меня по-умолчанию используется производная координат. Когда используешь скорость - результаты лучше.
По идее запустить можно, но у BMP180 по паспорту точность почти в 10 раз ниже в сравнении с ms5611 на сколько помню. Соот-но удержание высоты будет не то + лаг в ИНС настроен на ms5611… но попробовать можно.
Да, BMP180 дрейфует гораздо больше. Но на высотах 5-10м это не критично 😃
Скиньте мне в личку email
Отправил
EDIT: По вашему совету убрал в качестве теста фильтрацию с барометра, оставил только 3-точечную медиану для фильтрации единичных ошибок (иногда бывают у BMP085/BMP180) и уменьшил вес барометра при слиянии с акселем. Полетело лучше, собственно и не удивительно, задержка данных с барометра уменьшилась в несколько раз (3-4 по прикидкам).
вроде как нашел багу в гпс глитч детекторе…
Сообщение от Andy Durin
Как дела с самолетной частью? Хочу на своем “ренжере” с СС3Д запытать. ГПСка какая-то есть.
Вроде работает. По крайней мере мой тезка dollop успешно облетал как раз на CD3D
Тоже интересна самолетная часть! Можно на CC3D сделать стабилизацию, возврат по FS и по команде?
вроде как нашел багу в гпс глитч детекторе…
Благодарю! Пофиксю в скором времени.
Тоже интересна самолетная часть! Можно на CC3D сделать стабилизацию, возврат по FS и по команде?
Можно! Настройка FS может быть не вполне тривиальна, но если все правильно настроить, то должно работать.
вроде как нашел багу в гпс глитч детекторе…
Вроде пофиксил, спасибо.
Взлетаете в режиме удержания высоты? Тогда не удивительно, “целевая” высота запоминается при активации режима удержания высоты, а не при арминге. Об этом я не подумал, приделаю сброс целевой высоты/позиции при арминге.
Сегодня попробовал армить, дизармить, переключать режимы туда-сюда - высота не сбрасывается, как уплыла при включении, так и держится. Помогает только перезагрузка контроллера. Пробовал на прошивке iNav 1.0.1
Сегодня попробовал армить, дизармить, переключать режимы туда-сюда - высота не сбрасывается, как уплыла при включении, так и держится. Помогает только перезагрузка контроллера. Пробовал на прошивке iNav 1.0.1
Это потому, что еще никаких исправлений в коде не было 😁
Высота сбрасываться и не будет, сброс будет касаться “целевой” высоты, на которую котроллер будет ориентироваться при взлете.
Я делаю калибровку баро в ноль до арма. В принципе удобно, дизарм-арм и новый ноль высоты установлен.
Я делаю калибровку баро в ноль до арма. В принципе удобно, дизарм-арм и новый ноль высоты установлен.
Тоже вариант. Я еще думаю какой предпочесть. С одной стороны калибровка баро в ноль до момента арма - это никаких изменений логики работы альтхолда, с другой есть и платформы GPS-онли - самолеты.
Ну а для самиков, просто оффсет гпс высоты обновить до арма. Нет?
Ну а для самиков, просто оффсет гпс высоты обновить до арма. Нет?
Я все-таки оставлю высоту в покое а сбрасывать при арме буду целевую высоту, если АльтХолд включен.
Это потому, что еще никаких исправлений в коде не было 😁
Высота сбрасываться и не будет, сброс будет касаться “целевой” высоты, на которую котроллер будет ориентироваться при взлете.
Всё равно непонятная логика удержания высоты получается, вот в чём проблема : я армлю квадрик в режиме HORIZON, стик газа внизу до упора, квадрик стоит на столе, переключаю режим в NAV ALTHOLD и ПК тут же даёт моторам 50% газа, если ничего не трогать в таком положении то газ сбрасывается до 45% секунд через 10, переключаюсь обратно в HORIZON и моторы снова на минимальном газу. Это нормальная логика работы при минимальном положении газа? ведь получается как только я включаю удержание высоты и он пытается неконтролируемо взлететь и посадить я его не могу, потому что газ то у меня и так на минимуме. (ПК SP RF3, iNAV 1.0.1)
Всё равно непонятная логика удержания высоты получается, вот в чём проблема : я армлю квадрик в режиме HORIZON, стик газа внизу до упора, квадрик стоит на столе, переключаю режим в NAV ALTHOLD и ПК тут же даёт моторам 50% газа, если ничего не трогать в таком положении то газ сбрасывается до 45% секунд через 10, переключаюсь обратно в HORIZON и моторы снова на минимальном газу. Это нормальная логика работы при минимальном положении газа? ведь получается как только я включаю удержание высоты и он пытается неконтролируемо взлететь и посадить я его не могу, потому что газ то у меня и так на минимуме. (ПК SP RF3, iNAV 1.0.1)
На данный момент - это нормальная логика работы: арм есть, квадрик “летит” по мнению ПК, после включения удержания высоты происходит переход в режим “висение”, в качестве базового газа используется nav_mc_hover_th (1500 по умолчанию). Поскольку стик газа на минимуме - коптер пытается лететь вниз, и уменьшает скорость моторов.
Если бы квадрик не стоял на столе а действительно летел, он бы полетел вниз.
В режиме удержания высоты стик газа контролирует не газ, а вертикальную скорость (с висением на 50% газа). В планах доработка режима для комфортного взлета в режиме удержания высоты.
На данный момент - это нормальная логика работы
Теперь понятно, спасибо ) Просто я думал что для идентификации “полёта” недостаточно одного лишь арминга, а надо чтобы и газ был больше минимального положения.
Теперь понятно, спасибо ) Просто я думал что для идентификации “полёта” недостаточно одного лишь арминга, а надо чтобы и газ был больше минимального положения.
Идентификация полета это вообще беда - нет однозначного критерия по которому можно сказать - “оно летит”. Приходится предполагать что “оно летит” всегда 😁
релиз то когда ожидается?
Очередной релиз - к маю
1.1-RC1 - где-то к концу недели
Я все-таки оставлю высоту в покое а сбрасывать при арме буду целевую высоту, если АльтХолд включен.
не совсем понял идеи… что значит сбросить целевую высоту?
армлю квадрик в режиме HORIZON, стик газа внизу до упора, квадрик стоит на столе, переключаю режим в NAV ALTHOLD и ПК тут же даёт моторам 50% газа
На данный момент - это нормальная логика работы: арм есть, квадрик “летит” по мнению ПК, после включения удержания высоты происходит переход в режим “висение”, в качестве базового газа используется nav_mc_hover_th (1500 по умолчанию). Поскольку стик газа на минимуме - коптер пытается лететь вниз, и уменьшает скорость моторов.
Так в принципе это решается диапазоном работы пид регуля в альтхолде, т.е. если середина это висение и стик газа в верхнем/нижнем положениях соот-т макс. скоростям с разными знаками, то на макс. отриц. скорости пид регуль должен давать примерно мин_газ + делта (и это без И-части пид регуля), где дельта (=50-100) для стабильности на спусках для маневров по ролл питч. Т.е. при активитованном альтхолде и стике газа в нижнем положении газ будет всего на 50-100 единиц выше минимального разрешенного.
В режиме удержания высоты стик газа контролирует не газ, а вертикальную скорость (с висением на 50% газа). В планах доработка режима для комфортного взлета в режиме удержания высоты.
тут два момента: мин. газ (как писал выше) и детектор воздушной подушки, где без него будет дергаться (на медленном) взлете и посадке, т.к. пропы надувают давление около земли в эквивалент -(3-5) метров и чем ближе пропы к земле, тем сильнее еффект. У меня коптеры обычно без ног, потому эффект по макс. идет…
Но фича удобная. Я без альтхолд уже и не летаю, т.е. и взлет и посадка, все в этом режиме…
Идентификация полета это вообще беда - нет однозначного критерия по которому можно сказать - “оно летит”. Приходится предполагать что “оно летит” всегда
Я перебрал кучу вариантов и остановился на этом:
// depends on range of I part. varioErrorIPart reach this if we landed (see applyPIDControl() for details).
// Here -10 value to ignore vibro fluctuations.
#define VARIO_ERROR_I_PART_LAND_BOUND (VARIO_ERROR_I_PART_MAX - 15)
#define TIME_TO_CATCH_RAW_GROUND_ALT 100 // in ms
#define TIME_TO_BE_SHURE_DRONE_LANDED 3000 // in ms
bool groundRawAltSet = false;
uint32_t landDetectorStartTime;
uint32_t timeOnLand;
void runLandDetector() {
// detect whether we have landed by watching for low climb rate and VARIO_ERROR_I_PART_LAND_BOUND
bool landDetected = (abs(alt.estVario) <= 15) && (varioErrorIPart < -VARIO_ERROR_I_PART_LAND_BOUND)
&& (alt.estAlt < SAFE_NAV_ALTITUDE);
if (landDetected) {
timeOnLand = millis() - landDetectorStartTime;
} else if (!takeOffInProgress) { // don't reset until takeoff in progress
// we've detected movement up or down so reset land detector
landDetectorStartTime = millis();
timeOnLand = 0;
groundRawAltSet = false;
}
// protect to update groundRawAlt to keep 1st registration of ground altitude after 100ms, until reset, i.e. landDetected=false
if (!groundRawAltSet && (timeOnLand >= TIME_TO_CATCH_RAW_GROUND_ALT)) {
groundRawAltSet = true;
alt.groundRawAlt = alt.rawAlt;
}
}
// true if groundRawAlt is set and ground detected for at least TIME_TO_CATCH_RAW_GROUND_ALT
bool isGroundDetected() {
return groundRawAltSet;
}
bool isLanded() {
return groundRawAltSet && (timeOnLand >= TIME_TO_BE_SHURE_DRONE_LANDED);
}
т.е. основной критерий детектора это скорость у нуля и что бы И-часть пид регуля сползла в предельный низ, где диапазон И-части +/-250… + доп. условие что мы ниже опред-й высоты, но это для подстраховки и расчитано на равнинный ландшафт… ну и далее запускаем таймер, где каждая проверка в итерации должна говорить, да это земля, иначе сброс таймера… для не критических обработчиков (на основе этого детектора), достаточно 100-300мс (быстро-детектор), для критических (типа дизарм 3-5 сек)…
п.с. быстро-детектор используется для определения момента взлета + в ИНС что бы не наглотаться ложной высоты, т.е. корректор не будет брать высоту ниже “пойманной” высоты земли alt.groundRawAlt…
void correctZStateWithBaro(float* dt) {
// calculate error in position/vario from baro with our estimate
// reduce effect of air-cushion, i.e. influence of alt.rawAlt on take off and landing,
// because baro altitude value is dropped for 3-5m near the ground, i.e. it's not correct
bool isAirCushionEffectDetected = isGroundDetected() && (alt.rawAlt < alt.groundRawAlt);
float posError = (isAirCushionEffectDetected ? alt.groundRawAlt : alt.rawAlt)
- histZPosition[histZCount];
float varioError = ((isAirCushionEffectDetected && (alt.rawVario < 0)) ? 0.0f : alt.rawVario)
- histVario[histZCount];
/* !!! history z-position/vario and raw alt/vario baro values should be at the same phase
* i.e. looks the same on chart and depends on HIST_Z_POINTS !!! */
//debug[0] = histZPosition[histZCount];
//debug[1] = alt.rawAlt;
//debug[2] = histVario[histZCount];
//debug[3] = alt.rawVario;
ins.velocityEF[ALT] += varioError * (INS_Z_VEL_FACTOR * *dt);
ins.positionEF[ALT] += posError * (INS_Z_POS_FACTOR * *dt);
}