ERA and CARLA Detailed

ROS ERA and CARLA

ERA and CARLA use ROS to communicate each other. Standalone ERA currently does not have a way to read from or write to CARLA however it is not a complicated task to add that functionality.

How the system works?

CARLA is a driving simulator using unreal engine to simulate environments, vehicles, pedestrians, and sensors. It has a server-client architecture which means that you need to run Carla as a standalone application and interact with it through its API. CARLA's API is written in Python.

CARLA also has a ROS interface to easily interact with the ROS world. It is called ros-bridge. It basically uses CARLA's API and translate the sensor and position data to ROS topics. It also allows ROS nodes to control vehicles in CARLA using velocity commands.

ERA (master branch) uses ros-bridge (not to be confused with ros-bridge) to communicate with CARLA. CARLA runs, in a ROS independent fashion, separately in a single process. ros-bridge communicates with CARLA through sockets and exposes sensor data as ROS topics.

Current version of ERA only reads lidar data, camera data, and vehicle position data.

How to install ERA with CARLA?

Follow this wiki page.

As a summary, you need to install CARLA (apt-get), ros-bridge, and ERA ROS version.

How to run the system?

Running the system is straight forward:

• First run CARLA in a separate terminal: /opt/carla-simulator/bin/CarlaUE4.sh
• Run ERA in another terminal: roslaunch era_gazebo carla_two_cars.launch
• Finally you may want to run rviz in a third terminal for visualization.

What is happening under the hood?

roslaunch era_gazebo carla_two_cars.launch does many things and launches a bunch of ros nodes in parallel.

• It tells Carla to load Town10HD environment. This is a downtown environment with many two lane roads and intersections. You can find available maps here
• It loads two cars with specific models. For each car you need to specify its models. The list of models can be found here.
• For each car you need to specify a start location in the format of x,y,z,roll,pitch,yaw.
• Once the environment and vehicles are decided, the launch file runs $(find carla_ros_bridge)/launch/carla_ros_bridge.launch. This launch file runs ros-bridge. You only need one ros-bridge as it will take care of all the vehicles.
• For each car, the file runs through the following steps:
  • $(find carla_ego_vehicle)/launch/carla_example_ego_vehicle.launch: It spawns the vehicles at the given positions
  • $(find carla_manual_control)/launch/carla_manual_control.launch: It launch some controllers to help you move a car through ROS interface
  • $(find carla_ackermann_control)/launch/carla_ackermann_control.launch: It enables ackermann controls and commands.
  • costmap_2d_node: Our costmap node. Creates a costmap for a given car
  • $(find era_gazebo)/launch/v2v.launch: enables v2v communication. It runs the gnuradio communication layer between vehicles
  • $(find era_gazebo)/launch/object_detection.launch: It runs object detection using the front camera image.

Creating Scenarios

This is the tricky and somewhat painful part of the process. Unfortunately there is no easy way to create scenarios. A lot of trial and error is used in the process.

The scenario is defined in the python script era_gazebo/scripts/spawn_carla_npc.py. This file is not a ROS file and communicates directly with CARLA through its python API.

spawn_carla_npc.py is the file to fill to create a scenario. This file connects to Carla server, spawns additional non-user controlled (NPC) vehicles and pedestrians. It is also able to move them with a given speed and direction.

Standalone ERA and CARLA

The interface between standalone ERA and CARLA is not complete.This section provides some insights on linking the two.

CARLA to ERA link

ERA uses read_bag.py script to read a bag file containing recorded sensor streams. These files have been generated using CARLA's ros interface. This means that reading real-time sensor information from CARLA is quite straightforward since the interface is almost identical to reading a bag file.

I recommend creating a ROS node that reads the relevant topics from CARLA and sends them to ERA through TCP (like we do in read_bag.py)

ERA to CARLA link

Anything that goes to CARLA uses the ROS interface. ERA to CARLA link is in fact ERA to ROS link. The task will be to create a ROS node similar to read_bag.py which opens a TCP connection to ERA and reads the merged occupancy maps. Once the map is read this node should shape it to a nav_msgs/OccupancyGrid.msg and publish it. This will make the merged occupancy map available to the whole ROS environment.

If you want to make the vehicles react to the occupancy map, there are three options:

1. Creating a custom node to stop the vehicle: This is not too hard. This custom node will subscribe to the merged occupancy grid and look if the cells corresponding to the vehicles moving direction is occupied. If that is the case, then it will send a stop command (velocity 0) to CARLA (through the ROs interface)
2. Using a ROS Navigation motion planner: This option is easier to build but harder to tweak. ROS has already a complete motion planner that uses occupancy maps to navigation a robot. You can use this motion planner and give the merged occupancy grid as an input. The planner will plan a path and update the path accordingly. The issue with this approach is the lack of lane information in the planner. The planner will make the vehicle go anywhere in the free space which is not the right way to drive a car.
3. Use Carla's own navigation stack: I am not entirely sure about this since I have never used it. I know that CARLA ha some navigation capabilities. There might be a way to link ROS based occupancy map navigation to CARLA's own navigation.