1

作为一个学生项目，我们正在构建一个机器人，它应该通过一个定义的路线并捡起一个木制立方体。它的核心是一台运行 250MHz ARM9 的 debian 的单板计算机。因此，控制器的处理能力绰绰有余。此外，它还进行一些图像处理（不是在驾驶时，只有在停止时），这就是为什么我们不使用没有操作系统的简单微控制器的原因。

目前整个事情运行良好，但有一个问题：主控制循环执行没有任何延迟，并达到超过 1kHz 的循环频率。这绰绰有余，100Hz也足够了。但是每时每刻都有一个周期需要100ms甚至更多，这可能会对控制器造成很大的干扰。

我怀疑还有其他一些任务会导致这种延迟，因为调度程序可能会检测到它们在很长一段时间内没有任何 CPU 时间。

所以我最想要的是以下内容：在控制器的主循环中可能有 5 毫秒的短暂睡眠，这确实只需要 5 毫秒，但为系统的其余部分提供了一些处理器时间。我可以使用 nanosleep 包括例如 500us 的延迟，但这总是需要超过 10 毫秒才能执行，因此它不是真正的替代方案。我更喜欢自愿睡眠之类的东西，让等待的任务有机会做某事，但会尽快返回。

否则系统会被卸载，因此没有什么可以真正需要长时间进行大量处理。

有没有办法在用户空间做到这一点，即不必坚持像 RTAI 之类的东西？

谢谢，菲利普

4

4 回答 4

0

I suggest that you stick to real time interfaces when doing motor control; I've seen a 1000 kg truck slam into a wall during a demo due to that the OS decided to think about something else for once... :-)

If you want to stay away from RTAI (but you shouldn't); a (perhaps) quick fix is to slap an Arduino board for the actual driving, and keep the linux board for high level processing.

To fix the "wall problem" implement a watchdog in the driver board, that stops the thing if no command have arrived for a while...

于 2012-05-24T07:08:26.040 回答
0

实时问题需要实时操作系统。

因为实时操作系统是可预测的。您可以设置任务优先级，以便需要在指定时间产生结果的任务不会被需要处理能力但不受时间限制的任务抢占。

于 2012-05-24T07:19:46.017 回答
0

我们在工作中的 ARM7 板上运行 100 Hz 循环，使用带有RT 补丁的标准 Linux ，它允许（几乎）内核中的所有锁被抢占。将此与高优先级线程相结合，可为我们在内核和用户空间提供必要的性能。

由于您唯一需要做的就是应用补丁并将内核配置为使用完全抢占，它也很容易使用 - 无需更改软件架构中的任何内容，尽管我对 Debian 还不够熟悉补丁是否会干净地应用。

于 2012-06-03T17:32:09.267 回答
0

好的，我找到了一个更好的解决方案，虽然并不完美。还有另一个线程解释了 sched_setscheduler() 函数。我的初始化代码现在看起来像这样：

// Lock memory to reduce probability of high latency due to swapping
int rtres = mlockall(MCL_CURRENT | MCL_FUTURE);
if (rtres) {
  cerr << "WARNING: mlockall() failed: " << rtres << endl;
}

// Set real-time scheduler policy to get more time deterministic behaviour
struct sched_param rtparams;
rtparams.sched_priority = sched_get_priority_max(SCHED_FIFO);
rtres = sched_setscheduler(0, SCHED_FIFO, &rtparams);
if (rtres) {
  cerr << "WARNING: sched_setscheduler() failed: " << rtres << endl;
}

此外，我已经从主循环中删除了短暂的睡眠。该进程现在消耗了所有可用的处理能力，并且（显然）对来自外部世界的任何操作（例如控制台击键等）没有响应，但这对于手头的任务来说是可以的。主循环统计数据显示，大多数迭代需要不到一毫秒的时间才能完成，但仍有一些（每 1000 次左右）需要大约 1 毫秒。100 毫秒。这仍然不好，但至少不再有更长的延迟。

由于它“只是”一个学生项目，我们可以接受它并将其作为进一步改进的候选者。

无论如何，感谢您的建议。下一次，我会更好地了解如何应对实时要求并从一开始就采用 RT OS。

问候，菲利普

于 2012-06-03T17:09:26.360 回答