Создание собственной системы стабилизации
Кто знает, что это за ребята? Не vis.asta ли и ко?
не…
Не, есть конечно плата “NAVIO Rpi”, и и там якобы всё работает, но во первых подозрительно это как то (не верю), во вторых эта тема с ней как то заглохла (что подверждает “первое”)
У меня есть плата Navio+. Пробовал её на RPi B+ (как рекомендуют разработчики EMLID). Рама Tarot650 несколько раз летала с ней - всё нормально работает. RPI бралась для того чтоб на ней и летать, и видео на лету кодировать, и управлять коптером через дальнобойную USB Wi-Fi карточку. В принципе, всё это получилось.
Не понравились три момента, касающиеся не платы Navio, а самой Raspberry Pi:
- RPi надо как-то питать, на плате автопилота не предусмотрено блока питания для малины. И любая нестабильность по питанию сильно отражается на надёжности работы малины.
- RPI модели B+ - громоздкая, и я мог бы ей это простить, если бы все 4 USB-порта работали нормально, но это не всегда так.
- обнаружилось что работать с мультимедиа на том же проце который управляет полётом - крайне опасно. От мультимедийной работы RPi иногда перезагружалась, а если это случится в полёте, то коптеру пипец.
любая нестабильность по питанию сильно отражается на надёжности работы малины.
это единственная причина, все остальное вами перечисленное — следствие.
плюс (по опыту съемки малины с камерой) почти любая Pi (кроме Zero, ее не пробовал) очень сильно не дружит с наводками от моторов/передатчиков, в идеале нужно независимое питание от отдельного аккумулятора.
Насчёт программирования задач реального времени (в широком смысле этого слова), - есть всем известная прекрасная плата BeagleBoneBlack на проце ARM Sitara AM3358. Внутри этого проца есть блок с двумя сопроцессорами “реального времени”, называемыми PRU0 и PRU1. Они работают отдельно от основного проца на частоте 200 МГц, и могут обмениваться с ним данными. На этих PRU0 и PRU1 можно обрабатывать сигналы протоколов связи к примеру радиомодем, какие-нибудь отдельные i2c, spi, генерировать высокоточный PWM для ESC, или работать с IMU. Говорили что они предназначены именно для работы с различными аппаратными техническими интерфейсами, да и вся плата имеет некоторую “инструментальную” направленность. Производительности для большинства задач должно хватить, весь PixHawk работает на 168 МГц. Есть достаточно удобные средства разработки для PRU на языке C, они даже работают (пробовал лично).
Может дурь скажу, но как-то не укладывается в голове один маааааленький нюанс:
вот считаем мы угол с ДУС и угол с акселя да, и что откуда мы берём?
берём интеграл угловой скорости - правильно? - так это по сути мы заглядываем в будушее на время DT (т.е. при зафиксированной скорости через время DT будет такой угол) , а берём угол с акселя - уже свершившийся факт…
берём интеграл угловой скорости - правильно? - так это по сути мы заглядываем в будушее на время DT (т.е. при зафиксированной скорости через время DT будет такой угол)
Не совсем, скорее наоборот - прошлое, хотя и не dt датчика, а на dt вычисления и принятия решения о воздействии.
- ДУС измерил угловую скорость от момента 0 до dt;
- в dt+dt_прерывания он сообщил, что измерил,
- в момент dt+dt_прерывания+dt_передачи данные пришли в проц ;
4.в момент dt+dt_прерывания+dt_передачи +dt_вычисителя алго изменил своё кажущееся положение;
5.в момент dt+dt_прерывания+dt_передачи +dt_вычислителя+dt_автопилота принимается рещение об управлении.
Итого: dt+dt_прерывания+dt_передачи +dt_вычислителя+dt_автопилота.
Для акселя почти так же: dt+dt_прерывания+dt_передачи +dt_вычислителя+dt_корректора.
Кто знает, что это за ребята? Не vis.asta ли и ко?
Это вот эти
От мультимедийной работы RPi иногда перезагружалась, а если это случится в полёте, то коптеру пипец.
С питанием можно проблему можно решить недорого и просто (влепить отдельный импульсный рег. типа LM2596 или мельче), а вот все остальное… - незнаю, патч к линуксу в сети “ругают”, ды и не даёт он 100% реалтайма, а лишь уменьшает время задержки (?), выводы делайте сами… Всё что мне удалось выяснить в процессе “издевательств” над линуксом - он в некоторых моментах/случаях может чуть ли не на 2 секунды заблокировать любую задачу… поэтому нагружать его помимо управления полетом другими задачами крайне рискованно…
не укладывается в голове один маааааленький нюанс:
по факту - данные как бы вообще идут вразнобой с разных датчиков в реальном времени, аксель то еще ладно, а магнитометр вообще 20 Гц читать только можно, но тем не менее они сводятся одним алгоритмом расчета положения… тут кстати получается типа ФВЧ для акселя… (пробовал читать ДУС 500 Гц, а аксель 20 всё работает и довольно неплохо…)
по сути мы заглядываем в будушее
Нет, как раз в “настоящее” т.е. - на момент времени выборки имеем пройденный угловой путь…
Нет, как раз в “настоящее” т.е. - на момент времени выборки имеем пройденный угловой путь…
нее - для алгоритмов настоящее - это свершившийся факт (для нас прошлое - утрированно), т.е. если принять за точку отсчёта настоящего, то это именно обработка данных, но в это время, одни данные - это уже прошлое, а некоторые - предположительное будущее!..
нее - для алгоритмов настоящее - это свершившийся факт (для нас прошлое - утрированно), т.е. если принять за точку отсчёта настоящего, то это именно обработка данных, но в это время, одни данные - это уже прошлое, а некоторые - предположительное будущее!..
Формулировка, сложновата черезчур и довольно запутана))) Я б так сказал - при цифровом методе регулирования, актуальны те данные, которые имеются на момент “выборки”, все остальное время не в счет… - это погрешность…
Отсюда - чем выше частота выборок тем точнее система… , идеальный случай - полный аналог (датчики + регулятор + исп. устройство), где частота выборки условно равна бесконечности…
- есть всем известная прекрасная плата BeagleBoneBlack
Интересная штучка, посмотрел, спасибо… Только опять возникает вопрос (применительно к нашей теме) - ну сделали там отдельные “реалтаймовые ядра” (в т.ч. тем самым подняли цену)), а есть ли для Линукса программная поддержка этого “блока” (??) или опять Линукс “сам по себе” - а ралтайм “сам по себе” (?) … это я про магический “L3 Interconnect” на блок схеме…
В принципе у дешевой RPi тоже имеется 4 полноценных ядра, ды и периферия та- же почти, вопрос в программном обеспечении только…
ну сделали там отдельные “реалтаймовые ядра” (в т.ч. тем самым подняли цену)), а есть ли для Линукса программная поддержка этого “блока” (??)
512 байт оперативки и 4 Кб для программы на один PRU, ассемблер с 40 RISC-командами, отсутствие умножения… какой линукс? это “помогайки” для реализации интерфейсов или DSP, не более.
это “помогайки” для реализации интерфейсов или DSP, не более.
понятно, в топку…))
вариация на тему малина+ erlerobotics.com/blog/product/pxfmini/
схемы нет, софта нет. оно просто отдает сырые данные?
это шилд к малине с каким-то 103-м процем ввиде выхода шим и датчиками 9250 5X89 5611 код открытый в арду…
Если хотите реалтайм + “мощный” ARM с линуксом, то нужно ставить ARM+FPGA )))). Сколько угодно выходов шим, любые интерфейсы, самый реалтаймый реалтайм))). Что-то типо того habrahabr.ru/company/metrotek/blog/235707/.
нужно ставить ARM+FPGA )))).
Спецам по линуксу надо просто сделать “правильный кряк” ядра, а железа то у любого ARMa хватает, нам для задачи стабилизации достаточно одного SPI или даже I2C, на худой конец… лишь бы работу с ними никто не мог “вытеснить” … и желательно прерывания по аппаратному таймеру… (вот и всё счастье)))
Я думаю, даже уверен, что смысла ждать неделю нет. Лучше ее потратить на начало работы с FreeRTOS.
Таки изобрёл велосипед))) По сути обработчик программных прерываний, обработчик событий. Особо если портировать на АВР, там аппаратных прерываний мало.
Не нужно в прерываниях ничего считать. Только забрать данные которые “вдруг” “привалили” и выставить флаг (семафор) для задачи которая все это обсчитает.
Вот у меня всё так теперь, только не семафор, а вызов обработчика. При этом вызывающее прерывание освобождается, можно дальше “слушать” датчик.
Кста, кто может " прокатить" под отладчиком FreeRTOS, сколько циклов проца натикает до старта вычисления в самой приоритетной задаче? У меня 230 )
Подскажите , кто может, - как сделать чтоб коптер не разворачивало по “Yaw” на 360 гр. при переходе через “0-360” град. (всю голову сломал, не могу придумать, прям “ручник” какой то)))),
т.е. на ПИД по “Yaw” подаем 0-360 гр. с ИМУ и уставку 0-360 гр… получаем в районе перехода 0-360 сигнал управления на целый оборот…(?), как у людей то сделано ??.
получаем в районе перехода 0-360 сигнал управления на целый оборот…(?), как у людей то сделано ??.
Ну тут вроде всё просто: если разность больше 180, вычитай или прибавляй 360 (т.е. полный оборот). Хотя математически правильно на выходе иму получить угол ±Пи, а преобразование в азимутальный 0-360 только для индикации.
Хотя математически правильно на выходе иму получить угол ±Пи
Это ничем не лучше 0-360. Если угол используется для управления (в ПИД-контроллере, задание цели, и т.д.) то он должен быть непрерывным. Можно завести специальный тип данных, но проще всего во float преобразовать и не париться. Методика называется “phase unwrapping”. Обратно в ±180 также просто преобразовать. Ни и эту особенность углов надо всегда помнить. Если угол 10, а команда идет “повернуть на 380” - то это можно сделать двумя способами, длинным и коротким. И однозначно сказать какой “правильный”, может только тот, кто команду дает.