1. 课程导论与系统架构：激光雷达工作原理、运动控制基础、系统集成全景图
各位同学，欢迎来到《激光雷达与运动控制集成开发实战》的第一章。
我是这门课的主讲。做了十几年机器人系统集成，踩过的坑比写过的代码还多。今天咱们不聊虚的，直接切入正题——这门课到底要学什么？你学完之后能干什么？
说白了，这门课就是教你怎么让机器人“看见”并“动起来”。激光雷达是眼睛，运动控制是手脚。把它们连起来，就是一套完整的智能机器人系统。
1.1 激光雷达工作原理：机器人如何“看见”世界
激光雷达，英文叫 LiDAR。它的核心原理其实很简单：发射激光，测量反射回来的时间，算出距离。嗯，就是“激光测距仪”的升级版。
我最早接触激光雷达是在2015年，那时候一个单线雷达要两万多。现在？几百块就能买到不错的国产货。技术迭代真的快。
1.1.1 核心测量原理
激光雷达主要用两种测距方式：
- TOF（飞行时间法）：直接测量激光脉冲发射和接收的时间差。精度高，抗干扰强，但成本也高。
- 三角测距法：利用激光发射点和接收点之间的几何三角关系计算距离。成本低，近距离精度不错，远距离就吃力了。
关键参数对比
| 参数 | TOF 激光雷达 | 三角测距激光雷达 |
|---|---|---|
| 测距范围 | 10m - 200m+ | 0.1m - 10m |
| 精度 | ±2cm | ±1cm（近距离） |
| 抗环境光 | 强 | 弱 |
| 成本 | 高 | 低 |
| 典型应用 | 自动驾驶、AGV | 扫地机器人、室内导航 |
我个人习惯，做室外项目首选 TOF，室内小场景用三角测距就够了。别为了省钱选错方案，后期调试会让你崩溃。
1.1.2 数据输出与坐标系
激光雷达输出的原始数据，通常是一组极坐标点：(角度, 距离)。你需要把它转换成笛卡尔坐标系下的 (x, y) 坐标。
// 极坐标转笛卡尔坐标示例
float angle_rad = angle_deg * M_PI / 180.0;
float x = distance * cos(angle_rad);
float y = distance * sin(angle_rad);这里有个坑——雷达的安装位置。我曾经在一个项目里，直接把雷达数据拿来用，结果机器人一直撞墙。后来才发现，雷达坐标系和机器人基坐标系没对齐。你想想看，雷达装在车头左侧，它测到的“前方”其实是机器人的左前方。这个偏移量必须标定掉。
避坑指南：拿到雷达数据后，第一件事不是做算法，而是确认坐标系变换矩阵。我曾经因为忽略这一步，浪费了整整两天时间排查定位偏差。
1.2 运动控制基础：机器人如何“动起来”
运动控制，说白了就是让电机按照你想要的轨迹转起来。但实际做起来，远没这么简单。
1.2.1 运动控制的核心要素
一个完整的运动控制系统，包含三个层次：
- 执行层：电机、驱动器、编码器。负责把电信号变成机械运动。
- 控制层：运动控制器（MCU、PLC、专用运动控制卡）。负责计算控制指令。
- 规划层：上位机或主控。负责生成运动轨迹和速度曲线。
我见过很多新手，一上来就调 PID 参数。其实大部分问题出在底层——电机选型不对、驱动器配置错误、编码器接线松动。基础不牢，地动山摇。
1.2.2 常见的运动控制模型
对于轮式机器人，最常用的是差速驱动模型。两个独立驱动的轮子，通过转速差实现转向。
// 差速模型正运动学：由轮速计算机器人速度
float v = (wheel_speed_left + wheel_speed_right) / 2.0;
float omega = (wheel_speed_right - wheel_speed_left) / wheel_base;这个公式看起来简单，但实际用起来要注意单位。我习惯把轮速统一成 m/s，轮距用米，角速度用 rad/s。别混用，否则你会得到一堆莫名其妙的数据。
注意：运动控制中的“死区”问题。电机在低速时可能不转，或者转得不均匀。我曾经在调试一个精密对位平台时，因为没处理死区，导致定位精度始终达不到要求。解决方案是加一个“最小启动占空比”，或者用 dither 信号抖动一下。
1.3 系统集成全景图：从传感器到执行器
好了，现在我们把激光雷达和运动控制放在一起。这就是系统集成要做的事。
1.3.1 系统架构总览
一个典型的激光雷达+运动控制集成系统，包含以下模块：
- 感知层：激光雷达、IMU、里程计。负责采集环境数据。
- 处理层：主控（通常是 ARM 或 x86 工控机）。负责数据融合、建图、定位、路径规划。
- 控制层：运动控制器。负责执行轨迹跟踪、速度控制。
- 执行层：电机、舵机、驱动轮。负责物理运动。
下面这张图，是我自己总结的系统集成架构。你看一眼，就能明白整个数据流是怎么走的。
1.3.2 数据流与通信
系统里各个模块之间怎么通信？这是集成开发的核心问题。
- 激光雷达 → 主控：通常用以太网（UDP/TCP）或串口。数据量大时用 UDP，可靠性要求高时用 TCP。
- 主控 → 运动控制器：常用串口（RS232/RS485）、CAN 总线或 EtherCAT。工业场景首选 EtherCAT，实时性好。
- 运动控制器 → 电机驱动器：PWM + 方向信号，或者步进/伺服脉冲。
我建议你一开始就把通信协议定死。别今天用 JSON，明天换 Protobuf，后天又改自定义二进制。我在一个项目里吃过这个亏——三个工程师各写各的，联调时发现数据格式对不上，改了一周。
我的习惯：所有模块之间的通信，统一用结构体 + 校验和。简单、可靠、好调试。别整那些花里胡哨的序列化框架，嵌入式系统资源有限，稳定第一。
1.3.3 时间同步问题
激光雷达的数据有时间戳，运动控制器的数据也有时间戳。但这两个时间戳可能来自不同的时钟源。如果不做同步，你拿到的“当前”雷达数据和“当前”里程计数据，可能差了 50ms。对于高速运动的机器人，50ms 的误差足以让定位结果完全不可用。
解决办法？要么用硬件同步（PPS 信号），要么用软件同步（ROS 的 TF 树 + 时间戳插值）。我个人倾向硬件同步，精度高，省心。
警告：千万不要假设两个设备的时间戳是同步的。我曾经在一个 AGV 项目里，雷达和工控机的时间差了 200ms，导致建图出现重影。排查了三天才发现是时间同步的问题。从那以后，我每个项目的第一件事就是检查时间同步。
1.4 本章小结
这一章，我们聊了三个核心问题：
- 激光雷达怎么“看见”世界——TOF 和三角测距的原理，以及坐标系变换的重要性。
- 运动控制怎么“动起来”——差速模型、控制层次、死区处理。
- 系统集成怎么“连起来”——架构图、数据流、时间同步。
这些都是后面所有章节的基础。你把这些搞明白了，后面的建图、定位、路径规划、运动控制算法，学起来会轻松很多。
嗯，第一章就到这儿。记住，做机器人系统集成，别急着写代码。先把架构理清楚，把通信协议定好，把坐标系标定好。这些基础工作做好了，后面的开发就是水到渠成的事。