Vic*_*ani 8 robotics real-time rtos freertos
我们是学生在大学里开发一个中型(~4.5英尺高)人形机器人作为赞助研究项目.机器人应该能够执行的主要任务包括:四处移动(向前,向后,侧向),跑步,拾取物体.我们正在考虑使用硬实时操作系统来控制机器人.但是,由于我们是这个领域的新手,几乎没有嵌入式系统或操作系统的背景,并且有多种选择,我们不确定哪一个是合适的选择.我们遇到以下情况(括号内是我们目前对它们的印象):
我有很多问题:
更新:感谢您提供非常详细的答案.很明显,我们以错误的方式解决这个问题; 没有任何知识和vauge要求潜水肯定会很糟糕.我们必须坐下来,准确地说出我们需要的东西.当我们充分领先时,我们将尝试找出合适的操作系统.让我们看看它是如何运作的.我还将阅读MicroC OS II的第2章:实时内核.
Cli*_*ord 21
您选择的操作系统很难由"人形机器人"约束决定,没有特定的"人形机器人操作系统",当然也没有操作系统可以决定这样的机器人有多高!;-)!关键因素是
其他因素可能很重要,例如:
虽然在所有情况下这些并不一定是操作系统的固有部分,但由于在许多情况下可以使用第三方平台独立库,但在需要它们的地方,与操作系统的集成可能会有所帮助,因为它可以避免您必须处理线程安全和资源锁定自己.
您建议的两个选项都不会列入我的列表.
基于Linux的任何东西都需要MMU(除非使用uCLinux或其衍生产品,但MMU支持是在嵌入式系统中使用Linux的少数几个理由之一).Linux并不是一个实时操作系统,它拥有的任何实时支持几乎都是经过深思熟虑的,并且很少像真正的RTOS一样具有确定性.任何Linux都需要大量的内存资源来启动,期望任何可用的内存至少有4Mb的RAM,而RTR内核如FreeRTOS和uC/OS-II只需要大约4Kb - 你在这里比较粉笔和奶酪.这就是说它们没有基于Linux的操作系统的实用程序,例如文件系统或网络支持(尽管可以将它们添加为独立的库).
如果您要在与认知功能相同的处理器上执行运动控制和传感器/执行器功能,那么您当然需要一个确定性的RTOS.然而,如果该平台将是一个分布式系统,其中包含处理运动控制和其他实时传感器/执行器I/O的独立处理器,那么您可能会在I/O处理器中完全使用简单的RTOS内核或根本没有操作系统(也可以是更小,功能更弱的处理器)和认知(决策制定和规划)处理器中的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上运行特别有用,因为它意味着您可以测试和评估它,甚至可以在桌面上运行的VM中开发大量代码.
eCos是另一种真正的硬实时替代方案,同时支持OS服务,而不仅仅是调度和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上的VM上运行IA32(x86)端口来测试和开发高级代码,尽管你不得不自己开始工作,而不像QNX的开箱即用评估.
添加了关于:
我们对操作系统的了解很少.我们有必要先了解它们吗？如果是的话,什么是一个好的,短的入门主题？
这可能不是开始学习Linux的时候(虽然它具有广泛熟悉和社区支持的优点,但它有很多你不需要的东西,而且很多可用的支持资源都不熟悉实时控制系统应用.
Labrosse的uC/OS-II书的第2章概述了适用于大多数RTOS而不仅仅是uC/OS-II的RTOS概念,如调度,同步和IPC.Jack Ganssle最近在EETimes上的RTOS基础课程中提供了类似的材料(它可能是因为它由Mircium赞助并使用uC/OS-II作为案例研究,但在大多数情况下它同样是通用的).
我在任何主题中快速入门的解决方案是谷歌之后的"101"主题(学术界常见的入门课程编号). "RTOS 101"将为您提供一些不同质量的起点 - 检查来源的信誉,如果是公司,他们可能会兜售特定产品,如果是业余爱好者,他们可能会有一些见解,但也许狭隘的观点(通常与特定喜爱的硬件相关),可能没有严谨的学术论文.
添加了有关CONFIG_PREMPT_RT:
它不会使Linux成为一个硬实时操作系统.它可能适合某些应用.如果你正在进行PID运动控制(而不是使用专用控制器或单独的处理器),或任何类型的闭环反馈控制,我认为这个补丁不会启用它,至少不可靠.我发现了这一点: 实时Linux方法的比较.它讨论了在实时应用程序中使用Linux的许多方法,包括CONFIG_PREMPT_RT.它在C部分详细讨论了这些.
这并没有回答具体问题,但是:
在您询问有关特定操作系统的建议之前,您需要有关架构和约束的更多详细信息.
我从I/O开始:
既然您知道需要控制什么以及控制速度有多快,那么您如何控制它？
此时,您可以开始考虑特定的处理器和体系结构.只有在您将其缩小到一两个好的选项之后,才应该开始考虑操作系统.
我确实希望你最终需要一个硬实时操作系统来运行机器人的运动控制方面.
小智 6
可能没有必要在硬实时运行Linux.鉴于一个4.5英尺高的人形机器人,CM在3英尺处,你的控制环路可以在20赫兹运行,你仍然可以消化你的IMU信号并防止物体掉落.正常的嵌入式Linux没有与控制机器人的电机同时运行反击式游戏服务器,即使没有"很好"的机器人控制过程,也能为您提供至少50hz的可靠事件处理.(假设您将在RoBoard或FitPC上运行Linux).在任何情况下,从错过的帧恢复比运行RT linux更容易.让内核运行以便在X微秒内(即:实时)中断时可靠地调用处理程序涉及一些人认为非平凡且具有一些副作用的内容.
你可能最好还有另一个微处理器板与电机/伺服器进行低级别的通信,并将消化的信息传递给Linux.
在我们的项目ActuatedCharacter.com中,我们设法在RoBoard.com Linux和20(动态像素)伺服系统(带有自定义固件)之间获得超过200Hz的控制回路,其中FTDI接口连接到伺服系统,无需任何实时内核修改.如果您正在考虑使用动态像素伺服系统作为执行器,请查看robosavvy.com论坛,了解有关构建仿人机器人(用于robocup或一般研究)的一般信息,用于更好闭环控制率的替代固件,FTDI延迟问题,串行控制伺服系统.还要考虑您要开发的软件框架,这反过来将帮助您满足您的要求.显然,与已建立的Robocup人形联盟球队交谈,但也有兴趣的是inriaflowers,NAO/Aldebaran和ocourse ROS.
| 归档时间： |
|
| 查看次数： |
7180 次 |
| 最近记录： |