Как ни парадоксально звучит — потому что в некоторых областях Arduino подходит лучше, чем Linux устройства. Ключевое слово — система реального времени. Да, я знаю что и для linux пытаются сделать такую модификацию, но по моему это все зря, в связке с риалтайм сопроцессором сдеать это гораздо проще, а железо стоит копейки (+2-4$ за достаточно навороченный STM32).
Вот пример такого гибрида http://beagleboard.org/BLACK, только сопроцессор там очень слабенький, порты IO и немного DSP.
А разве шалоны не ведут к увеличению объема кода? К примеру у меня есть функция на 10 экранов, которая оперирует матрицами любого размера. Для возможности обращения вида a[i][j] нужно заранее определеить во всех переменных размерность матрицы, и это красиво делается при помощи шаблона. Но когда я вызову эту функцию для матрицы 3X3 и 4x4, разве компилятор не сделает 2 коппии кода фунции? Если задача экономить FLASH память, то очевидно шаблоны не лучшее решение.
Спасибо за развернутое объяснение, попробую на практике. ld-скрипты это то что я пропустил из-за их сложности, остановился на первом рабочем примере из того, что удалось найти.
В общем то new мне не нужен в проекте, поэтому я глубже не копал. Но думаю, вытянуть только часть функционала C++ связанного с конструкторами, и не тянуть исключения и прочее, будет достаточно сложно. Кстати, при создании объекта статически конструкторы не отрабатывают. Тоже нужно разибираться, почему.
Да, но они и не рабатают как надо. Выше я написал, что компилятор из всего конструктора выполняет только инициализацию переменных, которые указаны до фигурных скобок. Само тело конструктора не выполняется.
Да я особо не разбирался, просто достаточно упомянуть оператор 'new' и размер бинарника увеличивается на 40к. Это сам механизм конструкторов и выделения памяти, даже если сами фукнции пустые.
Причина в ограниченных ресурсах памяти FLASH и производительности. Конструкторы тянут достаточно много сервисного кода за собой, зато при их отсутсвии код сравним с генерируемым из С.
Из соображения что матрица F в выражении u_k = -Fx_k — константа, а x_k — вектор состоящий из x, dx, d2x в разных комбинациях. После перемножения и группировок получим все те же константы при x, dx, d2x что очень похоже на PID.
Но это только мое предположение, не судите строго :)
Уже давно использую "C++ с ограничениями" для микроконтроллеров, так как читабельнсть и структурирование кода в разы выше, чем на С. Если проект большой и сложный, то C++ здорово выручает. При этом практически не отличается от C в плане потребления ресурсов. Вот ограничения:
не используется динамическое выделение памяти и куча вообще. Все место отдано под стэк. Как правило, переменные состояния нужны на все время функционирования программы и прекрасно живут в статике. Если нужно выполнить операцию с большим расходом памяти, это делается объявлением переменных и объектов класса внутри функции. Такой подход автоматически избавляет от необходимости следить за фрагментацией кучи.
не используются конструкторы и деструкторы, кроме пустых конструкторов прямой инициализации:
SomeClass(int v1, int v2): member1(v1), member2(v2) {}
они компилятором правильно разворачиваются без доп. кода.
Если предполагается создать всего один экземпляр класса, то все функции и члены класса — статические. Результат компиляции ничем не отличается от С, но выигрывает синтаксисом.
Использование интерфейсов и мультинаследования бывает очень удобно, но приводит к расходу памяти (все нужные объекты всех реализаций создаются статически, и потом просто выбирается необходимая реализация). Впрочем, тут можно очень аккуратно использовать malloc — как правило, выбор реализаций интерфейса зависит от настроек и создается один раз при старте системы, удалять его не нужно и дефрагментация не страшна.
Ну у вас же 2 коэффициента a и b: один на расстояние — аналог Kp, другой при производной — аналог Kd:
u = Kpx + Kddx
Похоже что и в общем нелинейном случае если кол-во пременных состояния не более трех, управление сводится к PID, Если больше, то к одной из его каскадных версий или версии с 2-мя степенями свободы. И в этом случае LQR полезен тем что аналитически найдет коэффициенты под заданный критерий.
Вот реальный пример: STM32F303 с ядром M4F, компилятор gcc (arm-none-eabi). Использую fabsf(val) в коде — заменяется на одну инструкцию VABS.F32. Но в функциях из <math.h>, например atan2f() вызовы fabsf() ведут на софтовую реализацию. Притом что в этой фукнции ЕСТЬ другие инструкции FPU, то есть линкер подключает вроде как правильную библиотеку, заточенную под сопроцессор. Что это, недоработки реализации?
Физика это хорошо, только модель очень условно описывает реальный процесс, все тонкости железной реализации учесть сложно. А если динамика ещё и меняться может, то регулятору проще рассматривать процесс как черный ящик, а не строить контроллер только на аналитических моделях. Как я понял, LQR, описанный в википедии, строит контроллер именно аналитически, без сбора реальных данных и подстройки "по месту"?
Мне (как практически нулевому математику) PID контроллер интуитивно понятен и нравится с одной стороны простотой, с другой стороны большим объемом теоретических исследований и их практических применений, в том числе и по автонастройке под разные критерии. Но и познакомиться с другими алгоритмами тоже интересно, а вдруг они лучше PID?
У вас в итоге получился обычный PD контроллер, но как-то совсем с другой стороны :)
Адаптация контроллера в процессе работы, это на мой взгляд уже высшее исскуство математической магии :) Особенно адаптация под изменяющиеся условия без прерыани работы, т.е. без возможности провести специальные эксперименты по сбору доп. данных
Долго вникал в LQR но нифига не понял, чем он лучше PID контроллера, если критерий оптимальности все равно с потолка берется. Что такое minimum cost? А если мы от розетки питаемся и электричества не жалко, а нужен наилучший результат следования цели, то этот метод бесполезен?
Ещё интересно, применим ли он если полного знания о динамике системы нет? Например, на сигвей стал малыш 15кг или дядя в 120кг. Динамика же меняется в разы.
RCTimer BGM2804 очень хорош, уже штук 8 купил для разных проектов стабилизаторов, нареканий по качеству нет. Даже беззеркалку в консольном варианте держит (но это не для полетов, все таки момент слабоват для нее). Типичные проблемы, которые бывают и на которые надо обратить внимание: люфты (сразу есть или появляются со временм из-за некачественных подшипников), сильная неравномерность магнитного поля (бывает ОЧЕНЬ сильная, такие мотры проще выбросить чем ими пытаться стабилизировать), трение в подшипнике, плохо припаяны провода и фаза рвется при неосторожном обращении, неравномерность намотки. Как правило, самая частая проблема — это люфты.
К примеру, мой проект компилируется gcc, без подключения DSP_lib. При беглом просмотре ассемблерного листинга видно, что он активно использует инструкции FPU, и иногда даже проскальзываю инструкции DSP. Но например, sqrtf() он не заменил на аппаратную реализацию. Получается, что не обязательно тянуть в проект DSP_lib, так как по большей части эти инструкции оптимизирует сам компилятор, и DSP_lib полагается на него.
Я поясню в чем вопрос. Возьмем к примеру из исходников DSP_lib функцию arm_abs_f32() — там нет никаких специальных вызовов, кроме стандартной fabsf() из <math.h>. То же самое в arm_mult_f32() — обычная конструкция pDst++ = (pSrcA++) (pSrcB++);
На каком этапе происходит вызов FPU-инструкций?
VABS.F32 получение абсолютного значения операнда
VFMA.F32 перемножение двух переменных, прибавление результата умножения к содержимому указанного регистра
А как насчет поддержки DSP-инструкций компиляторами? В исходниках CMSIS-DSP нет явных ассемблерных команд обращения к DSP-инструкциям. На первый взгляд обычные арифметические операции. Вероятно, предполагается что компилятор их сам оптимизирует?
Странно, что в массы не пошли электростаты. Очень подходящий продукт для единичного производства — буквально на коленке можно собрать. Небольшие компании могли бы этим вполне себе заняться.
По характеру колебаний, видимо. Есть физический закон, по нему строится модель, где есть некие неизвестные M1 и M2 (а может и больше), она выдает опреденные параметры излучения, которые можно замерить. Можно решить обратную задачу и найти исходные параметры.
Вот пример такого гибрида http://beagleboard.org/BLACK, только сопроцессор там очень слабенький, порты IO и немного DSP.
Удаление неиспользуемых функций включено.
Но это только мое предположение, не судите строго :)
SomeClass(int v1, int v2): member1(v1), member2(v2) {}
u = Kpx + Kddx
Похоже что и в общем нелинейном случае если кол-во пременных состояния не более трех, управление сводится к PID, Если больше, то к одной из его каскадных версий или версии с 2-мя степенями свободы. И в этом случае LQR полезен тем что аналитически найдет коэффициенты под заданный критерий.
Мне (как практически нулевому математику) PID контроллер интуитивно понятен и нравится с одной стороны простотой, с другой стороны большим объемом теоретических исследований и их практических применений, в том числе и по автонастройке под разные критерии. Но и познакомиться с другими алгоритмами тоже интересно, а вдруг они лучше PID?
У вас в итоге получился обычный PD контроллер, но как-то совсем с другой стороны :)
Адаптация контроллера в процессе работы, это на мой взгляд уже высшее исскуство математической магии :) Особенно адаптация под изменяющиеся условия без прерыани работы, т.е. без возможности провести специальные эксперименты по сбору доп. данных
Ещё интересно, применим ли он если полного знания о динамике системы нет? Например, на сигвей стал малыш 15кг или дядя в 120кг. Динамика же меняется в разы.
На каком этапе происходит вызов FPU-инструкций?
VABS.F32 получение абсолютного значения операнда
VFMA.F32 перемножение двух переменных, прибавление результата умножения к содержимому указанного регистра