Search in topic

Создание собственной системы стабилизации

Может дурь скажу, но как-то не укладывается в голове один маааааленький нюанс:
вот считаем мы угол с ДУС и угол с акселя да, и что откуда мы берём?
берём интеграл угловой скорости - правильно? - так это по сути мы заглядываем в будушее на время DT (т.е. при зафиксированной скорости через время DT будет такой угол) , а берём угол с акселя - уже свершившийся факт…

берём интеграл угловой скорости - правильно? - так это по сути мы заглядываем в будушее на время DT (т.е. при зафиксированной скорости через время DT будет такой угол)

Не совсем, скорее наоборот - прошлое, хотя и не dt датчика, а на dt вычисления и принятия решения о воздействии.

1. ДУС измерил угловую скорость от момента 0 до dt;
2. в dt+dt_прерывания он сообщил, что измерил,
3. в момент dt+dt_прерывания+dt_передачи данные пришли в проц ;
   4.в момент dt+dt_прерывания+dt_передачи +dt_вычисителя алго изменил своё кажущееся положение;
   5.в момент dt+dt_прерывания+dt_передачи +dt_вычислителя+dt_автопилота принимается рещение об управлении.
   Итого: dt+dt_прерывания+dt_передачи +dt_вычислителя+dt_автопилота.
   Для акселя почти так же: dt+dt_прерывания+dt_передачи +dt_вычислителя+dt_корректора.

Кто знает, что это за ребята? Не vis.asta ли и ко?

Это вот эти

От мультимедийной работы RPi иногда перезагружалась, а если это случится в полёте, то коптеру пипец.

С питанием можно проблему можно решить недорого и просто (влепить отдельный импульсный рег. типа LM2596 или мельче), а вот все остальное… - незнаю, патч к линуксу в сети “ругают”, ды и не даёт он 100% реалтайма, а лишь уменьшает время задержки (?), выводы делайте сами… Всё что мне удалось выяснить в процессе “издевательств” над линуксом - он в некоторых моментах/случаях может чуть ли не на 2 секунды заблокировать любую задачу… поэтому нагружать его помимо управления полетом другими задачами крайне рискованно…

не укладывается в голове один маааааленький нюанс:

по факту - данные как бы вообще идут вразнобой с разных датчиков в реальном времени, аксель то еще ладно, а магнитометр вообще 20 Гц читать только можно, но тем не менее они сводятся одним алгоритмом расчета положения… тут кстати получается типа ФВЧ для акселя… (пробовал читать ДУС 500 Гц, а аксель 20 всё работает и довольно неплохо…)

по сути мы заглядываем в будушее

Нет, как раз в “настоящее” т.е. - на момент времени выборки имеем пройденный угловой путь…

Нет, как раз в “настоящее” т.е. - на момент времени выборки имеем пройденный угловой путь…

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

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

Формулировка, сложновата черезчур и довольно запутана))) Я б так сказал - при цифровом методе регулирования, актуальны те данные, которые имеются на момент “выборки”, все остальное время не в счет… - это погрешность…
Отсюда - чем выше частота выборок тем точнее система… , идеальный случай - полный аналог (датчики + регулятор + исп. устройство), где частота выборки условно равна бесконечности…

• есть всем известная прекрасная плата BeagleBoneBlack

Интересная штучка, посмотрел, спасибо… Только опять возникает вопрос (применительно к нашей теме) - ну сделали там отдельные “реалтаймовые ядра” (в т.ч. тем самым подняли цену)), а есть ли для Линукса программная поддержка этого “блока” (??) или опять Линукс “сам по себе” - а ралтайм “сам по себе” (?) … это я про магический “L3 Interconnect” на блок схеме…
В принципе у дешевой RPi тоже имеется 4 полноценных ядра, ды и периферия та- же почти, вопрос в программном обеспечении только…

ну сделали там отдельные “реалтаймовые ядра” (в т.ч. тем самым подняли цену)), а есть ли для Линукса программная поддержка этого “блока” (??)

512 байт оперативки и 4 Кб для программы на один PRU, ассемблер с 40 RISC-командами, отсутствие умножения… какой линукс? это “помогайки” для реализации интерфейсов или DSP, не более.

это “помогайки” для реализации интерфейсов или DSP, не более.

понятно, в топку…))

вариация на тему малина+ erlerobotics.com/blog/product/pxfmini/

схемы нет, софта нет. оно просто отдает сырые данные?

это шилд к малине с каким-то 103-м процем ввиде выхода шим и датчиками 9250 5X89 5611 код открытый в арду…

Если хотите реалтайм + “мощный” ARM с линуксом, то нужно ставить ARM+FPGA )))). Сколько угодно выходов шим, любые интерфейсы, самый реалтаймый реалтайм))). Что-то типо того habrahabr.ru/company/metrotek/blog/235707/.

нужно ставить ARM+FPGA )))).

Спецам по линуксу надо просто сделать “правильный кряк” ядра, а железа то у любого ARMa хватает, нам для задачи стабилизации достаточно одного SPI или даже I2C, на худой конец… лишь бы работу с ними никто не мог “вытеснить” … и желательно прерывания по аппаратному таймеру… (вот и всё счастье)))

Я думаю, даже уверен, что смысла ждать неделю нет. Лучше ее потратить на начало работы с FreeRTOS.

Таки изобрёл велосипед))) По сути обработчик программных прерываний, обработчик событий. Особо если портировать на АВР, там аппаратных прерываний мало.

Не нужно в прерываниях ничего считать. Только забрать данные которые “вдруг” “привалили” и выставить флаг (семафор) для задачи которая все это обсчитает.

Вот у меня всё так теперь, только не семафор, а вызов обработчика. При этом вызывающее прерывание освобождается, можно дальше “слушать” датчик.
Кста, кто может " прокатить" под отладчиком FreeRTOS, сколько циклов проца натикает до старта вычисления в самой приоритетной задаче? У меня 230 )

Подскажите , кто может, - как сделать чтоб коптер не разворачивало по “Yaw” на 360 гр. при переходе через “0-360” град. (всю голову сломал, не могу придумать, прям “ручник” какой то)))),
т.е. на ПИД по “Yaw” подаем 0-360 гр. с ИМУ и уставку 0-360 гр… получаем в районе перехода 0-360 сигнал управления на целый оборот…(?), как у людей то сделано ??.

получаем в районе перехода 0-360 сигнал управления на целый оборот…(?), как у людей то сделано ??.

Ну тут вроде всё просто: если разность больше 180, вычитай или прибавляй 360 (т.е. полный оборот). Хотя математически правильно на выходе иму получить угол ±Пи, а преобразование в азимутальный 0-360 только для индикации.

Хотя математически правильно на выходе иму получить угол ±Пи

Это ничем не лучше 0-360. Если угол используется для управления (в ПИД-контроллере, задание цели, и т.д.) то он должен быть непрерывным. Можно завести специальный тип данных, но проще всего во float преобразовать и не париться. Методика называется “phase unwrapping”. Обратно в ±180 также просто преобразовать. Ни и эту особенность углов надо всегда помнить. Если угол 10, а команда идет “повернуть на 380” - то это можно сделать двумя способами, длинным и коротким. И однозначно сказать какой “правильный”, может только тот, кто команду дает.

он должен быть непрерывным

но проще всего во float преобразовать и не париться

Непонятно как это сделать практически… , может формулу или пример дадите ? Если я правильно понял, то как бы угол +/- бесконечность нужно сделать и считать еще и обороты относительно “нуля” ?

Выше Александр написал уже: “если разность больше 180, вычитай или прибавляй 360 (т.е. полный оборот)”. Только ещё можно учесть, что полных оборотов может быть больше одного, и нужно в начале инициализировать фильтр сырыми данными без этой проверки (начальный угол может быть любым и не надо его сравнивать с нулем). Пример кода не буду давать чтоб не запутать, но там пара строк всего.

И однозначно сказать какой “правильный”, может только тот, кто команду дает.

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

Публикую свой “велосипед”, может кому пригодиться.
Чтоб работал нужно сделать:

В проект включить ROSA.c и соответствующие файлы порта для АВР или СТМ32

в main.c или другом ц,цпп-файле

#include “ROSA.h”

void hend0(void)
{
ROSA_CallEvent(3);
}

void hend1(void)
{
//ROSA_CallEvent(2);
}
void hend2(void)
{
//ROSA_CallEvent(3);
}

void hend3(void)
{
ROSA_CallEvent(4);
}

void hend4(void)
{
ROSA_CallEvent(1);
}

/* массив обработчиков */
Event_TypeDef Event_List [] = {

hend0,hend1,hend2,hend3,hend4
};

/* массив приоритетов */
const Event_Priorety_TypeDef _Ev_Prior[] = {
0,1,2,3,4 };

int main(void)
{
ROSA_Init(0); /* инициализация РОСА*/

for(;😉 {

ROSA_CallEvent(0);
}
}

Ну и в конфиге “ROSA_config.h” прописать определение регистров проца, количество обработчиков, не\использование фиксированных приоритетов, использование механизма очереди. В основной дериктории есть “рыба” “_ROSA_config.h”, надо только оставить нужно, лишнее удалить/закомметировать.

#include “stm32f10x.h” /* заголовочный файл для контроллера STM32 */

#include <avr/io.h>
#include <avr/interrupt.h> /* определение внутренних регистров МК */

#define Event_Count 4 /* количество обработчиков */

#define ROSA_ConstPriority /* массив приоритетов определяется в пользовательском файле */

#define ROSA_WaitEvent_QUEUE /* использование очереди, если нет, то простой перебор */

/* это только для AVR на другое не влияет */
#define ROSA_AVR_SW_PENDBIT_PORTD3 /* бит вызова прерывания для переключения обработчиков */

ROSA.rarROSA_AVRMega_Exp.rarCortex.rar

нахаляву досталась платка flip32 по случаю затестил горизонт cleanflight визуально вроде бы не валится в ускорениях

по случаю затестил горизонт cleanflight визуально вроде бы не валится в ускорениях

Каким образом испытывал? Каруселькой?

линейно перемещал вдоль поверхности

линейно перемещал вдоль поверхности

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

ну в арду даже при резких линейных перемещениях можно зафиксировать приличные отклонения
сложилось мнение что нужно интегральную составляющую корекции гироскопов добавлять а пропорциональную от акселя уменьшить

линейно перемещал вдоль поверхности

Только “каруселькой”…

сложилось мнение что нужно интегральную составляющую корекции гироскопов добавлять а пропорциональную от акселя уменьшить

У кого сложилось ? если можно поподробнее… как то, пока не встречал рабочего решения этой проблемы…