旋翼无人机飞控的软件设计

1 飞控软件的基本模块

无人机能够飞行主要是依靠传感器系统获取位姿信息并反馈到微处理器进行控制系统的运算。所以飞控软件设计主要负责搭建合理软件流程，使各功能模块协调有效的工作。

一个飞控系统的基本工作主要有：

1、CPU接收遥控器的操作指令和传感器信 ；

2、传感器的数据处理和数据融合算法运算，得到位置、姿态信息；

3、根据控制指令完成相应的控制器（姿态、位置）计算，得出控制量并输出到电机驱动；

2 软件设计方法的讨论

刚接触飞控的时候，实验室在设计之初，为了方便快捷，软件系统的编写采用前后台操作的方式。这个方式的应用程序是在放在mian主函数里面无限循环，调用相应的处理子函数。这称为后台程序。而前台程序指的就是中断程序处理异步触发事件的程序。故前台程序称为中断级程序，而后台程序称为任务级程序。因此有些固定周期执行的任务都要靠中断服务程序来完成，以保证时间的精确性。但是在中断处理程序中只标记事件的发生，不做任何处理，转而由后台系统调度处理，这是为了避免在中断程序执行时间过长影响后续和其他中断事件。

这种设计方法的优点：

1、实现简单，特别是对于笔者这样的编程渣，照着stm32的库函数写代码，也可简单实现；

2、类似单片机的编程，没有OS，因此对CPU的性能要求不算高，不太关注ROM/RAM；

3、如果设计得当，相较于带OS的飞控，系统运行更加稳定，听说很多工业级的飞控是不带OS的；

缺点：

由于是用在飞行控制系统中，对整个系统的实时性有着很高的要求，如果逻辑和时序出现偏差，将出现无法估计的严重后果。而在初始开发过程中，发现采用此前后台系统带来两大问题：

1、设计不当的话，比如某个周期的函数执行超时，后面所有的程序都会受到影响。如果飞控程序执行时间变得不够准确，不利于对飞行器的控制，严重时发生飞机失控的现象。

2、移植性和扩展性差，给整个程序后续改动和维护带来不便，由于各种任务都是相关的子函数，往往一个任务需要调用多个子函数。在程序改动或者维护的时候变得非常繁琐复杂。经常由于忽略某一细节而导致功能无法实现，最后导致程序的可读性降低，不利于他人做程序修改。

最近几年也接触了一些开源飞控，看了有关带OS的飞控设计。这种设计方法是在某一操作系统上进行二次开发，OS通过一个内核的调度来管理CPU，使得所有的模块也就是任务都能正常运行，达到相对意义的“并行”。同时采用基于优先级的可剥夺性调度算法来保证实时性。RTOS 将应用层软件分成多个任务，简化了应用软件的设计，同时使得飞行控制的实时性得到保证。

个人偏好，其实比较喜欢裸机的方案。飞控其实说到底不是一个软件功能特别复杂的产品，所以从开发角度来讲，事先定义好相应的功能，没必要经常的扩展设计，裸机代码在平时的调试也有一定的优势。飞控在整个飞行平台的开发中，可以专注于负责飞行部分，可与其他设备进行通信，接收飞行指令即可。

3 完整的飞控系统组成模块

当设计一个商业飞控的软件时，就不仅仅是让飞机飞起来那么简单了，也就是说软件模块除了基本要素外，还需有其他扩展，如下图所示。

这里补充一下，

PX4飞控从软件架构上可以分为四层。在每一层里，各个驱动程序或上层的控制/估计算法都是一个独立模块，能够在运行期间互相通信。这种模块化的设计不仅有助于支持更多机型(因为不存在特定机型的主循环)，同时使得代码具有高度的可移植性。

应用层：该层是整个飞控系统运行的核心。飞控日常飞行所用到的模块基本上都在这层，包括姿态控制，状态估计，导航模块等等来完成多旋翼和固定翼完全自主的航点飞行。应用层可以使用其他的控制软件，如APM:Plane、APM:Copter，但必须运行于中间层之上。
中间层： 通讯的中间层运行于操作系统之上，提供设备驱动和一个微对象请求代理（micro object request broker ，uORB)用于飞控上运行的单个任务之间的异步通信。
NuttX操作系统层：提供给用户操作环境，进行底层的任务调度。
底层驱动层： 提供系统运行所需要的硬件驱动，如一些传感器、执行器等。

综上，飞控的裸机方案设计，常用的是分时调度机制。将整个系统时间分成若干时间片，用ID进行标识（通常用频率标志），每个时间片内执行相应的功能模块。这就需要事先合理的分配各个软件任务，保证在相应的时间片内不能超时。

有关飞行模式与状态机的设计，有个视频讲解：

https://www.bilibili.com/video/av45087166/