① 不理解单片机通过定时器实现控制器需要周期性执行这一基本要求的重要性，如下图中在5ms周期性任务中引入了延时函数的飞行任务中，开发者OS是希望延时函数上方的速度控制执行10S，认为加了延时之后会速度控制函数就会一直执行。实则是程序会运行一次速度控制函数后，程序会在此处空转等待，后续的高度控制、姿态控制、PWM输出等得不到及时的执行，只有在10S等待空窗期后才会继续执行后续的控制，在10S等待时间内，飞控不会对自身的位置、速度、姿态进行即时高频（200Hz相对0.1Hz来讲）的调整与修正，无人机处于间歇性“失控”状态，飞行器的控制周期从5ms变成了10S，用此段代码去控制你的无人机，惨烈的炸机也就变得不可避免。上述问题的根源是延时函数破坏了控制器的周期性执行，连最基本的姿态控制都得不到保障，动摇了飞控系统的“国本”。
① 对飞控代码的执行流程与代码产生实际作用理解错乱，不会对任务按流程进行拆分，将部分重复作用的代码“杂乱堆砌”在一起，造成逻辑混乱，实际作用不明。如在下方代码中色块对准函数内部实现有光流速度控制函数，当视觉模块识别到了色块时，case 1内部的速度控制函数和色块控制内部的速度控制函数会顺序执行，即同一个控制周期5ms内，速度控制函数执行了两遍，第一次运行的控制器输出会被后续第二次运行的结果覆盖掉，似乎第一次可以视为“无用”代码，看似不影响最终的控制效果。但是事实是我们需要考虑到PID控制器的运算过程，同一个控制器一个周期内执行两遍，相当于积分I做了两次运算，微分项不起任何作用。因为两次计算过程中，当反馈和期望不变的情况下，第一次的运算过程的偏差和第二次运算的偏差相等，并且第一次的偏差赋值给了上次的偏差，即微分项会恒等于0，即不管微分项参数D为多少，最终计算出来的微分项结果恒等于0。在PID三个参数都存在的情况下，某个控制器重复执行亦会导致灾难性的BUG。
① 认为控制代码只需要执行一次就能达到期望的控制效果，如果从A飞到B，AB两点的距离为100cm，试想无人机需要在一个控制周期5ms内就能实现A到B，假设无人机做匀加速直线运动，零初始状态下无人机的加速度要到多少才能完成这一目标，无人机的实际推重比是否能达到这个要求？如果按照这个加速度进行加速无人机1S后是否会脱离地球轨道？
① 认为控制代码只需要执行一次就能达到期望的控制效果，如果从A飞到B，AB两点的距离为100cm，试想无人机需要在一个控制周期5ms内就能实现A到B，假设无人机做匀加速直线运动，零初始状态下无人机的加速度要到多少才能完成这一目标，无人机的实际推重比是否能达到这个要求？如果按照这个加速度进行加速无人机1S后是否会脱离地球轨道？
① 另外由于飞控自身硬件资源有限，飞控自身外界的外设占用比较多，可供用户它用的串口、PWM、IO资源不再富裕，使用起来使用捉襟见肘，常常需要外部MCU进行扩展，既然都引入了外部MCU到无人机平台中了，很自然的会想到用自己熟悉的MCU飞无人机飞行任务进行开发。
