Создание собственной системы стабилизации
под каким углом запустишь - так и будет держать
запустишь по горизонту — будет помнить этот горизонт и приводится к нему из любого положения. но да, он читерит маленько если использовать мышиный сенсор (с разрешением 8*8, вроде) и “поправляет” этот горизонт при опущенных стиках и висении. и это без акселей, гпс, барометров, компасов и пр.
просто и надёжно без всяких интеграторов…
дык если сложно и до сих пор не получается, то может пора вернуться к чему-то более простому? серьезно, пять лет назад этот топик начинался так “есть мысли по созданию собственного УНИВЕРСАЛЬНОГО контроллера для многомоторных систем”. что сейчас в наличии кроме процесса ради самого процесса?
Ща выбросим все свои проекты, назы, фишки, арду.
назы, фишки, арду — не ваши. а то что не работает — да, нужно выбрасывать. освободившееся время потратить на теорию “Linux и прерывания в userspace”, например.
щёточные мелкокоптеры устойчиво летают под ручным управлением я отлично знаю
а нужно чтоб пиво с кухни возили?
допускается работа прерываний (аппаратных или программных) с приоритетом выше чем у шедуллера самого ядра
то есть все, что работает в ядре и после него не может обрабатывать эти прерывания. а значит, никаких пользовательских задач с рилтаймовыми возможностями, то есть фактически аналог RTLinux. все что остается — низкоуровневый код, которому до пользователя очень далеко.
поэтому “Принципиальных противоречий совмещения того и другого” целый вагон.
никаких пользовательских задач с рилтаймовыми возможностями,
Ну почему же ? Если “официально” в ОС предусмотреть отдельный ТИП/КЛАСС/“ТЕРМИНАЛы” (как угодно) задач, которые при запуске в пространстве пользователя имеют прямой “канал” связи с таким же особым типом /DEV, в роли которых выступят аппаратные таймеры, пины, IrqHannler-ы ?? (эт я фантазирую,в меру способностей, конечно 😃), а так почему нет ?
если использовать мышиный сенсор (с разрешением 8*8, вроде) и “поправляет” этот горизонт при опущенных стиках и висении. и это без акселей, гпс, барометров, компасов и пр.
Интересно, до какой высоты он сможет компенсировать уплывание?
что сейчас в наличии кроме процесса ради самого процесса?
у меня это так, ибо хобби +мозги не закисают. Хотя цель тоже есть, но не эта
собственного УНИВЕРСАЛЬНОГО контроллера для многомоторных систем
Она уже достигнута Сергеем, ибо тогда речь шла (я так понимаю) именно о “железе”, а в то время ничего достойного и доступного не было. За это ему большая уважуха.
У меня цель создание надежного алго ИНС+АП УНИВЕРСАЛЬНОГО, не только на многоротор, и не только на самоль, а на всё подряд (в т.ч. на гибриды), причем чтоб прошивки не менять, просто изменить параметры руления.
Параметры, к которым нужно стремится по ИНС, Алексей Козин описал на предыдущей странице.
а нужно чтоб пиво с кухни возили?
нужна надёжная автономка.
то есть все, что работает в ядре и после него не может обрабатывать эти прерывания.
в юниксах не силен, но вижу так: Прерывание-> событие в ядре -> вызов пользовательских задач, подписанных на событие по приоритету.
/dev/mem, /dev/port , /proc/interrupt, /proc/irq/* — это и много чего еще есть уже существующие прямые “каналы” связи, точнее сказать, интерфейсы. начиная с 2.6 можно переконфигурировать ядро для поддержки полной вытесняемости и повысить всем своим нужным процессам приоритет до максимума. тогда юзерская задача получит доступ к чему угодно (практически) когда ей угодно, вплоть до игнора системных задач.
но я все равно не понимаю, для чего нужно пользовательским свистелкам иметь самый прямой доступ к железу, так никто не делает. нет задач пользовательского контекста, которым нужно строго детерминированный доступ к ресурсам. простейшие примеры: подушка безопасности, ABS, ESP — прикиньте что случится, если туда же запихнуть медиасистему с навигатором, которому вдруг потребуется всех выкинуть и занять время на опрос датчиков вращения колес.
для чего нужно пользовательским свистелкам иметь самый прямой доступ к железу
тут пользовательская задача - это жизть леталки, так что ждать пока “окна обновятся” или “модем отвиснет” здесь нельзя. Снятие данных с датчиков и обсчет ИНС должны выполняться с максимальным приоритетом.
Интересно, до какой высоты он сможет компенсировать уплывание?
до такой высоты новички (на которых расчитан девайс) обычно не долетают.
> у меня это так, ибо хобби +мозги не закисают
у меня к этому никаких предубеждений нет.
создание надежного алго ИНС+АП УНИВЕРСАЛЬНОГО, не только на многоротор, и не только на самоль, а на всё подряд (в т.ч. на гибриды), причем чтоб прошивки не менять, просто изменить параметры руления.
то есть повторение уже имеющихся наработок/разработок/продуктов. если это для все той же мозговой разминки, то тут вопросов быть не может, но может быть есть какая-то иная цель?
вижу так: Прерывание-> событие в ядре -> вызов пользовательских задач
замените значок -> словосочетанием “неизвестный временной интервал” и вы поймете суть претензий Олега 😉
Снятие данных с датчиков и обсчет ИНС должны выполняться с максимальным приоритетом.
поэтому никто и не делает их “пользовательскими”. а по большому счету ИНС должна физически быть отделена от всего остального и отсылать только готовый результат, от которого не требуется килогерцовых обновлений.
то есть повторение уже имеющихся наработок/разработок/продуктов.
Так тут ничего ПРИНЦИПИАЛЬНО нового придумать нельзя, всё это придумано давно и реализовано в середине прошлого века. Я просто не знаю ни одной системы (доступной любителям) с таким функционалом, гении-одиночки (типа ВизАсты) не в счёт, они без приличных денег ваши хотелки обсуждать не будут (на что имеют полное право).
- приятно почесть ЧСВ (Чувство собственной важности), “вот смотрите как летит! Моё!”
замените значок -> словосочетанием “неизвестный временной интервал”
Тогда зачем на борту нужен линукс? Для “веселых картинок” и питона, ну и определения эмоций владельца по видео в отдаленной перспективе?
Я просто не знаю ни одной системы (доступной любителям) с таким функционалом
можно еще уточнить, “ни одной системы, не являющейся копипастой другой системы”. и добавить “с подготовленной теоретической базой”.
вот вспоминается небезызвестный дядя Madgwick, у которого реализация алгоритма в коде занимала одну страницу, а остальные тридцать — сплошь формулы. (эти 30 страниц, ессно, никто не читал, код разошелся, а банальную опечатку в реализации разложении градиента заметили чуть-ли не через год).
Тогда зачем на борту нужен линукс?
ну, как для Parrot-а, к примеру, разместить на борту ground station, которая и занимается навигацией. а самой станцией рулить мобилкой.
что сейчас в наличии кроме процесса ради самого процесса?
почему бы и нет? нет предела совершенству, а значит всегда есть куда двигаться)))
Ну почему же ? Если “официально” в ОС предусмотреть отдельный ТИП/КЛАСС/“ТЕРМИНАЛы” (как угодно) задач, которые при запуске в пространстве пользователя имеют прямой “канал” связи с таким же особым типом /DEV, в роли которых выступят аппаратные таймеры, пины, IrqHannler-ы ?? (эт я фантазирую,в меру способностей, конечно ), а так почему нет ?
а почему нет? NuttX всей этой лабудой заниматься умеет, и довольно на большом разнообразии железа…
Она уже достигнута Сергеем, ибо тогда речь шла (я так понимаю) именно о “железе”, а в то время ничего достойного и доступного не было. За это ему большая уважуха.
Да к сожалению медленно всё это движется (разработка в смысле) ((( времени очень мало, а “рожать” обработку датчика через задний проход другого за полгода, так это вовсе ни в какие ворота не лезет… плюс барометр так ещё и не нашел где теряется в фильтре, да и вообще куча не систематизированных проблем, которые надо решать…
одна из дилемм: что в первую очередь? добить мелкую по железу (есть нюансы) или сделать хал под ф4бы … а ещё арду 3.3 надо на ф4бы… опенардувий ещё далёк до прошивок в люди…
вот стоит на коптере новая плата f4by v2.1.5 с арду 3.2 откалиброванная настроенная но не лётанная, вторая (2.0) лежит с px4firmware тоже без дела, мелкая может летать, но не так как я хочу, но к ней нет времени припаять st-link и подебажить - вот так и живу)))
NuttX всей этой лабудой заниматься умеет, и довольно на большом разнообразии железа…
о, напомнили. вот весьма красноречивая картинка от px4, кто где живет в рилтайме, а кто как придется:
вот весьма красноречивая картинка от px4
в серединке opencv
это точно относится к px4 реализованном на stm32?
или “px4” это что то иное в вашем контексте?
это смотря что называть Pixhawk-ом
pixhawk.ethz.ch/electronics/base_large
имхо просто компактная интеловская материнка с возможностью поставить винду. ломал голову не могу понять какое отношение к пихавку.
сбоку похожие сайты - и ссылка на официалов, а это чешсккий домен, про полетники вообще мимо - походу просто присоседились к популярному поисковому слову и использовали стыренный бренд и лого сайта
это точно относится к px4 реализованном на stm32?
Пожалуй самая удачная конструкция, из тех что вообще есть… только вот непонятно, однако, зачем двойной комплект сенсоров.
ломал голову не могу понять какое отношение к пихавку. сбоку похожие сайты - и ссылка на официалов, а это чешсккий домен, про полетники вообще мимо - походу просто присоседились к популярному поисковому слову и использовали стыренный бренд и лого сайта
меня просвятили вплане структуры отношений, вобщем не чешский домен а швейцарский, от этих ребят пошел проект пикса, тот домен который орг - уже наследники
читаю про ICM-20608, не могу понять, чего это в акселе нет LFP ? или я чего-то не догоняю? в том же MPU6500 - 9255 как раз раздельные фильтры дус и акселя, что очень понравилось, а тут только дус? непонятно, контора то одна???
Макс выйди из сумрака, пиксы спёрли нашу идею ((( 74LVC2G86 … конечно не спёрли, надо было раньше чесаться с аппаратно переворачиваемыми портами, а не держать мелкую целый год на полке пылиться…
речь про Pixracer если чё…
короче я опять отстал (
для сравнения если кто не в курсе rcopen.com/blogs/74247/20339
не могу понять, чего это в акселе нет LFP ?
Знать бы - как этот LPF реально работает… (?), а то вот мне например кажется, что он нафиг не нужен вообще…
а то вот мне например кажется, что он нафиг не нужен вообще…
а мне кажется(креститься пора что-ли), что аналоговый rc, lc, фильтр, ну или на операционнике лучше цифровых (программных) фильтров, усреднение математическое - это в первую очередь устраивает из белого шума, однобокий цветной, может и меньший, но “воевать” с ним на много сложнее…
что аналоговый rc, lc, фильтр, ну или на операционнике
Хорошо если так,… я склоняюсь всеж что там тупо такты чтения пропускаются… (уж чё чё, а назвать муху слоном эти “ребята” умеют…)))
но в тех же МПУ шум очень “хороший”, что нельзя сказать о LSM - там как раз на выходе не белый, хотя аналоговые аксели от ST очень даже не плохи…
на сколько могу разобраться в буржуйском Signal conditioning таки да не пропускает такты, а выбирает определённый (заданный) спектр из аналогово сигнала… остальное покрыто мраком…
ну да там в ацп встроены управляемые операционники…