Создание собственной системы стабилизации
об отсутствии в Linux каких либо ограничений на доступ к железу
Аналог прерывания от события на ножке в user space получится продемонстрировать?
а что, интересно, продемонстрировано в последней строке моего примера на баше?
там нарисовано чтение значения на ножке. Для вас это тоже самое, что и прерывание по событию?
да ёпрст… “событие” на цифровом входе — изменение его уровня. “прерывание” — вызов callback-функции по наступлению события (счетчик) либо по условию (уровень == 0/1). а как еще узнать про изменение кроме как прочитать ячейку памяти (“значение на ножке”)??
в общем, не надо больше про “Linux не пускает к железу напрямую”. в Linux любое устройство есть файл с блочным или символьным доступом, которое, по желанию/требованию mmap-ится в память без каких-либо трудностей.
Имхо все эти изыски для пары человек из миллионов.
важные вопросы сегодняшнего дня
-чтобы ахрс держало уровень горизонта в резких ускорениях
-чтобы инерциалка хотябы в пределах 30 секунд при перемещениях не уходила бы по позиции больше метра
а что в них такого важного? все уже давно придумано, реализовано и скопипащено тысячи раз. у меня Flymentor (на одних аналоговых гироскопах) начинает заваливать горизонт только через 2-3 минуты непрекращающейся “колбасни”. (уже) ширпотребный Parrot мобилками управляется и проблем не знает. китайцы продают игрушки по 20 уе, которые с успехом держат что угодно на любых ускорениях и висят на месте как вкопанные.
а тут (не конкретно тут, а образно) все что-то свое придумывают, для чего не хватает 9DOF+барометры+GPS+камеры 😉
довольно известный факт об отсутствии в Linux каких либо ограничений на доступ к железу
Прямой доступ к железу несомненно есть (в частности “чудесный” механизм маппирования), но ядро, опять же, предоставляет этот доступ когда ЕМУ угодно, а не когда угодно приложению в пользовательском пространстве…
Спустившись на уровень драйверов, в принципе, наверно можно заблокировать шедуллер и делать что то одно и вовремя, но ведь это изврат, который заблокирует всю ОС, а главное - не предусмотрен самой идеологией ядра линукса… (линукс изначально заточен - не пускать юзеровское пространство в обход шедуллера)… Не так ли ??
линукс изначально заточен - не пускать юзеровское пространство в обход шедуллера)… Не так ли ??
не так.
> в частности “чудесный” механизм маппирования
не вижу причин для сарказма. через WMI или сокеты организовывать межпроцессорное взаимодействие типа круче?
> ядро, опять же, предоставляет этот доступ когда ЕМУ угодно, а не когда угодно приложению в пользовательском пространстве
а с какого что-то из userspace должно иметь приоритет? его участь — сидеть тихонько в уголке и ждать очереди.
вы пытаетесь совместить несовместимое, “ах, хорошо бы иметь интерпретатор в жесткой рилтаймовой ОС…”. при этом вспоминаете про OS/2:
у нее под каждый запущенный процесс была возможность гибко выставлять приоритеты и кучу других системных настроек, распределением нагрузки на процессор можно было управлять прям из GUI…
в любой *nix системе все то же самое можно делать даже из консоли и даже удаленно. любую *nix систему можно запустить под RTOS как обычную задачу с любым приоритетом. если хотите превратить RTOS в багованное нечто, то сделайте любой интерпретатор ее задачей.
китайцы продают игрушки по 20 уе, которые с успехом держат что угодно на любых ускорениях и висят на месте как вкопанные.
Можно ссылку на игрушку < 100 уе, которая
-чтобы ахрс держало уровень горизонта в резких ускорениях
-чтобы инерциалка хотябы в пределах 30 секунд при перемещениях не уходила бы по позиции больше метра
То что щёточные мелкокоптеры устойчиво летают под ручным управлением я отлично знаю
все что-то свое придумывают
Спасибо, что подняли нам веки. Ща выбросим все свои проекты, назы, фишки, арду. Вот только семок пожуём мальца и сразу же пойдем купим себе китайских игрушек по 20 у.е. B-)B-)😎
P.S. Я думал, что Дринкера забанили пожизнено😢, а оно вона как…
у меня Flymentor (на одних аналоговых гироскопах) начинает заваливать горизонт только через 2-3 минуты непрекращающейся “колбасни”.
Дмитрий хватит уже про флайментор - он нифига не знает о положении относительно горизонта - под каким углом запустишь - так и будет держать, он просто регистрирует и “душит” все угловые скорости, тоже самое и его оптический датчик - регистрирует горизонтальные скорости и за счёт этого “душит” их - просто и надёжно без всяких интеграторов…
P.S. Я думал, что Дринкера забанили пожизнено, а оно вона как…
а Дринкер тут каким боком?
это наверное шутки такие чтоб народ повеселить, да тему расшевелить
Спасибо, что подняли нам веки.
Алексей, мне тоже подними ))) У тебя на АП реакция рулей самоля зависит от воздушной скорости или жесткий ПИД на все режимы?
Зависит, если есть СВС и он разрешен в настройках.
Но это только для самолета. На самолете я от ошибок по углам работаю и где-то 20 - 25 Гц обновление сервоканалов отдаю. Но, честно говоря, на скае я это не особо чувствую на скорости до 80км/ч. Если скорость выше, то лучше прижимать слегка рейты на ПИДах. Конечно, это все субъективно от носителя зависит ибо крыло ловит вибру гораздо быстрее классики. Димка, летает на полярисе с моим АП, там скорости под 120 км/ч и выше. Говорит, что все ок. Для крыла, у меня нет статистики, чтобы что-то объективное утверждать о пользе или недостатках подобных алгоритмов.
Если в качестве объекта управления АП указан коптер, то там ПИДы устроены по другому. На коптере я работаю от ошибок по угловым вращениям ну и частоты обновления регулей 480 Гц обязательно. А иначе на коптере перфектной плавности маневров и висения не получается достигнуть.
Для крыла, у меня нет статистики, чтобы что-то объективное утверждать о пользе или недостатках подобных алгоритмов.
Речь о самолях.
Зависит, если есть СВС и он разрешен в настройках.
Зависит от квадрата скорости потока или ступечатое переключение режимов полёта? А ещё чей-то опыт изучал?
Просто у меня “раздергивается” и штопорит на высокой скорости, а на низкой вяло рулится, если ПИДы прижать. Правда носитель - “фанера” из гофрированного картона )))
Зависит от квадрата скорости потока или ступечатое переключение режимов полёта? А ещё чей-то опыт изучал?
Просто линейное при достижении некоторого порога от 100% до заданных. Больше ничей опыт не изучал.
вы пытаетесь совместить несовместимое, “ах, хорошо бы иметь интерпретатор в жесткой рилтаймовой ОС…”. при этом вспоминаете про OS/2:
Например в CoOS (аналог FREE RTOS) ядре многозадачность реализована так, что допускается работа прерываний (аппаратных или программных) с приоритетом выше чем у шедуллера самого ядра… типа - само ядро даже не подозревает что у него отняли процессорное время… Вот я и высказался - “почему бы умным людям не сделать давным давно полноценную ОС уровня Линукс, но с поддержкой реалтайма”, это сильно помогло бы нам…
Принципиальных противоречий совмещения того и другого я не вижу, (и никакого сарказма, просто хотел сказать что реалтайм на линуксе невозможен).
под каким углом запустишь - так и будет держать
запустишь по горизонту — будет помнить этот горизонт и приводится к нему из любого положения. но да, он читерит маленько если использовать мышиный сенсор (с разрешением 8*8, вроде) и “поправляет” этот горизонт при опущенных стиках и висении. и это без акселей, гпс, барометров, компасов и пр.
просто и надёжно без всяких интеграторов…
дык если сложно и до сих пор не получается, то может пора вернуться к чему-то более простому? серьезно, пять лет назад этот топик начинался так “есть мысли по созданию собственного УНИВЕРСАЛЬНОГО контроллера для многомоторных систем”. что сейчас в наличии кроме процесса ради самого процесса?
Ща выбросим все свои проекты, назы, фишки, арду.
назы, фишки, арду — не ваши. а то что не работает — да, нужно выбрасывать. освободившееся время потратить на теорию “Linux и прерывания в userspace”, например.
щёточные мелкокоптеры устойчиво летают под ручным управлением я отлично знаю
а нужно чтоб пиво с кухни возили?
допускается работа прерываний (аппаратных или программных) с приоритетом выше чем у шедуллера самого ядра
то есть все, что работает в ядре и после него не может обрабатывать эти прерывания. а значит, никаких пользовательских задач с рилтаймовыми возможностями, то есть фактически аналог RTLinux. все что остается — низкоуровневый код, которому до пользователя очень далеко.
поэтому “Принципиальных противоречий совмещения того и другого” целый вагон.
никаких пользовательских задач с рилтаймовыми возможностями,
Ну почему же ? Если “официально” в ОС предусмотреть отдельный ТИП/КЛАСС/“ТЕРМИНАЛы” (как угодно) задач, которые при запуске в пространстве пользователя имеют прямой “канал” связи с таким же особым типом /DEV, в роли которых выступят аппаратные таймеры, пины, IrqHannler-ы ?? (эт я фантазирую,в меру способностей, конечно 😃), а так почему нет ?
если использовать мышиный сенсор (с разрешением 8*8, вроде) и “поправляет” этот горизонт при опущенных стиках и висении. и это без акселей, гпс, барометров, компасов и пр.
Интересно, до какой высоты он сможет компенсировать уплывание?
что сейчас в наличии кроме процесса ради самого процесса?
у меня это так, ибо хобби +мозги не закисают. Хотя цель тоже есть, но не эта
собственного УНИВЕРСАЛЬНОГО контроллера для многомоторных систем
Она уже достигнута Сергеем, ибо тогда речь шла (я так понимаю) именно о “железе”, а в то время ничего достойного и доступного не было. За это ему большая уважуха.
У меня цель создание надежного алго ИНС+АП УНИВЕРСАЛЬНОГО, не только на многоротор, и не только на самоль, а на всё подряд (в т.ч. на гибриды), причем чтоб прошивки не менять, просто изменить параметры руления.
Параметры, к которым нужно стремится по ИНС, Алексей Козин описал на предыдущей странице.
а нужно чтоб пиво с кухни возили?
нужна надёжная автономка.
то есть все, что работает в ядре и после него не может обрабатывать эти прерывания.
в юниксах не силен, но вижу так: Прерывание-> событие в ядре -> вызов пользовательских задач, подписанных на событие по приоритету.
/dev/mem, /dev/port , /proc/interrupt, /proc/irq/* — это и много чего еще есть уже существующие прямые “каналы” связи, точнее сказать, интерфейсы. начиная с 2.6 можно переконфигурировать ядро для поддержки полной вытесняемости и повысить всем своим нужным процессам приоритет до максимума. тогда юзерская задача получит доступ к чему угодно (практически) когда ей угодно, вплоть до игнора системных задач.
но я все равно не понимаю, для чего нужно пользовательским свистелкам иметь самый прямой доступ к железу, так никто не делает. нет задач пользовательского контекста, которым нужно строго детерминированный доступ к ресурсам. простейшие примеры: подушка безопасности, ABS, ESP — прикиньте что случится, если туда же запихнуть медиасистему с навигатором, которому вдруг потребуется всех выкинуть и занять время на опрос датчиков вращения колес.