返回介绍

中间件及架构 - uORB消息机制

发布于 2020-07-27 14:09:23 字数 7577 浏览 1261 评论 0 收藏 0


translated_page: https://github.com/PX4/Devguide/blob/master/en/middleware/uorb.md

translated_sha: 18f5865bf5265934136cf5d18f838203c3db2100

uORB消息机制

简介

uORB是一种用于线程间/进程间进行异步发布-订阅的消息机制的应用程序接口(API)。

在这个教程中可以学习通过C++如何使用uORB。

由于很多应用都是基于uORB的,因此在系统刚启动时uORB就自动运行了。uORB通过uorb start启动。可以使用uorb test进行单位测试。

添加新的话题(topic)

要想增加新的topic,你需要在msg/目录下创建一个新的.msg 文件,并在msg/CMakeLists.txt下添加该文件名。这样会自动生成所需的C / C ++代码

可以先看看现有的msg文件所支持的类型。一个消息也可以嵌套在其他消息当中。

每一个生成的C/C++结构体中,需要添加一个uint64_t timestamp 时间戳字段。该字段用于记录器(logger),因此确保在发布消息时一定要添加它。

为了在代码中使用”topic”,需要添加头文件:

  1. #include <uORB/topics/topic_name.h>

通过在.msg文件中,添加类似如下的一行代码,一个消息定义就可以用于多个独立的topic中:

  1. # TOPICS mission offboard_mission onboard_mission

【按】这里这一步将产生三个topic ID- mission、 offboard_mission 以及 onboard_mission (第一个ID务必与.msg文件名相同)

然后在代码中, 通过topic ID:ORB_ID(offboard_mission)来使用这个topic.

发布话题

在系统的任何地方都可以发布(publish)一个话题, 包括在中断上下文中(被hrt_call接口调用的函数). 但是, 公告(advertise)一个话题仅限于在中断上下文之外. 一个话题必须同它随后发布的同一进程中公告。一个话题必须在它随后发布的相同进程中进行公告。

列出话题并进行监听 {#listing-topics-and-listening-in}

Note 监听器(listener)命令仅在Pixracer(FMUv4)以及Linux/OS X上可用。

要列出所有话题, 先列出文件句柄:

  1. ls /obj

要列出一个话题中的5个消息, 执行以下监听命令:

  1. listener sensor_accel 5

得到的输出就是关于该话题的n次内容:

  1. TOPIC: sensor_accel #3
  2. timestamp: 84978861
  3. integral_dt: 4044
  4. error_count: 0
  5. x: -1
  6. y: 2
  7. z: 100
  8. x_integral: -0
  9. y_integral: 0
  10. z_integral: 0
  11. temperature: 46
  12. range_m_s2: 78
  13. scaling: 0
  14. TOPIC: sensor_accel #4
  15. timestamp: 85010833
  16. integral_dt: 3980
  17. error_count: 0
  18. x: -1
  19. y: 2
  20. z: 100
  21. x_integral: -0
  22. y_integral: 0
  23. z_integral: 0
  24. temperature: 46
  25. range_m_s2: 78
  26. scaling: 0

提示 在基于NuttX的系统(Pixhawk, Pixracer等), listener命令可从地面站QGroundControl MAVLink控制台调用,来监听传感器数值和其他话题。 这是一个强大的调试工具,因为QGC通过无线链路连接时也可以使用它(例如,当无人机在飞行过程中)。更多信息可以看Sensor/Topic Debugging.

uorb up 命令

uorb top 命令可以实时显示每个话题的发布频率:

  1. update: 1s, num topics: 77
  2. TOPIC NAME INST #SUB #MSG #LOST #QSIZE
  3. actuator_armed 0 6 4 0 1
  4. actuator_controls_0 0 7 242 1044 1
  5. battery_status 0 6 500 2694 1
  6. commander_state 0 1 98 89 1
  7. control_state 0 4 242 433 1
  8. ekf2_innovations 0 1 242 223 1
  9. ekf2_timestamps 0 1 242 23 1
  10. estimator_status 0 3 242 488 1
  11. mc_att_ctrl_status 0 0 242 0 1
  12. sensor_accel 0 1 242 0 1
  13. sensor_accel 1 1 249 43 1
  14. sensor_baro 0 1 42 0 1
  15. sensor_combined 0 6 242 636 1

每列分别是:话题名,多实例索引,订阅者数,发布频率(Hz),丢失消息数(所有订阅者合并显示),队列大小。

多实例(Multi-instance)

uORB提供一种通过 orb_advertise_multi 发布同一话题的多个实例的机制。它将向发布者(publisher)返回一个实例索引。一个订阅者(subscriber)必须用 orb_subscribe_multi (orb_subscribe ,订阅第一个实例)来选择订阅哪个实例。对于一个具有多个相同类型传感器的系统,这种多实例机制非常有用。

对于同一个话题,确保不要将 orb_advertise_multiorb_advertise 混淆。

完整的API文档可见src/modules/uORB/uORBManager.hpp.

故障排除和常见问题

以下列出一些常见的问题和几个极端情况:

  • The topic is not published: make sure the ORB_ID()‘s of each call match. It
    is also important that orb_subscribe and orb_unsubscribe are called from
    the same task
    as orb_publish. This applies to px4_task_spawn_cmd(), but
    also when using work queues (work_queue()).
  • Make sure to clean up: use orb_unsubscribe and orb_unadvertise.
  • A successful orb_check() or px4_poll() call requires an orb_copy(),
    otherwise the next poll will return immediately.
  • It is perfectly ok to call orb_subscribe before anyone advertised the topic.
  • orb_check() and px4_poll() will only return true for publications that are
    done after orb_subscribe(). This is important for topics that are not
    published regularly. If a subscriber needs the previous data, it should just
    do an unconditional orb_copy() right after orb_subscribe() (Note that
    orb_copy() will fail if there is no advertiser yet).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文