机器人技术中的实时编程有多成熟？[关闭]

编辑：我不知道为什么，但是这个问题似乎使很多人感到困惑。我知道何时/何地/为什么/如何使用实时。我很想知道执行实时任务的人是否真的足够在意实时执行任务。

无需提及为什么实时操作对机器人很重要。我的问题是，机器人技术中实际使用了多少？

以这个问题为例。只有一个答案提到了具有实时功能的任何平台，而且距离最高点也不远。ROS显然是一个非常受欢迎的非实时平台。

但是，在实时世界中，RTAI ¹似乎是唯一可行的免费实时使用平台。但是，它仅限于Linux（没有问题），文档记录不佳且开发缓慢。

那么，机器人开发人员追捧的实时行为有多少？问题是，当实际需要实时行为时，开发人员有多少倾向编写实时应用程序？如果不多，为什么呢？

例如，基于触觉数据的反身行为不能通过ROS，因为它将失去其实时属性。但是人们是否真的想出了实时解决方案或仍在使用ROS，而忽略了实时属性？

^1个或类似的Xenomai

请记住，存在实时，也存在实时。

如果没有硬件支持或底层软件支持，很难实现“ 硬实时”，但是您通常不需要具备“ 硬实时”功能。软实时实时响应更容易实现，通常对于许多应用程序来说绰绰有余。

同样，系统的不同部分可能具有非常不同的实时要求。如果您正在运行软件PID循环，则它们实际上应该具有较硬的实时响应（例如，您实际上不希望在对PID进行软调整或对其进行硬调整以使其偶尔变得不稳定的情况之间进行选择）。视觉系统可能对实时响应有严格的要求，如果您不能及时处理图像以做出下一个决定，则性能会下降，但是它不会阻止系统运行，在这种情况下，如果您无法及时处理图像，最好扔掉部分结果，而不浪费时间开始下一帧的分析。最后是您的整体计划和协调（可能是最复杂的机器人系统的一部分）通常可以始终保持在软实时领域内。

即使在Windows PC领域，您也可以获得实时性能，您只需要带有正确钩子的正确软件即可。Beckhoff的TwinCat软PLC通过将Pentium的一半机器周期切片，将另一半分配给Windows NT，从而愉快地运行了高扫描率PLC，而这是十年前的事了。即使是像Aerotech A3200系列中的某些选件之类的现代控制系统，也可以在主机PC上完成繁重的工作，低级内核占用的CPU时间与硬实时要求所需的时间一样多，而其余​​的CPU周期则留给Windows 7使用！

许多（大多数）机器人控制系统实际上并不需要实时系统。只要您的控制循环运行得足够快，并且抖动足够小，并且不会错过太多的周期，那么对于机器人控制和伺服来说这已经足够了。

作为证明，让我介绍一下PR2和Shadow Robot Hand：

该机器人具有大约20个自由度，所有这些自由度都通过ROS的主循环进行伺服。又或者说影子机器人手，它也有20个自由度，外加一系列触觉和其他传感器，并且也通过ROS的主循环进行伺服。

ROS主环路存在一些抖动，有时甚至高达100us，甚至有时会完全丢失周期。但是，是否成功执行了99.9％的周期并不重要。

在主机PC中使用许多内核意味着一个完整的内核专用于运行主循环，因此很少会因其他任务而延迟。

为机器人系统使用真正实时的OS的主要原因是为了安全。如果机器人在安全至关重要的情况下工作，那么您有责任确保100％的控制正常运行时间，而其中的一部分就是保证其实时性。

无论您是否使用实时操作系统，在控制回路完全中断的情况下，伺服器都应该做一些安全的事情。在您的非实时操作系统跳过一个周期以上的极少数情况下，此安全系统也很有用。例如，在“影子手”上，如果控制回路错过了20个以上的周期（20毫秒），则电动机将停止运行。我从未见过这种情况。

添加

另一种思考的方式是：您的伺服系统实际需要什么更新速率？如果它的手臂较大，并且不需要超高性能，高速定位，那么500Hz可能就足够了。对于四处行驶，200Hz可能就足够了。在这两种情况下，如果您的环路实际上以1000Hz运行，那么只要您的控制算法考虑了环路之间的实际经过时间，延迟周期或丢失周期就根本没有问题。

该软件的用途决定了是否需要严格实时。

在目的是路径规划或定位的情况下，通常低频就足够了，例如10Hz。在这些情况下，可以在Linux上运行播放器/舞台设置。我们可以看到，如果一个时间步长或短一些，则几乎没有问题。

如果机器人动态快速，则需要严格的实时行为。例如，移动机械臂以跟踪位置，或处理/抓握对象并将其移动。如果错过了时间步长，则仓位可能会超出预期，我们可能需要更多可预测的行为。在这种情况下，我们的频率可能高达1kHz或更高。如果使用操作系统，我们需要一个实时操作系统。

通过使用计时器和中断（微控制器上已编译的C代码），可以在嵌入式应用程序中实现实时行为。在这种情况下，我们必须确保处理负荷不会过高，以便可以维持规则的采样频率。

使用计算机/微处理器的机器人（因为需要更大的处理能力）将需要使用实时操作系统来保证高采样率。

因此，是否需要实时行为取决于开发人员打算将其用于什么用途。

我们公司使用在PIC微控制器上运行的FreeRTOS来构建机器人。对我们来说，使用FreeRTOS的主要原因是易于重新安排任务的优先级，同时处理多条通信线路以及中断处理程序与主要任务之间的便捷通信。与将完整的linux机器放入我们生产的每个机器人中相比，微控制器要便宜得多。

如果您确实需要实时，则可以使用实时操作系统。安全监控，数据采集和恒定采样率控制循环是使用实时调度的常见子系统。

编程的实时部分通常尽可能小，因为它调试起来更困难，并且更少的代码更容易检查正确性。实时操作系统的文档通常非常好（包括RTAI / Xenomai）。

我在不同的实际机器人项目中使用了QNX和RTAI-> Xenomai 。我更喜欢QNX，但Xenomai同样有效。

Orocos是成熟的实时机器人控制软件框架。我已经看到它用于成功地控制具有严格实时要求的高速机械手。它具有许多与ROS，通信，配置，序列化和基于组件的打包相同的框架级组件。

开始考虑使用多个CPU和实时问题转移来解决您的机器人问题。如果您有一个需要高速可靠反馈的算法，例如两轮平衡器或四轴稳定器或伺服脉冲输出，则实时性非常重要，但任务也非常有限。

您可以将这样的控制循环卸载到专用的实时CPU，例如Arduino类设备中的便宜的8位AVR或低端的32位ARM。没有什么可以阻止您添加许多运行专用控制环路的小型MCU的，USB设备枚举甚至使此操作变得容易。

现在，您已经由专用CPU处理了对时序敏感的控制循环，您可以放宽对机器人“大脑”的实时需求，该机器人可以使用Linux上的ROS或Windows的Kinect等组件来运行高端逻辑。

为了响应“何时/在哪种情况下”，使用实时系统：

以我的经验，运动控制是实时系统的主要应用。为了控制电动机，高频（100hz，1000hz及更高）和低抖动（时间变化）很重要。安全是这里的重点。考虑一下人类中的机器人：例如，您想要/需要确保机器人（手臂）在特定的时间范围/距离内停止。

对于其他任务，例如路径规划，视觉处理和实时系统推理并不那么重要，通常由于开发时间和硬件成本的开销而避免使用。

如今，像PR2这样的大型机器人将两者结合在一起。在启用RT的操作系统（例如Linux + Xenomai）的实时环境中，正在发生运动控制，而在非实时部分（用户区域）中，视觉处理和规划则被嵌入到ROS等系统中。两者都可以在同一台计算机上运行。

问题明确后，我很乐意编辑此答案。:-)

是的，假设硬件资源可以满足时序要求（足够的处理能力，足够低的等待时间），那么当调度程序无法适当地对进程和线程进行排序时，则可以使用实时调度程序，通常将其附加到专门针对内核进行了优化的内核上。挑战。硬件驱动程序也可以针对实时条件进行优化。

是的，如果不能保证某个软件可以在所需的时间限制内完成工作，那么就可以使用实时方法。

一个好的解决方案是同时做。我使用的设计将“硬”实时功能放置在小型微控制器，紧密的伺服控制回路等上。然后是另一个更大的CPU，它运行Linux和ROS。我让ROS处理更高级别的任务，而uP处理诸如控制步进电机或运行PID回路之类的事情。

就像其他人所说的那样，您可以允许非实时操作系统运行1KHz控制环路，但要使其正常工作，您需要一台过大的，过大的大型计算机，它将大部分时间都花在空闲环路上。如果您以接近100％的CPU使用率运行Linux / ROS计算机，则实时性能会很差。使用两层设计，可以使您始终获得非常好的RT性能，并且还可以使用体积更小，耗电更少的计算机（可能是Pi2更高级别的任务。）我的uP当前不运行任何操作系统，但我正在使用FreeRTOS