Гироскопы и кватернионы

D.k.> Можно и так
D.k.> Б.Г. вроде в этой теме разбирается, может чего и прояснит.

ну а что тут прояснять?
В кватернионе 4 компонента, действительная называется скаляр, мнимая - три числа - называется вектор.
Угловая скорость, получаемая с гироскопа, это тоже вектор, т.е., если рассматривать, как кватернион, у него нулевая скалярная часть.
Я использовал 32-разрядное представление с фиксированной десятичной точкой формата 2.30. Поскольку кватернион, используемый для описания ориентации, должен иметь модуль, равный 1, то такое представление выгоднее, чем плавающая точка с одинарной точностью, потому что там в мантиссе 24 бита, а у меня 30 бит.
Соответственно, единица - это число 0х40000000, или 2³⁰ . Минус единица - 0xc0000000.
Всё, что нужно сделать, считав данные с гироскопа, это помножить их на константу, потому что в кватернионах не могут фигурировать градусы, а только радианы, а ещё в кватернионах фигурируют половинные углы, т.е. при повороте на 360 градусов кватернион 1,0,0,0 перейдёт в кватернион -1,0,0,0, а период у кватерниона 720 градусов, или 4*пи.
Интегрирование угловых скоростей в кватернионах - это домножение текущего кватерниона ориентации, начиная со стартовой позиции, на вектор, получаемый с гироскопа после умножения на эту константу.
Формулу я чуть раньше приводил.
Но, чтобы из кватерниона вычленить сигналы, которые нужно подать на рулевые машины, его придётся "разложить" на три отдельных поворота по тангажу, рысканию, и крену.

Когда-то разбирался, сделал даже какую-то библиотеку работы с ними

//========================================//
//            Квантернионы                //
//========================================//
type TQuaternion=record
                 w,x,y,z:Extended;
                 end;

//--Умножить кватернион на скаляр
procedure MultQuatKf(A:TQuaternion;kf:Extended;var X:TQuaternion);
begin
X.w:=A.w*kf;X.x:=A.x*kf;X.y:=A.y*kf;X.z:=A.z*kf;
end;

//--Умножить кватернион на кватернион
procedure MultQuat(A,B:TQuaternion;var X:TQuaternion);
begin
X.w:=A.w*B.w-A.x*B.x-A.y*B.y-A.z*B.z;
X.x:=A.w*B.x+A.x*B.w+A.y*B.z-A.z*B.y;
X.y:=A.w*B.y-A.x*B.z+A.y*B.w+A.z*B.x;
X.z:=A.w*B.z+A.x*B.y-A.y*B.x+A.z*B.w;
end;

//--Скалярное произведение кватернионов
function MultScalQuat(A,B:TQuaternion):Extended;
begin
Result:=A.w*B.w+A.x*B.x+A.y*B.y+A.z*B.z;
end;

//--Сложить кватернион с кватернионом
procedure AddQuat(A,B:TQuaternion;var X:TQuaternion);
begin
X.w:=A.w+B.w;X.x:=A.x+B.x;X.y:=A.y+B.y;X.z:=A.z+B.z;
end;

//--Модуль кватерниона
function ModQuat(A:TQuaternion):Extended;
begin
Result:=Sqrt(Sqr(A.w)+Sqr(A.x)+Sqr(A.y)+Sqr(A.z));
end;

//--Сопряжение кватерниона
procedure ComplQuat(A:TQuaternion;var X:TQuaternion);
begin
X.w:=A.w;X.x:=-A.x;X.y:=-A.y;X.z:=-A.z;
end;

//--Норма кватерниона
function NormQuat(A:TQuaternion):Extended;
begin
Result:=Sqr(A.w)+Sqr(A.x)+Sqr(A.y)+Sqr(A.z);
end;

//--Обратный кватернион
procedure InvQuat(A:TQuaternion;var X:TQuaternion);
var b:Extended;
begin
b:=ModQuat(A);
ComplQuat(A,X);X.w:=X.w/b;X.x:=X.x/b;X.y:=X.y/b;X.z:=X.z/b;
end;

//--Нормировать вектор
procedure NormalizeVector(A:T3Vector;var X:T3Vector);
var v:Extended;
begin
v:=Sqrt(Sqr(A.x)+Sqr(A.y)+Sqr(A.z));
X.x:=A.x/v;X.y:=A.y/v;X.z:=A.z/v;
end;

//--Создать кватернион из вектора и угла вращения
procedure CreateQuat(A:T3Vector;angle:Extended;Q:TQuaternion);
begin
NormalizeVector(A,A);
Q.w:=Cos(angle/2);
Q.x:=A.x*Sin(angle/2);
Q.y:=A.y*Sin(angle/2);
Q.z:=A.z*Sin(angle/2);
end;

//--Умножить кватернион на вектор
procedure MultQuatVect(A:TQuaternion;B:T3Vector;var X:TQuaternion);
begin
X.w:=-a.x*b.x-a.y*b.y-a.z*b.z;
X.x:=a.w*b.x+a.y*b.z-a.z*b.y;
X.y:=a.w*b.y-a.x*b.z+a.z*b.x;
X.z:=a.w*b.z+a.x*b.y-a.y*b.x;
end;

//--Поворот вектора кватернионом
procedure QuatTransformVector(Q:TQuaternion;V:T3Vector;var X:T3Vector);
var TQ:TQuaternion;
begin
MultQuatVect(Q,V,TQ);
InvQuat(Q,Q);
MultQuat(TQ,Q,TQ);
X.x:=TQ.x;
X.y:=TQ.y;
X.z:=TQ.z;
end;

Massaraksh> Когда-то разбирался, сделал даже какую-то библиотеку работы с ними

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

quaternion Q_Norm (quaternion lambda1) //quaternion module adjust to 1
{
//1 - (a^2 + b^2 + c^2 + d^2 - 1)/2 - voila!
	quaternion lambda;
	long u_module;
	u_module = HALF - (((long long)lambda1.w * lambda1.w) >> (SHIFT_SCALE_1 + 1)) - (((long long)lambda1.x * lambda1.x) >> (SHIFT_SCALE_1 + 1)) 
	+ HALF - (((long long)lambda1.y * lambda1.y) >> (SHIFT_SCALE_1 + 1)) - (((long long)lambda1.z * lambda1.z) >> (SHIFT_SCALE_1 + 1)) + HALF;
	lambda.w = ((long long)lambda1.w * u_module) >> SHIFT_SCALE_1;
	lambda.x = ((long long)lambda1.x * u_module) >> SHIFT_SCALE_1;
	lambda.y = ((long long)lambda1.y * u_module) >> SHIFT_SCALE_1;
	lambda.z = ((long long)lambda1.z * u_module) >> SHIFT_SCALE_1;
	
	return lambda;
}

HALF - это, понятно, половина, т.е. 0х20000000. Делается так, чтобы избежать проверок на переполнение.

Massaraksh> Когда-то разбирался, сделал даже какую-то библиотеку работы с ними

И надо понимать физический смысл того, что делаешь. Ну, в смысле, зачем что нужно.
Например, произведение кватернионов - это композиция двух поворотов. Соответственно, нахождение обратного кватерниона нужно, чтобы повернуть обратно, где был. А, поскольку у нас модуль всех кватернионов, описывающих ориентацию, равен единице, то обратный кватернион и сопряжённый кватернион - одно и то же.

Б.г.> С плавучкой-то и тригонометрией любой сможет, прикол в том, чтобы без них обойтись
А смысл? Сейчас АRМ-процессоры достаточно быстрые, тем более, со встроенными сопроцессорами. Мы же не ракеты ПРО запускаем.

"Сущностей не следует умножать сверх необходимого" © Уильям Оккам.

 

Б.г.> Я использовал 32-разрядное представление с фиксированной десятичной точкой формата 2.30.

Я такое тоже использовал. На 8-битном МК.
А для спутника собирался сделать 2.38, там интегрирование скорости и расстояния при меньшей разрядности получалось грубое.
Но когда перешёл на 16-битный МК и попробовал прилагавшиеся к нему float и double, оказалось, что быстродействия хватает.
И бросил этой фигнёй маяться!

Б.г.> ... такое представление выгоднее, чем плавающая точка с одинарной точностью, потому что там в мантиссе 24 бита, а у меня 30 бит.

Давно было в планах сделать на компе симуляцию сферической ракеты, на которую действуют случайные моменты и она туда-сюда вращается.
Всё в double и с квантом времени 1/1000000 секунды. Чтоб уж наверняка!
Потом симуляцию гироскопов, которые выдают int16 уже с низкой частотой.
А потом натравить прогу, которая будет жить в МК, которая интегрирует и считает ориентацию в float.
И посмотреть, на сколько результат проги будет отличаться от "реальной" ориентации.

Вариант: комп передаёт через RS485 данные гироскопов в реальный МК, тот считает, и обратно докладывает результат.

Но потом плюнул.
Потому что на коротких временах далеко не уплывёт, а на длинных временах всё равно ориентацию надо определять другими датчиками.

Б.г.>> Я использовал 32-разрядное представление с фиксированной десятичной точкой формата 2.30.
Xan> Я такое тоже использовал. На 8-битном МК.

"Ачотакова?" Радхарда у нас в доступе нет, поэтому надо использовать то, что может противостоять спецфакторам хоть сколько-нибудь лучше среднерыночного. Например, МОКБ "Марс" построило БЦВМ на 80C196KC (ныне это 1874ВЕ05Т), а это всего 20 МГц и 16 бит.

Xan> А для спутника собирался сделать 2.38, там интегрирование скорости и расстояния при меньшей разрядности получалось грубое.
Xan> Но когда перешёл на 16-битный МК и попробовал прилагавшиеся к нему float и double, оказалось, что быстродействия хватает.

Ну вот с одной стороны, да, кажется, что времени вагон. С другой - а ведь, помимо вычислений, надо ещё датчики опрашивать, и не только гироскоп, надо компенсацию рассчитывать, надо кватернионы на рулевые машины отображать, да много ещё чего надо. Программу угла тангажа, коррекцию гироскопов по Солнцу, и т.д., и т.п.
Тех же 80C196KC поставили два на канал, чтобы всё успевали. Один обозвали центральным, другой - периферийным. И 4 канала для надёжности, с динамической переконфигурацией.

Xan> Давно было в планах сделать на компе симуляцию сферической ракеты, на которую действуют случайные моменты и она туда-сюда вращается.
Xan> Всё в double и с квантом времени 1/1000000 секунды. Чтоб уж наверняка!

Ага, с прецессией и нутацией!

Насчёт "далеко не уплывёт" - за время выведения порядочно может уплыть.

Б.г.> "Ачотакова?" Радхарда у нас в доступе нет, поэтому надо использовать то, что может противостоять спецфакторам хоть сколько-нибудь лучше среднерыночного. Например, МОКБ "Марс" построило БЦВМ на 80C196KC (ныне это 1874ВЕ05Т), а это всего 20 МГц и 16 бит.

Если на МКС пентиумы могут работать без сбоев, то несколько минут до орбиты любая бытовуха потерпит.
В смысле, скорее всего повезёт и проскочит.
Ну, мы не собирается космонавтов на Марс отправлять.
А если какой-нибудь университетский кубсат навёрнётся, то его и не жалко!!!

А для любительских атмосферных ракет проблемы радиации вообще нет.
А вот за атмосферное электричество надо подумать.

Б.г.> Ну вот с одной стороны, да, кажется, что времени вагон. С другой - а ведь, помимо вычислений, надо ещё датчики опрашивать, и не только гироскоп, надо компенсацию рассчитывать, надо кватернионы на рулевые машины отображать, да много ещё чего надо. Программу угла тангажа, коррекцию гироскопов по Солнцу, и т.д., и т.п.

У меня в ориентации и координатах получилось умножений: 88 float и 6 double.
Это вместе с гравитацией эллиптической Земли. Там ещё и три sqrt().
И с коррекцией неперпендикулярности осей гир и акселей.

Умножение жрёт много, вместе с окружающей арифметикой на одно умножение приходится около 550 тиков генератора. А сложение и пересылки всего от 2 до пары десятков тиков.
Поэтому считать надо только умножения.
Это, конечно, для конкретного МК.

Руление машинками — скорость и отклонение умножить на два коэффициента — 6 умножений float на три оси.

Опрос датчиков — там только пересылки байтов.

Коррекция тоже несравнима с ориентацией.

Не, времени валом!

Б.г.> Насчёт "далеко не уплывёт" - за время выведения порядочно может уплыть.

При хорошем ускорении оно за несколько секунд может на 180 градусов уплыть!
Ну не 180, но на пару десятков.
Поэтому опрос "негироскопов" и коррекция должны быть не намного реже, чем опрос гироскопов.

А! Ой!
Я про железо, а ты про программу?

Б.г.>> "Ачотакова?" Радхарда у нас в доступе нет, поэтому надо использовать то, что может противостоять спецфакторам хоть сколько-нибудь лучше среднерыночного. Например, МОКБ "Марс" построило БЦВМ на 80C196KC (ныне это 1874ВЕ05Т), а это всего 20 МГц и 16 бит.
Xan> Если на МКС пентиумы могут работать без сбоев,

А кто сказал, что без сбоев? В среднем несколько часов от сбоя до сбоя. А то и чаще, "несколько часов" - это то, что софт показывает космонавтам.

Xan> то несколько минут до орбиты любая бытовуха потерпит.

Тут я, в общем, солидарен, но, насчёт того, как следует программировать, останусь при своём мнении

Xan> Руление машинками — скорость и отклонение умножить на два коэффициента — 6 умножений float на три оси.

Это если считать, что у машинок бесконечное быстродействие. На самом-то деле приходится на машинку выдавать форсирующее воздействие, а при подходе к нужной точке уменьшать скорость перекладки. Я с этим сейчас, как раз, бодаюсь. И демпфирование влияет. Ну, то есть, вот летит твоя ракета, и попала в сдвиг ветра, ориентация нарушилась. На некий угол. Ты подаёшь сигнал на РМ, угловое ускорение начинает нарастать примерно линейно от времени, но с некой задержкой (на кадр, как минимум). Угловая скорость при этом нарастает квадратично от времени, а угол - кубично. Но, только пока не вмешается аэродинамическое демпфирование. Дальше, несмотря на то, что скорость перекладки РМ не изменилась, угловое ускорение падает почти до нуля, или, по крайней мере, не растёт, а, значит, угловая скорость растёт линейно (или медленнее), а угол - квадратично (или медленнее). Потом ты останавливаешь РМ, или даже перекладываешь в противоположную сторону, а у тебя уже вообще каша в зависимостях, и постоянные времени зависят от углов атаки и скольжения.

В общем, вот я сейчас пришёл к тому, что нужно подавать на машинку сигнал к перекладке на упор - на кадр или два, а потом уже только пропорциональный. Быстродействие машинки - 60 градусов за 60 миллисекунд - определяется при МГНОВЕННОЙ смене длительности управляющего импульса, а, если вводить его плавно, времени уходит заметно больше.

Xan> Опрос датчиков — там только пересылки байтов.

И, что, SPI и I2C работают с бесконечной скоростью? Оно, конечно, пересылка, но результат-то запаздывает.

Xan> Я про железо, а ты про программу?

Я вообще считаю, что тут железо от софта трудноотделимо, и не надо делать такие узкоспециализированные темы

Xan>> Руление машинками — скорость и отклонение умножить на два коэффициента — 6 умножений float на три оси.
Б.г.> Это если считать, что у машинок бесконечное быстродействие.

Нет, это, как раз, для машинок с задержкой.
Те древние картинки, что я рисовал, они считались для машинки с S-образной кривой исполнения.

Б.г.> На самом-то деле приходится на машинку выдавать форсирующее воздействие, а при подходе к нужной точке уменьшать скорость перекладки. Я с этим сейчас, как раз, бодаюсь.

Я до этого ещё до дошёл. До практики.
Вообще-то считал, что это в самих машинках должно быть встроено.

Б.г.> а у тебя уже вообще каша в зависимостях, и постоянные времени зависят от углов атаки и скольжения.

Вроде получалось, что управление работает в весьма большом диапазоне коэффициентов.

Б.г.> а, если вводить его плавно, времени уходит заметно больше.

А никакой плавности и нет. В каждом кадре для машинки выдаётся новое значение.
Которое должно быть отработано через некоторое время.
Лучше — через одинаковое для всех, и больших и маленьких.

Б.г.> И, что, SPI и I2C работают с бесконечной скоростью? Оно, конечно, пересылка, но результат-то запаздывает.

По сравнению с машинками — мгновенно!
Тут ещё неизвестно, какая задержка в микрухах гир с их встроенными фильтрами.
Мне тут АЦП попался, у которого задержка выдачи данных аж 32 отсчёта! Всё из-за внутренних фильтров.
Как бы и с гирами такое же не получилось — окажется задержка больше, чем у машинок!

Кстати, у тебя какого размера кадр?

Xan>> Я про железо, а ты про программу?
Б.г.> Я вообще считаю, что тут железо от софта трудноотделимо

Не, две разные вещи:
уход нуля гир из-за ускорения и прочего — железо;
уход нуля в программе интегрирования поворотов из-за неточности арифметики — софт.
Я ответил про железо, а ты писал про софт, вроде?

Xan> Вообще-то считал, что это в самих машинках должно быть встроено.

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

Б.г.>> а у тебя уже вообще каша в зависимостях, и постоянные времени зависят от углов атаки и скольжения.
Xan> Вроде получалось, что управление работает в весьма большом диапазоне коэффициентов.

А у тебя там возвращающее воздействие от чего зависело?

Б.г.>> а, если вводить его плавно, времени уходит заметно больше.
Xan> А никакой плавности и нет. В каждом кадре для машинки выдаётся новое значение.

Это-то понятно, но выдаётся оно "консервативно". Зависит от угла и угловой скорости, но создаёт угловое ускорение. И не сразу.

Xan> Которое должно быть отработано через некоторое время.
Xan> Лучше — через одинаковое для всех, и больших и маленьких.
Б.г.>> И, что, SPI и I2C работают с бесконечной скоростью? Оно, конечно, пересылка, но результат-то запаздывает.
Xan> По сравнению с машинками — мгновенно!

А у меня SPI занят сейчас бОльшую часть времени...
Xan> Тут ещё неизвестно, какая задержка в микрухах гир с их встроенными фильтрами.

Ну, у меня более-менее известно. У меня сейчас включено скользящее среднее по 8 отсчётов, после которого ещё одно скользящее среднее по 8 отсчётов, что, при частоте отсчётов 2048 Гц даёт задержку 2 мс. Плюс ещё где-то 1 мс ДО этого. Итого около 3 мс. При частоте среза аналогового тракта 330 Гц.

Xan> Мне тут АЦП попался, у которого задержка выдачи данных аж 32 отсчёта! Всё из-за внутренних фильтров.
Xan> Как бы и с гирами такое же не получилось — окажется задержка больше, чем у машинок!

Да, когда я начинал эксперименты с ADIS16300 в 2013 году, то из-за этой задержки в режиме "максимальной фильтрации" амплитуда колебаний была вдвое больше, чем при "минимальной фильтрации".

Xan> Кстати, у тебя какого размера кадр?

У интегрирования - 256 Гц, а у рулевых машин - 51,2 Гц.

Xan> Xan>> Я про железо, а ты про программу?
Б.г.>> Я вообще считаю, что тут железо от софта трудноотделимо
Xan> Не, две разные вещи:
Xan> уход нуля гир из-за ускорения и прочего — железо;
Xan> уход нуля в программе интегрирования поворотов из-за неточности арифметики — софт.
Xan> Я ответил про железо, а ты писал про софт, вроде?

Смотри. У меня в даташите написан перекос осей внутри корпуса (неперпендикулярность) 0,15 градуса, а относительно корпуса - 1 градус.
По факту я обнаружил, что, если крутануть гироскоп по Z на 360 градусов, то по оси Y пролазит паразитный сигнал размером 2 градуса. Надо делать матричную коррекцию. Это железо или софт?
Притом, внутри гироскопа уже делается эта матричная коррекция, но почему-то с точностью, которая мне недостаточна.


Видно, как наступает цифровое ограничение на уровне 24000 (120 градусов в секунду).
В моей радианной мере ограничение угловой скорости сделано 2 радиана в секунду, или 114 градусов в секунду с долями.

Xan> Вообще-то считал, что это в самих машинках должно быть встроено.
Б.г.> В некоторые встроено, в некоторые нет, но, в общем и целом, на это полагаться не выходит.

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

Б.г.> А у тебя там возвращающее воздействие от чего зависело?

Там совершенно железное (даже сильнее — математическое ) ограничение:
если выкинуть все затухания и задержки, оставить только k1 и инерцию,
то период колебаний будет

T = 2 * pi * m / k1

А сдвиг фазы на 90 градусов будет при времени

t = T / 4

И вот это время должно быть БОЛЬШЕ суммы всех задержек.
Лучше раза в два минимум. А можно и в десять.

Вот пример в некоторых попугаях про k1 и k2:
Подбор k2 по критерию "минимум суммы квадратов отклонения на единичное воздействие".
Последняя колонка — сумма квадратов = "энергия колебаний".

k1 = 050, k2 = 51.05, 35.96
k1 = 070, k2 = 49.28, 30.25
k1 = 100, k2 = 47.00, 24.81
k1 = 140, k2 = 44.61, 20.88
k1 = 200, k2 = 42.14, 18.41
k1 = 280, k2 = 39.49, 18.19
k1 = 400, k2 = 36.60, 23.56
k1 = 600 — незатухающие колебания

Видно, что даже если k1 на порядок меньше предельного, то колебания получаются не сильно больше.
Колебания становятся более растянутыми, а амплитуда растёт слабо.
Так что в сторону уменьшения жёсткости запас большой.

Б.г.> А у меня SPI занят сейчас бОльшую часть времени...

Вроде, в МК это делается железом. Без расхода процессора.

Б.г.> У интегрирования - 256 Гц, а у рулевых машин - 51,2 Гц.

У меня L3G4200D, там предполагаю использовать скорость и полосу такие: DR = 200 и BW = 70, с усреднением двух отсчётов. Или DR = 400 и BW = 110 с усреднением четырёх.
Так что частота кадров для программы получается 100 Гц.
Меньшую частоту кадров компенсирую меньшим k1.

Xan> Вроде, в МК это делается железом. Без расхода процессора.
Естественно. Всю обработку периферии надо строить на прерываниях. Иначе и суперпроцессор не поможет.

Xan>> Вообще-то считал, что это в самих машинках должно быть встроено.
Б.г.>> В некоторые встроено, в некоторые нет, но, в общем и целом, на это полагаться не выходит.
Xan> Ну, у меня в планах для машинок отдельные мозги, в них можно будет некую коррекцию поведения вставить.
Б.г.>> А у тебя там возвращающее воздействие от чего зависело?
Xan> Там совершенно железное (даже сильнее — математическое ) ограничение:
Xan> если выкинуть все затухания и задержки, оставить только k1 и инерцию,
Xan> Так что в сторону уменьшения жёсткости запас большой.

Х его з, у меня не получается.

Б.г.>> А у меня SPI занят сейчас бОльшую часть времени...
Xan> Вроде, в МК это делается железом. Без расхода процессора.

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

Б.г.>> У интегрирования - 256 Гц, а у рулевых машин - 51,2 Гц.
Xan> У меня L3G4200D, там предполагаю использовать скорость и полосу такие: DR = 200 и BW = 70, с усреднением двух отсчётов. Или DR = 400 и BW = 110 с усреднением четырёх.
Xan> Так что частота кадров для программы получается 100 Гц.
Xan> Меньшую частоту кадров компенсирую меньшим k1.

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

Б.г.> А на SPI сидит сильно не один датчик (и флэш для запоминания сидит на нём же). Но, пока ответ не пришёл, снимать чип-селект и выбирать другой датчик нельзя.
Так нужно в это время ожидания и обрабатывать математику от предыдущего шага данных.

Б.г.> А, для того, чтобы обновить кватернион ориентации, нужно получить три ответа, а это будет совсем не тогда, когда ты посылал вопрос.

Вроде ж микруха дёргает ножкой, когда в ней очередные данные сварились.
И их надо только вынуть все разом.
Ну и прерывания есть.

Б.г.> Идеологически, при этом, угол отклонения машинок пропорционален отклонению угла ориентации?

Да.

Б.г.> Но ведь, при этом, углу отклонения машинок (грубо) пропорционален управляющий момент, а он вызвает угловое ускорение?

Да.

Б.г.> То есть, грубо, в отсутствие дифференцирующего канала, частота колебаний вокруг программного положения не зависит от амплитуды этих колебаний?

Да.

Или я чего-то не понял!!!

Если ты уменьшаешь k1 в проге, то теперь на то же отклонение угла (показываемого гироскопами), машинки будут поворачиваться меньше.
И, соответственно, возвращающий момент будет меньше.
И ускорение, и скорость.
И период колебаний системы управления будет больше.
И вот его надо сделать достаточно большим по сравнению с задержкой в управлении.
Уменьшая k1 в программе.
Или уменьшая площадь рулей.
Или уменьшая механический коэффициент передачи от машинки к рулям.

А ещё надо следить за скоростным напором и с его ростом пропорционально уменьшать k1.
И за производной коэффициента подъёмной силы рулей в зависимости от махов.

А ещё за уменьшающимся моментом инерции ракеты в связи с выгоранием топлива.

Вот бы сделать автоматическое вычисление k1 !!!
Иногда кажется, что можно.
Хотя бы подстройку.

Б.г.>> А, для того, чтобы обновить кватернион ориентации, нужно получить три ответа, а это будет совсем не тогда, когда ты посылал вопрос.
Xan> Вроде ж микруха дёргает ножкой, когда в ней очередные данные сварились.
Xan> И их надо только вынуть все разом.

Если бы не было встроенного усреднения, то на нативной частоте 2048 Гц 6 данных по 16 бит каждое - это 196608 бит в секунду. По даташиту этого гироскопа клок нельзя делать больше 2 МГц. По даташиту этого процессора клок SPI я могу делать либо 41/16, либо 41/64 мегагерца. Причём, там между словами есть stall time, порядка 20% от времени передачи, а SPI у меня байтовый, и между байтами получается 1 холостой такт, т.е. не 16 бит, а 18. Плюс по команде на снять CS - подать CS. Итого в секунду надо потратить на приём примерно 265420 тактов SPI, который имеет тактовую частоту 652800 Гц, то есть, только этим гироскопом занято 40,6% всего времени SPI. С учётом того, что желательно ещё читать температуру, т.е. 7 слов на сэмпл, а не 6, получаем 47,4%.

То есть, только один гироскоп занимает физически половину всего времени SPI. И прерывания тут никак не помогают, ибо SPI физически всё это время передаёт и принимает.

Включение фильтрации и децимации уменьшает поток, но увеличивает задержку.

Xan> Ну и прерывания есть.

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

Xan> А ещё надо следить за скоростным напором и с его ростом пропорционально уменьшать k1.

До этого я дошёл ещё во времена первых полётов в "Лин Индастриал".

Xan> И за производной коэффициента подъёмной силы рулей в зависимости от махов.
Xan> А ещё за уменьшающимся моментом инерции ракеты в связи с выгоранием топлива.
Xan> Вот бы сделать автоматическое вычисление k1 !!!
Xan> Иногда кажется, что можно.
Xan> Хотя бы подстройку.

Вот эта подстройка существовала со времён Фау-2, причём, в те времена она делалась обмотками подмагничивания, менявшими коэффициенты усиления усилителей (структуры Модулятор-Демодулятор, ибо УПТ по-другому тогда строить не умели) и частоты среза фильтров.
И именно в силу ограниченности такого механизма, в 8К63 (Р-12) в баке окислителя было промежуточное днище, и сначала расходовался окислитель из нижней половины бака, а потом из верхней - чтоб уменьшить потребность в подстройке коэффициентов.

Б.г.> то есть, только этим гироскопом занято 40,6% всего времени SPI.
-DMA?
-Не, не слышали.

Б.г.> То есть, только один гироскоп занимает физически половину всего времени SPI. И прерывания тут никак не помогают, ибо SPI физически всё это время передаёт и принимает.

Ага, понял.
Поставить ещё один МК, пусть занимается только приёмом и усреднением.
С другим МК связать по UART, напрямую, ножка к ножке.

Б.г.> про прерывания мы уже беседовали несколько лет назад...

Поскольку у меня АСУПТ по прерываниям работала, я их не боюсь!

Б.г.>> то есть, только этим гироскопом занято 40,6% всего времени SPI.
Massaraksh> -DMA?
Massaraksh> -Не, не слышали.

Как DMA поможет от того, что окончание приёма одного сэмпла приходится на середину следующего?

Б.г.> Как DMA поможет от того, что окончание приёма одного сэмпла приходится на середину следующего?
Вот этого я не понял: гироскоп выдает данные чаще, чем принимает SPI, что ли?

Б.г.>> Как DMA поможет от того, что окончание приёма одного сэмпла приходится на середину следующего?
Massaraksh> Вот этого я не понял: гироскоп выдает данные чаще, чем принимает SPI, что ли?

Если я захочу принять все данные, которые может выдать гироскоп, это займёт 47% времени SPI. Больше того, в случае с более дорогим гироскопом, ADIS16490, ситуация вообще запиписечная - он в состоянии сгенерировать столько данных, что не может пропихнуть их через собственный SPI - у него максимальная частота обновления данных 4 кГц, данные по дефолту 32-разрядные, а, помимо "сырых" угловых скоростей, он выдаёт ещё и отфильтрованные расширенным фильтром Калмана.
У ADIS16460 тоже есть внутренний интегратор, и по углам, и по скоростям, и, если читать и его, то тоже легко забить весь SPI.
Поэтому я включаю внутреннюю фильтрацию и внутреннюю децимацию. Приходится. Но это вызывает увеличение задержки. Я, в итоге, читаю только каждый восьмой сэмпл, частота обновления 256 герц. Каждый такой сэмпл собирается внутри из 8 сэмплов, идущих с частотой 2048 Гц.
Каждый из которых, в свою очередь, как я подозреваю, собирается из 12 сэмплов, идущих с частотой 24576 Гц, но до них мне уже не добраться - это внутренняя кухня кубика.
Ну, да, фиг с ними, с потрохами.
Суть в том, что часть информации я из-за этого теряю. Думаю, что она неважна для целей управления, но теряю.
Аналог-девайсовцы предлагают уменьшить потери - можно читать не 16 бит, а все 32, при усреднении 8 чисел получается 3 лишних разряда, правда, отношение сигнал/шум улучшается только на полтора разряда.