我的解决方案是在 Google 上搜索后面带有“101”的主题（学术界常见的入门课程编号）。 ?q=rtos%20101" rel="nofollow">"RTOS 101" 会给你一些公认的不同质量的起点 - 检查来源的信誉，如果是一家公司，他们可能是兜售某种特定的产品，如果是业余爱好者，他们可能有一些见解，但也许是狭隘的观点（通常涉及特定喜欢的硬件），并且可能不具备学术论文的严谨性。
添加了有关 CONFIG_PREMPT_RT 的内容：
它不会使 Linux 成为硬实时操作系统。它可能适合某些应用。如果您正在进行 PID 运动控制（而不是使用专用控制器或单独的处理器），或任何类型的闭环反馈控制，我认为该补丁将无法启用它，至少不可靠。我发现了这个： 实时 Linux 方法的比较。它讨论了在实时应用程序中使用 Linux 的多种方法，包括 CONFIG_PREMPT_RT。它在 C 部分详细讨论了这些内容。
Your choice of OS is unlikly to be determined by the "humanoid robot" constraint, there is no specific "humanoid robot OS", and certainly no OS would be determined by how tall such a robot is! ;-) ! The critical factors are
real-time constraints (for motion control PID update, sensor/actuator reaction time etc.)
Communications and I/O requirements (e.g Ethernet, TCP/IP, USB, WiFi).
File system support
although these need not necessarily be an intrinsic part of the OS in all cases, since third-party platform independent libraries are available in many cases, but where you need them, integration with the OS can be helpful since it avoids you having to deal with thread-safety and resource locking yourself.
Neither of the options you have suggested would likely make into my list.
Anything Linux based will require an MMU (unless using uCLinux or its derivitives, but MMU support is one of the few good reasons for using Linux in an embedded system). Linux is not intended to be a real-time OS and any real-time support it has is pretty much an after-thought, and will seldom be as deterministic as a true RTOS. Any Linux will also require significant memory resources just to boot-up, expect a minimum of 4Mb of RAM for anything usable, while RTOS kernels such as FreeRTOS and uC/OS-II require only about 4Kb - you are comparing chalk with cheese here. That said they do not have the utility of a Linux based OS such as file-systems, or networking support (although those can be added as stand-alone libraries).
If you are going to be performing the motion-control and sensor/actuator functions on the same processor as your cognitive functions, then you certainly need a deterministic RTOS. If however the platform will be a distributed system with separate processors dealing with motion-control and other real-time sensor/actuator I/O, then you may get away with a simple RTOS kernel or no OS at all in the I/O processors (which can also then be smaller, less powerful processors) and a GPOS in the cognitive (decision making and planning) processor.
I have evaluated FreeRTOS recently, it is minimalistic, simple and small, providing only the basic threading, timing and IPC mechanisms and little else. It works, but so do many other more attractive options, both commercial and non-commercial. I compared it with Keil's RTX kernel (included with their MDK-ARM tool suite), and the commercial Segger embOS. It has significantly slower context switching time that the other two candidates (though still in the microseconds on a 72MHz Cortex-M3, and faster than anything you are likely to achieve with Linux).
uC/OS-II is well designed and documented (in Jean Labrosse's book), and is great if you aim were to see how an RTOS works. Its biggest failing is its very restrictive priority scheduling scheme, which is efficient for very small targets, but possibly not as flexible as you might like. Each thread must be assigned a distinct priority level so it has no support for round-robin scheduling, useful for non-real-time background tasks. uC/OS-III fixes that shortcoming, but again so do many other options.
If your target processor has an MMU I strongly suggest the use of an OS that supports it in such a way that each thread or process is protected from any other, the system will be far more robust and easy to debug, especially when developed as a team. In such an OS an errant task that would otherwise stomp on some other thread's resources with non-deterministic and generally hard to debug results, will instead cause an exception and halt right where the error occurred, rather than perhaps sometime later when the corrupted data gets used.
You probably need not restrict yourself to a free or open-source RTOS, many vendors allow free use for education and evaluation. I would strongly suggest that you consider QNX Neutrino, it is free for non-commercial and academic use, and has the most robust intrinsic MMU support available in any RTOS, and all the development tools you need including the Eclipse based Momentics IDE are included. It is more than just a mere scheduling kernel, including support for all the services you would expect of a complete OS. It runs on ARM, x86, SH-4 PowerPC and MIPS architectures. Running on x86 is particularly useful since it means you can test and evaluate it, and even develop much of your code in a VM running on your desktop.
Another alternative that is true hard-real-time, while supporting OS services beyond mere scheduling and IPC, is eCos. It has a native, POSIX and uITRON API, standard drivers for CAN, ADC, SPI, I2C, FLASH, PCI, Serial, Filesystems, USB and PCI and more, and includes TCP/IP networking support. It is a complete OS in that sense, but unlike Linux is not monolithic; it is scalable and statically linked to your application code, so that features you do not use are simply not included in the runtime binary. It runs on ARM, CalmRISC, Cortex-M, FR-V, FR30, H8, IA32, 68K/ColdFire, Matsushita AM3x, MIPS, NEC V8xx, PowerPC, SPARC, and SuperH. Again in theory you could run the IA32 (x86) port it on a VM on a PC for test and development of high level code, though you'd have to get that working yourself unlike QNX's out of the box evaluation.
Added regarding:
We have very little knowledge of operating systems in general. Is it necessary for us to learn about them first? If yes, what is a good, short primer to the subject?
This then is perhaps not the time to start learning Linux (although it has the advantages of wide familiarity and community support, it has a lot of stuff you will not need, and a lot of available support resources will not be familiar with real-time control systems applications.
Chapter 2 of Labrosse's uC/OS-II book gives a general overview of RTOS concepts such as scheduling, synchronisation and IPC that are applicable to most RTOS not just uC/OS-II. Similar material is presented in Jack Ganssle's recent RTOS Fundamentals course on EETimes (it is similar perhaps because it is sponsored by Mircium and uses uC/OS-II as a case study, but it is similarly general for the most part).
My solution to getting a quick start in any subject is to Google the subject with "101" after it (a common introductory course number in academia). "RTOS 101" will get you some starting points of admittedly varying quality - check the reputability of the source, if it is a company, they may be peddling a specific product, if it is a hobbyist, they may have some insights, but perhaps a narrow view (often relating to specific favourite hardware), and may not have the rigour of an academic paper.
Added regarding CONFIG_PREMPT_RT:
It does not render Linux a hard real-time OS. It may be suitable for some applications. If you are doing PID motion control (rather than using a dedicated controller or separate processor), or any kind of closed loop feedback control for that matter, this patch will not enable it in my opinion, at least not reliably. I found this: A comparison of real-time Linux approaches. It discusses a number of approaches to using Linux in real-time applications, including CONFIG_PREMPT_RT. It discusses these in detail in part C.
This doesn't answer the specific question, but:
Before you ask for advice on a specific OS, you need a lot more details about the architecture and constraints.
I'd start with the I/O:
How do you interact with the outside world? How many sensors?
What kind of motors drive the robot? How many? How are they driven?
What kind of sensors do you need for the motor control feedback?
What about body position feedback?
Have you done any systems analysis?
What update rate do you need to maintain stablity?
What other tasks need to run?
Vision?
Audio recognition
Audio generation?
Now that you know what you need to control and how fast, how do you control it?
Do you use a micro-controller with embedded A/D capability?
Or a PC with a plug-in A/D card?
Is one processor fast enough or do you need multiples
If more than one, how will they synchronize?
At this point you can start considering specific processors and architectures. Only after you have narrowed it down to one or two good options, should you start to consider the OS.
I do expect that you will end up needing a Hard Real-Time OS for the motion control aspects of a running robot.
It may not be necessary to run the Linux in hard real-time. Given a 4.5ft tall humanoid with CM at say 3ft, your control loop can run at 20hz and you can still digest your IMU signals and prevent the thing from falling. Normal embedded Linux that isn't running a counterstrike game server in parallel to controlling the robot's motors will give you reliable event handling at least at 50hz even without even "nice"ing the robot's control process. (assuming you will run your Linux on a RoBoard or FitPC). In any case, it is probably easier to recover from a missed frame than to run RT linux.
Getting the kernel to run so that it reliably calls your handlers upon an interrupt within X microseconds (ie: real-time) involves what would be considered by some as non-trivial and with some side effects.
You may be better off having another microprocessor board that does some low level talking to the motors/servos and relays digested information to the Linux.
In our project ActuatedCharacter.com we managed to get a control loop between a RoBoard.com Linux and 20 (dynamixel) servos (with custom firmware) at over 200Hz with an FTDI interface to the servos and without any real-time kernel modifications.
If you are considering using dynamixel servos as actuators, please check out robosavvy.com forums for general information about building humanoid robots (for robocup or for general research), alternative firmware for better closed loop control rates, issues with FTDI latency, serial controlled servos. Also consider the software framework you want to develop, which in turn will help you with your requirements. Obviously talk to established Robocup humanoid league teams but also of interest are inriaflowers, NAO/Aldebaran and ofcourse ROS.
发布评论
评论（3）
你选择的操作系统不太可能由“人形机器人”的约束来决定，没有特定的“人形机器人操作系统”，当然也不会由这样的机器人有多高来决定操作系统！ ;-)！关键因素是
其他因素可能也很重要，例如：
虽然在所有情况下都不一定是操作系统的固有部分，因为在许多情况下都可以使用第三方平台独立库，但在您需要它们时，与操作系统的集成会很有帮助，因为它可以避免您自己处理线程安全和资源锁定。
你所建议的选项都不可能出现在我的列表中。
任何基于 Linux 的东西都需要 MMU（除非使用 uCLinux 或其衍生物，但 MMU 支持是在嵌入式系统中使用 Linux 的少数几个充分理由之一）。 Linux 并不是一个实时操作系统，它所提供的任何实时支持几乎都是事后才想到的，并且很少像真正的 RTOS 那样具有确定性。任何 Linux 还需要大量内存资源才能启动，任何可用的东西至少需要 4Mb RAM，而 FreeRTOS 和 uC/OS-II 等 RTOS 内核只需要大约 4Kb - 您在这里将粉笔与奶酪进行比较。也就是说，它们没有基于 Linux 的操作系统的实用程序，例如文件系统或网络支持（尽管这些可以作为独立库添加）。
如果您要在与认知功能相同的处理器上执行运动控制和传感器/执行器功能，那么您当然需要确定性 RTOS。然而，如果该平台是一个分布式系统，具有处理运动控制和其他实时传感器/执行器 I/O 的单独处理器，那么您可能会使用简单的 RTOS 内核，或者 I/O 处理器中根本没有操作系统（也可以是更小、功能更弱的处理器）和认知（决策和规划）处理器中的 GPOS。
我最近评测过FreeRTOS，它简约、简单、小巧，只提供基本的线程、定时和IPC机制，其他很少。它有效，但许多其他更具吸引力的选择（商业和非商业）也有效。我将其与 Keil 的 RTX 内核（包含在他们的 MDK-ARM 工具套件中）进行了比较，以及商业 Segger embOS。它的上下文切换时间比其他两个候选者要慢得多（尽管在 72MHz Cortex-M3 上仍然是微秒级，并且比 Linux 可能实现的任何速度都快）。
uC/OS-II 设计良好并有文档记录（在 Jean Labrosse 的书中），如果您想了解 RTOS 的工作原理，那么它会非常有用。它最大的失败是其非常严格的优先级调度方案，这对于非常小的目标来说是有效的，但可能不像您希望的那样灵活。每个线程必须分配一个不同的优先级，因此它不支持循环调度，这对于非实时后台任务很有用。 uC/OS-III 修复了这个缺点，但许多其他选项也同样如此。
如果您的目标处理器有 MMU，我强烈建议使用支持它的操作系统，以保护每个线程或进程免受任何其他线程或进程的影响，系统将更加健壮且易于调试，特别是当开发为团队。在这样的操作系统中，错误的任务会以不确定的方式占用其他线程的资源，并且通常难以调试结果，而是会导致异常并在错误发生的地方停止，而不是稍后在损坏的数据获取时停止。用过的。
您可能不需要将自己限制在免费或开源 RTOS 上，许多供应商允许免费用于教育和评估。我强烈建议您考虑QNX Neutrino，它是免费用于非商业和学术用途，并且具有最强大的内在任何 RTOS 中都提供 MMU 支持，并且包含您需要的所有开发工具，包括基于 Eclipse 的 Momentics IDE。它不仅仅是一个调度内核，还支持您期望完整操作系统提供的所有服务。它在 ARM、x86、SH-4 PowerPC 和 MIPS 架构上运行。在 x86 上运行特别有用，因为这意味着您可以测试和评估它，甚至可以在 虚拟机在您的桌面上运行。
另一种真正的硬实时替代方案是 eCos，它同时支持超越调度和 IPC 的操作系统服务。它具有本机 POSIX 和 uITRON API、CAN、ADC、SPI、I2C、FLASH、PCI、串行、文件系统、USB 和 PCI 等标准驱动程序，并包括 TCP/IP 网络支持。从这个意义上说，它是一个完整的操作系统，但与 Linux 不同，它不是单一的；它是可扩展的并且静态链接到您的应用程序代码，因此您不使用的功能根本不会包含在运行时二进制文件中。它运行在 ARM、CalmRISC、Cortex-M、FR-V、FR30、H8、IA32、68K/ColdFire、Matsushita AM3x、MIPS、NEC V8xx、PowerPC、SPARC 和 SuperH 上。同样，理论上，您可以在 PC 上的虚拟机上运行 IA32 (x86) 端口，以测试和开发高级代码，但与 QNX 的开箱即用评估不同，您必须自己完成该工作。
添加了以下内容：
那么也许现在还不是开始学习 Linux 的时候（虽然它具有广泛熟悉和社区支持的优点，但它有很多你不需要的东西，而且很多可用的支持资源不会实时熟悉） 。
Labrosse 的 uC/OS-II 书籍的第 2 章概述了 RTOS 概念，例如调度、同步和 IPC，这些概念适用于大多数 RTOS，而不仅仅是 uC/OS-II RTOS 基础知识
我的解决方案是在 Google 上搜索后面带有“101”的主题（学术界常见的入门课程编号）。 ?q=rtos%20101" rel="nofollow">"RTOS 101" 会给你一些公认的不同质量的起点 - 检查来源的信誉，如果是一家公司，他们可能是兜售某种特定的产品，如果是业余爱好者，他们可能有一些见解，但也许是狭隘的观点（通常涉及特定喜欢的硬件），并且可能不具备学术论文的严谨性。
添加了有关 CONFIG_PREMPT_RT 的内容：
它不会使 Linux 成为硬实时操作系统。它可能适合某些应用。如果您正在进行 PID 运动控制（而不是使用专用控制器或单独的处理器），或任何类型的闭环反馈控制，我认为该补丁将无法启用它，至少不可靠。我发现了这个：
实时 Linux 方法的比较。它讨论了在实时应用程序中使用 Linux 的多种方法，包括 CONFIG_PREMPT_RT。它在 C 部分详细讨论了这些内容。
Your choice of OS is unlikly to be determined by the "humanoid robot" constraint, there is no specific "humanoid robot OS", and certainly no OS would be determined by how tall such a robot is! ;-) ! The critical factors are
Other factors may be important such as:
although these need not necessarily be an intrinsic part of the OS in all cases, since third-party platform independent libraries are available in many cases, but where you need them, integration with the OS can be helpful since it avoids you having to deal with thread-safety and resource locking yourself.
Neither of the options you have suggested would likely make into my list.
Anything Linux based will require an MMU (unless using uCLinux or its derivitives, but MMU support is one of the few good reasons for using Linux in an embedded system). Linux is not intended to be a real-time OS and any real-time support it has is pretty much an after-thought, and will seldom be as deterministic as a true RTOS. Any Linux will also require significant memory resources just to boot-up, expect a minimum of 4Mb of RAM for anything usable, while RTOS kernels such as FreeRTOS and uC/OS-II require only about 4Kb - you are comparing chalk with cheese here. That said they do not have the utility of a Linux based OS such as file-systems, or networking support (although those can be added as stand-alone libraries).
If you are going to be performing the motion-control and sensor/actuator functions on the same processor as your cognitive functions, then you certainly need a deterministic RTOS. If however the platform will be a distributed system with separate processors dealing with motion-control and other real-time sensor/actuator I/O, then you may get away with a simple RTOS kernel or no OS at all in the I/O processors (which can also then be smaller, less powerful processors) and a GPOS in the cognitive (decision making and planning) processor.
I have evaluated FreeRTOS recently, it is minimalistic, simple and small, providing only the basic threading, timing and IPC mechanisms and little else. It works, but so do many other more attractive options, both commercial and non-commercial. I compared it with Keil's RTX kernel (included with their MDK-ARM tool suite), and the commercial Segger embOS. It has significantly slower context switching time that the other two candidates (though still in the microseconds on a 72MHz Cortex-M3, and faster than anything you are likely to achieve with Linux).
uC/OS-II is well designed and documented (in Jean Labrosse's book), and is great if you aim were to see how an RTOS works. Its biggest failing is its very restrictive priority scheduling scheme, which is efficient for very small targets, but possibly not as flexible as you might like. Each thread must be assigned a distinct priority level so it has no support for round-robin scheduling, useful for non-real-time background tasks. uC/OS-III fixes that shortcoming, but again so do many other options.
If your target processor has an MMU I strongly suggest the use of an OS that supports it in such a way that each thread or process is protected from any other, the system will be far more robust and easy to debug, especially when developed as a team. In such an OS an errant task that would otherwise stomp on some other thread's resources with non-deterministic and generally hard to debug results, will instead cause an exception and halt right where the error occurred, rather than perhaps sometime later when the corrupted data gets used.
You probably need not restrict yourself to a free or open-source RTOS, many vendors allow free use for education and evaluation. I would strongly suggest that you consider QNX Neutrino, it is free for non-commercial and academic use, and has the most robust intrinsic MMU support available in any RTOS, and all the development tools you need including the Eclipse based Momentics IDE are included. It is more than just a mere scheduling kernel, including support for all the services you would expect of a complete OS. It runs on ARM, x86, SH-4 PowerPC and MIPS architectures. Running on x86 is particularly useful since it means you can test and evaluate it, and even develop much of your code in a VM running on your desktop.
Another alternative that is true hard-real-time, while supporting OS services beyond mere scheduling and IPC, is eCos. It has a native, POSIX and uITRON API, standard drivers for CAN, ADC, SPI, I2C, FLASH, PCI, Serial, Filesystems, USB and PCI and more, and includes TCP/IP networking support. It is a complete OS in that sense, but unlike Linux is not monolithic; it is scalable and statically linked to your application code, so that features you do not use are simply not included in the runtime binary. It runs on ARM, CalmRISC, Cortex-M, FR-V, FR30, H8, IA32, 68K/ColdFire, Matsushita AM3x, MIPS, NEC V8xx, PowerPC, SPARC, and SuperH. Again in theory you could run the IA32 (x86) port it on a VM on a PC for test and development of high level code, though you'd have to get that working yourself unlike QNX's out of the box evaluation.
Added regarding:
This then is perhaps not the time to start learning Linux (although it has the advantages of wide familiarity and community support, it has a lot of stuff you will not need, and a lot of available support resources will not be familiar with real-time control systems applications.
Chapter 2 of Labrosse's uC/OS-II book gives a general overview of RTOS concepts such as scheduling, synchronisation and IPC that are applicable to most RTOS not just uC/OS-II. Similar material is presented in Jack Ganssle's recent RTOS Fundamentals course on EETimes (it is similar perhaps because it is sponsored by Mircium and uses uC/OS-II as a case study, but it is similarly general for the most part).
My solution to getting a quick start in any subject is to Google the subject with "101" after it (a common introductory course number in academia). "RTOS 101" will get you some starting points of admittedly varying quality - check the reputability of the source, if it is a company, they may be peddling a specific product, if it is a hobbyist, they may have some insights, but perhaps a narrow view (often relating to specific favourite hardware), and may not have the rigour of an academic paper.
Added regarding CONFIG_PREMPT_RT:
It does not render Linux a hard real-time OS. It may be suitable for some applications. If you are doing PID motion control (rather than using a dedicated controller or separate processor), or any kind of closed loop feedback control for that matter, this patch will not enable it in my opinion, at least not reliably. I found this:
A comparison of real-time Linux approaches. It discusses a number of approaches to using Linux in real-time applications, including CONFIG_PREMPT_RT. It discusses these in detail in part C.
这并没有回答具体问题，但是：
在寻求有关特定操作系统的建议之前，您需要有关架构和约束的更多详细信息。
我将从 I/O 开始：
既然您知道需要控制什么以及控制多快，那么如何控制它呢？
此时您可以开始考虑特定的处理器和架构。只有当您将范围缩小到一两个好的选择后，您才应该开始考虑操作系统。
我确实预计您最终将需要一个硬实时操作系统来实现运行机器人的运动控制。
This doesn't answer the specific question, but:
Before you ask for advice on a specific OS, you need a lot more details about the architecture and constraints.
I'd start with the I/O:
Now that you know what you need to control and how fast, how do you control it?
At this point you can start considering specific processors and architectures. Only after you have narrowed it down to one or two good options, should you start to consider the OS.
I do expect that you will end up needing a Hard Real-Time OS for the motion control aspects of a running robot.
可能没有必要以硬实时方式运行 Linux。给定一个 4.5 英尺高的人形机器人，CM 高度为 3 英尺，您的控制回路可以以 20hz 运行，您仍然可以消化 IMU 信号并防止物体掉落。正常的嵌入式 Linux 不会在控制机器人电机的同时运行反恐精英游戏服务器，即使没有“良好”地控制机器人的控制过程，也会为您提供至少 50hz 的可靠事件处理。 （假设您将在 RoBoard 或 FitPC 上运行 Linux）。无论如何，从丢失的帧中恢复可能比运行 RT Linux 更容易。
让内核运行，以便它在 X 微秒内（即：实时）中断时可靠地调用处理程序涉及到一些人认为不平凡的事情，并且会产生一些副作用。
您可能最好拥有另一个微处理器板，它可以与电机/伺服系统进行一些低级对话，并将消化后的信息转发给 Linux。
在我们的 ActuatedCharacter.com 项目中，我们成功地在 RoBoard.com Linux 和 20 个（dynamixel）伺服系统（带有自定义固件）之间建立了一个超过 200Hz 的控制环路，并通过 FTDI 接口连接到伺服系统，并且无需任何实时内核修改。
如果您正在考虑使用 dynamixel 伺服系统作为执行器，请查看 robosavvy.com 论坛，了解有关构建人形机器人（用于 robocup 或用于一般研究）的一般信息、用于更好闭环控制速率的替代固件、FTDI 延迟问题、串行控制伺服系统。还要考虑您想要开发的软件框架，这反过来又会帮助您满足您的需求。显然，我们正在与已建立的 Robocup 人形联盟球队进行交谈，但我们也感兴趣的是 inriaflowers、NAO/Aldebaran，当然还有 ROS。
It may not be necessary to run the Linux in hard real-time. Given a 4.5ft tall humanoid with CM at say 3ft, your control loop can run at 20hz and you can still digest your IMU signals and prevent the thing from falling. Normal embedded Linux that isn't running a counterstrike game server in parallel to controlling the robot's motors will give you reliable event handling at least at 50hz even without even "nice"ing the robot's control process. (assuming you will run your Linux on a RoBoard or FitPC). In any case, it is probably easier to recover from a missed frame than to run RT linux.
Getting the kernel to run so that it reliably calls your handlers upon an interrupt within X microseconds (ie: real-time) involves what would be considered by some as non-trivial and with some side effects.
You may be better off having another microprocessor board that does some low level talking to the motors/servos and relays digested information to the Linux.
In our project ActuatedCharacter.com we managed to get a control loop between a RoBoard.com Linux and 20 (dynamixel) servos (with custom firmware) at over 200Hz with an FTDI interface to the servos and without any real-time kernel modifications.
If you are considering using dynamixel servos as actuators, please check out robosavvy.com forums for general information about building humanoid robots (for robocup or for general research), alternative firmware for better closed loop control rates, issues with FTDI latency, serial controlled servos. Also consider the software framework you want to develop, which in turn will help you with your requirements. Obviously talk to established Robocup humanoid league teams but also of interest are inriaflowers, NAO/Aldebaran and ofcourse ROS.