Search in topic

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

Вообщем если в течение недели своих результатов не будет, буду ртос ковырять.

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

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

Привет, Макс! Не скажи! Я вот обзаботился разобраться в деталях, как всё это работает, и щас смотрю исходники ртоса и всё понятно. Но мне все возможности фриртос особо не нужны (возможно пока) , посему я не буду ждать, а попытаюсь сделать необходимый функционал сам. К тому же заменить на фриртос мою поделку будет не сложно, вызовы методов сделаю аналогично фриртосу.

Я вот обзаботился разобраться в деталях, как всё это работает, и щас смотрю исходники ртоса и всё понятно.

Если все понятно, то зачем изобретать свое. FreeRTOS все же оттестирована и портирована на множество камней.

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

Ну и смысл изобретать свой велосипед.

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

здесь матерными словами писать нельзя:( дешевше “крутыми” датчиками обойтись )))

Если все понятно, то зачем изобретать свое. FreeRTOS все же оттестирована и портирована на множество камней.

Ну и смысл изобретать свой велосипед.

Смысл есть, ибо:

1. фртос сделана для удовлетворения максимально широких потребностей максимального количества использователей. Мне же надо обеспечить максимльно удобно свои и только.
2. Во фриртос задачи вешаются динамически, мне это не надо, у меня задачи и обработки будут статическими в виде глобальных структур. Что это дает? Нет сложного механизма списков и выделения памяти. Зачем мне использовать сложные, универсальные и тяжелые механизмы РТОС, в которых я всё равно всех тонкостей не знаю, если достаточно простого с ограниченным (и достаточным!) набором функционала?
3. Большая часть моего кода - обработчики событий (сопрограммы в терминах фриртос), а в ртос они всегда в низком приоритете относительно задач. Т.е. использовать сопрограммы как я хочу нельзя. Да можно было бы вызывать их из задачи по семафору, но это опять усложняет механизмы (и увеличивает время реакции!) и плодит частные стеки, ведь обработок нужно более 20, либо нужно делать одну задачу (или 3-4 по функционалу - инс, навигация, связь и т.п.) с выборкой вызовов обработчиков по семафорам. По сути ещё один или несколько планировщиков второго уровня, управляемых планировщиком РТОС через сложный механизм списков… Оно мне надо?
   А так конечно подкупает простота: подключил файлы к проекту, исправил конфиг и вперед…

Но ГУИ и сетевые приложения безусловно нужно рисовать из под РТОС, хотя это другая история )))

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

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

дешевше “крутыми” датчиками обойтись )))

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

обработчики событий (сопрограммы в терминах фриртос)… использовать сопрограммы как я хочу нельзя.

в терминах freertos сопрограммы — подпрограмма с множеством точек выхода -> продолжения выполнения. в них пихают либо самые ненужные, либо самые простейшие действия, на которые действительно жалко тратить память. если обработчики событий попадают под это определение, то у вас очень необычный стиль программирования.

у меня задачи и обработки будут статическими в виде глобальных структур. Что это дает? Нет сложного механизма списков и выделения памяти.

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

кстати, что сложного в однократном выделении памяти при создании задачи?

Оно мне надо?

по моему, все ваши требования укладываются в

while(1) {
task1();
task2();
...
taskN();
}

со вставкой в начало каждой задачи простейшего диспетчера отслеживающего количество тиков.

в терминах freertos сопрограммы — подпрограмма с множеством точек выхода -> продолжения выполнения. в них пихают либо самые ненужные, либо самые простейшие действия, на которые действительно жалко тратить память. если обработчики событий попадают под это определение, то у вас очень необычный стиль программирования.

У меня наоборот, всё критичное выполняется в обработчиках, а в “задачах” самые некритичные действия.

а контролировать и гарантировать атомарность будете ручками?

Ручками, всё и так контролируется.

не факт, что ваш велосипед не превысит сложность имеющихся и “незаметных” инструментов.

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

по моему, все ваши требования укладываются в
Код:
while(1) {
task1();
task2();
…
taskN();
}
со вставкой в начало каждой задачи простейшего диспетчера отслеживающего количество тиков.

Укладывается, но не в такою простую, нужен опрос состояний датчиков и выполнение обработок.

Да и вообще “вращалка” задач мне пока и не актуальна, важно изменить принцип вызова обработчиков по событию. Сейчас так: готовность датчика - запуск чтения через КА в прерывании - вызов обработчика из прерывания, т.е. вся обработка в прерывании, а надо чтоб в прерывании обновился датчик, после чего обработка прерывания завершается, управление предается планировщику, планировщик запускает вычисления.

всё критичное выполняется в обработчиках, а в “задачах” самые некритичные действия.

ну я и говорю, очень необычный стиль.

вся обработка в прерывании, а надо чтоб в прерывании обновился датчик, после чего обработка прерывания завершается, управление предается планировщику, планировщик запускает вычисления.

если вычисления полностью зависят от обновления датчика, то накой нужен планировщик? это линейная задача, практически атомарная, а вы ее зачем-то бьете на части. подозреваю, что с остальными “более 20 обработками” происходит так же.

ну я и говорю, очень необычный стиль.

Наверное, если обычным считать программирование на Бейсике.

если вычисления полностью зависят от обновления датчика, то накой нужен планировщик? это линейная задача, практически атомарная, а вы ее зачем-то бьете на части.

Нужен для разделения получения данных от их обработки. Бить на части нужно, потому что, способ получения данных (“низы”) для разных платформ может быть разный, а “верхи”, обработчик для всех один и обращается к абстрактному вектору из абстрактного датчика по обновлению данных в нём. Безусловно всё это можно было “выпрямить” в линейный алгоритм внутри задачи ртос, но так сложилось исторически, и упрощать это СЕЙЧАС я смысла не вижу. Зачем то, что работает явно, загонять в экосистему, которая от меня скрыта? Я просто хочу разорвать “атомарную цепочку” на “верх” и “низ” в процеесе выполнения, а не только в структуре проекта, ну и плюсом получить механизм “вращения” задач.

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

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

с разными готовыми РТОСами на этот счёт будет сложно договориться…

Имею сказать - CoOS мучаю уже год, задержки прерываний -0, все вроде работает даже “из коробки”, проще чем FREE RTOS, чего ещё надо ?, советую обратить внимание… (один минус описание слабовато…)

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

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

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

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

нет это не так, это период обработки низкоприоритетного прерывания меньше, чем вычисление “навалившихся” приоритетных, описывать “многа букафф” будет, но попробую кратко, как пример:
“вдруг” привалило данных по датчикам ИНС, стало быть в приоритетных прерываниях надо последовательно обсчитать интеграцию, местоположение (по барику и ГНСС) и коррекцию (3-4 задачи последовательно), а в это время считается период входного ППМ. Получается так, что входной фронт поймали, а спад не успели.

меньше, чем вычисление “навалившихся” приоритетных,

Тогда это проблема не в прерываниях-как таковых, а в расстановке приоритетов… (причёсывать надо).

проблема не в прерываниях-как таковых, а в расстановке приоритетов…

Нет, я об этом выше писал. Проблема действительно в том, что обработка прерываний длинная, но сам цепочки состоят из 10 “низов”- 1"верх" (длинный “верх” обрабатывается 1 раз из 10 вызовов). Так например получение инфы с приемыша, надо “поймать” 16 перепадов чтоб получить кадр управления, по которому вычислить “задатчик положения”. Ловить перепады быстрая задача (“низ”), а формирование управления в АП (“верх”) долгая. Соответственно я могу на недолго прервать расчёт “верха” ДУС на обработку “низа” ППМ, но нельзя прирывать “верх” ДУСа “верхом” ППМ. Так понятно?

То есть я хочу дать “низам” приоритет выше “верхов”, при этом сохранив их горизонтальные приоритеты меж разными обработками. Было бы хорошо вызывать прерывания для верхов программно, но даже у СТМ32 нет такого количества векторов.

Так понятно?

Понятно… Просто из двух “конкурирующих реалтаймов” (ДУС и ППМ), один наверно придётся в “свободное плавание” отпустить с поправкой на SysTick… , хотя возможные задержки и искажения результатов могут быть настолько малы что ими можно пренебречь… (это просто мысли вслух, не более… у меня ППМа нету, главный - ДУС и всё…, поэтому и проблем этих нет))

“вдруг” привалило данных по датчикам ИНС, стало быть в приоритетных прерываниях надо последовательно обсчитать

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

Не нужно в прерываниях ничего считать.

Это так, но если очень хочется, то можно ))) Пока хватало, вот когда сделал “виртуального” летуна, тут и проблемы начались, ибо все данные для обработки “приплывают” разом в одном пакете.

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

Так и буду делать, только через вращатель программных прерываний, которые будут ниже железных по приоритету.

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

не…

Не, есть конечно плата “NAVIO Rpi”, и и там якобы всё работает, но во первых подозрительно это как то (не верю), во вторых эта тема с ней как то заглохла (что подверждает “первое”)

У меня есть плата Navio+. Пробовал её на RPi B+ (как рекомендуют разработчики EMLID). Рама Tarot650 несколько раз летала с ней - всё нормально работает. RPI бралась для того чтоб на ней и летать, и видео на лету кодировать, и управлять коптером через дальнобойную USB Wi-Fi карточку. В принципе, всё это получилось.

Не понравились три момента, касающиеся не платы Navio, а самой Raspberry Pi:

1. RPi надо как-то питать, на плате автопилота не предусмотрено блока питания для малины. И любая нестабильность по питанию сильно отражается на надёжности работы малины.
2. RPI модели B+ - громоздкая, и я мог бы ей это простить, если бы все 4 USB-порта работали нормально, но это не всегда так.
3. обнаружилось что работать с мультимедиа на том же проце который управляет полётом - крайне опасно. От мультимедийной работы RPi иногда перезагружалась, а если это случится в полёте, то коптеру пипец.

любая нестабильность по питанию сильно отражается на надёжности работы малины.

это единственная причина, все остальное вами перечисленное — следствие.
плюс (по опыту съемки малины с камерой) почти любая Pi (кроме Zero, ее не пробовал) очень сильно не дружит с наводками от моторов/передатчиков, в идеале нужно независимое питание от отдельного аккумулятора.