Специальные цены   новые товары
+ Ответить в теме
Страница 156 из 165 ПерваяПервая ... 146 154 155 156 157 158 ... ПоследняяПоследняя
Показано с 6,201 по 6,240 из 6569

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

Тема раздела Квадрокоптеры. Общие вопросы в категории Квадрокоптеры и мультироторы; Не знаю как у вас, а у нас кредит - это минимум 36% годовых, в "цивилизованном" мире пальцем у виска ...

  1. #6201

    Регистрация
    01.11.2010
    Адрес
    Belarus Slonim
    Возраст
    36
    Сообщений
    4,462
    Записей в дневнике
    8
    Не знаю как у вас, а у нас кредит - это минимум 36% годовых, в "цивилизованном" мире пальцем у виска покрутят с такими предложениями...

  2.  
  3. #6202

    Регистрация
    19.04.2010
    Адрес
    Ханты
    Возраст
    40
    Сообщений
    1,472
    Цитата Сообщение от SergDoc Посмотреть сообщение
    ну как сказать, оси типа ртос и чибиос... оно как-то не очень помогает, если у тебя всё выстроено до этого, наттикс - да такая никс-платформа позволяющая "пообщаться" с железом, но "тяжелая" да и добавление нового устройства - ацкий труд (... так бы мелкая уже давно под ней жила, сейчас как раз пытаюсь запустить отладочную консоль под чибиос и тоскую по консоли наттикса )))
    Вообще меня всё устраивало бы "на прерываниях", но дело всё в том, что по мере разрастания кода в вычислениях ИНС начали появляться пропуски низкоприоритетных прерываний (вывод в консоль, визуализация), так может дойти и до чтения приёмыша и отправки телеметрии. Посему надо отделить "низы" от "верхов", чтоб прерывания могли "переслать один байт" в процессе "размышлений о бытие". Сменить приоритеты не получиться, т.к. мелкие прерывания иногда тянут за собой тяжелые, но не критичные по времени и актуальности данных, расчеты. Ну и плюсом хотелось иметь движек для "постоянного оборота" не привязанных к жесткому времени задач (моргать СВД, выпуск шасси, закрылков, бортовая "медленная" автоматика и тд), с разными готовыми РТОСами на этот счёт будет сложно договориться...
    Поэтому планирую за основу взять простой движек дополнить семафорами и отдельным классом задач-обработчиков без собственного стека (которые ранее в порываниях крутились), да и было бы неплохо через USB монтировать СД или фрам на подключенный комп. Да ещё в перспективе "инвентаризировать" все устройства полетника в АПИ, ибо пользуем мы их в одних и тех же режимах (усарт, и2ц, спи, гпио), чтоб зоопарка "в низах" не было.
    Последний раз редактировалось rual; 25.01.2016 в 14:46.

  4. #6203

    Регистрация
    19.04.2010
    Адрес
    Ханты
    Возраст
    40
    Сообщений
    1,472
    Вот ведь, оказывается, в фриртосе есть уже такой функционал, задачи без своего стека, сопрограммы называется... Вот и думай.... то ли своё рисовать, то ли фриртос влепить? Вообщем если в течение недели своих результатов не будет, буду ртос ковырять.

  5. #6204

    Регистрация
    22.01.2014
    Адрес
    Москва
    Возраст
    36
    Сообщений
    234
    Цитата Сообщение от rual Посмотреть сообщение
    Вообщем если в течение недели своих результатов не будет, буду ртос ковырять.
    Я думаю, даже уверен, что смысла ждать неделю нет. Лучше ее потратить на начало работы с FreeRTOS.

  6.  
  7. #6205

    Регистрация
    19.04.2010
    Адрес
    Ханты
    Возраст
    40
    Сообщений
    1,472
    Цитата Сообщение от strizhmax Посмотреть сообщение
    Я думаю, даже уверен, что смысла ждать неделю нет. Лучше ее потратить на начало работы с FreeRTOS.
    Привет, Макс! Не скажи! Я вот обзаботился разобраться в деталях, как всё это работает, и щас смотрю исходники ртоса и всё понятно. Но мне все возможности фриртос особо не нужны (возможно пока) , посему я не буду ждать, а попытаюсь сделать необходимый функционал сам. К тому же заменить на фриртос мою поделку будет не сложно, вызовы методов сделаю аналогично фриртосу.

  8. #6206

    Регистрация
    22.01.2014
    Адрес
    Москва
    Возраст
    36
    Сообщений
    234
    Цитата Сообщение от rual Посмотреть сообщение
    Я вот обзаботился разобраться в деталях, как всё это работает, и щас смотрю исходники ртоса и всё понятно.
    Если все понятно, то зачем изобретать свое. FreeRTOS все же оттестирована и портирована на множество камней.

    Цитата Сообщение от rual Посмотреть сообщение
    К тому же заменить на фриртос мою поделку будет не сложно, вызовы методов сделаю аналогично фриртосу.
    Ну и смысл изобретать свой велосипед.

  9. #6207

    Регистрация
    15.09.2011
    Адрес
    Москва
    Возраст
    45
    Сообщений
    5,942
    Записей в дневнике
    22
    а выход есть - модульность.
    система стабилизации система навигации
    система визуальной ориентации
    у каждой из систем свой проц, все общаются по универсальной шине, сбой в одном из модулей не влечет последствий дляостальных.
    можно отказоустойчивый кластер втч с наблюдательными нодами)

  10.  
  11. #6208

    Регистрация
    01.11.2010
    Адрес
    Belarus Slonim
    Возраст
    36
    Сообщений
    4,462
    Записей в дневнике
    8
    здесь матерными словами писать нельзя дешевше "крутыми" датчиками обойтись )))

  12. #6209

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

    Но ГУИ и сетевые приложения безусловно нужно рисовать из под РТОС, хотя это другая история )))
    Цитата Сообщение от alexeykozin Посмотреть сообщение
    а выход есть - модульность.
    система стабилизации система навигации
    система визуальной ориентации
    у каждой из систем свой проц, все общаются по универсальной шине, сбой в одном из модулей не влечет последствий дляостальных.
    Алексей, дык оно и так: вся летательное ПО крутится в полётнике, управление двигателями в регулях, визио ( у кого есть) в отдельном вычислителе, ну и у пикса для переифиии отдельный проц... такшта, всё уже есть... Полетные же алгоритмы и так вполне надежны в плане "подвеса" вычислителя, но не надежны с точки зрения обработки инфы ( в разной степени) и получения результатов, тут поле не пахано ( ну мож только отдельными гражданами ).

    Цитата Сообщение от SergDoc Посмотреть сообщение
    дешевше "крутыми" датчиками обойтись )))
    насчет дешевле это вряд ли, то что лежит в цене тех же порядков ничего не даёт, а оптогироскопы это уже совсем другие деньги.
    Последний раз редактировалось rual; 26.01.2016 в 08:03.

  13. #6210

    Регистрация
    11.05.2008
    Адрес
    Великий Новгород
    Возраст
    38
    Сообщений
    3,939
    Записей в дневнике
    22
    Цитата Сообщение от rual Посмотреть сообщение
    обработчики событий (сопрограммы в терминах фриртос)... использовать сопрограммы как я хочу нельзя.
    в терминах freertos сопрограммы — подпрограмма с множеством точек выхода -> продолжения выполнения. в них пихают либо самые ненужные, либо самые простейшие действия, на которые действительно жалко тратить память. если обработчики событий попадают под это определение, то у вас очень необычный стиль программирования.

    Цитата Сообщение от rual Посмотреть сообщение
    у меня задачи и обработки будут статическими в виде глобальных структур. Что это дает? Нет сложного механизма списков и выделения памяти.
    а контролировать и гарантировать атомарность будете ручками? одна задача начнет запись в вашу глобальную структуру, планировщик запустит вторую задачу на чтение этой структуры, не до конца обновленной. собираетесь в конце каждой вешать флаг готово/не готово? не факт, что ваш велосипед не превысит сложность имеющихся и "незаметных" инструментов.

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

  14. #6211

    Регистрация
    19.04.2010
    Адрес
    Ханты
    Возраст
    40
    Сообщений
    1,472
    Цитата Сообщение от HikeR Посмотреть сообщение
    в терминах freertos сопрограммы — подпрограмма с множеством точек выхода -> продолжения выполнения. в них пихают либо самые ненужные, либо самые простейшие действия, на которые действительно жалко тратить память. если обработчики событий попадают под это определение, то у вас очень необычный стиль программирования.
    У меня наоборот, всё критичное выполняется в обработчиках, а в "задачах" самые некритичные действия.
    Цитата Сообщение от HikeR Посмотреть сообщение
    а контролировать и гарантировать атомарность будете ручками?
    Ручками, всё и так контролируется.

    Цитата Сообщение от HikeR Посмотреть сообщение
    не факт, что ваш велосипед не превысит сложность имеющихся и "незаметных" инструментов.
    Думаю что не превысит, но если превысит, так же легко уйду в ртос.

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

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

  15. #6212

    Регистрация
    11.05.2008
    Адрес
    Великий Новгород
    Возраст
    38
    Сообщений
    3,939
    Записей в дневнике
    22
    Цитата Сообщение от rual Посмотреть сообщение
    всё критичное выполняется в обработчиках, а в "задачах" самые некритичные действия.
    ну я и говорю, очень необычный стиль.

    Цитата Сообщение от rual Посмотреть сообщение
    вся обработка в прерывании, а надо чтоб в прерывании обновился датчик, после чего обработка прерывания завершается, управление предается планировщику, планировщик запускает вычисления.
    если вычисления полностью зависят от обновления датчика, то накой нужен планировщик? это линейная задача, практически атомарная, а вы ее зачем-то бьете на части. подозреваю, что с остальными "более 20 обработками" происходит так же.
    Последний раз редактировалось HikeR; 26.01.2016 в 10:56.

  16. #6213

    Регистрация
    19.04.2010
    Адрес
    Ханты
    Возраст
    40
    Сообщений
    1,472
    Цитата Сообщение от HikeR Посмотреть сообщение
    ну я и говорю, очень необычный стиль.
    Наверное, если обычным считать программирование на Бейсике.
    Цитата Сообщение от HikeR Посмотреть сообщение
    если вычисления полностью зависят от обновления датчика, то накой нужен планировщик? это линейная задача, практически атомарная, а вы ее зачем-то бьете на части.
    Нужен для разделения получения данных от их обработки. Бить на части нужно, потому что, способ получения данных ("низы") для разных платформ может быть разный, а "верхи", обработчик для всех один и обращается к абстрактному вектору из абстрактного датчика по обновлению данных в нём. Безусловно всё это можно было "выпрямить" в линейный алгоритм внутри задачи ртос, но так сложилось исторически, и упрощать это СЕЙЧАС я смысла не вижу. Зачем то, что работает явно, загонять в экосистему, которая от меня скрыта? Я просто хочу разорвать "атомарную цепочку" на "верх" и "низ" в процеесе выполнения, а не только в структуре проекта, ну и плюсом получить механизм "вращения" задач.

  17. #6214

    Регистрация
    26.11.2012
    Адрес
    Tambov
    Возраст
    46
    Сообщений
    777
    Цитата Сообщение от rual Посмотреть сообщение
    но дело всё в том, что по мере разрастания кода в вычислениях ИНС начали появляться пропуски низкоприоритетных прерываний
    Это признак того, что время выполнения прерывания уже больше периодичности вызова... (определяется и лечится легко).
    Цитата Сообщение от rual Посмотреть сообщение
    с разными готовыми РТОСами на этот счёт будет сложно договориться...
    Имею сказать - CoOS мучаю уже год, задержки прерываний -0, все вроде работает даже "из коробки", проще чем FREE RTOS, чего ещё надо ?, советую обратить внимание.. (один минус описание слабовато..)
    Цитата Сообщение от alexeykozin Посмотреть сообщение
    у каждой из систем свой проц, все общаются по универсальной шине,
    Реализовать это "общение" - задача не из тривиальных, и дико медленно получится, и по факту на каждом "модуле" должна быть многозадачность, иначе приоритет задач общения придется ставить наивысшим... т.е. о реалтайме можно забыть... (короче - думал, пробовал, непонравилось, выкинул....))))

  18. #6215

    Регистрация
    19.04.2010
    Адрес
    Ханты
    Возраст
    40
    Сообщений
    1,472
    Новый проект, где большее количество задач и меньше критичность по выполнению, буду делать на ртос. Торжественно клянусь )))

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

  19. #6216

    Регистрация
    26.11.2012
    Адрес
    Tambov
    Возраст
    46
    Сообщений
    777
    Цитата Сообщение от rual Посмотреть сообщение
    меньше, чем вычисление "навалившихся" приоритетных,
    Тогда это проблема не в прерываниях-как таковых, а в расстановке приоритетов... (причёсывать надо).

  20. #6217

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

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

  21. #6218

    Регистрация
    26.11.2012
    Адрес
    Tambov
    Возраст
    46
    Сообщений
    777
    Цитата Сообщение от rual Посмотреть сообщение
    Так понятно?
    Понятно.. Просто из двух "конкурирующих реалтаймов" (ДУС и ППМ), один наверно придётся в "свободное плавание" отпустить с поправкой на SysTick.. , хотя возможные задержки и искажения результатов могут быть настолько малы что ими можно пренебречь.. (это просто мысли вслух, не более.. у меня ППМа нету, главный - ДУС и всё.., поэтому и проблем этих нет))

  22. #6219

    Регистрация
    22.01.2014
    Адрес
    Москва
    Возраст
    36
    Сообщений
    234
    Цитата Сообщение от rual Посмотреть сообщение
    "вдруг" привалило данных по датчикам ИНС, стало быть в приоритетных прерываниях надо последовательно обсчитать
    Не нужно в прерываниях ничего считать. Только забрать данные которые "вдруг" "привалили" и выставить флаг (семафор) для задачи которая все это обсчитает.

  23. #6220

    Регистрация
    19.04.2010
    Адрес
    Ханты
    Возраст
    40
    Сообщений
    1,472
    Цитата Сообщение от strizhmax Посмотреть сообщение
    Не нужно в прерываниях ничего считать.
    Это так, но если очень хочется, то можно ))) Пока хватало, вот когда сделал "виртуального" летуна, тут и проблемы начались, ибо все данные для обработки "приплывают" разом в одном пакете.

    Цитата Сообщение от strizhmax Посмотреть сообщение
    Только забрать данные которые "вдруг" "привалили" и выставить флаг (семафор) для задачи которая все это обсчитает.
    Так и буду делать, только через вращатель программных прерываний, которые будут ниже железных по приоритету.

  24. #6221

    Регистрация
    24.02.2015
    Адрес
    Берлин
    Возраст
    31
    Сообщений
    754
    Кто знает, что это за ребята? Не vis.asta ли и ко?

  25. #6222

    Регистрация
    01.11.2010
    Адрес
    Belarus Slonim
    Возраст
    36
    Сообщений
    4,462
    Записей в дневнике
    8
    не...

  26. #6223

    Регистрация
    04.06.2015
    Адрес
    Екатеринбург
    Возраст
    40
    Сообщений
    240
    Цитата Сообщение от oleg70 Посмотреть сообщение
    Не, есть конечно плата "NAVIO Rpi", и и там якобы всё работает, но во первых подозрительно это как то (не верю), во вторых эта тема с ней как то заглохла (что подверждает "первое")
    У меня есть плата Navio+. Пробовал её на RPi B+ (как рекомендуют разработчики EMLID). Рама Tarot650 несколько раз летала с ней - всё нормально работает. RPI бралась для того чтоб на ней и летать, и видео на лету кодировать, и управлять коптером через дальнобойную USB Wi-Fi карточку. В принципе, всё это получилось.

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

  27. #6224

    Регистрация
    11.05.2008
    Адрес
    Великий Новгород
    Возраст
    38
    Сообщений
    3,939
    Записей в дневнике
    22
    Цитата Сообщение от seaowl Посмотреть сообщение
    любая нестабильность по питанию сильно отражается на надёжности работы малины.
    это единственная причина, все остальное вами перечисленное — следствие.
    плюс (по опыту съемки малины с камерой) почти любая Pi (кроме Zero, ее не пробовал) очень сильно не дружит с наводками от моторов/передатчиков, в идеале нужно независимое питание от отдельного аккумулятора.

  28. #6225

    Регистрация
    04.06.2015
    Адрес
    Екатеринбург
    Возраст
    40
    Сообщений
    240
    Насчёт программирования задач реального времени (в широком смысле этого слова), - есть всем известная прекрасная плата BeagleBoneBlack на проце ARM Sitara AM3358. Внутри этого проца есть блок с двумя сопроцессорами "реального времени", называемыми PRU0 и PRU1. Они работают отдельно от основного проца на частоте 200 МГц, и могут обмениваться с ним данными. На этих PRU0 и PRU1 можно обрабатывать сигналы протоколов связи к примеру радиомодем, какие-нибудь отдельные i2c, spi, генерировать высокоточный PWM для ESC, или работать с IMU. Говорили что они предназначены именно для работы с различными аппаратными техническими интерфейсами, да и вся плата имеет некоторую "инструментальную" направленность. Производительности для большинства задач должно хватить, весь PixHawk работает на 168 МГц. Есть достаточно удобные средства разработки для PRU на языке C, они даже работают (пробовал лично).


  29. #6226

    Регистрация
    01.11.2010
    Адрес
    Belarus Slonim
    Возраст
    36
    Сообщений
    4,462
    Записей в дневнике
    8
    Может дурь скажу, но как-то не укладывается в голове один маааааленький нюанс:
    вот считаем мы угол с ДУС и угол с акселя да, и что откуда мы берём?
    берём интеграл угловой скорости - правильно? - так это по сути мы заглядываем в будушее на время DT (т.е. при зафиксированной скорости через время DT будет такой угол) , а берём угол с акселя - уже свершившийся факт...

  30. #6227

    Регистрация
    19.04.2010
    Адрес
    Ханты
    Возраст
    40
    Сообщений
    1,472
    Цитата Сообщение от SergDoc Посмотреть сообщение
    берём интеграл угловой скорости - правильно? - так это по сути мы заглядываем в будушее на время 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_корректора.

    Цитата Сообщение от SergejK Посмотреть сообщение
    Кто знает, что это за ребята? Не vis.asta ли и ко?
    Это вот эти
    Последний раз редактировалось rual; 29.01.2016 в 18:49.

  31. #6228

    Регистрация
    26.11.2012
    Адрес
    Tambov
    Возраст
    46
    Сообщений
    777
    Цитата Сообщение от seaowl Посмотреть сообщение
    От мультимедийной работы RPi иногда перезагружалась, а если это случится в полёте, то коптеру пипец.
    С питанием можно проблему можно решить недорого и просто (влепить отдельный импульсный рег. типа LM2596 или мельче), а вот все остальное.. - незнаю, патч к линуксу в сети "ругают", ды и не даёт он 100% реалтайма, а лишь уменьшает время задержки (?), выводы делайте сами.. Всё что мне удалось выяснить в процессе "издевательств" над линуксом - он в некоторых моментах/случаях может чуть ли не на 2 секунды заблокировать любую задачу.. поэтому нагружать его помимо управления полетом другими задачами крайне рискованно..
    Цитата Сообщение от SergDoc Посмотреть сообщение
    не укладывается в голове один маааааленький нюанс:
    по факту - данные как бы вообще идут вразнобой с разных датчиков в реальном времени, аксель то еще ладно, а магнитометр вообще 20 Гц читать только можно, но тем не менее они сводятся одним алгоритмом расчета положения.. тут кстати получается типа ФВЧ для акселя.. (пробовал читать ДУС 500 Гц, а аксель 20 всё работает и довольно неплохо..)
    Цитата Сообщение от SergDoc Посмотреть сообщение
    по сути мы заглядываем в будушее
    Нет, как раз в "настоящее" т.е. - на момент времени выборки имеем пройденный угловой путь..

  32. #6229

    Регистрация
    01.11.2010
    Адрес
    Belarus Slonim
    Возраст
    36
    Сообщений
    4,462
    Записей в дневнике
    8
    Цитата Сообщение от oleg70 Посмотреть сообщение
    Нет, как раз в "настоящее" т.е. - на момент времени выборки имеем пройденный угловой путь..
    нее - для алгоритмов настоящее - это свершившийся факт (для нас прошлое - утрированно), т.е. если принять за точку отсчёта настоящего, то это именно обработка данных, но в это время, одни данные - это уже прошлое, а некоторые - предположительное будущее!....

  33. #6230

    Регистрация
    26.11.2012
    Адрес
    Tambov
    Возраст
    46
    Сообщений
    777
    Цитата Сообщение от SergDoc Посмотреть сообщение
    нее - для алгоритмов настоящее - это свершившийся факт (для нас прошлое - утрированно), т.е. если принять за точку отсчёта настоящего, то это именно обработка данных, но в это время, одни данные - это уже прошлое, а некоторые - предположительное будущее!....
    Формулировка, сложновата черезчур и довольно запутана))) Я б так сказал - при цифровом методе регулирования, актуальны те данные, которые имеются на момент "выборки", все остальное время не в счет.. - это погрешность..
    Отсюда - чем выше частота выборок тем точнее система.. , идеальный случай - полный аналог (датчики + регулятор + исп. устройство), где частота выборки условно равна бесконечности..

    Цитата Сообщение от seaowl Посмотреть сообщение
    - есть всем известная прекрасная плата BeagleBoneBlack
    Интересная штучка, посмотрел, спасибо.. Только опять возникает вопрос (применительно к нашей теме) - ну сделали там отдельные "реалтаймовые ядра" (в т.ч. тем самым подняли цену)), а есть ли для Линукса программная поддержка этого "блока" (??) или опять Линукс "сам по себе" - а ралтайм "сам по себе" (?) ... это я про магический "L3 Interconnect" на блок схеме..
    В принципе у дешевой RPi тоже имеется 4 полноценных ядра, ды и периферия та- же почти, вопрос в программном обеспечении только...
    Последний раз редактировалось oleg70; 30.01.2016 в 12:40.

  34. #6231

    Регистрация
    11.05.2008
    Адрес
    Великий Новгород
    Возраст
    38
    Сообщений
    3,939
    Записей в дневнике
    22
    Цитата Сообщение от oleg70 Посмотреть сообщение
    ну сделали там отдельные "реалтаймовые ядра" (в т.ч. тем самым подняли цену)), а есть ли для Линукса программная поддержка этого "блока" (??)
    512 байт оперативки и 4 Кб для программы на один PRU, ассемблер с 40 RISC-командами, отсутствие умножения... какой линукс? это "помогайки" для реализации интерфейсов или DSP, не более.

  35. #6232

    Регистрация
    26.11.2012
    Адрес
    Tambov
    Возраст
    46
    Сообщений
    777
    Цитата Сообщение от HikeR Посмотреть сообщение
    это "помогайки" для реализации интерфейсов или DSP, не более.
    понятно, в топку....))

  36. #6233

    Регистрация
    01.11.2010
    Адрес
    Belarus Slonim
    Возраст
    36
    Сообщений
    4,462
    Записей в дневнике
    8
    вариация на тему малина+ http://erlerobotics.com/blog/product/pxfmini/

  37. #6234

    Регистрация
    11.05.2008
    Адрес
    Великий Новгород
    Возраст
    38
    Сообщений
    3,939
    Записей в дневнике
    22
    схемы нет, софта нет. оно просто отдает сырые данные?

  38. #6235

    Регистрация
    01.11.2010
    Адрес
    Belarus Slonim
    Возраст
    36
    Сообщений
    4,462
    Записей в дневнике
    8
    это шилд к малине с каким-то 103-м процем ввиде выхода шим и датчиками 9250 5X89 5611 код открытый в арду...

  39. #6236

    Регистрация
    10.12.2013
    Адрес
    Люберцы
    Возраст
    33
    Сообщений
    168
    Если хотите реалтайм + "мощный" ARM с линуксом, то нужно ставить ARM+FPGA )))). Сколько угодно выходов шим, любые интерфейсы, самый реалтаймый реалтайм))). Что-то типо того http://habrahabr.ru/company/metrotek/blog/235707/.

  40. #6237

    Регистрация
    26.11.2012
    Адрес
    Tambov
    Возраст
    46
    Сообщений
    777
    Цитата Сообщение от djdron Посмотреть сообщение
    нужно ставить ARM+FPGA )))).
    Спецам по линуксу надо просто сделать "правильный кряк" ядра, а железа то у любого ARMa хватает, нам для задачи стабилизации достаточно одного SPI или даже I2C, на худой конец... лишь бы работу с ними никто не мог "вытеснить" ... и желательно прерывания по аппаратному таймеру.. (вот и всё счастье)))

  41. #6238

    Регистрация
    19.04.2010
    Адрес
    Ханты
    Возраст
    40
    Сообщений
    1,472
    Цитата Сообщение от strizhmax Посмотреть сообщение
    Я думаю, даже уверен, что смысла ждать неделю нет. Лучше ее потратить на начало работы с FreeRTOS.
    Таки изобрёл велосипед))) По сути обработчик программных прерываний, обработчик событий. Особо если портировать на АВР, там аппаратных прерываний мало.

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

  42. #6239

    Регистрация
    26.11.2012
    Адрес
    Tambov
    Возраст
    46
    Сообщений
    777
    Подскажите , кто может, - как сделать чтоб коптер не разворачивало по "Yaw" на 360 гр. при переходе через "0-360" град. (всю голову сломал, не могу придумать, прям "ручник" какой то)))),
    т.е. на ПИД по "Yaw" подаем 0-360 гр. с ИМУ и уставку 0-360 гр... получаем в районе перехода 0-360 сигнал управления на целый оборот....(?), как у людей то сделано ??.

  43. #6240

    Регистрация
    19.04.2010
    Адрес
    Ханты
    Возраст
    40
    Сообщений
    1,472
    Цитата Сообщение от oleg70 Посмотреть сообщение
    получаем в районе перехода 0-360 сигнал управления на целый оборот....(?), как у людей то сделано ??.
    Ну тут вроде всё просто: если разность больше 180, вычитай или прибавляй 360 (т.е. полный оборот). Хотя математически правильно на выходе иму получить угол +-Пи, а преобразование в азимутальный 0-360 только для индикации.

+ Ответить в теме

Похожие темы

  1. Система стабилизации гиро+акселерометр
    от Фантомас в разделе Полеты по камере, телеметрия
    Ответов: 32
    Последнее сообщение: 25.01.2011, 14:47
  2. Продам Продам Клона Trex 450SEV2 + Аппаратура + Запчасти+ система стабилизации RTF
    от omegapraim в разделе Барахолка. Вертолеты
    Ответов: 1
    Последнее сообщение: 12.01.2011, 18:16
  3. Продам Трёхосевую систему стабилизации Turnigy V-Bar 600
    от avi@tor в разделе Барахолка. Аппаратура
    Ответов: 1
    Последнее сообщение: 08.11.2010, 13:02
  4. Продам Gaui система стабилизации GU365, дёшево.
    от avi@tor в разделе Барахолка. Вертолеты
    Ответов: 3
    Последнее сообщение: 03.08.2010, 11:13
  5. Системы стабилизации
    от max815 в разделе Фото и видеосъемка, системы стабилизации
    Ответов: 16
    Последнее сообщение: 11.03.2010, 03:14

Метки этой темы

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения