Search in topic

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

короче я опять отстал (

Серёг, нафига за ними гнаться? Ну чес слово… А плата классная! Однако, если приглядеться повнимательней… - это F4BY в миниупаковке!
Посему ты был первый ) Важно ПО, если есть что предложить, то проект будет жить, если нет, то увы…

что аналоговый rc, lc, фильтр, ну или на операционнике лучше цифровых (программных) фильтров,

Таки да, фильтры должны стоять ДО АЦП(вообще по-человечески это называется не LPF, а устройство выборки-хранения) и обеспечивать интеграцию аналогового сигнала за промежуток времени, отведенный для измерения. Это даёт возможность получить достаточно точную цифровую копию (за срезом ВЧ) аналогового сигнала.

Важно ПО, если есть что предложить, то проект будет жить, если нет, то увы…

Парадокс, но F4BY живёт только за счёт арды и, боюсь, очень трудно кого-либо перекрестить в другую религию перевести на другое ПО 😦
заметь, на счёт арды - это мы с тобой замутили )))

Парадокс, но F4BY живёт только за счёт арды и, боюсь, очень трудно кого-либо перекрестить в другую религию перевести на другое ПО

Это да… Но там щас вроде муть какая-то, типа ПО уже не открытое?
А я вот всё своё пилю-пилю, никак допилить не могу… Назрел вопрос с ОСью, но я же не могу взять готовое 😁😈

заметь, на счёт арды - это мы с тобой замутили )))

Да, было дело, целый месяц из жизни ) Но доводили то до рабочей версии вы с Максом.

А так, насчет арды, то она за время от рождения F4BY серьезно подросла, удобна и проста для пользователя, но при этом гибка и функциональна… эт я по слухам сужу)

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

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

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

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

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

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

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

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

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

да, только без тебя, рабочей концепции платы не было бы)))
я сейчас на распутье с мелкой (её всё равно переделывать - мой косяк 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();
}
со вставкой в начало каждой задачи простейшего диспетчера отслеживающего количество тиков.

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

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