关于实验室里Tyran移动机器人的使用和问题说明（总结）

出现以上错误时，需打开/home/sparks/mybot_ws/src/robot_bringup/src/mbot_linux_serial.cpp，然后将39行的/dev/ttyUSB1改为/dev/ttyUSB0，或将/dev/ttyUSB0改为/dev/ttyUSB1，然后重新编译，souce，运行，问题解决。笔者本义是想部署上语义相机，然后跑一些基于语义地图改进的路径规划算法，结果由于

Wanna.63

640人浏览 · 2025-12-18 19:05:28

Wanna.63 · 2025-12-18 19:05:28 发布

2025-12-19

目前已经实现的功能：Gmapping算法建图，Cartographer算法建图，机器人导航，yolov8目标识别，基于deeplab和ORB-SLAM2的语义相机（但是卡顿），视觉部分用的都是D435。

建图算法部分

Gmapping算法建图

# 机器人使能
cd mybot_ws
source ./devel/setup.bash
roslaunch robot_bringup robot_bringup.launch

# 开启Gmapping算法建图
cd mybot_ws
source ./devel/setup.bash
roslaunch my_slam_gmapping gmapping_slam.launch 

#开启键盘控制节点
rosrun teleop_twist_keyboard teleop_twist_keyboard.py

#保存地图
cd mybot_ws
source ./devel/setup.bash
roslaunch my_slam_gmapping save_map.launch #地图的名字和位置均可在该launch文件里修改

Cartographer算法建图

# 机器人使能
cd mybot_ws
source ./devel/setup.bash
roslaunch robot_bringup robot_bringup.launch

# 开启Cartographer算法建图
cd mybot_ws
source ~/.bashrc
roslaunch my_slam_gmapping cartographer_slam.launch

#开启键盘控制节点
rosrun teleop_twist_keyboard teleop_twist_keyboard.py

#保存地图
cd mybot_ws/src/my_slam_gmapping/scripts/
./finish_slam_and_save_map.sh

Gmapping算法和Cartographer算法在长走廊环境下的性能对比

左边这张图是Gmapping算法的建图结果，右边这张图是Cartographer算法的建图结果，我们可以清晰的看到，Cartographer所建的图看起来更加的干净，并且没有由于里程计误差累积而造成的图像偏移；相反，Gmapping所建的图则图像偏移明显，表明了Cartographer算法在长距离建图工作环境下的优越性能。

机器人导航部分

# 机器人使能
cd mybot_ws
source ./devel/setup.bash
roslaunch robot_bringup robot_bringup.launch

#开启机器人导航
cd mybot_ws
source ./devel/setup.bash
roslaunch mbot_navigation navigation_mymap.launch

#直接启动上面的launch文件所打开的map是实验室的map，如果想指定自己的map可以运行如下代码
roslaunch mbot_navigation navigation_mymap.launch map_file:=/path/to/your/map.yaml

运行结果图

PS：因为笔者在截图时没有将机器人移动到起点位置，所以打开后rviz中的雷达信息是与map不相符的。

补充：

这里局部路径规划算法用的是DWA算法，全局路径规划算法是dijkstra和A*。这里默认是dijkstra算法，如果需要使用A*，则可以在/home/sparks/mybot_ws/src/mbot_navigation/param/base_local_planner_params.yaml中进行设置。

这里因为该map是在实验室里，环境比较拥挤，所以这里笔者将膨胀层半径设置为了0.1，如果转移到了相对宽阔的环境或者需要保持更大的安全距离，可以在/home/sparks/mybot_ws/src/mbot_navigation/param/costmap_common_params.yaml中设置膨胀半径。

yolov8目标识别

#启动realsense D435深度相机
cd mybot_ws
source ./devel/setup.bash
roslaunch realsense2_camera rs_rgbd.launch

#启动yolov8目标检测节点
cd mybot_ws
source ./devel/setup.bash
roslaunch yolov8_detection yolov8_detection.launch

#可以启动rviz配置image来实现可视化
rviz

运行效果图

基于deeplab和ORB-SLAM2的语义相机

#启动Realsense D435深度相机
cd realsense_ws/
source ./devel/setup.bash 
roslaunch realsense2_camera rs_rgbd.launch 

#启动ORB-SLAM2和语义相机节点
cd /home/sparks/ORBSLAM2_Semantic_Mapping-master
source ~/anaconda3/etc/profile.d/conda.sh
conda activate deeplab-pytorch

export LD_PRELOAD=/usr/local/lib/libopencv_core.so.3.4:/usr/local/lib/libopencv_imgproc.so.3.4:/usr/local/lib/libopencv_highgui.so.3.4
export LD_LIBRARY_PATH=/usr/local/lib:$PWD/lib:$PWD/Thirdparty/DBoW2/lib:$PWD/Thirdparty/g2o/lib:$LD_LIBRARY_PATH

source ./Examples/ROS/ORB_SLAM2/build/devel/setup.bash
./Examples/ROS/ORB_SLAM2/RGBD Vocabulary/ORBvoc.txt config/Intel_D435i.yaml null

运行结果图

笔者本义是想部署上语义相机，然后跑一些基于语义地图改进的路径规划算法，结果由于机载电脑的处理器性能不够，导致打开语义相机节点后，ORB-SLAM2和语义相机画面极其卡顿，便作罢了。

问题及解决

1 - 开机后运行机器人使能，可能会出现如下错误

解决：这是因为每次开机USB接口的名字都会变换，有时为/dev/ttyUSB1有时为/dev/ttyUSB0。出现以上错误时，需打开/home/sparks/mybot_ws/src/robot_bringup/src/mbot_linux_serial.cpp，然后将39行的/dev/ttyUSB1改为/dev/ttyUSB0，或将/dev/ttyUSB0改为/dev/ttyUSB1，然后重新编译，souce，运行，问题解决。

2 - 当使用Cartographer算法建图时，可能会出现以下问题

解决：这个问题是cartographer初始化的时候出现了问题，只要ctrl + c关闭cartographer节点，然后重新启动即可。

3 - 笔者在最开始部署Gmapping算法进行建图时，出现的问题

类似这种现象（图是网上找的，当时笔者没有截图），启动键盘节点控制机器人移动，发现实体机器人可以随着键盘节点的控制正常移动，而Rviz中的机器人模型则总是移动一小段距离后，瞬间闪现回到原点，导致建出来的图像，是以机器人模型为中心的旋转放射状。

问题分析：这是个TF坐标系不一致导致的问题，robot_bringup节点发布的TF变换:odom -> base_footprint，robot_state_publisher发布的TF变换:base_footprint -> base_link -> [其他机器人部件]，而gmapping节点期望的TF链:map -> odom -> base_link -> laser_link，但是实际的TF链: map -> odom -> base_footprint -> base_link -> laser_link。原始gmapping配置使用base_frame="base_link"，但robot_bringup发布的是odom->base_footprint，导致gmapping无法正确获取机器人位姿，从而计算出错误的地图变换，表现为机器人模型漂移抖动。

解决：修改gmapping_slam.launch中的base_frame参数，从base_link改为base_footprint。

2025-12-25

笔者结合上面已经实现的功能，使用Python的tkinter库做了一个GUI操作界面，方便后面的学弟学妹们使用。源代码的位置为/home/sparks/mybot_ws/robot_control_gui.py，正常使用时双击桌面上的“机器人控制中心”启动即可。

使用说明：机器人使能是机器人建图，控制和导航功能的前提，所以如果你需要启动以上功能时，一定要先启动机器人使能。而视觉部分（语义相机和yolov8识别）则不需要，直接启动相应功能即可。当工作完成之后，点击“停止所有进程”即可，这会直接关闭所有ROS进程。

PS：由于上述问题1，几乎每次重新启动机器人都会出现，所以笔者将问题1的修复也集成到了该操作界面中，当运行机器人使能出现问题1的错误时，点击下图的“切换端口”按钮，并等待编辑完成即可。

2025-3-9

笔者想尝试一下“多传感器融合”，即“雷达 + 视觉 + imu”，于是就在机器人上部署了ORB-SLAM3。

最初，因为最近实验室添置了一台D435i，所以就想尝试一下ORB-SLAM3的 Stereo-Inertial 模式，结果发现在使用相机内置imu的情况下，随着相机的移动，ORB-SLAM3窗口中的相机总是出现复位的问题，导致轨迹混乱。多次修改无果后，决定使用更加稳定的Stereo 模式。

启动ORB-SLAM3，这里有两种模式可供选择，其中Stereo 模式更加稳定。

# 1.启动 Stereo-Inertial 模式（用D435i跑，不稳定，带有相机IMU）
# 启动相机
roslaunch realsense2_camera rs_camera.launch \
  initial_reset:=true \
  align_depth:=false \
  enable_color:=false \
  enable_depth:=false \
  enable_infra1:=true \
  enable_infra2:=true \
  infra_width:=640 \
  infra_height:=480 \
  infra_fps:=30 \
  enable_gyro:=true \
  enable_accel:=true \
  unite_imu_method:=linear_interpolation \
  enable_sync:=false
# 启动ORB-SLAM3
rosrun ORB_SLAM3 Stereo_Inertial /home/sparks/ORB_SLAM3/Vocabulary/ORBvoc.txt /home/sparks/ORB_SLAM3/Examples/Stereo-Inertial/RealSense_D435i.yaml false

# 2.启动 Stereo 模式（用D435i和D435均可以跑，稳定，不用相机IMU）
# 启动相机
roslaunch realsense2_camera rs_camera.launch \
  initial_reset:=true \
  align_depth:=false \
  enable_color:=false \
  enable_depth:=false \
  enable_infra1:=true \
  enable_infra2:=true \
  infra_width:=640 \
  infra_height:=480 \
  infra_fps:=30 \
  enable_gyro:=false \
  enable_accel:=false \
  enable_sync:=true
# 启动ORB-SLAM3
rosrun ORB_SLAM3 Stereo /home/sparks/ORB_SLAM3/Vocabulary/ORBvoc.txt /home/sparks/ORB_SLAM3/Examples/Stereo-Inertial/RealSense_D435i.yaml false

其中，词袋模型字典路径为/home/sparks/ORB_SLAM3/Vocabulary/ORBvoc.txt，深度相机（D435i和D435）的相关配置文件路径为/home/sparks/ORB_SLAM3/Examples/Stereo-Inertial/RealSense_D435i.yaml。这里D435和D435i两款相机使用的是同一个配置文件，即RealSense_D435i.yaml。

Stereo 模式效果图

2025-3-15

今天，笔者结合ORB-SLAM3，里程计信息以及相机imu，实现了基于动态协方差的多传感器软融合定位系统。该系统有效突破了移动机器人在复杂场景下极易丢失定位的底层瓶颈，为上层的建图与导航提供了一个坚如磐石的位姿基石。

该系统总结成一句话就是：该系统以扩展卡尔曼滤波（EKF）为核心枢纽，创新性地引入了视觉 SLAM 的“动态协方差”自评判机制，将绝对准确但易受干扰的视觉坐标、高频平滑的 IMU 陀螺仪与底盘轮速计进行深度松耦合，从而实现了移动机器人在复杂环境中“视觉主导全局精准纠偏、致盲瞬间惯性无缝接管”的高鲁棒底层定位。

整个系统是通过以下 4 个核心步骤一步步搭建起来的：

1. 视觉算法的“按需信任”改造 (核心源码修改)

我们并没有把视觉 SLAM 当作一个“黑盒”直接用，而是深入了 ORB-SLAM3 的 C++ 源码/home/sparks/ORB_SLAM3/Examples/ROS/ORB_SLAM3/src/ros_stereo.cc，植入了动态协方差机制。

系统会实时监控当前画面中成功匹配的特征点数量。当特征点丰富时，赋予定位数据极小的协方差（如 0.01），告诉后续系统“绝对信任我”；一旦遇到大面积白墙或强光导致特征点跌破安全阈值，就瞬间将协方差拉爆（如 9999.0），让视觉系统主动交出控制权，从而从根源上斩断了视觉跟丢导致导航崩溃的可能。

2. 传感器数据的“精准提纯” (EKF 降维配置)

不同的传感器有不同的物理缺陷。在 ekf.yaml 中，我们像用滤网一样，对输入数据进行了极其严格的筛选：

底盘里程计： 仅提取其平面前进线速度和转向角速度，作为基础运动学推算依据。
相机 IMU： 坚决屏蔽带有重力分量和巨大噪音的线加速度（成功规避了由于 -9.8 重力引发的 数学爆炸），仅提取其 200Hz 极高频的三轴角速度，充当对抗旋转漂移的“小脑”。
视觉 SLAM： 仅提取其无累计漂移的绝对空间坐标和偏航角。

3. 坐标系权力的“中央集权” (TF 树重构)

在开源环境中，各个底层硬件往往会“各自为政”。为了消除 RViz 中的模型抖动，我们进行了彻底的物理剥权：

强行关闭了底盘代码 (robot.cpp) 和相机驱动 (rs_camera.launch) 私自发布 odom 坐标系的代码。将 odom -> base_footprint 的最高裁决发布权，授予给 EKF 融合节点。同时，将发布实体模型物理连接的节点提速至 50Hz，最终打通了一条严丝合缝的单向坐标树。

4. EKF 核心大脑的“统一裁决” (时序与融合)

完成上述准备后，robot_localization 节点以稳定的 50Hz 频率开始接管全局：

在低频视觉数据（30Hz）还没算出来的间隙，它利用底盘速度和高频 IMU 角速度进行极致丝滑的“盲走推算”；而一旦收到高信任度的视觉坐标，它就立刻把机器人的位置“拉扯纠偏”到绝对正确的坐标上。

具体而言，该系统实现了以下三大核心功能：

多源异构数据的高效互补： 系统以 50Hz 的固定频率，将底盘提供的基础平面速度、IMU 提供的高频抗漂移角速度（200Hz）与视觉 SLAM 提供的无累计误差绝对坐标（15~30Hz）完美糅合，输出了极致丝滑且精准的融合轨迹。
“防闪崩”的动态平滑降级： 依托深度定制的动态协方差逻辑，机器人具备了感知环境状态的“自我认知”能力。当面对大面积白墙、反光或遮挡导致视觉“致盲”时，系统会瞬间拉满视觉数据的协方差（拒收视觉坐标），无缝切换至“底盘+IMU”的短时惯性盲走模式，彻底杜绝了由于特征点丢失引发的坐标飞点与导航崩溃。
高鲁棒的底层统一管控： 系统通过EKF夺取了全局odom坐标系的唯一发布权，剔除了极易引发数学爆炸的IMU重力线加速度，并配合50Hz超频的机器人骨架状态同步，从根本上消除了多传感器之间的TF冲突与时间戳插值抖动。

启动流程

#1.启动底盘
cd mybot_ws
source ./devel/setup.bash 
roslaunch robot_bringup robot_bringup.launch 
#2.启动相机
cd mybot_ws
source ./devel/setup.bash 
roslaunch realsense2_camera rs_camera.launch 
#3.启动ORB-SLAM3
cd ORB_SLAM3
source ~/.bashrc
rosrun ORB_SLAM3 Stereo /home/sparks/ORB_SLAM3/Vocabulary/ORBvoc.txt /home/sparks/ORB_SLAM3/Examples/Stereo-Inertial/RealSense_D435i.yaml false
#4.启动EFK
cd mybot_ws
source ./devel/setup.bash 
roslaunch robot_bringup ekf.launch

效果展示

明亮条件下演示gif链接：

https://ibb.co/vCXyjC15

可以看到，在环境光照良好的情况下将机器人悬空，即使通过键盘控制驱动轮转动，Rviz 中的机器人模型依然能停留在原点。在此期间虽然会产生小幅度的位姿波动，但此时主要由 ORB-SLAM3 提供视觉定位，所以系统能够迅速纠正偏移，使模型回到初始位置。

黑暗条件（捂眼）下演示gif链接：

https://ibb.co/93yT6DY8

与之相对可以看到，在黑暗或完全遮挡相机的情况下将机器人悬空，当通过键盘控制驱动轮转动时，Rviz 中的机器人模型便无法停留在原点。在此期间，由于视觉特征丢失导致 ORB-SLAM3 追踪失败，系统的 EKF（扩展卡尔曼滤波）融合算法便失去了高置信度的视觉观测数据。此时的状态估计只能主要依赖底盘里程计的输入，由于缺乏视觉修正，EKF 无法过滤掉车轮空转产生的虚假位移累积，从而导致模型持续偏离初始位置。

以上两个演示表明：在多传感器融合框架下，视觉系统在全局位姿估计中占据着决定性的权重，能够有效抑制和修正底盘里程计固有的滑动和累积误差。EKF 算法在这种观测条件的切换中表现出了符合预期的逻辑机制：在视觉正常时依赖高精度观测进行位姿校正，在极端视觉失效时则平滑退化为依赖里程计进行短时局部推算。这证明了该定位系统在复杂环境下具备较好的鲁棒性。

2025-3-20

博主近期通过深度相机成功建出了3D 八叉树地图，效果如下图所示。

并又在此基础上生成了基于deeplab ResNet-50模型的3D语义地图，为以后跑语义相关算法打下了基础。

启动顺序

### 启动底盘

```bash
cd mybot_ws
source ./devel/setup.bash 
roslaunch robot_bringup robot_bringup.launch 
```

### 启动相机

```bash
cd mybot_ws
source ./devel/setup.bash 
roslaunch realsense2_camera rs_camera.launch 
```

### 启动 Deeplab

```bash
cd mybot_ws
source ./devel/setup.bash 
rosrun yolov8_detection deeplab_detector.py
```

### 启动 ORB-SLAM3

```bash
cd ORB_SLAM3
source ~/.bashrc
rosrun ORB_SLAM3 Stereo /home/sparks/ORB_SLAM3/Vocabulary/ORBvoc.txt /home/sparks/ORB_SLAM3/Examples/Stereo-Inertial/RealSense_D435i.yaml false
```

### 启动 EFK 卡尔曼滤波

```bash
cd mybot_ws
source ./devel/setup.bash 
roslaunch robot_bringup ekf.launch
```

### 启动 2D 建图

```bash
cd mybot_ws
source ./devel/setup.bash 
roslaunch robot_bringup 2d_mapping.launch
```

### 启动 3D 语义建图

```bash
cd mybot_ws
source ./devel/setup.bash 
roslaunch robot_bringup semantic_mapping.launch
```

2025-3-23

博主今天基于explore_lite实现了移动机器人自主探索建图，但是行至狭窄路段机器人可能会原地旋转。这时候可以对base_local_planner_params.yaml文件做出以下调整以改善DWA对于此现象的影响（缩短 DWA 的“远视眼”）。

DWAPlannerROS:
  # ... 其他参数 ...
  sim_time: 1.2         # 🚨 从 1.7 降到 1.2 或 1.5，减轻狭窄空间的远期碰撞恐惧
  sim_granularity: 0.05 # 可以稍微调大一点点(原0.025)，减少算力消耗

也可以尝试修改该文件的如下部分，来保证机器人紧紧咬住全局路径。

DWAPlannerROS:
  # ... 其他参数 ...
  path_distance_bias: 64.0  # 🚨 从 32.0 翻倍到 64.0！强迫它像走钢丝一样贴着全局绿线走
  goal_distance_bias: 20.0  # 适当降低目标权重，不要为了抄近道而撞墙
  occdist_scale: 0.02       # 稍微提高一点对障碍物的警惕(原0.01)，防止它贴墙太近被卡死

还可以修改explore.launch文件中的如下部分，避免机器人钻进死胡同或者太小的缝隙。

<param name="min_frontier_size" value="0.75"/>  #可以修改value的值来进行调整

启动顺序

### 启动底盘

```bash
cd mybot_ws
source ./devel/setup.bash 
roslaunch robot_bringup robot_bringup.launch 
```

### 启动相机

```bash
cd mybot_ws
source ./devel/setup.bash 
roslaunch realsense2_camera rs_camera.launch 
```

### 启动 Deeplab

```bash
cd mybot_ws
source ./devel/setup.bash 
rosrun yolov8_detection deeplab_detector.py
```

### 启动 ORB-SLAM3

```bash
cd ORB_SLAM3
source ~/.bashrc
rosrun ORB_SLAM3 Stereo /home/sparks/ORB_SLAM3/Vocabulary/ORBvoc.txt /home/sparks/ORB_SLAM3/Examples/Stereo-Inertial/RealSense_D435i.yaml false
```

### 启动 EFK 卡尔曼滤波

```bash
cd mybot_ws
source ./devel/setup.bash 
roslaunch robot_bringup ekf.launch
```

### 启动 2D 建图

```bash
cd mybot_ws
source ./devel/setup.bash 
roslaunch robot_bringup 2d_mapping.launch
```

### 启动 3D 语义建图

```bash
cd mybot_ws
source ./devel/setup.bash 
roslaunch robot_bringup semantic_mapping.launch
```

### 启动 move_base

```bash
cd mybot_ws
source ./devel/setup.bash 
roslaunch mbot_navigation move_base.launch
```

### 启动自主建图
```bash
cd mybot_ws
source ./devel/setup.bash 
roslaunch mbot_navigation explore.launch
```

2025-3-25

因为之前查看机器人的STM32源码时发现，源码里没有控制相机云台的程序，所以博主就买了一个RS-485转USB模块来尝试直接将相机云台连接到机载电脑上，直接通过python节点实现控制。如图。

并且在调试过程中出现了以下现象：

一、现象 1：总线收到规律性异常乱码

症状： 使用 Python 脚本以 1 Mbps 波特率轮询 RS-485 节点（ID 1-10），收到长度一致但数据畸变的 FFFF... 乱码响应。
排查： 拔除云台信号线，使 USB-RS485 模块悬空测试，乱码依然存在。
结论： 劣质 CH340+485 模块在 1M 高波特率下存在收发状态切换（DE/RE）延迟，导致其将自身发送的指令残影误认为接收数据。
对策： 评估硬件更换成本后，采用软件规避方案。在发送指令后，强制 read(6) 丢弃固定长度的硬件自身回音缓冲。

二、现象 2：屏蔽回音后总线无响应

症状： 优化脚本后总线无数据返回。
排查过程：
1. 物理探活（失败）： 尝试手动转动云台判断保持扭矩，因重载云台含蜗轮蜗杆自锁机构，断电与通电状态均无法转动，该方法失效。
2. 源码核查（排除软件限幅）： 查阅底盘 STM32 主板 main.c 与 gpio.c，确认不存在控制 24V01 端子输出的引脚配置（使能电源锁），该端口应为常通。
3. 供电链路排查（锁定问题）： 发现底盘物理急停开关处于按下状态，切断了 24V 外设供电回路。
对策： 释放急停开关，恢复云台供电。

三、现象 3：供电正常，发送端有信号但无动作及回复

症状： 急停释放后，运行测试脚本，USB 模块 TXD 闪烁（指令已发出），但 RXD 无响应，云台无动作。
排查过程：
1. 接口核对： 重新检查主板布线，发现云台信号线误接在电源端子旁，主板另配有丝印为 A/B 的标准 RS-485 通讯接口，随即更正接线。
2. 协议覆盖测试： 考虑到重载云台可能采用安防领域的 Pelco-D 单工通讯协议（只接收不应答），编写循环脚本盲发不同 ID 与波特率（2400/4800/9600）的运动指令。测试后云台依然无动作。
3. 电平测试（异常）： 使用万用表测量悬空的黑、灰信号线对地电压，两根线均停留在 1.25V 左右。该电平不符合常规 RS-485 的空闲偏置电压（通常 2~3V），怀疑并非 485 协议（类似 3.3V CAN 总线特性），或存在地电位隔离问题。

四、最终定性：阻抗测试与双重短路

鉴于电平异常，为彻底排除物理层损坏，断电进行万用表阻抗测试。

测试方法： 底盘总电源断电，万用表调至电阻档，测量黑灰两根信号线之间的阻抗。
测试结果： 阻抗为 0 欧姆。
交叉验证： 拔下云台本体端的 JST 插头，实施物理隔离测试。
- 测量底盘内部走线的线缆悬空端：0 欧姆。
- 测量云台本体通讯板输入针脚：0 欧姆。
故障根因定性：
1. 底盘内部布线存在机械挤压或磨损，导致线缆皮破损，信号线与 24V 动力线发生短路。
2. 在通电瞬间，24V 高压顺着信号线灌入云台内部，超出通讯芯片（如 MAX485 或 CAN 收发器）的耐压极限，导致芯片输入端直接击穿熔毁，形成永久性内部短路。

五、后续处理与经验总结

硬件处置： 废弃并更换底盘内部该段受损线缆。云台本体需拆解，使用热风枪更换被击穿的通讯收发芯片，或整体更换通讯板。
排障 SOP 优化：
- 万用表先行： 当软件端穷举无效时，应尽早介入万用表测试。断电测信号线间阻抗（查短路/终端电阻），带电测悬空电压（查电平特征/芯片死活）。
- 不可轻信工具： 工业现场应尽量配备带隔离的工业级 USB 通讯模块，避免廉价模块的收发延迟干扰排障方向。
- 警惕物理损伤： 凡涉机电联动的设备，排障时必须考虑机械运动对线束造成的隐性物理破坏。