px4_simple_app(PX4-Autopilot/src/exampes/px4_simple_app)，这个程序是用c语言调用orb API和poll机制订阅和发布通讯数据，但是这个例子并不是既有接收又有发送的完整例子。例子中订阅了主题vehicle_acceleration，但是程序中没有发布(publish)这个主题数据的程序。反过来，这个程序advertise/publish主题vehicle_attitude，但是没有subscribe/copy这个主题的程序。所以，这个例子是不完整的。
这个例子不好做，因为如果从自己建立主题开始可能其过程过于复杂了。介绍建立主题本身就是一个过程，因为这里面有代码自动生成的软件。
传统的基于client和server通讯方法是client向server请求发送数据，server接收请求，然后把请求的数据发送给client。这个没有问题，但是，反过来做双向通讯，就需要两边都有client和server，这就增加了程序的复杂性了。确实，orb机制就是想解决任意两个程序模块之间的双向通讯。
有了orb机制，你并不需要自己做client/server。orb帮助你做了，当然也是用了client/server的办法，只是隐藏在了底层。
在orb机制中，被传输数据的数据结构在发送端和接收端都是已知的，或者说，数据结构在两边是共享的。比如：要传输的是一个整形数或者字符串，或者一个复杂的数据结构，数据可以是任意的，但结构是确定的。一个数据结构是一个对数据实体的描述，它有自己的名字。比如：这里为了便于理解，我们把例子中的vehicle_acceleration（数据本身有点复杂）的主题名字改成position。对于数据实体为position的数据，我们用数据结构描述如下：
struct position{ int x，int y，int z};
position描述了一个飞行器在三维空间中的坐标。
一个程序A请求另一个叫orb的程序将position数据发送给A，请求发送数据的程序A只需要把这个数据结构的名字发送给程序orb，然后等待（px4_poll）数据更新通知事件发生（POLLIN）。
orb程序在接到A的请求后知道了请求发送的数据的名字是position。orb不是直接将position这个名字对应的数据发送给A，而是注册position这个名字和请求程序A的名字，这个注册记载了A程序想得到position数据。然而，真正产生position数据的程序不是orb这个程序，而是程序C。程序C定期从传感器获取当前的position数据并向数据交换存储区发送数据，当然在此之前，也要注册一下postition数据的名字以及发送程序C的名字，这个注册与ORB对A的请求注册是一个地方，不一样的是，possition名字后还有个发送程序的名字。这样，这个注册表除了position名字，还有请求者的名字（多个，可以想象成一个链表）和发送者的名字（多个，可以想象成一个链表）。
一旦position数据更新，由于orb可以从注册表中知道“A想拿到position数据”，所以，可以通知（触发POLLIN事件）程序A取走数据。另外，更新position的程序会在注册表中标识它更新了当前数据，所以，orb也可以让A程序知道当前的position数据是哪个程序发送的，可供A选择。
orb_advertise_multi中的instance是输出参数，这个instance由orb程序产生并返回给应用程序，应用程序可以用这个instance向orb程序说明我要哪个主题数据。
想象一个两个程序都在更新position数据的例子:
北斗模块
pub_handle = orb_advertise_multi(ORB_ID(position), &beidou_position, &instance_beidou, 1));
---将北斗传感器数据存到beidou_speed变量中，然后
publish（ ORB_ID(position), pub_handle, &beidou_position);
负责发送北斗数据的程序执行上面语句，则instance_beidou就存储了标识北斗数据发送者的信息，
gps模块
pub_handle = orb_advertise_multi(ORB_ID(position), &gps_position, &instance_gps，1));
---将gps传感器数据存到gps_position变量中，然后
publish（ ORB_ID(position), pub_handle, &beidou_position);
负责发送GPS数据的程序执行上述语句，则instance_gps就存储了标识GPS数据发送者的信息;
A程序如果想得到北斗数据，则
sub_fd = orb_subscribe_multi(ORB_ID(position), instance_beidou);
copy(ORB_ID(position), sub_fd, &beidou_position);
想得到GPS数据，则
sub = orb_subscribe_multi(ORB_ID(position), instance_gps);
copy(ORB_ID(speed), sub_fd, &gps_position);
如果position这个数据只有一个发送源，就不必区分了; 所谓的instance_beidou和instance_gps里面存的是什么，其实不必关心，就是一整数，是由orb程序生成的。
每个主题都有对应的instance，如果只有一个数据发送源，instance就是0。在程序语言中我们把instance叫实例，第一次调用orb_subscribe_multi给它编号为1,第二次调用orb_subscribe_multi, 编号为2，同一个程序被调用了两次，每次执行的虽然是同一个程序，但是需要当两个不同程序来看待，这样就需要区分，通常用数字区分，这就是instance里面存储内容的意义。
从上面所述可以看出几点，首先，交换数据的存储区是两个模块A和C之间共享的，当前放在存储区的position数据是谁要的，是谁发的，在注册表中都有标识，ORB负责告诉你。position数据长什么样？因为在注册表中注册了position的名字，所以，数据结构两边都是知道的。
另外，A不需要知道C的存在，因为可能存在多个C发送position数据（确实存在这样一种情况，虽然数据来源不一样，但是数据结构的名字是一样的，比如：为了获得可靠数据，安装了多种传感器，传感器数据是一样的，其数据结构当然是一样的，没有必要起不同的名字）至于是哪种传感器程序发送的position数据，由orb程序在C程序以及其他程序在注册position数据时加以区分。
其次，C程序不需要关心取position数据的是谁，因为可能存在多个程序在请求发送position数据，至于是程序A1还是程序A2请求发送则由orb程序在A程序注册请求position的时候加以区分。
最后可以知道，ORB只是一个代理，并不真正产生position数据。
所有PX4能传输的数据的数据结构在PX4-Autopilot/msg中都定义好了，PX4通过代码自动生成了可以用在C/C++中的数据结构定义，它们被保存在目录PX4-Autopilot/build/uORB/topics中。
px4_poll机制是这样的，poll这个动作是一个让你的线程停下来的操作，停下来的目的是与orb机制打交道的还有另外一个程序C，它将在适当的时候通知你的线程，你可以继续运行了，因为程序C已经改变了你程序中变量的值，你可以检查这个值变成什么样了，你自己做判断。通常这个值叫POLLIN，表明你想要的数据准备好了，可以把它取走了。你可以把你的程序叫client，把这个C线程叫server。在这个例子中，这个server是一个PX4中运行的模块，在: PX4-Autopilot/src/module/sensors/vehicle_acceration目录中。事实上，在PX4中几乎所有module（模块）都可以看作是server。
综上所述，orb机制确实在多个模块之间实现了多个client和多个server，在orb机制下，client和server两边都知道要交换的数据的数据结构。
题外话，这自然让我想到，DDS这种机制与uorb机制本质是一样的，由于两边的数据结构都知道，因此，写和读符合这些数据结构的数据的程序也可以自动生成了，uorb没有做到这一点，然而这正是DDS的核心技术之一。ROS2已经把DDS作为offboard计算机与PX4 uORB通讯的机制，实现了两对orb机制进行通讯，进一步，ROS团队还准备把完整的DDS放进PX4，不知道何时能实现。如果真实现了，MAVSDK怎么办？mavlink团队和ROS团队竞争激烈，但是作为用户，我们只能有一种选择吧。
应用程序如果用到一个主题，比如px4的官方用例px4_simple_app.c中，一般都需要include 2个文件：
#include <uORB/uORB.h>
#include <uORB/topics/vehicle_acceleration.h>
uORB.h是在platforms/common/uORB目录中，是编译前就存在的，是uORB系统通用的一些机制的定义。vehicle_acceleration.h是在/build/uORB/topics目录中。vehicle_acceleration这个主题对应的定义是在编译过程中自动生成的。
在vehicle_acceleration.h文件中：
ORB_DECLARE(vehicle_acceleration);
ORB_DECLARE()是一个宏，它在uORB.h中定义，这句话的意思是定义一个vehicle_acceleration的orb对象。我们看这个宏的定义：
//
#if defined(__cplusplus)
# define ORB_DECLARE(_name) extern "C" const struct orb_metadata __orb_##_name __EXPORT
#else
# define ORB_DECLARE(_name) extern const struct orb_metadata __orb_##_name __EXPORT
#endif
///
在代入vehicle_acceleration这个名字后展开得到：
extern const struct orb_metadata __orb_vehicle_acceleration __EXPORT
这就是vehicle_acceleration这个orb对象的名字，叫__orb_vehicle_acceleration。
接收PX4的消息，应用程序需要订阅（subscribe）主题，订阅的目的是告诉PX4的发送方，我要你传输符合这个主题的数据，我等待接收。执行下面的API就可以订阅一个主题：
int sensor_sub_fd = orb_subscribe(ORB_ID(vehicle_acceleration));
orb_subscribe是PX4的uORB系统提供的一个API，其他API都在uORB.h中定义了，所以，也需要include <uORB.h>，API在这里都做了声明，详细的API定义可以参看：uORBManager.hpp。
在subscribe函数中，第一个参数是函数ORB_ID（），这个函数可以从主题名字获得主题id，在编译时，已经为每个主题名字编了一个序号，返回的就是这个序号，见build/px4_sitl_default/uORB/topics/uORBTopics.h。
ORB_ID()也是一个宏，它在uORB.h中定义，我们来看ORB_ID这个宏定义：
//
#define ORB_ID(_name) &__orb_##_name
///
在代入vehicle_acceleration这个名字后展开得到：
&__orb_vehicle_acceleration
这样
int sensor_sub_fd = orb_subscribe(ORB_ID(vehicle_acceleration));
就变成了：
int sensor_sub_fd = orb_subscribe(&__orb_vehicle_acceleration));
这样，orb_subscribe函数传入的就是一个指向__orb_vehicle_acceleration对象的指针。
__orb_vehicle_acceleration这个对象长什么样？其实在vehicle_acceleration.cpp中已经有定义,也是在编译时自动生成的，存放在build/px4_sitl_default/msg/topics_sources中。我们来看这个文件中的内容：
#include <uORB/topics/vehicle_acceleration.h>
#include <uORB/topics/uORBTopics.hpp>
// 上述略去其他.h文件
constexpr char __orb_vehicle_acceleration_fields[] = "uint64_t timestamp;uint64_t timestamp_sample;float[3] xyz;uint8_t[4] _padding0;";
ORB_DEFINE(vehicle_acceleration, struct vehicle_acceleration_s, 28, __orb_vehicle_acceleration_fields, static_cast<uint8_t>(ORB_ID::vehicle_acceleration));
其中ORB_DEFINE是一个宏，在uORB.h中定义，我们来看这个宏：
ORB_DEFINE()宏定义：
//
#define ORB_DEFINE(_name, _struct, _size_no_padding, _fields, _orb_id_enum) \
const struct orb_metadata __orb_##_name = {
#_name,
sizeof(_struct),
_size_no_padding,
_fields,
_orb_id_enum
}; struct hack
//
ORB_DEFINE(vehicle_acceleration, struct vehicle_acceleration_s, 28, __orb_vehicle_acceleration_fields, static_cast<uint8_t>(ORB_ID::vehicle_acceleration)) 宏替换展开后：
//
const struct orb_metadata __orb_vehicle_acceleration = {
“vehicle_acceleration”,
sizeof(vehicle_acceleration_s),
28,
"uint64_t timestamp;uint64_t timestamp_sample;float[3] xyz;uint8_t[4] _padding0;",
150
}; struct hack
//
这里vehicle_acceleration_s在vehicle_acceleration.h已经定义：
struct vehicle_acceleration_s {
uint64_t timestamp;
uint64_t timestamp_sample;
float xyz[3];
uint8_t _padding0[4]; // required for logger
}
可以简单计算，这个结构的尺寸是28个字节。sizeof(struct vehicle_acceleration_s)算出来也是28，150是在uORB系统为vehecle_acceleration这种对象的一个编号，在uORBTopics.h中已经有定义。
orb_metadata类型也已经在uORB.h中定义如下：
struct orb_metadata {
const char *o_name; /**< unique object name */
const uint16_t o_size; /**< object size */
const uint16_t o_size_no_padding;
/**< object size w/o padding at the end (for logger) */
const char *o_fields;
/**< semicolon separated list of fields (with type) */
uint8_t o_id; /**< ORB_ID enum */
};
这样就知道，__orb_vehicle_acceleration是一个类型为orb_metadata的对象,在uORB机制中，这个对象叫object request broker，对象请求代理。orb_subscribe要的是指向这个对象的指针，这个对象是个常量，这个常量是orb_metadata类的一个实例（instance）。有了这个对象请求代理，uORB机制就可以用它来读写vehicle_acceleration这个主题的数据，因为orb机制已经知道应用程序想要的数据的尺寸。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
