ardupilot固件移植_ardupilot 就不支持bmi088

---

前言

ardupilot和PX4作为开源飞控的两大巨头，他们的完整的生态，科学的架构设计，完整的功能，和强大的二次开发能力等吸引了很多玩家和科研人员的眼球。有很多有趣的研究和设计都在他们的基础上完成。当然优秀的固件离不开实际的硬件平台，虽然pixhawk的硬件设计也非常优秀，又或者一些专业厂商如CUAV，holybro,Hex,QIOTEK，Matek等基于pixhawk硬件标准设计的硬件也很棒且具有官方固件支持。但是善于折腾的玩家向来不愿意轻易满足，基于开源的标准和原理图，我们其实可以自己设计属于自己的板子来满足自己一些奇奇怪怪的要求。（当然这付出的精力和金钱觉得比直接买高的多的多！）基于两大固件的优秀移植设计，只要你选用的器件目前官方都支持，那么其实移植的工作量也还可以接受。想想或者自己专属的硬件和固件还是一件很酷的事情！好了，言归正传，开始介绍ardupilot的移植（PX4的还没研究，应该类似）

---

一、编写硬件描述文件

首先把自己的飞控硬件的各引脚的定义以及选取的晶振频率等做成简明的table（当然只要其实画板子的时候这些话不多就弄好了）
然后我们进入ardupilot\libraries\AP_HAL_ChibiOS\hwdef文件。如下图所示，这里存放了一大堆的硬件描述文件。市面上我们能买到的飞控的硬件描述文件都在这里了。所以如果我说就直接照着葫芦画瓢弄一个自己的硬件描述文件这部分就可以完事儿了。当然，这显然太坑了。也许会坑到以后我自己忘了回来翻看一下都忍不住骂出声，所以还是要大概介绍一下。

目前市面上的飞控基本都是FMUV5标准的，所以我们就看看V5系列的飞控，其他就不看了。那么打开V5系列的亲儿子pixhawk4。

显然最后两个文件呢，不是必要的。道理很简单，不可能用图片和md文本来指导生成我们的最终文件嘛。这两个打开文件打开就是描述飞控硬件定义的可读信息，我们也可以学着弄两个。

那么接下来是重点了：

• defaults.parm:
  这个文件定义了针对该电路板的默认参数设置。比如不使用串口流控制，电源电压检测的比例系数等。注意:只是硬件相关的默认设置参数，而不是飞控的飞行控制算法相关参数。所以该文件不是必须的，没有它，我们完全可以在地面站对相关硬件设置参数进行手动更改。

  举个栗子：
  
  上面两个参数是defaults.parm里常定义的两个参数。实际上，我们完全可以连上飞控在地面站设置。
  

• hwdef.dat:
  这个文件很厉害了，它非常重要。该文件定义了飞控程序对应的所有硬件描述，其中包含了STM32时钟配置、串口、SPI、IIC、CAN等接口配置。IMU芯片型号描述以及其安装方位描述，PWM以及其对应定时器配置等关键信息。这里我推荐大家打开ardupilot\libraries\AP_HAL_ChibiOS\hwdef\fmuv3\hwdef.dat去浏览它的注释，这里写的非常全面了。这里截出其部分，大家就能明白它是个好东西。当然了其实也不必一定要读，比如我们是基于某款开源硬件原理图，只是重做PCB设计的话，基本上把原来的hwdef.dat搬过来就完事儿了。

# hw definition file for processing by chibios_hwdef.py
# for FMUv3 hardware (ie. for Pixhawk1, Pixhawk2 cube, XUAV2.1 etc)

# This hwdef.dat file contains a lot of comments so it can act as a
# reference for developers adding new boards.

# The hwdef.dat file defines all the hardware peripherals and pins for
# a port of ArduPilot to a board using the ChibiOS HAL. You should be
# able to write the hwdef.dat file for a new board with just the
# schematic for the board.

# This file is processed by chibios_hwdef.py to create hwdef.h for
# this board. You may find it useful to run chibios_hwdef.py manually
# when building this file for a new board. The resulting hwdef.h file
# is formatted to make it quite readable. It is strongly suggested
# that you read the resulting hwdef.h file when porting to a new board
# to make sure it has resulted in what you want.

# You should read this file in conjunction with the schematic for your
# board, the datasheet for the MCU for your board and the python
# tables file that we have extracted from the datasheet for your
# MCU. The python tables file is particularly important, so if you
# haven't seen it before go and look at it now. For the STM32F427 it
# it called STM32F427xx.py and it is in the hwdef/script/ directory
# inside the HAL_ChibiOS directory. That file tells you what each pin
# can do (the alternate functions table) and what DMA channels can be
# used for each peripheral type. The alternative functions table is
# particularly useful when doing a new hwdef.dat file as you can work
# out peripheral numbers given a port/pin name.

# We need to start off by saying what main CPU is on the board. There
# are two CPU identifiers that you need to specify. The first is the
# ChibiOS MCU type. So far we only support STM32F4xx for all STM32F4
# board types. In the future we will add F7 and other MCU types
# The second string needs to match the name of a config file in the
# libraries/AP_HAL_ChibiOS/hwdef/script directory. In this case we are
# using a F427 MCU, so we select STM32F427xx to match the
# STM32F427xx.py file in the script directory. If you are supporting a
# board type that doesn't have a python hardware database file yet
# then you will need to create one. There are scripts in the scripts
# directory to help with that by parsing the STM32 datasheets to
# extract the required DMA and alternate function tables.

# MCU class and specific type
MCU STM32F4xx STM32F427xx

# We set a specific HAL_BOARD_SUBTYPE, allowing for custom config in
# drivers. For this to be used the subtype needs to be added to
# AP_HAL/AP_HAL_Boards.h as well.
define CONFIG_HAL_BOARD_SUBTYPE HAL_BOARD_SUBTYPE_CHIBIOS_FMUV3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

这里我再说明一下特别值得注意的一点：
就是这个compass和IMU的安装定义设置。因为在设计PCB时，也许IMU和compass的安装和飞控的定义坐标系是不一致的，那么我们就需要设置这个参数说明这些IC的坐标系和飞控坐标系的关系是如何的。否则姿态解算肯定就会有问题了，当然这也说明我们在设计硬件时咋放compass和IMU都行，只要在这里作好定义就可以了。

# up to 2 IMUs
IMU BMI088 SPI:BMI088_a SPI:BMI088_g ROTATION_ROLL_180
# second is icm20689
IMU Invensense SPI:icm20689 ROTATION_YAW_180

define HAL_DEFAULT_INS_FAST_SAMPLE 1

# probe external I2C compasses plus some internal IST8310
# we also probe some external IST8310 with a non-standard orientation
define HAL_PROBE_EXTERNAL_I2C_COMPASSES
COMPASS IST8310 I2C:ALL_EXTERNAL:0x0E true  ROTATION_ROLL_180_YAW_90
COMPASS IST8310 I2C:ALL_INTERNAL:0x0E false ROTATION_YAW_180
1
2
3
4
5
6
7
8
9
10
11
12

• hwdef-bl.dat:
  这个文件是定义了飞控bootloader程序对应的硬件描述。因为飞控的bootloader主要功能只是简单的进行硬件初始化，对于使用来说最直接的作用是通过bootloader来进行固件的刷写。所以它的功能是比飞控固件少很多的，因此该文件的内容也就明显少于“hwdef.dat”。其相关的定义和hwdef.dat是基本一致的，这里就不再赘诉。

二、编译并刷写BootLoader

// 第一步，清理之前的编译中间文件，一定要清理一下，能避免很多奇怪的问题
./waf distclean

// 第二步，设置编译目标为针对你的硬件的BootLoader
./waf configure --board YourBoard --bootloader
// 注意，这里的“YourBoard”就是上面步骤中你自己新建的文件夹的名字
// 比如本文学习的出处的“鹏心”飞控，那么就是“NFCYv5”
./waf configure --board NFCYv5 --bootloader

// 第三步，编译BootLoader
./waf bootloader
1
2
3
4
5
6
7
8
9
10
11

编译生成的BootLoader文件在“ardupilot\build\YourBoard\bin\”目录下。会有有.hex，.bin，.apj三种格式的文件。一般用STlink SWD模式烧录的话，我就选用.hex文件了。如何用STlink刷写单片机，我就不写了，这个是基本常识。给飞控烧写好bootloader后那么飞控就可以像平常一样用USB刷写飞控固件了。

三、编译并刷写飞控固件

/ 第一步，清理之前的编译中间文件，一定要清理一下，能避免很多奇怪的问题
./waf distclean

// 第二步，设置编译目标为针对你的硬件的飞控固件
./waf configure --board YourBoard

// 第三步，编译飞控固件（此处以编译多旋翼固件为例）
./waf copter
1
2
3
4
5
6
7
8

编译好后就可以像往常一样用地面站刷写到你自己的飞控里了。如果一些顺利的话，那么congratulations!你就已经完成了固件移植了！

---

总结

飞控固件的移植主要工作就在hwdef文件上，根据自己飞控硬件的定义，对照着已有的hwdef文件照葫芦画瓢即可。最后，本片文章主要是学习了怒飞垂云的课程后再加上自己的一点点探索思考所写的笔记。没看懂的话，欢迎去怒飞老师的课程学习，视频讲解相信效果更佳，买了绝对超值！课程地址 参考文章