lida2003的专栏

iNav整体代码框架与Betaflight类似。(因为BF最初就是从iNav分出去的。目前代码框架上任然或多或少有相似性，但也存在不同的设计技巧。iNav更加注重的是功能（远航，悬停等）。换句话说，从功能设计的角度更加完善，另外适用的航模模型范围更广。从研读的角度：框架、代码、场景、异常、配置等逐步入手是一个比较好的方法后续如果有更多的资料，会尽量同步到这个入口文档中！有什么感兴趣的，大家也可以留言告诉我！

升级下固件，追下“时髦”，赶下“潮流”，本着“活着就要折腾的原则”，碰到不少“怪”现象。注1：这里Aocoda-RC F405V2替换MCU芯片AT32F435的定制飞控。注2：这里测试Mark4基本配置(功能)与四轴飞控DIY Mark4类似。TX12 ELRS RC 10 信号无法操作。配置bdshot，电机#4没有RPM转速。配置dshot600，四个电机转动正常。

Download link: BetaFlight_Current_Calibration_v2.xlsxThis is a guide for how to use this xlsx file.Step 1 Filling Pre-Set-Scale, and make sure Pre-Set-Offset is zero.Step 2 5 points current test, filling [GroundStation] and [Y-PowerMeter] in green.Step 3

注：STM32在计算时，运用了一些整形变换，使得上述运算不用到浮点指令，减少MCU的工作量。VBAT_ADC直接接MCU引脚进行ADC转换形成12bit ADC数据，供后续算法处理。上述任何一个位置和路径都可能发生问题，导致电压不准。都过了一遍，电压相对来说是比较简单的，一起过一下。

好了，不在多说，很多或者说大部分能力是可以通过后天学习、锻炼的，当然确实有一些“第六感”很难说清楚，有人会说“天生”的。先做一个常规逻辑/常用概念，老外比较喜欢说"common sense”，因为没有这个概念的人，沟通工程技术问题是很难的，因为没有"common sense"。如果您确实对电流不准的问题非常在意，希望通过校准来确保显示的数据正确，那么需要准备万用表，串接到电源上，进行测试。那么，恭喜您，第一步就是复现客户现象，并整理“环境因素，操作步骤，以及不准确现象的量化测试一手数据”。

从目前性能的角度，AT32 F435非常接近STM32 F7系列；从FLash角度，AT32 F435可以支持到最大4MB容量；从IO的角度AT32 F435基本可兼容，甚至某些封装可以直接替换；从价格的角度，性价比非常诱人，尤其国际市场STM32芯片短缺的情况看就更具有重要意义;若飞控厂商，能考虑做了AI屏蔽前后进行相关极端环境的对比干扰分析，那就更有意义了，毕竟很多高级飞控都是CNC屏蔽罩着的。飞控性能量化指标&测试方法。

的代码支持问题做一个研读，看看目前设计上这个框架代码是否支持SBUS。对通道数据进行译码，并根据接收机内部信息判别。获取最近一帧有效数据的时间。

从SoftSerial代码角度，采用定时器、边沿中断的方式，随机使用CPU资源。如果应用在高速、大数据量通信场景，将会影响和打扰CPU正常业务逻辑，尤其是在CPU资源紧张时。

做个简单的Aocoda-RC F405V2 Mark4 7"适配过程记录，本人并不推荐去飞iNav目前这个最新版本的inav 6.1.1固件。原因：iNav开源代码之严重炸机 – 危险隐患据说是已经修复，但是目前(截止发稿日)还没有放出稳定的发布版本，可能在内测中。模拟套机的配置清单如下：PNP整机主要是焊接一个接收机，其他基本上都是焊接到位的，不过上手固件之前，请确认接线是否正确！！！截止发稿日，最新地面站软件版本：INAV Configurator 6.1.0安装方法详见链接：Windows/Linu

飞控硬件厂商在设计飞控的时候，在开发、测试阶段已经将IMU方向配置在硬件定义文件中了。目前，相对来说，国内比较主流的飞控代码可以分为两大类：两者坐标系有差别，尤其在硬件配置文件中定义的角度，更是出现非常离奇的情况。这里做一个整体应用级别的分析，希望能够帮助后续定位底层差异。3.2 betaflight/inav4. 实例注：始终采用Y轴方向朝前进行变换。相关映射，后续会补充，其主要原因，会随着底层分析深入，给出答案！正常旋转获得结果，XYZ轴重叠。非正常旋转，Y变成X、X变成Y、Z反向，需要驱动底层

Betaflight 4.5 + Aocoda-RC F405V2 + AT32F435 Mark4 试飞初步总结

Betaflight关于STM32F405 SBUS协议兼容硬件电气特性问题

xFlight开源飞控之AT32F435计划xFlight主要指betaflight/inav，延伸扩展Ardupilot/PX4-Autopilot。

betaflight固件版本、飞控配置 ==》 基本正常Gyro/Acc/Baro以及传感数据 ==》基本正常Gyro校准，Pitch/Roll/Yaw ==》基本正常OSD MAX7456 芯片 SPI已经发现 ==》基本正常// 但atbetaflight是正常的。

BF4.0抽象统一配置文件BF4.5抽象统一配置文件BF4.0抽象统一配置文件BF4.5抽象统一配置文件BF4.0抽象统一配置文件BF4.5抽象统一配置文件BF4.0抽象统一配置文件BF4.5抽象统一配置文件# dma# feature# serial。

根据FAILSAFE策略、触发流程、状态机，以及异常场景的分析，当iNav执行救援时，如果配置恰当，炸机风险相对来说是可控，但是要注意参数的设置，尤其是【值得关注】的参数。

根据FAILSAFE策略执行流程以及GPS救援状态机的分析，当Betaflight执行救援时，如果遇到异常，仍然存在炸机风险。当然相关问题，还在和官方沟通中，期待后续能有比较完美的解决方案。#11970。

卡尔曼滤波非常适合不断变化的系统，其优点是内存占用较小（只需保留前一个状态）、速度快，是实时问题和嵌入式系统的理想选择。结合一个物体（飞行器）位置和速度的关系来简单的描述下kalman滤波。在速度-位置坐标系中表示：在物体匀速运动时：经过变化，可以表示为：通常来说，变速运动比较常见，因此引入加速度概念后：经过变化，可以表示为：然后，这个位置-速度坐标系下，可以表达为：当我们监控无人机时，它可能会受到风的影响；当我们跟踪轮式机器人时，它的轮胎可能会打滑，或者粗糙地面会降低它的移速。

多轴飞行器，在紧急着陆消息例程中，最为重要的就是不断更新x-y坐标位置，在x-y坐标有效的情况下，确保垂直降落。因此，从进一步认识、理解问题的角度看，需要进一步深入“【传感数据】IMU姿态”和“【PID】姿态计算”的调查。更新着陆x-y位置，如果检测到成功，则反馈NAV_FSM_EVENT_SUCCESS触发后续完成事件。通过表面上的分析及测试验证，初步确认问题的方向已经找到，并最终指向的是紧急降落出现了翻滚，导致失控。任务，不过从代码看，Betaflight做了更好的整理和封装。

分析虽然缩小的范围，但基于上述数据尚无法给出明确的结论。同时开源社区，缺少仿真环境、人力的情况下，尚未得到有效的问题分析结论。中，已经做了初步的分析，并且将重点怀疑的方向放到了Emergency Landing阶段。8. 在电池没有拔掉，飞控未重启情况下，起飞直接翻跟斗；为了更好的可控跌落，设置一个高度保持（因为没有GPS，所以无法位置保持）。为了进一步缩小问题范围，本章节将跟进测试紧急降落功能。【第一次严重丢机后续】正常飞，操作很灵活，无任何问题。，确认相关配置项，确保一致性。经过重新上电后，飞行正常！

关于炸鸡的过程，就不再展开，都是“泪”啊！想进一步了解的，请参阅前面的初步分析。以下类别与Configurator中的Drop/Land/RTH一一对应，其中。是一个默认的状态，仅程序使用，GUI界面没有相关配置选项。的类别，配置，阶段，以及状态机来看看是怎么个过程。为了更清楚的搞清楚到底是哪里的问题，还是要从。在编译时，在目标板目录。最近因为炸机，百思不得其解。模式下代码逻辑是如何发生的。的工作原理来分析，在相应。

主要目的是为了检查桨叶安装牢固程度，天线(VTX/RC)、基本操控（俯仰/翻滚/RTL等）功能是否正常。集合#2和#3章节，异常出现于“Emergency Landing”时，模型出现了翻滚，无法控制姿态。正如大家看到的很多空难事件一样，都是多因素导致的坠机。正因为如此，航模也好，无人机也罢，才需要更加注意安全。本次炸机是相对来说比较复杂的，或者说“水很深”的场景。注：基本测试并非完全测试，所以实际飞的时候，还是会出现各种情况。为了更好的理解炸机原因，并未后续安全飞行提供更好的保障和经验。

iNav在导航飞行功能是非常强大的，尤其是GPS路点飞行等。同时，也做一个备份记录，以便可查阅。

最近上了iNav 6.1.1固件，总体感觉非常不错。但是出现了一个百思不得其解的蜂鸣器持续蜂鸣的问题。虽然是个小问题，总的来说就欠缺完美。研发研发就是研究问题，发现问题，最后解决问题。

为了更好的整理和记录当前状态，将所有配置信息做个存档，以便后续进行对比分析。如有必要也可以快速恢复到当前配置。手头这台航模四轴，基本调试的差不多（还算满意），后续准备上ArduPilot。BetaFlight Mark4 3S 2200mAh 续航 城北公园 转圈圈。

上述默认PID在本机上出现了翻滚以后“bounce back”的情况，这里简单根据BF滚动条的提示，将“Tracking: P & I Gains”设置为1.1，有所好转。注：关于这些数据资料，优快云上传说要2~5个工日之后才能进行审核，目前还在审核中，因此这个黑匣子数据想看的朋友，可以等几天，或者评论区告诉我。注：PID的调参貌似玄学，经过一些资料介绍，其实也并非那么神秘，在实操面，大家可以看下附录里面大佬们的一些经验心得。【“血的”的教训】航模飞行危险意外常在，这就是为什么我说的要注意安全！

上述问题基本已经得到回复，虽然有些问题尚有存疑部分。显然很多历史的问题，并不一定都是能寻根究底的。我们暂且考一段落，希望能有更加明确的场景和rootcause给出，以便工程角度更好的分析和定位问题。这也是我通常比较强调的为什么很多事情要搞清楚rootcause的原因。相信上面的问题是有这些内容的，但是需要挖掘出来，需要和真正处理的当事人非常紧密和深入的探讨。当然这样也就为后面设计和重构提供了基础。

BN880模块冷启动到定位耗时长；总可用星数量不理想，常规模块通常在12~18颗左右）；测试的BN880不如M8N的定位能力强；注1：上述BN880配置，已经厂家技术支持确认过配置参数。注2：上述情况将反馈厂家技术支持，会再次确认是否质量问题。

更换原Aocoda-RC F405 （6000） 为H743 Dual（270 x 2）随着油门45%左右开始，gyro raw data出现很多噪声。怀疑飞控设计存在问题。注：桨叶、电机整体性能并非优秀，且操作可能并不完美，因此波形上并不理想，但是相较于。【纹波】增加一些滤波电容，过滤~ 100Hz左右或者其他频率的干扰。后续可以考虑使用独立给给摄像头和/或图传供电，以期望找出横纹影响。BetaFlight H4Dual 电机控制波形测试。机尾打印支架位置干扰（机尾干扰比机头严重）的波形，已经明显改善。

这个结构体是一个优先级和任务配置的相关结构。当然因为BetaFlight自研调度器与飞控应用高度耦合（强耦合），这只是调度的一部分内容。BetaFlight整体代码可以分为两部分：初始化(init)和运行时(run)应用功能代码已经通过宏定义，支持可剪裁编译；整个调度器要了解存在一些背景知识需要澄清和讨论（已经在附录中整理，并正在与开发团队讨论中。。。。

从目前测试的效果看，主要问题还是滤波问题。【节省系统资源】关掉gyro lpf1；dterm保留一个；【去掉无关高频IMU数据】lpf2静态pt1 250hz；【抑制了146Hz电机振动】dterm改120hzpt1静态；【有一定效果，但是有了dterm 120hzpt1静态，就显得多余了，可以节省出系统资源】动态带通滤波增加到2个；因此，最关键的还是需要了解四轴飞行器振动来源，以及振动对四轴的影响。只有这样才能更好的去设置滤波。

注：这个其实厂家也可以不配置，在BetaFlight Configurator的UI界面是可以配置的。有了一个大概的了解，针对上述板子做一个简单review，并记录澄清一些问题。厂家反馈：S9(D14)和S10(D15)分别对应电机#9和电机#10。上述问题汇总，希望大家能指正/纠错，让博主和读者更加了解这些配置项。b) 从精简的角度考虑，可以删除(已经与厂商确认)。已反馈生厂商或研读代码，待继续跟进。已反馈生厂商或研读代码，待继续跟进。已反馈生厂商或研读代码，待继续跟进。的板子，后续也许可以派上用处。

H743 DMA控制器 x 2每个DMA控制器 有 stream x 8DMA stream由 DMAMUX信号来驱动(Request)Request信号可以是115种可用信号的其中一种DMA主要功能不在这里展开，希望更多了解请下载RM0433资料，更深入的了解DMA技术细节，可以对工作原理，优先级、带宽、工作模式优化提供帮助，但这不是本章节重点。有兴趣的朋友可以自行研究先，有时间我们会在后续驱动方面的文章中进行探讨。

统一硬件配置文件的设计是一种非常好的设计模式，可以将硬件和软件的工作进行解耦。cli命令中feature是对BetaFlight飞控软件功能使能开关。至于功能的含义，这里就不展开，随着对系统的深入理解，慢慢就会一点点了解起来的。

统一硬件配置文件的设计是一种非常好的设计模式，可以将硬件和软件的工作进行解耦。cli命令中set是对BetaFlight系统内部参量进行变量赋值的主要命令。

统一硬件配置文件的设计是一种非常好的设计模式，可以将硬件和软件的工作进行解耦。cli命令中serial是对UART串口的配置，通常情况下BetaFlight飞控会有一个USB VCP端口用来处理MSP消息配置飞控，其他端口更具应用来进行配置，所以厂家默认出厂可以不配，由用户根据需要调整。

统一硬件配置文件的设计是一种非常好的设计模式，可以将硬件和软件的工作进行解耦。cli命令中timer是对硬件引脚和timer资源进行绑定的一个操作。

统一硬件配置文件的设计是一种非常好的设计模式，可以将硬件和软件的工作进行解耦。

统一硬件配置文件的设计是一种非常好的设计模式，可以将硬件和软件的工作进行解耦。cli命令中resource是对硬件引脚资源进行配置的最为基础的一个命令。

这里说了这么多阶段性的东西，整体上还是想简单捋一下，从嵌入式的角度，如何将业务层层设计，并最终一步一步的落实到物理世界的。很多问题的分析不仅仅要从局部入手，更要从全局，甚至要有长期布局的思路。这里就不展开，否则话太多，离题了。