2026年9月12日晚，在进行lidar里程计无人机的px4ctrl模块PID调试过程中，无人机进入autotakeoff后，无人机持续向上飞行。

2026年9月12日晚

通过查看飞行日志，发现飞机在进入AUTO_TAKEOFF模式后3s，退出AUTO_TAKEOFF。


退出AUTO_TAKEOFF后，同时也退出了飞控的OFFBOARD模式，转为飞控的自稳模式，由于油门操作杆位于50%处，悬停油门45%左右，所以飞机表现为持续向上飞行。下一步排查是由于什么问题导致了退出OFF_BOARD模式。

退出AUTO_TAKEOFF有以下几种原因：遥控器hover开关被关闭、动捕里程计超时、融合节点报告失败、RC消息超时，通过添加日志打印，发现退出时报RC 消息超时，同时px4ctrl报IMU频率低于100Hz。


对/mavros/rc/in的消息进行持续检测，发现确实是消息频率降低，越过了设定的2Hz阈值，起飞前（甚至是起桨离地前）/mavros/rc/in 遥控器信号RC的消息都是稳定在4Hz左右。飞机离开地面后，频率大幅度降低，一直降低至不到2Hz，甚至出现了短时间内“no new messages”的情况



2026年9月13日

后续发现不止是/mavros/rc/in降低频率，所有的通过飞控串口线通信的消息都降频严重，包括非常重要的/mavros/imu/data_raw和/mavros/imu/data，降低到100Hz以下，所以这也能解释了之前的px4ctrl报IMU频率低于100Hz。

下一步怀疑是由于起飞后，飞控计算量增大，导致CPU loading过高，使飞控减少串口的通信频率，但是通过打印相关日志，发现在飞机飞行过程中，飞控的CPU loading稳定在57%，并没有超过90%。


下一步怀疑是飞控在起飞后，由于SD卡质量问题，导致写入日志阻塞，进而影响串口通信频率，将SD卡拔掉，关闭日志写入SD卡功能后，问题没有解决。

突然想到之前github工程的readme中一个比较奇怪的说法：为什么请求1000Hz的IMU频率，最后只能获得250Hz的/mavros/imu/data_raw，但是之前的实际测试中，发现这个频率并不是250Hz，而是300Hz左右，也就是请求的频率和实际频率和README的说明频率完全不对应，到底哪一方是对的？


目前的串口线使用的UART通信波特率为921600，单向理论通信速率为921600 / 10 = 92160 B/s，92.16 kB/s，如果使用上述github readme中的配置：

HIGHRES\_IMU        1000 Hz：约 74 kB/s
ATTITUDE            200 Hz：约  8 kB/s
ATTITUDE\_QUATERNION 250 Hz：约 11 kB/s

仅这三项就已经约93 kB/s，还没有计算 RC、ODOMETRY、TIMESYNC、BATTERY等消息。因此921600不能稳定承载这套频率配置，PX4会自动缩放或延迟消息。所以这也解释了reademe中为什么是配置请求1000Hz的imu/data_raw，可能是尽可能榨干px4的发送频率。

所以怀疑是由于px4无法承受这套频率配置，导致的自动降低频率以适应，（但是之前的机型一直没有出现过这么严重的问题：RC频率降低到2Hz以下）。

将请求的各项频率从1000Hz降低到200Hz，并进行了测试，发现问题还是没有解决，还是存在起飞离开地面严重降低频率的问题。

2026年9月13日晚

怀疑是硬件串口通信的问题，但是在软件应用层，没有任何丢包的错误显示。排查陷入了瓶颈。


之后采用了将通信换成了PX4的typec接口通过双口typec线连接到orin的typec接口，突然问题消失了，起飞后RC频率十分稳定，同时不像之前一定要请求1000Hz的IMU，才能收到300Hz左右的IMU信号，直接请求300Hz，接收到也是稳定的300Hz，请求250Hz，接收到也是稳定的250Hz.

后面进行了各种交叉测试

怀疑是orin到px4的串口线问题，又和orin10无人机进行了对比，orin10的频率起飞后也没有问题，请求1000Hz，imu频率一直稳定在300Hz左右。排查根因陷入了瓶颈。

将串口线换成了之前1年前焊接的连接线（长度15cm，划重点）。问题并没有解决，难道线不是问题？


之后把orin10号的串口线换到了lidar无人机上进行测试，问题消失了。


把lidar的串口线还有之前一直使用的焊接的串口连接线换到了orin10上，orin10也出现了同样的问题。

问题出在串口线材上，是什么的问题呢，唯一的不同就是lidar以及之前的串口连接线的长度为15cm，而之前没有问题的typec、orin10的串口连接线的长度更短，typec是10cm，orin10的线是我当时自己焊的非常短只有不到5cm，他们都没有问题，那就是串口线的长度问题了。

通过打印日志发现：不是 PX4 主动降频，也不是 SD 卡或 CPU，而是飞行/电机带载时 /dev/ttyTHS0 串口通信发生严重帧损坏。



最可能的硬件原因依次是：

1. PX4到Orin的TTL串口线受ESC、电机线或电源线干扰。
2. 飞控与Orin共地不可靠，飞行电流增大后地电位发生偏移。
3. 921600波特率对当前线长、接插件或电平质量过于敏感。
4. Orin供电或飞控5V电源在大油门下存在纹波/压降。
5. 使用了质量较差或速度不足的电平转换模块。

而之前mavlink显示的丢包为0是ros应用层的表现，而无法显示底层内核层的丢包。

定位为 921600 baud TTL串口线过长导致的信号完整性问题，不是PX4负载、MAVROS配置、消息请求频率或串口理论带宽不足。由于lidar飞机较大，导致px4与orin距离远，使用的通信线长过长，导致问题暴露。
原来使用约15 cm的TX/RX/GND串口线，飞机起飞、电机工作后，受电磁干扰、串扰、地弹或信号边沿振铃影响，UART出现误码和MAVLink丢包，表现为IMU从约200 Hz降到100 Hz以下，RC频率同步下降，严重时出现心跳超时。换成约5 cm串口线后，起飞过程中频率稳定，未再发生丢包。
USB Type-C通信也没有丢包。
最终建议：

• 921600 baud TTL串口线尽量控制在5 cm左右。
• 如无法缩短串口线，建议使用屏蔽线、差分通信或USB连接。

1. 之前说orin10飞机的飞行表现比其他飞机都好，是因为orin10的串口连接线短没有出现丢包问题。
2. 之前的readme中要通过配置1000HzIMU来请求250Hz的IMU，一是由于串口连接线丢包导致IMU频率降低，二是921600波特率硬件上不允许发送1000Hz的高频信息，PX4自动降低频率
3. 之前的视觉定位效果不理想，说是IMU的质量不高，可能是由于IMU数据丢包严重
4. 之前的IMU时间戳不均匀性分析，经过对比发现使用短线材/USB串口，飞控的IMU时间戳不均匀性有很大改善，实际对比方差：长串口线45.94%，换成短线后降低至36.70%

imu\_long.bag
  Messages                  : 14801
  Header time duration      : 50.726842 s
  Mean frequency            : 291.759 Hz
  Mean interval             : 3.427489 ms
  Median interval           : 2.507000 ms
  Interval standard dev.    : 1.574576 ms
  Coefficient of variation  : 45.939634 %
  Min / P01 / P99 / Max    : 2.492000 / 2.496000 / 7.521000 / 62.679000 ms
  Duplicate/backward stamps : 0
Reading /root/host\_home/code/imu/imu\_typec.bag ...

imu\_typec.bag
  Messages                  : 10538
  Header time duration      : 43.469152 s
  Mean frequency            : 242.402 Hz
  Mean interval             : 4.125382 ms
  Median interval           : 3.048000 ms
  Interval standard dev.    : 1.514203 ms
  Coefficient of variation  : 36.704563 %
  Min / P01 / P99 / Max    : 2.948000 / 2.952000 / 6.132575 / 45.008000 ms
  Duplicate/backward stamps : 0