В общем то 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 (а может и больше), она выдает опреденные параметры излучения, которые можно замерить. Можно решить обратную задачу и найти исходные параметры.
"начинающие разработчики встроенных приложений для автомобилей " — после этой фразы становится страшно садиться за руль :)
А то чем пугает автор в статье в примере про руль, называется "теория управления", она достаточно сложна, зато хорошо проработана и изучена. Конечно, программист интерфейсов в нее въезжать будет долго, для этого есть специальные отделения в ВУЗах где пару лет учат этому.
На самом деле полезная статья. Опасность литиевых батарей мало кто понимает, если не сталкивался с ними. Бояться качественных Li-Ion батарей, корорые используются в подавляющем большинстве техники, не стоит (хотя и там бывают недоработки, вызывающие возгорания в ноутбуках именитых брендов). Но сейчас стало появляться много китайской техники вроде тех же гироскутеров, где используются мощные Li-Po батареи, и я очень допускаю что в попытке съэкономить туда могут не поставить защиту вообще, или использовать компоненты недостаточной точности, или просто не проработанные до конца схемы, при производстве зарядных устройств для них, искренее не понимая всю серьезность такой ошибки. Личный пример: приобрел китайский зарядник на HobbyKing, и понимая риски перезаряда, естественно проверил точность напряжений. На одной банке он стабильно выдавал 4.30В вместо предельных 4.20В для LiPo. Скорее всего взяли правильную схему и поставили резистор не из той группы допуска (они же дороже!). 4.30В в тестах на 1000шт может и не вызовет проблем, а на 1001 бахнет.
Вы используете обычные узконаправленные сенсоры или какие-то специальные модификации? По идее широкая диаграмма направленности достаточно критична для такого проекта, может этим объясняются большие ошибки, которые иногда проскакивают?
Какой минимальный процент излучателей в прямой видимости необходим (т.е. насколько система чувствительна к препятсвиям и вообще характеристикам помещения)?
Несколько мыслей: можно было б сразу «из коробки» совместить с инерциалнкой, чтобы отфильтровать выбросы. Можно задать модель динамики системы, как в некоторых GPS, по ней определять достоверность новых данных.
Проект очень полезный, удачи в развитии! Стоимость вполне адекватная (с учетом отсутсвия каких-то вменяемых альтернатив).
Удаление неиспользуемых функций включено.
Но это только мое предположение, не судите строго :)
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 перемножение двух переменных, прибавление результата умножения к содержимому указанного регистра
А то чем пугает автор в статье в примере про руль, называется "теория управления", она достаточно сложна, зато хорошо проработана и изучена. Конечно, программист интерфейсов в нее въезжать будет долго, для этого есть специальные отделения в ВУЗах где пару лет учат этому.
Какой минимальный процент излучателей в прямой видимости необходим (т.е. насколько система чувствительна к препятсвиям и вообще характеристикам помещения)?
Несколько мыслей: можно было б сразу «из коробки» совместить с инерциалнкой, чтобы отфильтровать выбросы. Можно задать модель динамики системы, как в некоторых GPS, по ней определять достоверность новых данных.
Проект очень полезный, удачи в развитии! Стоимость вполне адекватная (с учетом отсутсвия каких-то вменяемых альтернатив).