最近在进行固定翼的仿真和控制学习，从动力学建模到路径跟随，基于Pixhawk飞控的半实物仿真整个过程。之前也学习过多旋翼无人机的整个开发过程，现在总结一下。在整个无人机的开发过程中，主要使用了Pixhawk和Rflysim平台，Rflysim平台是一个用于无人系统开发的仿真平台。当然，个人对该领域理解深度也有限，部分说法也引用自Mathworks的大牛工程师，如有问题欢迎讨论指出。

---

一、什么是基于模型设计

1.宽泛的概念

基于模型设计（MBD）可以说是工程设计、研究开发的一种理念，广泛应用于很多领域，可以说总结出算法的模型并围绕其进行设计的过程，都可以叫做基于模型的设计。在Mathworks基于模型设计的主页（Mathworks-MBD）中也可以看到众多的应用领域，针对于无人机开发是基于模型的控制器设计和测试的过程。在我的理解中，基于模型的开发很重要的一点是将模型和代码直接联系在了一起，即代码生成，并且在后续过程中大大加快了开发和测试的进度。对于基于模型设计的应用，目前个人感觉与传统开发过程最明显的不同就是代码自动生成部分。

2.In-the-Loop测试流程

基于模型设计中的In-the-Loop测试实际上就是有序进行的、一系列的仿真测试，它与正是这一系列测试加快了开发进度，节省了时间和成本。
（1）MIL，模型在环测试。在Simulink中，建立控制器模型和被控对象模型，并将控制器和被控对象连接起来并形成闭环，让控制器去控制被控对象。这个过程是在理想或较为理想的条件下，测试算法，实际上，这一部分往往在其他传统开发过程中也存在。主要针对于被控对象物理模型比较复杂，但是可以理清。
（2）SIL，软件在环测试。应该说是从模型在环测试引申过来的，区别只是把控制器的模型换成了由控制器模型生成的C代码编译成的S-function，SIL的目的是为了验证生成的代码和模型在功能上是否一致，或者说验证生成的代码和模型在功能上是否等效。
（3）PIL，处理器在环测试。一是为了等效性验证，二是为了测量模型生成的代码在目标处理器上的运行时间。如果明确知道代码在目标处理器上的运行是绰绰有余的，那这一部分可以略去。
（4）HIL，硬件在环测试。测试的目的是为了验证控制器。在HIL测试中，我们将较为真实的被控对象的物理模型（包括被控对象本身、环境、传感器、其他扰动等）编译成C代码并生成一个可执行文件，放到一个工控机（或者一个可以运行该物理模型，并可以与硬件控制器交互的平台）上，这样一个机器（平台）相当于数字化的替代了真实的物理环境。这样将硬件控制器和机器（平台）连接，形成闭环，进行测试。

二、基于模型设计的优势

基于模型设计的优势有很多，其主要优势来自于强大的Simulink以及其代码生成的功能，由于个人只在基于模型设计中涉足一个很小的部分，对于其优势理解有限，这里部分内容援引自董淑成老师。

1.图形化设计

图形化的东西本就比代码本身更容易理解，对于算法的继承性也更好，在软件设计开发的过程中也会去画流程图和状态机。况且个人感觉大多数人的代码往往有个人的风格，如果把源码给到别人去读，去扩充或者修改，那么要消耗大量的时间在理解代码结构。而Simulink的图形化设计，比较规范，也非常容易修改。

2.代码生成

如果一个算法工程量比较大，那么直接下手写代码进行调试，一定是比仿真调试更加费时费力的，在我个人以前的学习开发经历中，对于一种新的控制方案往往要在仿真中进行初步验证，验证其合理性，这样在没有实物被控对象的情况下，就可以把算法先走通，相信很多人也是这么搞。然而在实物开发阶段，代码往往又要从零开始写起，实际上这是一个重复的过程，如果将仿真中的代码直接生成，烧录到硬件中，那整个开发过程就大大缩减了。
有人可能会纠结，通过代码生成得到的代码，效率如何？是不是肯定不如自己写的啊，实际上Mathworks在代码生成部分下了很大的功夫，生成的代码以及比很多人写的代码更加高效且规范。

3.早期验证

代码生成最大的好处是，算法的早期验证，之前NASA有研究表明，开发初期引入的bug，如果到了晚期才发现出来，那么修复这一的bug，会产生非常大的费用。所以，我们期望能够尽早的发现开发过程中引入的bug。
如何尽早的发现设计上的错误？传统的开发模式里，我们使用review的方式去发现错误，在质量体系ISO9001里面有定义，任何一份设计，都必须要评审。评审的目的，也就是为了发现这个阶段的错误，以防错误被带到后续的开发过程中。而评审的效率，却是非常低下的。评审作为一种非常传统的验证方式，并不能及时发现设计过程中引入的各种错误。而仿真，从效率上讲，要远高于评审，仿真更容易发现设计中的问题。
仿真是可以运行的，如果我们设定一些输入，运行模型之后，我们会得到相应的输出，我们很容易观测到此时的输出是否是我们期望的输出。另外还有好处，仿真的结果是确定的，给定输入，就会得到确定的输出，当然，期望输出也是确定的。而不像评审，同样的文字，对于不同人，可能理解成不同的含义。

4.文档自动化

代码生成和早期验证之外，基于模型的设计，还可以给我们带来其他好处，比如文档自动化。
1.文档很重要，不能没有，至少从质量体系上要求我们必须有文档
2.工程师都不愿意写文档，是啊，如果愿意写文档的话，在开发过程中自然会把各类文档写起来的。
好，工程师不愿意写，开发过程中又不能少，如果计算机可以帮我们写，岂不是很美好的事情。基于模型的设计，可以帮助我们实现文档自动化，至少有相当大的一部分文档可以让计算机替我们写。

三、基于模型设计如何应用于无人机开发

1.再说说硬件在环仿真（HIL）

硬件在环仿真（HIL）作为基于模型设计仿真阶段的最后一个测试，其实已经非常接近于实物的测试，对于我们硬件控制器实际上接收的是数字化的一些数据，这样我们把整个实物飞行的物理模型以及环境等都集成为一个虚拟的环境，接收控制器信号，并将状态反馈到控制器，形成闭环，这样仿真就可以安全而高效。
正像我们所说的，HIL经常被用于以下几种情形：
a）被控对象非常昂贵，如果控制器不成熟会导致被控对象的损害；
b）被控对象失效会危及人身安全；
c）开发过程中，先开发出了控制器，而被控对象还没有开发出来。
在航空航天领域、车辆以及自动驾驶领域，基于模型设计方法以及普遍应用，现在这种方法也逐渐延伸到无人机开发领域，实际上比较重要的一环就是硬件在环测试。像PX4、树莓派等都与Mathworks公司联合开发了基于模型的硬件在环测试仿真方案，代码生成方案，这样在PX4、树莓派这样的成熟完整的硬件上进行基于模型开发就变成了相对容易的事情。

2.在Rflysim平台上加入无人机动态模型（被控对象建模）

Rflysim平台集成了众多基于模型设计的功能，在硬件仿真过程中，通过这个平台就可以实现在自己电脑上，模拟无人机的动态模型并与Pixhawk形成闭环，并通过UE4进行实时显示。
（1）首先要在Simulink中对无人机进行动态建模，包括无人机的6dof运动方程、受力分析、执行机构、环境、传感器等，下图以固定翼无人机模型为例，大致包括这么几个部分。这一部分首先要再模型在环中验证，模型没有问题之后进入下一步。

（2）模型没有问题之后，就将模型中除了传感器模型之外的部分移植到\RflySimAPIs\OtherVehicleTypes的demo中，去掉传感器部分是因为在demo中已经建立了相关传感器的模型，也包括Mavlink通信部分等，注意：模型中位置速度等初始化参数要用demo中的初始化参数，也就是6dof模块中的参数要修改一下。
（3）以上完成之后就可以进行代码生成，得到cpp文件，后通过平台中提供的GenerateModelDLLFile.p将得到的相关文件转为DLL文件，放到\CopterSim\external\model中，即可在coptersim中调用。另外，ue4视景中的模型也可以导入自己的三维模型。

3.Simulink/PSP工具箱与代码生成（控制方案与算法建模）

（1）控制器搭建与模型在环测试：控制方案和控制算法首先要在Simulink中模型在环测试通过，最好是模型在环测试的控制频率也和后续的Pixhawk硬件在环的频率一致。
（2）PSP工具箱中控制信号、传感器数据获取和uORB：将之前仿真中的输入信号、传感器反馈信号等都替换为PSP工具箱中提供的模块。

（3）代码生成，并烧录到Pixhawk中，注意：首先要配置RflySim中的“屏蔽官方固件输出”。