无名小哥对无名飞控中的问题回答总结

小哥对无名飞控中的问题回答总结"/>

无名小哥对无名飞控中的问题回答总结

文章目录

• • • IIR二阶数字低通
    • 陀螺仪数据噪声
    • 传感器矫正
    • 姿态解算
    • 惯性导航
    • 控制
    • 滤波性能
    • 系统响应
    • 巴特沃斯滤波器的截止频率如何取
    • 累计漂移
    • 姿态估计精度误差大
    • 控制周期
    • 时间
    • 保证传感器数据不丢帧

IIR二阶数字低通

对于IIR而言，阶次越高，阻带衰减越快，但是数据相延为越大，所以一般用2～4阶即可，数字低通滤波器解决的是控制器所需的反馈信号，传感器输出的原始信号会参杂有不同频率的信号，单纯对于加速度计而言，会由机体、桨振动引入高频噪声，需要设计合适的截止频率，来把这部分噪声尽可能的剔除，把原始加计数据发送Matlab做FFT变换，分析在悬停油门附近频谱图，可以知道噪声的频率范围，通用来讲，把加计截止频率设置成30hz基本就可以。

陀螺仪数据噪声

一般的飞控在初始化设置的时候，开启了陀螺仪内部低通，从而使得输出的数据已经低通过了，通常是42hz，一般在开源控里面，就没有对陀螺仪再次进行低通，无名飞控里面，对陀螺仪内部不设置低通，只在飞控里面对原始数据进行低通处理，所以有看到对陀螺仪也进行了低通处理。

传感器矫正

加速度计低通2Hz采集用作加计六面矫正是为了避免手抖造成矫正误差。

姿态解算

主体传感器是陀螺仪，所以我们希望输入姿态解算的陀螺仪数据的实时性尽可能大，同时陀螺仪噪声要在合理范围内（静态能保证收敛、精度要满足要求），这就需要相对加计而言，截止频率要尽可能的大一点。姿态解算观测传感器：加计、磁力计为辅助传感器，实时性要求不高，只需要保证姿态收敛、动态精度等即可，我们不希望因为观测传感器的噪声，给姿态解算的精度带来负担，在姿态解算里面，对加速度计、磁力计的截止频率设的相对较低，这里就会涉及一个时间同步问题，在姿态解算里面，主体传感器陀螺仪与观测传感器加计、磁力计因为采样、低通等造成的时间不同步问题，需要做延时修正补偿，提高姿态解算的实时性。

惯性导航

主体传感器为加计，观测传感器为气压计、GPS、TOF、VIO等，同样对于加计我们希望数据在合理噪声范围内实时性要尽可能的高，所以这里用于做惯导的加计和用作姿态解算观测传感器的加计，截止频率前者要大一点，注意一点，惯性导航载体三轴加计到导航系运动加速度，需要有载体到导航系的旋转矩阵，因此旋转矩阵（姿态解算）的实时性直接影响惯导的实时性，做惯导的前提是拥有一套精度高、实时性好的姿态解算。同理，在惯导里面也有时间同步问题。

控制

对于加速度环来讲，相比位置、速度、姿态控制（加计作为观测传感器、惯导融合等），加速度计是直接作为反馈量，加速度计反馈信号的噪声会直接引入到控制器里面，造成控制器输出异常，引起油门输出失控炸鸡，所以在APM飞控里面，在加速度控制器里面，对偏差进行低通后，然后参与PID运算，这里对偏差低通，而不是只对微分低通，是因为输入与反馈同样存在噪声，而且这里APM截止频率用的是2Hz，这是一个相当恐怖低通，牺牲了数据的实时性，就是为了避免加计噪声造成失控，实际如果加过减震后，加速度计反馈用15Hz也没问题。

滤波性能

姿态解算中，主体为陀螺仪，加速度计滤波性能直接决定了姿态估计的精度，惯性导航中加速度计为主体，滤波性能决定位置、速度估计得实时性、动态精度，在姿态、惯导数据得到的姿态数据、位置、速度数据用于控制时中，加速度计的噪声间接参与PID运算，而在高度控制加速度反馈时，加速度是直接参与PID运算，前两者直接对比频谱即可，加速度反馈需要综合考虑:比如飞控受到撞击时，加速度计输出噪声异常，最直观的是落地、起飞时震动惯导易发散，加速度用于反馈时，容易导致油门输出异常，早期APM返航着陆落地时会在地面弹几下才进入怠速，后面把截止频率改到2hz之后，就解决了此问题。

系统响应

单姿态自稳时，姿态输入的期望角度，来源于遥控器解码，标准遥控器PPM（PWM）周期为20ms，Sbus会快一点大概7.5ms，加了位置、速度控制，如果速度控制器的输出，给定期望姿态角很频繁，这对姿态环带宽要求很高，执行机构很难做到这么快的响应（3～5个周期跟踪到期望输入），所以你的姿态外环（位置、速度）给的再快，系统也跟不上，给的太快最直观反作用是会使得内环角速度微分容易突变（会频繁的加入外层回路位置、速度、角度的噪声），就发现飞机高频、小舵量，颠颤，所以对于位置、速度环控制器执行周期可以相对大一点，一般超过10ms就可以。

巴特沃斯滤波器的截止频率如何取

可以参考下最新的1.7.3版本的代码里面的计算公式，二阶IIR滤波器会根据品质因素、截止频率，采样频率等来确定滤波参数，实际在Matlab里面也是这么计算的，你可以对比下Matlab计算出来的参数和飞控计算出来的参数，是一致的，差别只在于小数点后6位之后的数据，这个是由单片机计算精度决定的。

累计漂移

很大可能是初始陀螺仪标定未标定或者标定的零点漂移不是真实值，较大的陀螺仪静差，这个时候加速度修正也是无能为力的，小的静差在互补滤波里面将叉乘得到的角度误差项通过比例、积分运算去修正陀螺仪漂移，对于小的静差，正常来讲积分项可以抵消这部分小静差+bias漂移。

姿态估计精度误差大

加计噪声比较大，或者加计融合权重太大，可以尝试低通滤波处理下原始数据、减小加计融合权重；如果由于陀螺仪初始零偏标定错误造成比较大的静差，较大的陀螺仪零偏静差+bias漂移，再优秀的融合算法，用加速度修正是无能为力。

控制周期

飞控系统传感器采样、姿态解算、惯导融合、控制器等调度周期需要保证，但是因为程序会存在抢占式中断，导致调度时间不能严格等周期，在实际处理时，只要保障在每个调度周期内，能把这些事情全部干完即可，需要用到间隔时间的地方，用实测调度周期就可以，比如姿态、惯导更新周期，控制器积分时间等。
这里需要注意的是，保证主要任务在每个调度周期内都能执行完毕，需要主任务的执行时间之和小于等于任务调度周期，设计时需要对每个任务的时间开销进行测试，合计安排优先级和调度周期。

时间

飞控里面的每个任务时间开销都有实际测试，程序里面用了一个高优先级的定时器，测量精度可以到us级，测最大任务开销有两如下两种办法:
方法1、直接在主任务调度定时器的开头与结尾各运行一次测时函数，将两个测时函数的得到的结构体时间做差，就可以得到所有任务的总开销Delta_T，由于不同子任务里面也存在调度、每次单个子任务时间开销不一、存在串口中断、外部中断打断等，所以这个Delta_T是变化的，其最小值对应总任务的调度最小时间开销，最大值即为总任务的调度最大时间开销，这里注意一点，串口中断、外部中断里面处理的任务时间开销很小，基本是几个us级别的，主要的开销还是定时器里面的各个子任务开销。
方法2、对主任务调度器里面的各个子任务分别测量开销，测量方法为在该子任务的开头和结尾依次运行测时函数，两个结构体的时间做差即可得到子任务的运行开销delta_n，这个delta_n对于某些子任务其运行时间仍然是变化的，记录其最大值即可，依次测量每个子任务的时间开销，包括串口中断、外部中断的时间开销，把所有的子任务时间开销delta做和即可得到总任务的最大、最小时间开销。
目前总任务最大运行时间接近4ms左右，主任务调度器为5ms，留了充足的裕量给客户二次开发，用户在自行编写、移植飞控代码时，需要实际测试这部分在对应处理器上的时间开销，确保飞控系统稳健运行。

飞控里面传感器采样、滤波、姿态解算、惯导融合、控制这些对时间有严格要求。

保证传感器数据不丢帧

首先这里需要明白一点，串口通讯波特率与数据传输时间的关系，以无名飞控GPS解析为例，正常工作时，GPS工作以波特率921600，8个数据位，一个起始位，一个停止位。921600bps/(8+1+1)bit=传输92160字节/s，故串口传输一个字节用时1000000us/92160≈10.85us，这里可以简单计算一下，飞控接受pvt语句开销92数据位+2检验位=94，94*10.85约等于1.02ms，与飞控实际测试时间基本一致，实际也可以测试115200、38400通讯时开销分别为8.53ms、25.6ms，接受单个字节耗时分别为86.8us、264.4us。
以GPS解析为说明串口传输时间后，再来考虑中断问题，首先为保障数据不丢帧，当只存在一个串口中断时，该串口中断内部函数执行时间，务必要小于该串口的传输一个直接所需的时间，以波特率115200的串口1为例，串口1的中断函数执行时间务必小于86.8us，即串口1的下一个字节传输来之前，上一个字节的串口中断处理函数务必运行完成，否则数据就会丢帧。
所以一般来讲，串口中断函数里面都不会去执行大段时间开销的任务，目的就是确保不丢帧，常用的办法是在串口中断里面采用环形队列缓冲区存储数据，数据解析用低优先级的任务去处理。
环形队列缓冲区存储函数的执行时间在STM32F1里面大概2us不到，在STM32F4里面不足1us，所以当串口中断函数里面只运行环形对接缓冲区存储函数时，即使以波特图921600(传输一个字节10.85us)通讯，数据也不会丢帧。
当存在多个串口接受函数时，此时以STM32F1为例，假设环形队列缓冲区存储函数的执行时间在STM32F1里面为2us，此时存在6个串口中断以波特率921600同时运行，各中断彼此之间不能打断，但是存在子优先顺序，同一时刻6个中断全部挂起，这个时候系统首先响应子优先级第一的串口中断接受函数耗时2us，接着依次响应子优先级23456，当第6个串口中断函数刚开始执行时是第10us，在10—12us时系统正在执行第6个串口中断函数，在10.85us时刻，下一次串口中断又来了，此时便发生了数据丢帧。可以可以想一下，此时在不丢帧情况下，系统能设计的最大串口中断数为5个。
上面是以很极端的例子说明了丢帧在实际系统中是怎么发生的，一般串口通讯波特率不会到921600这么大，并且不是每个串口都必须工作在同一波特率，当工作波特率为115200时，串口接收单个字节为86.8us，此情况下系统能够执行足够多的串口中断函数，仍然能确保不丢帧。所以当系统所需串口中断很多时，可以通讯把波特率降下来，来确保不数据丢帧。
以上只考虑了串口中断彼此之间开销，当系统存在比串口中断接收优先级更好的中断任务时，比如利用外部中断的ppm接收、超声波测距等，为了确保串口不丢帧，需要优先级高于串口中断的任务最大执行时间+串口中断函数执行时间，务必小于串口接收单个字节所需的时间，才能确保不丢帧。
总结:
1、多个串口通讯时，串口通讯波特率可以降低一点。
2、合计设计优先级，当存在不同波特率通讯时，通讯波特率高的串口中断优先级要高于波特率低的。
3、存在优先级高于串口中断的其它中断任务时，其它中断任务的总的最大时间开销也要考虑。