作业三

Xenomai实时操作系统简介

Xenomai是一个在Linux平台上建立起的通用实时框架的自由软件项目。主要的项目目标是帮助从专有的实时系统迁移到系统的工业应用。早期是一种在采用双内核机制时对不能用于强实时应用的Linux内核的扩展，其优先级高于Linux内核。后来逐渐发展成一个成熟的实时Linux架构，可独自成为一个单/本地内核系统。Xenomai实时内核为开发强实时应用提供了丰富的功能，主要包括实时线程调度与管理、用户空间实时任务支持、线程同步服务、时钟服务、中断服务、动态内存申请和实时对象注册服务等。主要用于工业自动化行业。

Xenomai项目起始于2001年。从2003年夏天起，Xenomai和RTAI有了两年时间的合作，期间开发了广为人知的RTAI/fusion项目分支。到2005年，Xenomai项目又重新独立出来。而从2.0.0版本开始，Xenomai在硬件平台的移植就一直是基于Adeos构架来实现的。

在基于Adeos的系统中，分为多个域。每个域中独立运行一个操作系统（或者是实现一定功能的程序模块），每个域可以有独立的地址空间和类似于进程、虚拟内存等的软件抽象层。在各个域下层有一个Adeos通过虚拟中断等方法来调度上面的各个域。在基于Adeos的系统中，存在着A、B、C、D四种类型的交互。A类交互是各个域直接操作硬件设备，包括访问内存等；B类交互指当Adeos接收到硬件中断后，会根据中断来对相应的域进行中断服务；C类交互指当前域内的操作系统主动向Adeos请求某些服务；D类交互是指Adeos接收硬件产生的中断和异常，同时也可以直接控制硬件。

Xenomai除了在内核层利用Adeos实现了硬实时外，它在用户空间也有很好的实时性。在S3C2410平台上，为了实现用户层的实时，Xenomai实现了一个硬件计数器--Decrementer.这个硬件计数器可以在用户空问里很好地模拟TSC（Time Stamp Counter,时间戳计数器）。

同时，Xenomai在Linux内核中加入了一个全新的数据结构__ipipe_tscinfo,可以通过此数据结构变量存放用户层需要的数据。在用户层，应用程序通过系统调用可以迅速得到struct_ipipe_tscinfo结构体中的数据。而且为了避免受到缓存的影响，Xenomai将此结构体变量存放在Linux的向量页中。内核通过函数_ipipe_mach_get_tscinfo来填充struct_ipipe_tscinfo结构体变量中的各项内容。

除了提供Linux硬实时，Xenomai的另一个目的是使基于Linux的实时操作系统能提供与传统的工业级实时操作系统（包括VxWorks、pSOS+、VRTX或者uITRON）功能相同的API.这样，可以让这些操作系统下的应用程序能够很容易地移植到GNU/Linux环境中，同时保持很好的实时性。

Xenomai的核心技术表现为使用一个实时微内核（real-time nucleus）来构建这些实时API,也称作"skin".在实时核复用的基础上，一个skin可以很好地模拟一种实时操作系统的API.

编制实时程序时，在很多实时操作系统上只能在内核层实现；而编制实时内核模块时，会受到内核的限制，比如有些实时内核不支持浮点运算，模块出错时容易使整个系统挂起，而且内核模块的调试比较困难。Xenomai能够支持较好的用户层实时，这为编制实时性要求不是非常高的实时程序提供了一个有效途径。

团队项目

实现一个两轴机械手的运动控制仿真，主要功能包括：

用户接口任务：负责接收来自用户的请求，并发送运动指令给轨迹插补任务。

轨迹插补任务：接收运动指令，实时计算各轴的位置和速度设定值。

物理引擎接口：基于ODE开源物理引擎，创建一个两轴机械手及环境的物理模型，用轨迹插补任务输出的各轴位置和速度设定值控制模型的运动，并把实时状态反馈给轨迹插补任务。

图形化用户接口：可基于qt把上述功能集成到一个GUI界面。

个人而言，对图形化用户接口部分最感兴趣。以前没有接触过实时软件，没有这方面的基础，所有编程的基础是用opencv做图像处理，感觉在这里用不上。QT是自己一直想学但又没有付诸实践的东西，借这个课堂的平台，好好锻炼一波吧。

团队协作开发方面，因为加入了机器人团队，对队友之间的协作、交流感触挺多。一个团队里大家都是分组工作，各自承担着不同的任务，比如机械组、嵌入式组、视觉组、电路组。而最后作品的完成是建立在每个组都保质保量地完成任务的基础上的，就好像“木桶定律”，所以首先，在团队工作中一定要有责任感，不能拖大家的后腿，不能坑队友。

其次，交流和沟通是团队协作的基础，因此在团队工作中一般都会规定共同工作时间，有一起工作的场所，方便随时交流。然后，如何交流总是比较困难的事情，因为首先大家都有自己的事情要做，很忙；其次，不同组之间对别人的领域不熟悉，很多事情解释起来很费力。我想说，再忙也要沟通，不然做出的东西不能相互配合忙也是白忙。比如机械组在做底盘时要根据电路组的布线来设计结构，还要预留出控制组放置minPC、摄像头等等的空间，制作合理的夹具，否则就不是合格的作品；可以对别的领域不熟悉，但是要清楚别人需要自己的东西具有什么功能，或者说让别人清楚自己需要什么功能，具体实现就是各自的事了。比如嵌入式组需要视觉组做重定位，告诉视觉组能传回来的是机器人位姿，需要的是重定位得到的偏移量，视觉组就可以自己去实现了。

最后，时间的规划很重要，因为很多时候，一项工作是建立在另一项完成的基础上的，比如控制组的工作得建立在机械和电路都搭好的基础上，那么时间规划时就要让机械和电路先完成工作，给控制预留调试时间。当然调试中会发现问题，机械电路又需要改动，最后肯定是边改边调，边调边改，队友间配合尤其重要。