Smalltim OSD and autopilot (часть 2)

baychi
Pavel_K:

т.е. подозрения не на глюк бутлоадера, а на процесс записи лога, так получается? но там ведь вроде как внешняя память…

Пока основная версия, слет вызывает отключение питания в момент обращения проца ко внейшней FLASHке (почему - отдельная загадка). Это происходит либо в начале работы (проц читает настройки и пишет их заново), либо во время записи лога. По крайней мере, при отключенной записи лога, если выключать питание через несколько секунд после включения (когда настройки уже считаны), прошивку сбить не удалось.
Но это разумеется полумера, так как вероятность дребезга во время включения питания (особенно втыканием разъемов) весьма велика.
Так-же не удалось сбить прошивку и при включенном логе, если перед отключением питания нажимать и удерживать Reset.

Остается выяснить у Тимофея вопрос с фьюзами BODLEVEL. Как они стоят и чем это проверить?
Или решать задачу аппаратно: ставить супервизор питания типа AD706 или на TL431 что-нить городить.
Лучше бы конечно программно… 😃

Федор_Иванович

Можно не в тему вопросик? 😉

Тимофей, Александр, или может кто еще в теме - подскажите, как самостоятельно рассчитать значение центробежного ускорения для ИМУ от Smalltim (без автопилота!)?

Делаю свой стабилизатор полета на базе этой ИМУ, в общем и целом все понятно и кое что даже работает, но вот эти центробежные ускорения не понимаю. Единственно, до чего дошел - взять скорость по GPS в м/с, по траектории от GPS взять (посчитать по точкам) радиус поворота в метрах и посчитать ускорение как “скорость в квадрате деленная на радиус”. Если это верно (а вообще это верно?) то за какой период времени надо брать траекторию движения? За 0,5 сек, 1 сек, 5 сек, 10 сек?

baychi
Федор_Иванович:

Единственно, до чего дошел - взять скорость по GPS в м/с, по траектории от GPS взять (посчитать по точкам) радиус поворота в метрах и посчитать ускорение как “скорость в квадрате деленная на радиус”. Если это верно (а вообще это верно?)

Это верно. Тимофей примерно так и делает, только скорость предпочтительнее брать воздушную. А вот деталей не подскажу. ИМХО, коль речь идет о мгновенном ускорении, лучше всего брать минимальное время.

ubd

Остается выяснить у Тимофея вопрос с фьюзами BODLEVEL. Как они стоят и чем это проверить?

А там на плате есть возможность подсоединить обычный программатор через SPI (SCK, MOSI, MISO)? Тогда можно легко посмотреть фузы.
И что там за проц? Обычная Мега 64 по моему?

А вообще не понятно, почему уже столько дней Темофей не появляется? Тут вот какие дебаты горячие… Глюк нашли мощный!

baychi
ubd:

А там на плате есть возможность подсоединить обычный программатор через SPI (SCK, MOSI, MISO)? Тогда можно легко посмотреть фузы.

Вы уверены, что можно посмотреть фьюзы, если стоит бит секретности?

ubd:

что там за проц?

AT90USB1287

ubd

Кстати, у меня надписи OSD не отбрасывают чёрную тень, и на фоне неба надписи не видны. Перемодуляции по видео нет, а вот перемодуляции по наложениею OSD, может есть. Но где это регулируется понятия не имею.

Биты секретности не защищают фузы. Можно защитить память программ, ЕЕПРОМ, но фузы всегда должна читаться.

Федор_Иванович
baychi:

Тимофей примерно так и делает, только скорость предпочтительнее брать воздушную.

Спасибо большое, а как понять, что правильно замеряно/посчитано? М.б. какой полетный тест порекомендуете?

RID
Pavel_K:

Что бы кто ни говорил, но FPV это не развлечение выходного дня, а сложная область, стоящая на переднем крае технического прогресса

Улыбнуло))). Это скорее первое, так как появился спрос на бюджетные решения и дешевая элементная база для удовлетворения этого спроса.😉
А до переднего края скакать и скакать…😃

baychi
Федор_Иванович:

а как понять, что правильно замеряно/посчитано?

Сравните поведение модели с компенсацией центробежных и без. Должно стать лучше.
Ведь далеко не все IMU используют эту компенсацию, только самые продвинутые. 😃

Федор_Иванович:

М.б. какой полетный тест порекомендуете?

Можно такой: rcopen.com/forum/f90/topic289242/2

msv

Без компенсации центробежки никак… При полете по кругу в активном вираже крен со временем будет показывать близким к нулю, соответственно система стабилизации в итоге неизбежно свалит самолет. Проверил… 😃 Скорость нужна именно относительно земли. Идеально бы знать вектор скорости вдоль оси самолета, но ее честно никак не измерить, поэтому довольствуются GPS- скоростью.

baychi
msv:

Скорость нужна именно относительно земли. Идеально бы знать вектор скорости вдоль оси самолета

Почему относительно земли? Модель же относительно воздуха движется.

msv:

Без компенсации центробежки никак

Фишка вон летает. 😃
И я не уверен, что Иглы используют компенсацию.

msv

Самолет летит относительно воздуха, аксель - относительно земли. 😃 Ему все равно чем вызвано ускорение в повороте- большой линейной скоростью скоростью за счет попутного ветра или мощного движка.

baychi:

Фишка вон летает.

Что у нее на уме, похоже никто не знает… 😃
Жаль не сохранил видео полета своей IMU с выключенной коррекцией…

baychi
msv:

Самолет летит относительно воздуха, аксель - относительно земли

Представьте себе восходящую часть мертвой петли или начало выхода из пике. Горизонтальная скорость относительно земли близка к 0, а ускорение - отнюдь! Или представьте себе полет по окружности малого радиуса. Ускорение постоянно, скорость отн. воздуха тоже. Относительно земли - скорость зависит от ветра. Добавьте ветер и получите синусоиду скорости отн. земли. А ускорение то не меняется. 😃

msv:

Что у нее на уме, похоже никто не знает.

В 20 и 30-й GPS не предусмотрен. В 21/31 есть, но что-то мне подсказывает, что алгоритм их не учитывает.

msv:

Жаль не сохранил видео полета своей IMU с выключенной коррекцией…

Первые варианты IMU SmallTim не учитывали центробежки. И картинка горизонта на тестах была как у Фишки.

Sergiv
Федор_Иванович:

Тимофей, Александр, или может кто еще в теме - подскажите, как самостоятельно рассчитать значение центробежного ускорения для ИМУ от Smalltim (без автопилота!)?

В документации вот что написано:

КОРРЕКЦИЯ ЦЕНТРОБЕЖНЫХ УСКОРЕНИЙ
IMU при работе с автопилотом поддерживает работу без коррекции центробежных ускорений, и два варианта
коррекции: по данным от модуля GPS и по угловым скоростям модели и скорости модели в воздухе.
Коррекция центробежных ускорений абсолютно необходима при использовании IMU на моделях самолетов,
поскольку любой маневр модели сопровождается возникновением продольных, вертикальных и боковых
ускорений. Эти ускорения искажают работу акселерометров, в результате чего, без компенсации этих
искажений, рассчитанные IMU углы ориентации модели могут сильно отличаться от фактических углов
ориентации модели.
Коррекция центробежных ускорений по данным GPS – базовый метод коррекции центробежных ускорений,
применяемый по умолчанию. При использовании этого метода автопилот рассчитывает угловую скорость
модели по курсу как разницу между текущим курсом по GPS и курсом по GPS из предыдущего сообщения от
модуля GPS, и, умножая ее на величину скорости по GPS, получает величину центробежного ускорения.
Рассчитанная величина центробежного ускорения передается на IMU по приходу каждого нового сообщения от
модуля GPS.
Этот метод коррекции центробежных ускорений обеспечивает хорошие результаты, но имеет ряд очевидных
недостатков.
Во-первых, из-за принципа получения угловой скорости по GPS коррекция центробежных ускорений
запаздывает по времени на величину, равную временному интервалу между сообщениями от модуля GPS,
обычно 0.1 или 0.2 сек (для 10 Гц и 5 Гц модулей GPS).
Во-вторых, модули GPS, как правило, имеют встроенные алгоритмы подавления шумов по координатам,
скорости и направлению движения, неизбежно вносящие временную задержку между фактическим
изменением курса и изменением курса, выдаваемым модулем GPS.
В-третьих, при небольших скоростях по GPS, например, при полете против сильного ветра, точность вычисления
центробежных ускорений снижается.
Наконец, при использовании коррекции по данным GPS учитывается только горизонтальная составляющая
центробежного ускорения, чего вполне достаточно для спокойных непилотажных полетов, но может вызывать
заметные ошибки определения ориентации модели при активном пилотаже, например, выполнении петель,
когда присутствует большая вертикальная составляющая центробежного ускорения.
Типичный результат применения коррекции центробежных ускорений по данным GPS выглядит таким образом:
модель начинает резкий маневр, например, разворот на 180 градусов с креном вправо. IMU корректно
показывает начальное изменение ориентации модели. Через долю секунды появившееся центробежное
ускорение искажает показания IMU и угол крена, вычисленный IMU, оказывается несколько заниженным. Через
0.2 – 0.5 секунды поступает информация о наличии центробежного ускорения, и IMU начинает производить
коррекцию, выдавая корректный угол крена вплоть до окончания маневра. После окончания маневра модель
занимает горизонтальное положение. IMU, по-прежнему, производя коррекцию центробежных ускорений,
показывает небольшой крен в сторону, противоположную крену при маневре. Через 0.2 – 0.5 секунды
приходит информация об отсутствии центробежных ускорений и IMU начинает вновь корректно рассчитывать
угол крена.
Эти небольшие погрешности не накапливаются и практически не влияют на устойчивость работы автопилота, но
могут вызывать заметные на глаз отличия положения линии искусственного горизонта от линии горизонта в
кадре видеокамеры.
Коррекция центробежных ускорений по данным бародатчика скорости и данным датчиков угловых скоростей
обеспечивает гораздо более точную компенсацию центробежных ускорений и в результате граздо более точный расчет углов ориентации модели. При использовании этого метода коррекции IMU предполагает, что
модель движется в воздухе в том направлении, в котором она ориентирована, то есть, отсутствует заметное
скольжение, способное сильно исказить результаты расчета.
При применени этого метода, во-первых, рассчитываются все компоненты центробежных ускорений, а не
только горизонтальная составляющая, во-вторых, отсутствует задержка в компенсации центробежных
ускорений. Поэтому при наличии корректно работающего датчика воздушной скорости рекомендуется
использовать именно этот метод коррекции центробежных ускорений.

взято от сюда: shevaaviator.ru/wp-content/…/IMU_manual_1-1.pdf

msv
baychi:

Представьте себе восходящую часть мертвой петли…

Представим теоретическую ситуацию, ветер равномерно меняет направление и синхронно модель, летящая с скоростью ветра, поворачивает против ветра. Линейная скорость относительно земли всегда ноль (самолет висит над одной точкой), и ускорения никакого нет. Воздушная -есть.
Да, скорость GPS не учитывает вертикальных составляющих ускорений, но для фпв более характерны полеты в горизонте, и ситуация полета против и по ветру ( на виражах будут совершенно разные ускорения при одинаковой воздушной скорости) более жизненны, чем петли… В идеале конечно нужна скорость относительно земли вдоль оси самолета, но такой прибор имхо пока не изобрели…

baychi
msv:

модель, летящая с скоростью ветра, поворачивает против ветра. Линейная скорость относительно земли всегда ноль (самолет висит над одной точкой), и ускорения никакого нет. Воздушная -есть.

Мы компенсируем ЦЕНТРОБЕЖНЫЕ УСКОРЕНИЯ, а они возникают от поворота и зависят только от скорости поворота и его радиуса.
Представьте себе что Земли нет. Мы в глубоком космосе. Разве от этого ускорения отменяются? 😃

smalltim

Коллеги, я не отдыхаю уже, включаюсь в повседневный ритм.

Коллеги, про слет прошивок и питание я уже подробно описывал, но это было давно и, похоже, было не так актуально.
Опишу еще раз, тем более, что появились новые мысли.

На старте АП при подаче питания прошивка не слетает. Несмотря на медленное поднятие напряжения питания (специально сделан плавный старт импульсника) ничего такого не происходит. Почему, станет понятно после следующих абзацев.

Прошивка может повреждаться именно при отключении питания. Происходит это из-за включенной записи логов, и объясняется следующим:

Флешка под логи работает в страничном режиме, по 528 байт. Если проц в какой-то момент хочет записать лог в память, то он считывает страницу, обновляет ее часть, и записывает обратно во флешку. Так вот, если в момент попытки записать данные в лог отключить питание, то проц может успеть стартануть процесс чтения страницы и начать притухать или отресетиться из-за падения напряжения питания.
Флешка в этот момент продолжает лить в проц данные (до 528 байт) через интерфейс SPI, а это, при условии, что процессор находится в состоянии ресета, соответствует режиму программирования процессора. В итоге флешка вливает мусор в проц и прошивка портится.

BOD биты в проце стоят по дефолту, 011, что соответствует 2.6В. Флешка, по всей видимости, сохраняет работоспособность при меньшем напряжении питания, и исправно гонит данные в проц.

Решений проблемы может быть несколько:

  1. Поднять BOD Level до 4В и выше. Через DFU программатор это никак не делается, только отдельным внешним программатором. Я посмотрю, можно ли заставить телеметрию ввести проц АП в режим программирования и обновить процу BOD биты.

  2. Поставить аппаратный формирователь ресета. На новом железе так и сделано, но оно не выпускается пока.

  3. Переделать алгоритм работы с флешкой, чтобы минимизировать или вовсе исключить вероятность жизни флешки собственной жизнью, пока проц полуживой после отключения питания.
    Я как раз сейчас подумал, что при записи логов можно не считывать страницу памяти, всё равно она будет целиком перезаписана.
    Обязательно изменю это и отправлю на проверку baychi, у него, как раз, “вредный” экземпляр АП.

В худшем случае при отключении питания пропадет страница с последними записями - несколько секунд работы АП.

Как временную меру сейчас можно отключить запись логов в Контрольной Панели, это практически убирает вероятность слета прошивок.

Федор_Иванович:

как самостоятельно рассчитать значение центробежного ускорения для ИМУ от Smalltim (без автопилота!)?

Линейную скорость в метрах в секунду умножайте на угловую скорость в радианах в секунду, получите величину ускорения.
Линейная скорость - скорость относительно земли по ГПС.
Угловая скорость - курс по ГПС сейчас минус курс по ГПС секунду назад, это надо перевести в радианы.

У меня ГПС 5-герцовый, поэтому я считаю сейчас минус 200 миллисекунд назад.

baychi
smalltim:

BOD биты в проце стоят по дефолту, 011,

Ты уверен? Проверял? А то в некоторых даташитах написано, что по дефолту там стоят 111 - BOD отключен. А в других 100. 😃

smalltim:
  1. Поставить аппаратный формирователь ресета.

Ясно. Как раз нашел AD706S с порогом в 2.93 В. Буду колхозить. Там кнопка ресета к +5 В подвешена внешним резистором или тока внутренним?
RESET флэешки с ресетом проца объединен, надеюсь?

msv
baychi:

Представьте себе что Земли нет. Мы в глубоком космосе. Разве от этого ускорения отменяются?

Александр, забавно, но именно этот пример, чуть ли не дословно хотел привести в доказательство своей правоты… 😃 Действительно был неправ, привязывая скорость к земле, а подразумевая некую инерциальную систему координат в не слишком искривленном пространстве… 😃 Для центробежного (ну строго говоря центростремительного…) ускорения не нужен воздух, не нужна земля, нужно только изменение направления линейной скорости. Как уже написал Тимофей, нехитрыми преобразованиями получаем: a=W^2*r; r=V/W; итого a=W*V;
Получается что по ветру V будет больше и, при той-же скорости поворота, ускорение будет больше…
Странно, почему Тимофей так сложно считает скорость поворота, ведь она в явном виде получается от гироскопа.
И даже самые старые алгоритмы банального DCM именно так корректирует центробежку…

baychi
msv:

Странно, почему Тимофей так сложно считает скорость поворота, ведь она в явном виде получается от гироскопа

Мне тоже странно. Тем более в КП это режим так и называется: коррекция по ДУС и воздушной скорости. 😃

smalltim:
  1. Поднять BOD Level до 4В и выше.

Это не поможет, если это верно.

smalltim:

при условии, что процессор находится в состоянии ресета, соответствует режиму программирования процессора.

Процу нужен порог ниже флешкиного.

Pavel_K
smalltim:

Флешка в этот момент продолжает лить в проц данные (до 528 байт) через интерфейс SPI, а это, при условии, что процессор находится в состоянии ресета, соответствует режиму программирования процессора. В итоге флешка вливает мусор в проц и прошивка портится.
… Как временную меру сейчас можно отключить запись логов в Контрольной Панели, это практически убирает вероятность слета прошивок.

Глюк найден, это радостно, теперь хоть понятно почему и отчего это происходит. Значит с логом пока летаем только в тестовых полётах и ждём полноценного решения (повторюсь - многим и вариант паяльником памахать подойдет, так что если будет опубликовано промежуточное решение такого рода - будем и ему рады).