Search in topic

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

удобна и проста для пользователя

Но “наземную станцию”, всё ж, таскать с собой в поле заставляет…

Но “наземную станцию”, всё ж, таскать с собой в поле заставляет…

зачем? есть товер про и планнер под андроид, единственное калибровки не сделаешь - они не в контроллере а в планнере…

Это да… Но там щас вроде муть какая-то, типа ПО уже не открытое?

да не, всё открыто, только муть ещё та, чтобы собрать что-то вразумительное, надо по коммитам шарится…

Назрел вопрос с ОСью, но я же не могу взять готовое

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

Да, было дело, целый месяц из жизни )

да, только без тебя, рабочей концепции платы не было бы)))
я сейчас на распутье с мелкой (её всё равно переделывать - мой косяк rx-tx перепутал причём в критичном месте) - оставить как есть 9250 и 6000+5883 или сделать 9250+5x83, 9250 и 5983 (у меня есть оба варианта в ПО) сохранив размер основного устройства 28Х28мм? при условии надёжности пп для летательных аппаратов - 2 слоя?

отличия мелкой от пиксрейсера - нету разъёма под вайфай модуль (зачем он?) 8 полноценных выходов вместо 6-и, sd на spi (работает - работает- не надо лишних лап проца) и всё это в 64-х лапах а не в 100 и в 2 слоя а не в 4…
так же вход один на всё без переходников, тоже один усарт с возможностью инверсии и один с возможностью использовать как i2c плюс 2 простых усарта и свободная i2c, rssi - одна лапа хочешь - ацп хочешь таймер, контроль внуреннего напряжения +5, и 3 внешних входа ацп (напряжение, ток, аналоговый датчик воздушной скорости), пусть они догоняют)))

sd на spi

А я вот поигрался с microSD и чё то прихожу к мнению что не нужна она на плате… лучше наверно i2c пзушку впаять…
Причины такие:

1. Места занимает много. 2. Нужный SPI (1 из 3-х всего) занимает. 3.Надежность при вибрациях и окислении контактов низкая. 4.Сохранять данные в виде файлов (на кастрированной fat) крайне не удобно и муторно.
2. Ды и чего такого на ней хранить в таком объеме ? (у меня там правда *.wav для “говорилки” сейчас лежат, но это скорей пижонство…)

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

Серёг, нафига за ними гнаться?

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

изначально нужен системный подход

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

всем нужна выгода, а где её взять?

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

Не знаю как у вас, а у нас кредит - это минимум 36% годовых, в “цивилизованном” мире пальцем у виска покрутят с такими предложениями…

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

Вообще меня всё устраивало бы “на прерываниях”, но дело всё в том, что по мере разрастания кода в вычислениях ИНС начали появляться пропуски низкоприоритетных прерываний (вывод в консоль, визуализация), так может дойти и до чтения приёмыша и отправки телеметрии. Посему надо отделить “низы” от “верхов”, чтоб прерывания могли “переслать один байт” в процессе “размышлений о бытие”. Сменить приоритеты не получиться, т.к. мелкие прерывания иногда тянут за собой тяжелые, но не критичные по времени и актуальности данных, расчеты. Ну и плюсом хотелось иметь движек для “постоянного оборота” не привязанных к жесткому времени задач (моргать СВД, выпуск шасси, закрылков, бортовая “медленная” автоматика и тд), с разными готовыми РТОСами на этот счёт будет сложно договориться…
Поэтому планирую за основу взять простой движек дополнить семафорами и отдельным классом задач-обработчиков без собственного стека (которые ранее в порываниях крутились), да и было бы неплохо через USB монтировать СД или фрам на подключенный комп. Да ещё в перспективе “инвентаризировать” все устройства полетника в АПИ, ибо пользуем мы их в одних и тех же режимах (усарт, и2ц, спи, гпио), чтоб зоопарка “в низах” не было.

Вот ведь, оказывается, в фриртосе есть уже такой функционал, задачи без своего стека, сопрограммы называется… Вот и думай… то ли своё рисовать, то ли фриртос влепить? Вообщем если в течение недели своих результатов не будет, буду ртос ковырять.

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

Я думаю, даже уверен, что смысла ждать неделю нет. Лучше ее потратить на начало работы с 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, чего ещё надо ?, советую обратить внимание… (один минус описание слабовато…)

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

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