爬一手好线杆我很早之前就一直在写无人机仿真相关的项目，从最初的单线程版本一路迭代过来，到V2.0的时候终于把多线程这套体系完整落地。这篇文章我就以“智能仿真无人机平台（多线程V2.0）”为背景，详细讲讲在开发无人机自动防空平台时，多线程架构是怎么设计的，线程之间怎么协作，数据怎么同步，以及我在实操过程中踩过的坑和最终的解决方案。整个内容围绕“线程进阶”这条主线展开，适合已经掌握了基础线程概念、想在仿真类项目中真正用好多线程的开发者阅读，也欢迎初学者把它当作一份带代码的实践教程来参考。
1. 为什么自动防空仿真平台必须多线程
1.1 业务场景拆解：防空平台都在跑什么
无人机自动防空平台，核心任务说起来并不复杂：探测到目标、判断威胁、生成拦截策略、控制拦截弹发射并命中目标。但一旦放到仿真环境里，情况就完全不一样了。仿真不是只算一个结果，而是要同时模拟多个对象在时间轴上的连续状态变化。
我举个具体的例子，假设场景里有4架来袭无人机、2个地面防空阵地、每套阵地配3枚待发射拦截弹。系统每一帧需要更新以下内容：
- 无人机的位置、速度、姿态，这部分由动力学模型实时解算，涉及坐标变换和欧拉角积分；
- 雷达探测模型，包括扫描周期、探测概率、噪声干扰、目标丢失和重新捕获逻辑；
- 威胁评估逻辑，要计算每架无人机对地面目标的威胁等级，这涉及距离、速度、航向角、历史轨迹等多个参数；
- 拦截决策与制导模型，要根据威胁等级决定是否发射拦截弹、发射几枚、采用什么制导律；
- 通信链路模拟，包括指令上行、遥测下行、时延和数据丢包；
- 界面显示，也就是把以上所有数据实时绘制到屏幕上，包括2D地图、3D视图和数据仪表盘。
如果你在一个线程里按顺序执行以上所有任务，性能瓶颈会非常明显。尤其是界面渲染和物理计算之间会互相拖后腿，一帧卡顿，整个仿真时间轴都会抖动。
1.2 单线程版本的“卡脖子”点在哪里
我在V1.0版本里就是单线程顺序处理所有逻辑。一开始的目标只是跑通业务闭环，确实也跑通了：一个场景下来，整个流程没有问题，逻辑也正确。但问题出在实时性和扩展性上。
单线程最大的痛苦是：任何一个子模块出现耗时波动，都会影响全局节奏。例如，雷达信号模拟里如果加入了更精细的噪声模型，算法复杂度上去了，单帧计算时间就从几毫秒涨到几十毫秒，这时候整个仿真的帧率会瞬间跌到20fps以下。而无人机飞行动力学模型如果改用更小步长的积分器，计算量又增加了。所有任务共用同一个执行时间线，彼此抢占CPU资源，最后的结果就是“谁都没跑好”。
我当时的实测数据是：单线程4架无人机加2个阵地，逻辑帧率在30fps左右，但一旦开启完整3D渲染，帧率立刻跌到18fps，操作界面肉眼可见地卡顿。对于仿真平台来说，这不仅仅是体验问题，更严重的是时间步长不稳定会导致仿真结果的可信度下降。同一个场景跑两次，结果差异很大，因为每一次各模块的执行间隔都不一样。
1.3 V2.0多线程重构的核心目标
V2.0重构时，我给自己定了几个非常明确的目标，这些目标也是后面所有设计决策的出发点：
第一，逻辑计算和界面渲染必须分离。不能让OpenGL或者图形引擎的绘制耗时拖累仿真逻辑的推进，也不能让物理计算阻塞界面操作响应。
第二，高频模块和低频模块分开。无人机的动力学模型需要尽量高的更新频率来保证数值稳定性，而威胁评估、路径规划这类决策模块不需要每帧都跑，可以以一个较低的频率异步执行。
第三，支持多架无人机并行仿真。每一架无人机理论上可以拥有独立的计算任务，从而利用多核CPU的优势。V2.0要求的是至少支持8架目标同时仿真而不掉帧。
第四，系统必须可扩展。以后想加入新的传感器模型、新的拦截武器模型，不应该改动整体线程框架。
基于这四点，我把平台从“一个大循环”彻底重构为“多个协作线程”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 线程模型整体设计：四个线程各司其职
2.1 V2.0的线程划分总览
我在V2.0里采用了“四线程+线程池”的混合结构。四个常驻线程分别是：主逻辑线程、渲染线程、雷达与通信IO线程、决策计算线程。另外还有一个线程池，专门用来并行解算无人机动力学模型。
这个结构不是拍脑袋决定的，而是经过一个很简单的性能分析得出来的。我把V1.0单线程里每个模块的耗时单独统计，得到了一组数据：
| 模块 | 平均耗时(ms) | 频率要求 | 是否可异步 |
|---|---|---|---|
| 无人机动力学积分 | 2.5 | 尽量高 | 可并行 |
| 雷达探测与噪声模拟 | 1.5 | 中 | 可异步 |
| 威胁评估与拦截决策 | 3.0 | 低 | 必须最新数据 |
| 通信链路模拟 | 0.5 | 低 | 可异步 |
| 界面渲染 | 8.0 | 60fps | 必须独立 |
很明显，渲染和逻辑计算是两块最大的耗时源，必须拆开。动力学积分虽然单次耗时不高，但架不住频率要求高，所以适合并行化。决策模块虽然耗时高，但在一个仿真场景里，决策不需要每帧都重新计算，设置成每10帧刷新一次即可。
2.2 主逻辑线程：整个系统的时钟源
主逻辑线程是整个平台的核心调度者，它负责维护系统时间，也就是仿真时钟。我的设计是主逻辑线程固定以50Hz的频率推进一个全局仿真时间片，每一个时间片代表0.02秒的仿真时间，这就是整个系统的时间基准。
主逻辑线程在每一个时间片内做的事情包括：获取来自雷达线程的最新目标列表、检查决策线程是否产出了新的拦截指令、读取线程池中已经计算完成的动力学结果，然后把所有数据统一封装成一个不可变的“世界状态”快照，推送给渲染线程。
这里有一个很重要的设计思想：主逻辑线程不负责具体计算，它只负责“协调和汇总”。这样做的好处是，主逻辑线程的逻辑非常简单，几乎不会出bug，也不会有复杂的锁竞争。它就像一个乐队指挥，自己不演奏乐器，但负责让所有乐手节奏对齐。
2.3 渲染线程：只管画，决不计算
渲染线程是最纯粹的，它只做一件事：读取最新的世界状态快照，然后绘制场景。我用的底层是OpenGL，配合一个轻量级的UI框架，但不管你用什么渲染库，原理都是一样的。
渲染线程和主逻辑线程之间通过“帧数据缓冲”交互。我用了双缓冲机制：前端缓冲用于渲染，后端缓冲用于写入新数据。主逻辑线程每完成一次世界状态更新，就把新数据写入后端缓冲，然后交换指针。渲染线程只读取当前的前端缓冲，不直接接触正在被写入的数据。
这个双缓冲机制可以用一个生活化的例子来理解：咖啡店出杯窗口。后厨做好咖啡放进窗口，客人从窗口取走。后厨不会把咖啡直接塞到客人手里，客人也不会跑到后厨去抢。窗口是唯一交接点，两边各干各的。
2.4 雷达通信IO线程与决策计算线程
雷达与通信IO线程负责模拟传感器探测和通信链路。这个线程的特点是有明显的“间歇性阻塞”，比如模拟一个雷达扫描周期时，就得让线程睡上一段时间，等下一个波束扫描周期开始再继续。
我原本考虑过直接用主逻辑线程做雷达模拟，后来发现不行，因为“扫描等待”完全是浪费CPU时间。放在单独线程里，就可以利用条件变量实现事件驱动：扫描周期到了就唤醒工作，没有新目标时就让线程进入休眠状态。
决策计算线程是四个线程里计算密度最高的。威胁评估要用到目标距离、速度、航向、高度、雷达截面积等多维数据，还要跑一个简单的灰色关联分析算法来综合打分。这部分计算对数据实时性要求高，但又不需要每帧都做。我用了一个“按需触发”机制——主逻辑线程每隔N个时间片发一个“请重新评估”的事件信号，决策线程收到信号后基于最新的目标数据开始计算。
2.5 线程池：并行解算无人机的动力学模型
线程池是V2.0里性能提升最明显的一块。它的作用是并行计算所有参演无人机的动力学模型。
每一架无人机的动力学模型是完全独立的，它们之间的耦合只通过“领航指令”或“编队约束”实现，而那个约束不是每帧都要强制同步的。既然相互独立，就可以放进线程池并行计算。
我用的线程池大小是CPU物理核心数减一，在我那台8核机器上就是7个工作线程。每次需要更新无人机动力学时，主逻辑线程把8架无人机的状态参数打包成独立任务，塞进线程池的调度队列，线程池自动分配到空闲线程上执行。
实测下来，8架无人机并行解算只需要大约3毫秒，比单线程顺序解算的20毫秒足足缩短了6倍多，效果立竿见影。
3. 线程间同步与数据共享实战
3.1 锁的选择：互斥锁、读写锁和原子变量的适用场景
多线程开发绕不开同步问题。V2.0里我用到了三类同步原语，各自的适用场景完全不同，初学者特别容易混。
互斥锁适用于临界区比较短、写操作频繁的场景。我的消息队列就用了互斥锁，因为队列入队和出队都很频繁，而且操作时间极短，用互斥锁最合适。
读写锁适用于“读多写少”的场景。比如目标列表，雷达线程不断写入新的探测结果，但主逻辑线程、决策线程、渲染线程全都在读。如果直接用互斥锁，读操作之间也会互相阻塞，白白浪费并行能力。读写锁允许多个读线程同时持有，只有写操作才会独占。实际使用下来，目标列表的读取效率提升了近3倍。
原子变量适用于更简单的场景。比如一个线程计数器，记录当前已经完成的动力学任务数量，多个工作线程共同递增。用std::atomic
最需要谨慎的是：千万不要为了炫技而无脑使用原子变量实现复杂的数据结构。原子变量只适合“单个数值”的简单操作，如果你试图用原子变量去维护一个链表的多个指针，那就是自找麻烦。我一开始就在一个环形缓冲区上尝试用无锁方式实现，结果各种内存顺序问题调试到怀疑人生，最后还是换回了互斥锁。
3.2 线程安全的消息队列：生产者和消费者的桥梁
在线程通信层面，我的选择非常传统但很稳妥：用std::queue加上互斥锁和条件变量，实现一个线程安全的消息队列。虽然这个概念在面试题里被问烂了，但在真实项目中仍然是最实用、最好维护的方案。
消息队列的接口很简单，一共就四个方法，push、pop、tryPop、empty。核心细节在于pop方法的设计。我的实现是，pop会先锁定互斥锁，然后判断队列是否为空，如果为空就调用条件变量的wait方法进入等待状态，直到其他线程调用notify唤醒。为了防止虚假唤醒，我用了while循环来判断条件，而不是if。
这里有个容易踩的坑：消息队列里存的内容不能是原始对象引用，因为对象可能被其他线程修改。我统一用std::shared_ptr
3.3 环形缓冲区：高性能渲染数据交接
渲染数据的交接我用了环形缓冲区，这个模块的性能要求比通用消息队列高得多。因为是图形渲染，数据是一帧一帧连续产生的，每一帧的数据量又固定，天然适合用固定大小的环状数组。
我的环形缓冲区设计是：固定16个槽位，每个槽位存一份世界状态快照。主逻辑线程每50Hz写入一个新快照，渲染线程以显示器的刷新率读取最新快照。
这里要注意一个问题：主逻辑线程频率是50Hz，而显示器刷新率往往是60Hz甚至更高。如果渲染线程跑得比逻辑线程快，它读到的快照可能是旧的。我的解决办法是，在渲染线程里不追求每一帧都拿到新数据，而是拿到“当前最新的快照”，即使两次渲染之间数据没有变化，也只是视觉上的重复，不会导致逻辑错误。
更有意思的是，环形缓冲区还要保证一个关键规则：写入者永远不覆盖尚未被读取的最新槽位。如果渲染线程处理得慢，主逻辑线程已经写满了所有槽位，那就必须有两种选择：要么阻塞等待渲染线程消费，要么丢弃旧数据。我选择了丢弃旧数据，因为对于一个仿真平台来说，更倾向于“最新的状态”，而不是“补全每一帧”。
3.4 条件变量的使用细节：为什么while循环比if安全得多
如果你想真正理解多线程同步，条件变量这一关必须过。条件变量用于实现线程间的“事件通知”机制，比如雷达扫描完成、决策线程计算完毕、线程池任务清空，这类事件用轮询不是不行，但浪费CPU，用条件变量才能做到“事件来了才醒来”。
我在条件变量上踩过的最典型的一个坑是虚假唤醒。线程被唤醒之后，并不代表条件一定满足。可能是操作系统信号干扰，也可能是其他线程先行消费了资源。如果使用if判断条件，线程可能继续执行一个不应该执行的操作。正确的写法是while循环判断条件，不满足就继续等待。
还有一个使用细节：在调用条件变量的notify方法时，不一定需要持有锁。理论上，先解锁再notify可以减少唤醒线程的锁竞争。但实际测试下来，在std::condition_variable的前提下，先解锁再notify和先notify再解锁的性能差异微乎其微，不用过于纠结。
我真正想说的是，条件变量背后有一个很容易被忽略的代价：线程被唤醒后，即使条件已经满足，它仍然需要和其他线程一起竞争一把互斥锁。这个竞争在高并发情况下可能成为性能瓶颈。如果条件变量的使用频率非常高，可以考虑用状态标志位加自旋锁替代。
4. 实操：用一个具体场景演示多线程防空流程
4.1 场景定义与参数设置
为了让你能直观地看到多线程的协作过程，我设计了一个具体的仿真场景，这也是V2.0版本的典型用例。场景设定如下：
- 4架来袭无人机从不同方向飞向地面指挥中心；
- 地面部署了1套雷达阵列和2个拦截弹发射阵地；
- 每个阵地有6枚拦截弹，每枚拦截弹最多拦截一个目标；
- 仿真时间长度120秒；
- 逻辑线程频率50Hz，渲染线程通过交换缓冲方式独立运行。
在这个场景里，无人机以不同的速度和高度突防，雷达线程负责在覆盖范围内发现目标并更新目标状态，决策线程每隔10帧重新计算威胁等级和拦截优先级，主逻辑线程根据决策结果生成拦截指令，并监控拦截弹的命中结果。
4.2 线程协作的主循环代码演示
我下面给出一个简化但结构完整的关键代码演示，你可以直接拿来作为参考。这是主逻辑线程的核心循环。
cpp复制void MainLogicThread::run()
{
auto lastTime = std::chrono::steady_clock::now();
while (m_running) {
auto currentTime = std::chrono::steady_clock::now();
double elapsed = std::chrono::duration<double>(currentTime - lastTime).count();
if (elapsed >= m_timeStep) {
lastTime = currentTime;
// 1. 从雷达线程获取最新目标列表
auto targets = m_radarQueue.popAll();
m_worldState.setTargets(targets);
// 2. 通过线程池并行计算所有无人机的新状态
m_threadPool.enqueue([this]{
m_dynamicsCalculator.computeAll(m_worldState.getTargets());
});
m_threadPool.waitAll();
// 3. 检查决策线程是否有新的拦截指令
auto order = m_decisionQueue.tryPop();
if (order) {
m_worldState.setInterceptOrder(*order);
}
// 4. 将世界状态推送到渲染缓冲区
m_renderRingBuffer.push(m_worldState.snapshot());
}
// 让出CPU时间片，避免忙等
std::this_thread::sleep_for(std::chrono::microseconds(100));
}
}
这段代码里面最关键的两行是线程池任务的提交和等待。每帧结束前都必须确保动力学计算完成，否则下一帧的数据就会用上一帧的结果，时间轴就乱套了。
4.3 雷达线程与决策线程的协作逻辑
雷达线程的代码相对独立，它的主要任务是周期性更新目标列表。我使用了一个500ms的扫描周期，也就意味着每秒钟更新2次目标数据。这个频率在防空场景里已经足够了，因为雷达探测本来就不需要跟着逻辑线程的50Hz一起跑。
cpp复制void RadarThread::run()
{
while (m_running) {
// 模拟雷达波束扫描
std::this_thread::sleep_for(std::chrono::milliseconds(500));
auto detectedTargets = m_radarModel.scan(m_worldState.getTargets());
// 更新到雷达队列，等待主逻辑线程取走
m_radarQueue.push(detectedTargets);
}
}
决策线程的工作方式则是事件驱动。主逻辑线程每10帧发一个“评估请求”事件，决策线程收到后开始计算威胁排序和拦截策略。
cpp复制void DecisionThread::run()
{
while (m_running) {
m_evalRequest.wait(); // 等待评估请求
auto targets = m_worldState.getTargets();
auto threats = m_threatEvaluator.evaluate(targets);
auto order = m_interceptPlanner.plan(threats);
m_decisionQueue.push(order);
}
}
4.4 并发数据更新的安全性保障
上面的代码里，世界状态m_worldState是一个全局共享对象，多个线程都会去读写它。为了保证安全，我在世界状态的get和set方法上都加了读写锁。比如setTargets使用独占锁，getTargets使用共享锁。
读写锁在这里特别合适，原因是多线程之间“读多写少”。决策线程需要读取目标数据，雷达线程需要写入目标数据，渲染线程需要读取快照数据。如果不加区分地全部使用互斥锁，读操作之间的并发优势就会被浪费。
另一个安全措施是，所有跨线程传递的数据都以“值拷贝”或“共享只读指针”的形式传递，绝不传递可变引用。也就是说，一旦把目标数据pack成快照传给渲染线程，渲染线程就只能读取，不能修改。如果渲染线程需要做视角变换或者图层筛选，它必须自己拷贝一份数据。
这个规矩我强烈建议你也遵守，因为它把“数据竞争”从设计层面直接杜绝了，而不是依赖锁去兜底。每当别人问我多线程项目里最容易出永远也查不到的bug的地方，我都会说：数据竞争，而且数据竞争里最难查的就是那种“看起来锁都加了但还是偶尔崩溃”的情况，根因几乎都是因为某个地方把可变引用传了出去。
5. 常见的多线程问题与排查经验
5.1 数据竞争：用ThreadSanitizer一把拦住
V2.0开发早期，我的代码仍然存在数据竞争问题，最典型的症状就是程序偶尔崩溃，崩溃位置完全不固定，而且加了很多日志都找不到原因。
后来我学乖了，直接在编译时开启了ThreadSanitizer。在Linux环境下，这是最强大的线程错误检测工具之一。你只需要在编译时加上-fsanitize=thread选项，运行时就自动开始检测数据竞争。
它的基本使用方式是这样的：
bash复制g++ -fsanitize=thread -g -O1 -o sim sim.cpp
./sim
一旦有数据竞争发生，ThreadSanitizer会在终端输出很详细的报告，包括是哪些线程间发生的冲突、对应的代码行号和调用栈。我当时抓到过的最典型的一个问题：在渲染线程里直接读取了主逻辑线程正在更新的目标状态数组。从代码逻辑上看，渲染只是“读一下”，但主逻辑线程可能在“重写整个数组”，读操作就可能读到一半数据。
修复方式就是改成正儿八经的快照机制。从此之后，我养成了一个习惯：涉及多线程的代码，每完成一个里程碑，就用ThreadSanitizer完整跑一遍所有场景测试，确保它报告零问题才认为这一步完成。
5.2 死锁：在线程转储里看到四个线程互相等待
死锁是另一个经常遇到的问题，尤其是当你开始使用多个锁的时候。我的第一个死锁案例发生在雷达线程和主逻辑线程之间，两个线程分别持有不同的锁，然后尝试申请对方的锁，产生了循环等待。
这个死锁的排查过程我印象非常深。程序运行到某个场景下就完全卡住，敲键盘无响应，只能强制结束进程。我当时先查看了进程的线程栈，在Linux下用gdb附加进这个进程，然后输入thread apply all bt命令，把当前所有线程的调用栈全部打出来，一眼就看到了两个线程都停在lock()调用上，互不相让。
从根因上分析，这个问题的本质是我破坏了锁的加锁顺序。雷达线程先加锁A再加锁B，主逻辑线程先加锁B再加锁A，形成了循环等待。
修复方式很简单，我约定了一条全局规则：任何线程如果需要同时获取多个锁，必须严格按照固定的顺序来获取。那之后我再也没有遇到过程序级死锁问题。
5.3 界面卡顿：UI线程被非UI操作阻塞
如果你用Qt或者任何其他GUI框架做界面，那么界面卡顿几乎是最影响体验的问题。V2.0早期，我把威胁评估的计算放在了UI线程的事件回调里，结果就是每进行一次威胁评估，界面就会卡顿几百毫秒。
排查这类问题比较直接。我先把界面线程的每秒刷新次数统计出来，然后用一个异步分析工具记录每帧的耗时来源。从时间线弹窗里可以明显看到，每次威胁评估开始的时候，渲染帧率就出现一个断崖式下跌。
解决方案就是把所有耗时计算全部移出UI线程。决策计算放到了决策线程上，UI线程只负责订阅计算结果。界面上再加一个小标签显示“正在评估威胁等级”或“已更新拦截方案”，用户操作完全不会被阻塞。
5.4 线程数量设定：盲目追求多线程反而更慢
关于线程数量，我见过不少初学者一上来就创建50个线程，以为线程越多越好。但实际上，线程太多会带来大量的上下文切换开销，CPU都在忙着切换线程，真正干活的时间反而变少了。
我做过一组对比实验：在8核CPU上运行同一个8无人机仿真场景，分别使用1个、4个、8个、16个动力学计算线程。结果是：
- 1个线程：总计算耗时约22ms；
- 4个线程：总计算耗时约8ms；
- 8个线程：总计算耗时约4.5ms；
- 16个线程：总计算耗时约5ms。
看到没有，线程数超过CPU核心数之后，性能不但没提升，反而因为过度切换而开始下降。所以我现在设置线程池大小的原则是：不要超过CPU物理核心数，通常设置为核心数减一，留出一个核心给主逻辑线程和其他基础操作。
6. 性能优化与后续扩展方向
6.1 实测数据对比：V1.0与V2.0的性能提升
前面说了这么多理论和实操，最后用数据来收个尾。我在同一台测试机器上，用完全相同的场景参数，分别运行V1.0单线程版本和V2.0多线程版本，得到了一组对比数据：
| 性能指标 | V1.0单线程 | V2.0多线程 | 提升幅度 |
|---|---|---|---|
| 逻辑帧率 | 30fps | 50fps | 提升67% |
| 8架无人机动力学总耗时 | 20ms | 3ms | 提升85% |
| 渲染线程帧率 | 18fps | 55fps | 提升200% |
| 同时对抗目标数量 | 4架 | 8架 | 提升100% |
| 操作响应延迟 | 500ms | 50ms | 提升90% |
这组数据基本印证了多线程重构的价值。尤其是动力学计算从20毫秒降到3毫秒，释放出的CPU时间片可以支撑更多复杂的模型算法，比如更精细的雷达干扰模型、更智能的突防策略。
6.2 当前阶段的优化心得分享
在整个V2.0开发过程中，我自己最大的几个心得分别是：
第一，先把单线程版本跑通，再来做多线程，这是铁律。如果业务逻辑在单线程下就是错的，那多线程只会让错得更复杂，排查难度翻倍。
第二，用共享锁代替互斥锁做读多写少的场景。这个优化改动量极小，但收益非常明显。
第三，数据快照思想贯穿始终。任何跨线程的数据传递，都以不可变快照为最小单位，杜绝共享可变指针。
第四，用ThreadSanitizer做常态化的线程安全监控，而不是等到线上出bug再排查。我把这句写进了代码仓库的README，团队里所有人都能看见。
6.3 V3.0我们可以期待什么
如果你看完这篇，也想把你的仿真平台改造为多线程架构，那我可以给你几个后续扩展的方向：
一是引入任务优先级调度，让紧急的拦截决策能够抢占低优先级任务的线程资源。
二是把渲染线程迁移到基于GPU的渲染引擎，比如Vulkan，进一步释放CPU资源。
三是加入跨进程乃至跨机器的分布式仿真能力。多线程解决的是单机多核利用问题，而分布式仿真可以解决多台机器协同仿真的问题，比如雷达仿真跑在一台机器上，无人机群仿真跑在另外几台机器上，用网络协议或消息中间件做数据传输。
在我看来，整个V2.0版本最大的收获不是代码本身，而是让我真正理解了线程之间“分工和协作”的关系。仿真平台是一个天然的并行任务集合体，只要把任务边界划清楚、同步机制设计到位，多线程带来的性能提升是超乎预期的。希望这篇笔记对你也有帮助，不管你是准备做无人机仿真、机器人仿真还是其他实时系统，这套思路都可以直接借鉴。