自动驾驶仿真器CARLA_0.9.12安装、使用及存在的问题
作者：互联网
目录
简介
作为自动驾驶两大开源仿真器（LGSVL、CARLA）之一，CARLA基本具备了自动驾驶仿真器需要具备的大部分功能，诸如完整的车辆运动系统、地图系统、各类常规传感器、天气系统等等，并且其基于UE4开发，在仿真效果真实性上是LGSVL不能比拟的，因此其还有很大的一个用途是可以通过其采集各类数据用于神经网络训练，CARLA可以直接输出各类数据及其真值，大大减少了训练成本。
安装
CARLA分为服务器端与客户端，需要分别安装。
服务器端
在CARLA官网直接下载仿真器，并运行即可，需要提前安装好NVIDIA驱动，相关教程很多，这里不详细写了，ubuntu下运行命令为：
./CarlaUE4.sh -quality-level=Low -RenderOffScreen
附带参数第一个指将画质调低，默认为高，视自己的机器配置而定；第二个指不开启预览窗，这个预览窗没啥作用，大部分时候都可以不开。
客户端
这里我是基于ROS2开发的，因此下载carla-ros-bridge作为客户端使用，这个模块包含有多个package，这里重点注意下carla_ros_bridge、carla_spawn_objects、carla_manual_control三个package。
-
carla_ros_bridge
这个包封装了操作carla服务端的API，使用户不用关心server层的东西，直接通过其提供的几个ROS service创建车辆、传感器、路灯等等各种objects，并对其进行了管理，同时将各类传感器数据从carla格式转化为ROS消息publish出去。
launch文件中提供了多个参数供设置，这里挑重点参数讲解一下：
1、host、port
CARLA server所在主机的IP和端口，端口默认为2000，CARLA server与client在同一局域网即可，server与client在同一机器时IP填localhost，不同机器就填server所在机器IP即可。
2、fixed_delta_seconds
很关键的一个参数，决定了仿真时间的前进步长，即每两帧之间的仿真时间差，这里需要首先理解仿真时间与真实时间，做游戏的都很熟悉，它们是并行的两条时间线，仿真有自己的独立时间线，它一定程度上与真实时间无关，仿真器永远是一个帧接一个帧去计算，那么两帧之间的仿真时间差决定了仿真器在仿真时间内的运行频率，而仿真器在真实时间中的运行频率则由两帧计算所需要的真实时间决定，这个跟你机器配置、仿真器效果设置都有关系。
举例说明，假如设置了fixed_delta_seconds=0.05，会可能发生如下情况：
由于每一帧的计算与计算机配置、当帧需要的计算量都有关系，因此计算该帧需要的真实时间是有波动的，这也导致仿真时间与真实时间无法对齐。
这个参数之所有很重要，是因为它会跟你设置的传感器频率关联，如果不能理解这个参数，后续传感器频率的配置以及传感器同步都会出问题。 -
carla_spawn_objects
用来在仿真器中生成各种物体的节点，主要调用carla_ros_bridge生成物体的service完成，实际使用时，需要在config中参考给定的参考json文件新建自己的车辆和传感器配置，并创建对应的launch文件即可，细节参考官方文档。
这里主要讲下sensor_tick这个参数：
官方解释：Simulation seconds between sensor captures (ticks). 解释的比较直白了，其倒数也就是传感器输出频率，实际使用时要注意结合fixed_delta_seconds使用，也就是仿真步长时间。仿真与真实的区别在于真实时间是连续的，而仿真时间是离散的，仿真器只会计算时隔fixed_delta_seconds的帧，也就是说，将sersor_tick设置为小于fixed_delta_seconds（传感器频率高于仿真器频率）是没有太大意义的，因为会导致仿真一步计算需要计算多帧该传感器数据，并且在同一时刻发出，用户也无法获取每个传感器数据的精确时间，如下图所示：
可以认为，fixed_delta_seconds要小于你配置的所有传感器的sersor_tick，也就是仿真器频率要大于等于所有传感器频率才有意义，在上图的案例中，建议将fixed_delta_seconds设置为0.01s，但是这样会导致计算量增加，而且由于目前python版ros有些bug，会导致计算更慢，此外，使用大量高频率传感器会让仿真器计算量大幅增加，尤其是图像传感器，因此实际使用时，sersor_tick需要酌情而定，如果发现仿真器跑得太慢，可以考虑减少图像传感器或者降低其输出频率。 -
carla_manual_control
使用pygame显示仿真器画面和接受键盘并转换为控制指令的节点，没有太多可说的，参考其帮助指导即可，这个节点可以借助ROS2的多机通讯机制跟前面两个节点运行在不同的计算机上，当然，server本身也可以跟整个client运行在不同的机器上，前者利用ROS2的多机通信机制，后者利用CARLA的通信机制。
使用流程
一般使用流程如下：
目前存在的问题
目前CARLA客户端问题主要在于运行卡顿，无法设置为与真实时间同步等，部分跟ROS2有关，其中运行卡顿与多个因素有关，这里列举几个个人使用过程中比较头疼的问题如下：
1、激光数据转换时间长
bridge中将激光数据转换为ROS消息的部分采用一个一个点迭代计算的方式，实际测试计算时间很长，可以直接改为整块内存复制，运行速度会大幅加快。
2、ROS2 python版publish时间长
主要导致的原因是python publish部分底层数据拷贝同样采用单个数据迭代拷贝的方式，数据量越大复制时间越长，在图像数据拷贝时尤为明显，这个PR对其进行了修复，但目前只有ROS2 galactic最新版本采用了该修改，实测可以大幅减少publish时间。
3、bridge中采用单线程进行处理
同步模式下对server的tick操作实测在计算量大时可以花费较长时间，再加上tick返回后update所有的传感器同样需要耗费不少时间，实际上以上操作可以并行处理，实测同样可以提升性能。
4、bridge无法设置与真实时间同步
由于仿真时间与真实时间是完全并行的两条线，因此仿真时间可能快于或慢于真实时间，但很多算法验证需要考虑其性能，在部分情况下需要仿真时间与真实时间一致去进行测试，才最符合实际情况，该功能目前没有提供，大部分机器不进行合理的配置，仿真时间都是远远慢于真实时间，直接体现就是卡顿，仿真器跑得很慢，这个可以结合3的问题进行线程优化，考虑fixed_delta_seconds进行合理的sleep来解决。
标签：0.9,仿真,12,仿真器,carla,CARLA,时间,传感器 来源： https://blog.csdn.net/liu3612162/article/details/121423418