第4章客户端日志分析

4、客户端日志分析：客户端连接日志、Actor生成与销毁日志、控制命令日志、传感器订阅日志

大家好，我是你们的老朋友。今天咱们来聊聊客户端日志分析。说实话，很多人在Carla里跑仿真，出了问题第一反应就是去翻服务端日志，却忽略了客户端日志这个宝藏。我个人习惯是，遇到诡异问题，先看客户端日志，往往能快速定位到七八成的问题。

客户端日志，说白了就是记录你写的Python脚本和Carla服务器之间“对话”的流水账。它包含了连接建立、Actor的出生与死亡、你发的控制指令、以及传感器数据的订阅情况。把这些日志读懂了，你就能知道仿真过程中到底发生了什么。

每次你运行脚本，第一件事就是连接服务器。连接日志会记录下这个“握手”过程是否顺利。

核心日志内容：

举个例子，你可能会看到这样的日志：

尝试连接服务器 127.0.0.1:2000...
连接成功！服务器版本: 0.9.13

嗯，这里要注意。如果连接失败，日志里会直接报错。比如：

连接超时：无法连接到 127.0.0.1:2000

为什么会这样？最常见的原因就是服务器没启动，或者端口写错了。我曾经有一次排查了半天，最后发现是手抖把端口写成了2001，你说冤不冤？

我的小技巧： 建议在脚本里加个重试机制。连接失败后等几秒再试一次，能避免很多因为服务器启动慢导致的偶发问题。

Actor就是仿真世界里的各种实体，比如车辆、行人、传感器。它们的生成和销毁，日志里都会记录得清清楚楚。

生成Actor时，日志会包含：

销毁Actor时，日志会记录：

看个例子：

生成 Actor: vehicle.tesla.model3, ID: 123, 位置: (100.0, 50.0, 0.0)
销毁 Actor: ID: 123, 原因: 用户请求销毁

避坑指南： 我曾经遇到过一个问题，Actor生成后没几秒就自动销毁了。查日志发现是生成位置和另一个Actor重叠了，触发了碰撞销毁。所以，生成Actor时一定要检查位置是否合理。

另外，如果你发现Actor数量一直在增长，但日志里没有对应的销毁记录，那八成是内存泄漏了。你的脚本里肯定有地方忘了调用 destroy()。

控制命令日志，记录了你通过脚本发给Actor的每一个控制指令。比如油门、刹车、转向、换挡等等。

日志内容通常包括：

举个例子：

发送控制命令: Actor ID: 123, 类型: VehicleControl, 油门: 0.8, 刹车: 0.0, 转向: 0.1

你想想看，如果车不动，第一反应是不是去查控制命令日志？看看指令到底发出去没有。我遇到过好几次，脚本逻辑写错了，油门一直给的是0，车当然不会动。日志一看就明白了。

我的习惯： 调试阶段，我会把控制命令的日志级别调到DEBUG，这样每个指令都能看到。等上线了再调回INFO，避免日志刷屏。

传感器是自动驾驶的“眼睛”。订阅日志会告诉你，传感器是否成功挂载到了Actor上，以及数据是否在正常传输。

关键信息包括：

看日志：

订阅传感器: sensor.camera.rgb, 挂载到 Actor ID: 123, 状态: 成功
接收传感器数据: sensor.camera.rgb, 帧率: 30 FPS

如果订阅失败，日志会给出原因。比如：

订阅传感器失败: 传感器类型 sensor.camera.depth 不存在

嗯，这里要注意。传感器类型名一定要写对，大小写敏感。我曾经因为把 sensor.camera.rgb 写成了 sensor.camera.RGB，折腾了半小时。

重要提醒： 如果你发现传感器数据频率远低于预期，比如只有5 FPS，那可能是CPU或GPU性能不够。这时候别急着优化代码，先看看是不是仿真环境负载太高了。

好了，关于客户端日志的四个核心部分，咱们就聊到这儿。说白了，这些日志就是你和Carla服务器之间的“聊天记录”。读懂了它们，你就能知道仿真过程中每一步发生了什么，问题出在哪里。下一章，咱们会深入聊聊服务端日志，看看服务器那边又藏着哪些秘密。