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

无需提及为什么实时操作对于实时任务很重要。机器人。但是,我的问题是,机器人技术中实际使用了多少?例如,以这个问题为例。只有一个答案提到了具有实时功能的任何平台,而且距离最高点也不远。 ROS显然是一个非常流行的非实时平台。

然而,在实时世界中,RTAI1似乎是唯一可行的免费实时使用平台。但是,它仅限于Linux(没有问题),记录不充分且开发缓慢。

那么,机器人技术开发人员需要多少实时行为?问题是,当实际需要实时行为时,开发人员有多少倾向编写实时应用程序?如果不是很多,为什么?

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

1或类似的Xenomai

评论

我认为这是一个很好的问题。考虑将其分为两部分,并澄清您的主要问题。 ROS可以用于实时吗?或“ ROS是否与实时一起使用?” (2个不同的问题)与您的主要问题分开。

@ hauptmech,ROS肯定不能用于实时,因为它不是实时的!

我同意@hauptmech。这些问题令人困惑。首先,您要询问使用多少人/多长时间使用一次实时系统,然后再询问何时/在哪种情况下。两者都是很好的问题,因此请分成两个或简化为一个。谢谢!

@ bit-pirate,我不明白您为什么说我问何时/在哪种情况下。我从来没有问过这样的事情。就像我说的那样,问题是,当实际需要实时行为时,开发人员倾向于编写实时应用程序吗?换句话说,实际上需要实时执行的应用程序中有多少百分比需要实时行为?我个人知道何时以及在何种情况下需要实时行为,对此绝对没有问题。实际上,我很惊讶地看到解释这一点的答案。

感谢您的澄清!对我来说,标题令人困惑。 IMO实时编程+实现在Robotics中已经很成熟,但是它涉及更多的工作(时间,金钱,技能等),因此大多数人在不需要时会避免使用它。

#1 楼

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

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

系统的不同部分也可能具有非常不同的实时要求。如果您正在运行软件PID循环,则它们确实应该具有较硬的实时响应(例如,您真的不希望在对PID进行软调整或对其进行硬调整以及偶尔使其变得不稳定之间进行选择)。视觉系统可能对实时响应有严格的要求,如果您不能及时处理下一个决定的图像,性能将会降低,但是它不会阻止系统运行,在这种情况下,如果您不能及时处理图像,最好扔掉部分结果,而不浪费时间开始下一帧的分析。最后,您的总体规划和协调(可能是机器人系统中最复杂的部分)通常可以始终牢牢地处于软实时领域。

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

评论


$ \ begingroup $
这里的区别是非常相关的...即使在“现实世界”的低级系统中,真正的实时位还是很小的(基于计时器滴答中断),而大多数系统在名义上都是时间(但在此范围内可以容忍+/-纳秒)。当我看到人们谈论基于WindowsCE或Linux构建的实时应用程序时,我笑了。
$ \ endgroup $
–安德鲁♦
2012年10月26日19:04

$ \ begingroup $
正如我说@Andrew使用正确的软件,即使Windows 7也可以通过RTX实时实现。不知道为什么您不认为Windows CE是实时的,它具有实时确定性的任务调度功能,因为第2版和Linux可以使用RTLinux之类的内核实时实现。
$ \ endgroup $
– Mark Booth♦
2012年10月26日20:40

$ \ begingroup $
马克,您好(不确定谁在这里跟踪谁...)-我同意您可以这样做,但是严酷的经验表明,在很多(大多数)情况下,用户(经理)会忽略要求的添加-on并假设香草系统会起作用。
$ \ endgroup $
–安德鲁♦
2012年10月26日在21:10



$ \ begingroup $
@Andrew-我对RTX的经验是它确实有效。在奔腾4天后,您必须注意不要使用使PCI总线饱和的集成图形或音频,但这几天不应该成为问题。
$ \ endgroup $
– Mark Booth♦
2012年10月26日21:25

$ \ begingroup $
已经有很长的时间了,但是回读此页面,尤其是关于Windows的问题,我想说的是,您只提到了实时系统的一部分。当然,实时调度很重要,但是有各种各样的事情会产生尖峰,为了使系统实时,还需要对其进行处理。中断是常见的示例,SMI,缓存和内存带宽是其他示例。仅仅因为有一个实时调度程序就不能使系统实时。
$ \ endgroup $
– Shahbaz
18年5月28日在17:54



#2 楼

许多(大多数)机器人控制系统实际上并不需要实时系统。只要您的控制循环运行得足够快,具有足够低的抖动并且不会错过太多的周期,那么这对于机器人控制和伺服就足够了。 ,让我介绍一下PR2和Shadow机器人之手:



该机器人具有大约20个自由度,所有这些自由度都通过ROS的主循环进行伺服。或者说还有20个自由度的Shadow Robot Hand,还有一系列触觉传感器和其他传感器,它们也通过ROS的主回路进行伺服。有时多达100us,甚至有时会完全错过周期。但是,是否成功执行99.9%的周期并不重要。

在主机PC中使用许多内核意味着一个完整的内核专用于运行主循环,因此很少会因其他任务而延迟。为机器人系统使用真正实时的OS的主要原因是为了安全。如果机器人在安全至关重要的情况下工作,那么您有责任保证100%的控制正常运行时间,其中一部分就是保证其实时性。

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


已添加

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

评论


$ \ begingroup $
简而言之,您是说经常不使用实时,因为非实时软件的工作“足够好”吗?
$ \ endgroup $
– Shahbaz
2012年10月25日13:52

$ \ begingroup $
@Shahbaz-我无法确切说明它的实际使用频率,但是我可以说,如果使用它,则可能完全没有必要。我们曾经使用RTAI,但后来放弃了它,因为它实际上阻碍的不仅仅是帮助。
$ \ endgroup $
– Rocketmagnet
2012年10月25日15:10



$ \ begingroup $
我想强调一点:您在PR2上拥有如此强大的处理能力,因此您可能会得到“足够好”的东西。我使用“仅” Core2 Duo开发了一个机器人。那不是一个选择:完整的堆栈在大多数情况下会占用每个内核100%的资源。在这里,Rock(Orocos)和RT-Linux对于将1kHz控制环路结合在一起是必要的。
$ \ endgroup $
– sylvain.joyeux
2012年10月25日20:34



$ \ begingroup $
@ sylvain.joyeux-我同意。当您只有2个内核时,ROS的控制性能会很差。
$ \ endgroup $
– Rocketmagnet
2012年10月25日20:45

$ \ begingroup $
@Rocketmagnet对不起,我不得不对此进行投票,但是PR2部分是错误的。在PR2上,有一个与ROS并行的,以1000Hz运行的实时环路(在Linux + RT PREEMPT上),该环路通过Ethercat与电机控制器板通信,对每个自由度进行实际的电机控制。在对控制器(例如联合轨迹控制器)进行编程时必须小心,以免实时中断,并且它们还具有用于管理它们的特殊工具(例如加载/卸载它们)。在这里查看更多详细信息。
$ \ endgroup $
–比特海盗
2012年11月8日,0:23



#3 楼

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

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

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

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

使用计算机/微处理器的机器人(因为需要更多的处理能力),使用实时操作系统来确保高采样率。


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

评论


$ \ begingroup $
感谢您的答复。也许我的问题需要更好的措辞,但我不想问“何时使用实时”,而是“人们在需要实时时实际使用实时的频率”。不过,我没有考虑过您不需要微控制器就可以在微控制器上进行实时操作的优点。
$ \ endgroup $
– Shahbaz
2012年10月25日在11:37



$ \ begingroup $
附带说明,实时和快速是两个正交的概念。如果路径规划者必须在一分钟内严格决定,那么它是实时应用程序。虽然我了解您为什么提到快速机器人。
$ \ endgroup $
– Shahbaz
2012年10月25日上午11:38

#4 楼

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

#5 楼

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

编程的实时部分通常尽可能小,因为它更难调试和更少的代码更容易检查正确性。实时操作系统的文档通常都不错(包括RTAI / Xenomai)。

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

#6 楼

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

#7 楼

开始考虑使用多个CPU和实时问题转移来解决您的机器人问题。如果您有需要高速可靠反馈的算法,例如两轮平衡器或四轴稳定器或伺服脉冲输出,则实时性非常重要,但任务也非常有限。 >您可以将这样的控制循环卸载到专用的实时CPU,例如Arduino类设备中的廉价8位AVR或低端32位ARM。没有什么可以阻止您添加许多运行专用控制回路的小型MCU的了,USB设备枚举甚至使此操作变得简单。放宽了机器人“大脑”的实时需求,该机器人可以使用Linux上的ROS或Windows的Kinect等组件运行高端逻辑。

#8 楼

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

以我的经验,运动控制是实时系统的主要应用。为了控制电动机,高频(100hz,1000hz及更高)和低抖动(时间变化)很重要。安全是这里的重点。以人类中的机器人为例:例如,您希望/需要确保机器人(手臂)在特定的时间范围/距离内停下。实时系统并不是那么重要,并且由于开发时间和硬件成本上的开销而经常避免使用。在启用RT的操作系统(例如Linux + Xenomai)的实时环境中,正在发生运动控制,而在非实时部分(用户区域)中,视觉处理和规划已嵌入到ROS等系统中。两者都可以在同一台计算机上运行。

问题明确后,我很高兴编辑此答案。 :-)

#9 楼

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

#10 楼

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

如上其他人所述,您可以允许非实时操作系统运行1KHz控制循环,但是要使其正常工作,您需要一台过时的,过大的大型计算机在空闲循环中。如果以接近100%的CPU使用率运行Linux / ROS计算机,则实时性能会很差。使用两层设计,您可以始终获得非常好的RT性能,并且还可以使用体积更小,耗电更少的计算机(可能是Pi2更高级别的任务。)我的uP当前不运行任何操作系统,但是我将转向FreeRTOS