Какая ОСРВ для гуманоидного робота?

Мы являемся студентами, разрабатывающими гуманоидного робота среднего размера (~ 4,5 фута) в качестве спонсируемого исследовательского проекта в колледже. Основные задачи, которые робот должен уметь выполнять, включают в себя: передвижение (вперед, назад, вбок), бег, подбор предметов. Мы рассматриваем возможность использования жесткой операционной системы в реальном времени для управления роботом. Однако, поскольку мы новички в этой области, практически не имеющие опыта работы со встроенными системами или операционными системами, и у нас имеется широкий выбор доступных вариантов, мы не уверены, какой из них будет подходящим выбором. Мы столкнулись со следующим (в скобках указано наше текущее впечатление о них):

  1. RTLinux (сейчас мертв, ядро ​​2.4.x, gcc 2.95 (так сложно собрать), документация практически отсутствует)
  2. FreeRTOS (хорошее сообщество и документация, популярная, портированная на многие архитектуры)
  3. UC-OS II (маленький, чистый ядро, легкий)
  4. RTAI (на основе Linux)

У меня есть ряд вопросов:

  1. Какой из вариантов лучше подойдет для этого проекта? Я знаю, это звучит немного субъективно, но любой совет будет принят с благодарностью. Если вы считаете, что какая-то важная информация отсутствует, укажите это.
  2. Я встречал нечто, называемое патчем CONFIG_PREEMPT_RT для ядра Linux, которое предоставляет ядру жесткие возможности в реальном времени. Есть также скомпилированные ядра с этим патчем, доступные для дистрибутивов на основе Debian. Будет ли этого достаточно для наших требований?
  3. У нас очень мало знаний об операционных системах в целом. Нужно ли нам сначала узнавать о них? Если да, что является хорошим коротким учебником по теме?

ОБНОВЛЕНИЕ: Спасибо за ваши невероятно подробные ответы. Понятно, что мы идем об этом неправильным путем; погружение без знаний и требований, конечно, было бы плохо. Придется сесть и написать мелом именно то, что нам нужно. И когда мы достаточно продвинемся в этом, мы попытаемся найти подходящую ОС. Давайте посмотрим, как это работает. Я также собираюсь прочитать Главу 2 из MicroC OS II: Ядро реального времени.

Источник

3 ответа

Решение

Ваш выбор ОС вряд ли будет определяться ограничением "человекоподобный робот", нет конкретной "ОС гуманоидного робота", и, конечно, ни одна ОС не будет определяться тем, насколько высок такой робот!;-)! Критические факторы

Другие факторы могут быть важны, такие как:

  • Требования к связи и вводу / выводу (например, Ethernet, TCP/IP, USB, WiFi).
  • Поддержка файловой системы

хотя они не обязательно должны быть неотъемлемой частью ОС во всех случаях, поскольку независимые от платформы сторонние библиотеки доступны во многих случаях, но там, где они вам нужны, интеграция с ОС может быть полезной, поскольку она избавляет вас от необходимости иметь дело с потокобезопасность и блокировка ресурсов самостоятельно.

Ни один из предложенных вами вариантов вряд ли попадет в мой список.

Все, что основано на Linux, потребует MMU (если только не используется uCLinux или его производные, но поддержка MMU является одной из немногих веских причин для использования Linux во встроенной системе). Linux не предназначен для того, чтобы быть ОС реального времени, и любая поддержка в реальном времени, которую он имеет, в значительной степени запоздалая и редко будет такой детерминированной, как настоящая ОСРВ. Любой Linux также потребует значительных ресурсов памяти только для загрузки, ожидайте минимум 4 МБ ОЗУ для чего-либо полезного, в то время как для ядер RTOS, таких как FreeRTOS и uC/OS-II, требуется всего около 4 КБ - здесь вы сравниваете мел с сыром. Тем не менее, у них нет утилиты на базе Linux, такой как файловые системы или сетевая поддержка (хотя они могут быть добавлены в виде автономных библиотек).

Если вы собираетесь выполнять функции управления движением и датчика / исполнительного механизма на том же процессоре, что и ваши когнитивные функции, то вам, безусловно, нужна детерминированная ОСРВ. Однако, если платформа будет распределенной системой с отдельными процессорами, работающими с управлением движением и другими входами / выходами датчиков / исполнительных механизмов в реальном времени, то вам может не понравиться простое ядро ​​RTOS или вообще нет ОС в процессорах ввода / вывода (которые также могут быть меньшими, менее мощными процессорами) и GPOS в когнитивном (для принятия решений и планирования) процессоре.

Я недавно оценил FreeRTOS, он минималистичный, простой и небольшой, предоставляющий только базовые механизмы потоков, синхронизации и IPC, и немного другое. Это работает, но и многие другие более привлекательные варианты, как коммерческие, так и некоммерческие. Я сравнил его с RTX-ядром Keil (входит в их набор инструментов MDK-ARM) и с коммерческой платформой Segger EmbOS. У него значительно меньше времени переключения контекста, чем у двух других кандидатов (хотя он все еще в микросекундах на 72 МГц Cortex-M3, и он быстрее, чем все, что вы, вероятно, достигнете с Linux).

uC/OS-II хорошо спроектирован и задокументирован (в книге Жана Лаброса), и это здорово, если вы хотите увидеть, как работает ОСРВ. Самым большим его недостатком является очень строгая схема планирования приоритетов, которая эффективна для очень маленьких целей, но, возможно, не так гибка, как вам хотелось бы. Каждому потоку должен быть назначен отдельный уровень приоритета, чтобы он не поддерживал циклическое планирование, полезное для фоновых задач не в реальном времени. UC/OS-III исправляет этот недостаток, но также и многие другие варианты.

Если у вашего целевого процессора есть MMU, я настоятельно рекомендую использовать ОС, которая поддерживает его таким образом, чтобы каждый поток или процесс был защищен от любого другого, система будет гораздо более устойчивой и простой в отладке, особенно если она разработана как команда. В такой ОС ошибочная задача, которая в противном случае затопит ресурсы какого-либо другого потока с недетерминированными и, как правило, трудными для отладки результатами, вместо этого вызовет исключение и остановится прямо там, где произошла ошибка, а не, возможно, когда-нибудь позже, когда поврежденные данные получат используемый.

Возможно, вам не нужно ограничиваться бесплатной ОСРВ с открытым исходным кодом, многие поставщики разрешают бесплатно использовать ее для обучения и оценки. Я настоятельно рекомендую вам рассмотреть QNX Neutrino, он бесплатный для некоммерческого и академического использования и имеет самую надежную встроенную поддержку MMU, доступную в любой ОСРВ, и все необходимые вам инструменты разработки, включая IDE Momentics на основе Eclipse, включены. Это больше, чем просто планирование ядра, включая поддержку всех сервисов, которые вы ожидаете от полной ОС. Он работает на архитектурах ARM, x86, SH-4 PowerPC и MIPS. Запуск на x86 особенно полезен, так как это означает, что вы можете протестировать и оценить его, и даже разработать большую часть своего кода на виртуальной машине, работающей на вашем рабочем столе.

ECos - это еще одна альтернатива, которая по-настоящему сложна в реальном времени и поддерживает службы ОС, помимо простого планирования и IPC. Он имеет собственный API POSIX и uITRON, стандартные драйверы для CAN, ADC, SPI, I2C, FLASH, PCI, Serial, Filesystems, USB и PCI и др., А также поддерживает сетевую поддержку TCP / IP. В этом смысле это полная ОС, но в отличие от Linux она не монолитна; он масштабируется и статически связан с кодом вашего приложения, поэтому неиспользуемые вами функции просто не включаются в исполняемый двоичный файл. Он работает на ARM, CalmRISC, Cortex-M, FR-V, FR30, H8, IA32, 68K/ColdFire, Matsushita AM3x, MIPS, NEC V8xx, PowerPC, SPARC и SuperH. Опять же, теоретически, вы можете запустить порт IA32 (x86) на виртуальной машине на ПК для тестирования и разработки высокоуровневого кода, хотя вам придется заставить его работать самостоятельно, в отличие от готовой оценки QNX.

Добавлено относительно:

У нас очень мало знаний об операционных системах в целом. Нужно ли нам сначала узнавать о них? Если да, что является хорошим коротким учебником по теме?

Тогда, возможно, сейчас не время начинать изучать Linux (хотя он обладает преимуществами широкого знакомства и поддержки сообщества, в нем есть много вещей, которые вам не понадобятся, и многие доступные ресурсы поддержки не будут знакомы в режиме реального времени приложения систем управления.

Глава 2 книги Labrosse uC/OS-II дает общий обзор таких понятий RTOS, как планирование, синхронизация и IPC, которые применимы к большинству RTOS, а не только к uC/OS-II. Подобный материал представлен в недавнем курсе основ RTOS Джека Гансле по EETimes (возможно, он похож, потому что он спонсируется Mircium и использует uC/OS-II в качестве тематического исследования, но он по большей части аналогичен общему).

Мое решение для быстрого начала в любом предмете состоит в том, чтобы найти в Google предмет с "101" (обычный вводный курс в академических кругах). "RTOS 101" даст вам некоторые отправные точки, предположительно отличающиеся по качеству - проверьте авторитетность источника, если это компания, они могут торговать конкретным продуктом, если это любитель, они могут иметь некоторые идеи, но, возможно, узкий взгляд (часто относящийся к конкретному любимому оборудованию), и может не иметь строгости академической статьи.

Добавлено относительно CONFIG_PREMPT_RT:

Это не делает Linux жесткой ОС реального времени. Это может быть подходящим для некоторых применений. Если вы выполняете ПИД-управление движением (а не используете выделенный контроллер или отдельный процессор) или какой-либо другой вид управления с обратной связью в этом отношении, этот патч, по моему мнению, не включит его, по крайней мере, ненадежно. Я нашел это: сравнение подходов Linux в реальном времени. В нем обсуждается ряд подходов к использованию Linux в приложениях реального времени, включая CONFIG_PREMPT_RT. Это обсуждает это подробно в части C.

Источник

Это не отвечает на конкретный вопрос, но:
Прежде чем обратиться за советом по конкретной ОС, вам нужно узнать больше подробностей об архитектуре и ограничениях.

Я бы начал с ввода-вывода:

  • Как вы взаимодействуете с внешним миром? Сколько датчиков?
  • Какими моторами управляет робот? Как много? Как они управляются?
  • Какие датчики вам нужны для обратной связи управления двигателем?
  • Как насчет обратной связи положения тела?
  • Вы сделали какой-нибудь системный анализ?
    • Какая частота обновления вам нужна для поддержания стабильности?
  • Какие еще задачи нужно выполнить?
    • Видение?
    • Распознавание звука
    • Аудио поколение?

Теперь, когда вы знаете, что вам нужно контролировать и как быстро, как вы это контролируете?

  • Используете ли вы микроконтроллер со встроенной возможностью A/D?
  • Или ПК с подключаемой АЦП?
  • Является ли один процессор достаточно быстрым или вам нужно умножить
    • Если их больше одного, как они будут синхронизироваться?

С этого момента вы можете начать рассматривать конкретные процессоры и архитектуры. Только после того, как вы сузили его до одного или двух хороших вариантов, вы должны начать рассматривать ОС.

Я ожидаю, что в конечном итоге вам понадобится ОС Hard Real-Time для управления движением робота.

Источник

Возможно, нет необходимости запускать Linux в режиме реального времени. Учитывая гуманоида высотой 4,5 фута с CM, скажем, 3 фута, ваш контур управления может работать на частоте 20 Гц, и вы все равно можете переваривать сигналы IMU и предотвращать падение устройства. Обычный встроенный Linux, в котором нет параллельного управления игровым сервером противодействия управлению двигателями робота, обеспечит вам надежную обработку событий, по крайней мере, с частотой 50 Гц, даже без "приятного" процесса управления роботом. (при условии, что вы будете запускать свой Linux на RoBoard или FitPC). В любом случае, вероятно, легче восстановиться после пропущенного кадра, чем запускать RT Linux. Чтобы ядро ​​работало так, чтобы оно надежно вызывало ваши обработчики при прерывании в течение X микросекунд (т. Е. В реальном времени), требуется то, что некоторые считают нетривиальным и с некоторыми побочными эффектами.

Возможно, вам лучше иметь другую микропроцессорную плату, которая на некотором низком уровне общается с двигателями / сервоприводами и передает переваренную информацию в Linux.

В нашем проекте ActuatedCharacter.com нам удалось получить цикл управления между Linux-серверами RoBoard.com и 20 (динамическими) серво (с пользовательской прошивкой) на частоте более 200 Гц с интерфейсом FTDI для сервоприводов и без каких-либо модификаций ядра в реальном времени. Если вы планируете использовать сервоприводы Dynamixel в качестве исполнительных механизмов, посетите форумы robosavvy.com для получения общей информации о создании роботов-гуманоидов (для robocup или для общих исследований), альтернативных прошивок для улучшения скорости управления в замкнутом контуре, проблем с задержкой FTDI, сервоприводов с последовательным управлением, Также рассмотрите программную среду, которую вы хотите разработать, которая, в свою очередь, поможет вам с вашими требованиями. Очевидно, что поговорить с созданными командами человекоподобных лиг Robocup, но также могут быть интересны представители команды, NAO/Aldebaran и ROS.

Источник
Другие вопросы по тегам