This repository provides examples demonstrating how to develop and run your own V2X (Vehicle-to-Everything) application on the cube-its within a ROS 2 (Robot Operating System) environment. The content is structured as follows:
The cube-its framework is designed to seamlessly integrate Intelligent Transportation Systems (ITS) applications and Vehicle-to-Everything (V2X) communication capabilities within a ROS 2 environment. It facilitates data exchange and communication between vehicles and external entities such as other vehicles, infrastructure, pedestrians, and cloud systems, leveraging V2X communication technologies.
The framework comprises multiple nodes and components that collaboratively handle GNSS data, vehicle kinematics, I/O operations, ITS facilities, and V2X communication, utilizing the Vanetza library, as illustrated in Figure 1.
Furthermore, cube-its serves as a comprehensive platform for the development, deployment, and operation of ITS applications and related innovations.
Component | Description |
---|---|
GNSS | Provides accurate global positioning data for the system. It reads data from GNSS receiver and provides the position, velocity, and time information. |
Kinematics | Computes the kinematic state of the system based on GNSS data and other sensors. It calculates the system's pose, velocity, and acceleration. |
I/O | Handles sensor inputs and actuator outputs. It processes data from various sensors or interfaces such as CAN (Controller Area Network). |
ITS Facilities | Provides services and functionalities for intelligent transportation systems, including communication with traffic infrastructure and managing V2X communication. |
Vanetza | Facilitates V2X communication by implementing the ETSI (European Telecommunications Standards Institute) ITS-G5 protocol for vehicle and infrastructure communication. |
The cube-its framework incorporates the etsi_its_messages package to facilitate the use of standardized ETSI ITS messages for V2X communication within ROS and ROS 2 environments. This integration enables developers to implement and manage V2X communication protocols, adhering to the ETSI specifications, within robotic and autonomous vehicle systems.
Status | Acronym | Name | EN Specification | TS Specification | Supported in cube-its |
---|---|---|---|---|---|
✅ | CAM | Cooperative Awareness Message | EN 302 637-2 V1.4.1 (ASN.1) | - | >=v1.0.0 |
✅ | DENM | Decentralized Environmental Notification Message | EN 302 637-3 V1.3.1 (ASN.1) | - | >=v1.0.0 |
✅ | CPM | Collective Perception Message | - | TS 103 324 V2.1.1 (ASN.1) | >=v1.2.0 |
🔜 | VAM | VRU Awareness Message | - | TS 103 300-3 V2.2.1 | - |
🔜 | MAPEM | Map Extended Message | - | TS 103 301 V2.1.1 (ASN.1) | - |
🔜 | SPATEM | Signal Phase and Timing Extended Message | - | TS 103 301 V2.1.1 (ASN.1) | - |
The cube-its framework is validated using the ETSI conformance validation framework, as specified in ETSI TR 103 099 V1.5.1.
ROS 2 is known as an advanced middleware for creating software for self-driving robots and even autonomous vehicles. It has a decentralized setup with nodes handling specific tasks, such as processing data from a single sensor etc. Since we will be working with ROS, it makes sense to get familiar with the environment and features of ROS.
In order to run ROS 2 nodes in the same ROS 2 environment, ROS 2 introduces a domain mechanism. By default ROS_LOCALHOST_ONLY is set to 1, which means that cube-its, its topics, services, and actions will not be visible to other ROS 2 environments on the local network. By setting ROS_LOCALHOST_ONLY=0 enables ROS 2 nodes from v2x_apps and cube_its to discover each other, if they share the same domain (default: ROS_DOMAIN_ID=42). You can simply disable the localhost only setting by typing in a terminal:
export ROS_LOCALHOST_ONLY=0
In other words, they are part of the same ROS 2 environment, and the ROS 2 nodes from v2x_apps can now access to all services and topics of the cube-its.
In the same way, it's possible to set the domain to a different value:
export ROS_DOMAIN_ID=45
More information about domain ID can be found here: https://docs.ros.org/en/humble/Concepts/Intermediate/About-Domain-ID.html
- cube:evk or cube:micro OBU running the cube-its framework
- You likely already have worked with devcontainer projects in VSCode (Visual Studio Code). If you are not familiar with developing inside a container, check the following link https://code.visualstudio.com/docs/devcontainers/containers before you start.
dev_ws
├── src/v2x_apps
│ ├── btp_listener.py
│ ├── btp_sender.py
│ ├── cam_listener.py
│ ├── cpm_provider.py
│ ├── denm_node.py
│ └── ...
...
The cam_listener, depicted in Figure 2, monitors for received Cooperative Awareness Messages (CAMs) sent through the designated published topic /its/cam_received by cube-its. Within the cube-its framework, the publication of received CAM data is managed, while the cam_listener node is set up to subscribe to this particular topic. This setup allows the cam_listener node to receive and process CAM data, highlighting a key aspect of the project's functionality.
The cam_listener node operates within a Docker container, similar to the cube-its. Both are functioning within a ROS 2 environment and share the same domain, facilitating the ability of ROS 2 nodes to discover each other.
The denm_node, illustrated in Figure 3, handles the transmission and reception of Decentralized Environmental Notification Messages (DENMs) via cube-its. It subscribes to specific topics to receive position updates and incoming DENMs, and it utilizes a service call to initiate the transmission of DENMs. Furthermore, the denm_node periodically generates and sends DENMs based on its current location.
Subscriptions:
- /its/position_vector: The denm_node subscribes to this topic to receive regular updates about the current position.
- /its/denm_received: This subscription allows the denm_node to receive incoming DENMs from other V2X capable stations. By processing these messages, the node can react to various environmental events and updates.
Services:
- /its/den_request: The denm_node can use this service to request the transmission of a DENM. This is likely an on-demand feature, where a specific condition or event triggers the need to send a DENM immediately. Here, in this example the transmission is called periodically.
In the following example, we regularly create a Collective Perception Message (CPM) that includes sample Perceived Object data and transmits it based on the current position. The cpm_provider, illustrated in Figure 4, is tasked with supplying CPMs to cube-its. It subscribes to receive position updates and publishes a CPM to the /its/cpm_provided topic, where the CPS facility in cube-its handles the transmission of the CPM. Furthermore, it consistently generates and sends CPMs according to the current position.
Subscriptions:
- /its/position_vector: The cpm_provider subscribes to this topic to receive continuous updates regarding the current position.
Publisher:
- /its/cpm_provided: The cpm_provider provides the generated CPM to cube-its on this topic for transmission.
Navigate to the root of the workspace, dev_ws:
cd dev_ws
Build application by:
colcon build --packages-select v2x_apps
Still in the same terminal, source the setup files:
source install/setup.bash
Now run the corresponing node. In this case 'cam_listener':
ros2 run v2x_apps cam_listener
The node is running correctly when you see the following terminal output:
[INFO] [1706013094.349399714] [cam_listener]: Node "cam_listener" started
The cam_listener is now waiting for a received CAM message by cube-its. When cube-its starts receiving CAMs, cam_listener will output on terminal:
[INFO] [1706013095.341824275] [cam_listener]: Received CAM from Station Id: 84281098
[INFO] [1706013096.345854233] [cam_listener]: Received CAM from Station Id: 84281098
[INFO] [1706013097.345731609] [cam_listener]: Received CAM from Station Id: 84281098
[INFO] [1706013098.345113236] [cam_listener]: Received CAM from Station Id: 84281098
[INFO] [1706013099.344528362] [cam_listener]: Received CAM from Station Id: 84281098