我目前正在使用蜂窝系统(4G 或 5G)构建和实施机器人控制系统。我正在考虑使用 RTOS 以减少服务器中的处理时间。
RTOS 不是关于“减少处理时间”,它支持对事件的快速和确定性响应。也就是说,对现实世界外部事件的响应可以通过明确定义的最小和最大响应时间来实现。我说“支持”是因为粗心大意的人有很多方法可以搞乱调度和 IPC 并使系统在这方面表现不佳。
减少处理时间是处理速度和处理负载的问题。即你的处理器有多快以及你要求它处理什么。从这个意义上说,选择有效的算法和数据结构以及编译器优化是比使用 RTOS 更有效的方法。
服务器接收来自机器人的请求并响应它。通过实验,我发现了以下内容。
好的,现在我不清楚您打算在哪里使用 RTOS。在机器人上还是在服务器上?如果在服务器上,要获得确定性的端到端实时响应,则通信通道还必须具有实时能力——即保证最大响应时间。它可以做到吗?
现在,我正在考虑在云/边缘服务器上安装 preempt-rt 内核。
preempt-rt 并没有真正制作 Linux 和 RTOS,尽管它在这个应用程序中可能是足够和合适的。它的好处是为 COTS PC 架构板提供所有硬件、I/O 和网络支持,而大多数(但绝不是全部)真正的 RTOS 缺乏,并且您可能必须由第三方组件提供 - 这是一个对复杂和 PC 的要求很高。
如果它适用于普通 Linux,并且您需要保证特定的响应时间,那么它是合适的。你只是想让代码运行得更快,这不是办法。基于优先级的抢先式调度程序允许您确保特定代码在需要时运行,而不是在内核开始调度它时运行。它可以防止处理延迟,而不是加快处理速度。
是否通过在服务器上安装 RTOS 减少端到端延迟和处理时间超过 10 毫秒?
服务器上运行的软件无法改变通信网络的延迟。如上所述,您实现的是处理中的最小延迟,而不是更快的处理。在这种情况下,如果通信中没有延迟保证,那么将延迟最小化几乎没有什么优势,而您不太可能获得 - 测量“典型”响应时间并不能保证。
robot -----> base station -----> edge server
<----- <-----
or
robot -----> base station -----> cloud server
<----- <----
除非每个组件——机器人、通信链路、基站和服务器——都具有实时能力,否则整个系统将不具备实时能力。