V2X-Enabled Communication for Traffic Operations via ROS
The traffic system consists of vehicular components and road infrastructure across both cyber and physical layers. A key challenge in traffic operations is ensuring effective communication between vehicles and infrastructure. Vehicle data, sampled at around 1 Hz, captures detailed information at many locations but with sparse and intermittent sampling in both time and space. Traffic data, updated about once per minute, covers fewer locations but provides concentrated, more continuous spatial sampling within those limited areas, thus complementing vehicle data by enhancing overall spatial coverage [8]. On the other hand, as actuators, vehicles can also leverage their high-frequency spatial and temporal updates, enabling them to respond to critical traffic events with lower latency than infrastructure systems.Unlike safety-critical Intelligent Transportation Systems (ITS) [7], the majority of traffic-operation-oriented applications are not latency-sensitive (second-level latency is generally tolerable), and therefore do not require a dedicated network for communication [4]. The primary challenge is to ensure that data from other vehicles and traffic sensors can be accurately interpreted and utilized by vehicles. Our work proposes a framework called VECTOR (V2X-Enabled Communication for Traffic Operations via ROS), which addresses these challenges through a cloud server layer (labeled with dark red box in Figure 1(a)) that functions as a data exchange hub for various agents. Agents in VECTOR include vehicle agents, infrastructure (traffic) agents, and server application agents, each of which will be described in detail below. Notably, ROS is primarily used on vehicle agents to manage local operations and enable communication through publishing and subscribing to ROS topics. The proposed framework is highly scalable, supporting a wide range of scenarios and enabling both open-loop and closed-loop testing and experimentation for V2X cooperative traffic operations.Vehicle and Traffic Agents. Vehicle and traffic agents constitute the actual agents operating within the traffic environment. These include vehicles, radar sensors, and other infrastructure elements. Each vehicle agent, as demonstrated in Figure 1(b), is connected to a managing edge computer - specifically, a Raspberry Pi 4 running ROS. ROS nodes expose relevant aspects of the agent’s operation as ROS topics through integration with device drivers [2]. The Raspberry Pi connects to the Internet, and consequently the cloud server, via an LTE modem. It periodically polls the cloud server to send telemetry and receive information about other traffic agents. The collection of ROS nodes and programs responsible for actuation, communication with the server, and decision-making processes forms the edge application for that vehicle agent.Cloud Server. The cloud server serves two main purposes. First, it acts as a communication hub between all traffic agents via standard Representational State Transfer (REST) HyperText Transfer Protocol (HTTP) endpoints. Incoming agent telemetry is stored in server-side databases as needed and redistributed to other traffic agents when required. The agents manage this process by periodically contacting the endpoints to send and receive data; in our case studies, this occurs at 1 Hz. It sends and receives data from the agents, such as onboard telemetry, events, and more. It can store this data for later analysis and troubleshooting. All traffic agents poll this server to send data to the other agents and to receive data from them as well. The cloud server layer executes time and spatial synchronization to ensure consistent data integration across all agents. This cloud server architecture is highly flexible, ranging from a single dedicated server for small-scale experiments to scalable cloud instances for large-scale deployments. As a result, it supports a wide spectrum of use cases, from small independent research projects to large integrated fleets and systems.Server Application Agents. As shown in Figure 1(d), server application agents run on a dedicated cloud server separate from basic communication services. They use database Application Programming Interfaces (APIs) to read and write traffic data from vehicle and infrastructure agents. After storing the data, these agents perform complex tasks to support decision-making and enhance edge applications. This setup offloads heavy processing from vehicle agents, allowing for real-time insights and advanced control strategies that edge devices on the vehicle side cannot handle.Case study: Enabling following vehicles to monitor pilot vehicle speed. In our recent work [5], we show that stop-and-go waves are predictable, with lead vehicle speed changes propagating downstream. Monitoring the pilot vehicle’s speed enables drivers to anticipate deceleration events. In our case study, vehicles transmitted location and speed data at 1 Hz to a central server, enabling real-time monitoring of a vehicle several positions ahead.The pilot vehicle, as a sensor, collects kinematic data via Controller Area Network (CAN) bus and transmits it to a server, which stores the data and provides the pilot vehicle’s velocity to the ego (control) vehicle. The ego vehicle, as an actuator, retrieves this velocity, runs control algorithms (including a speed controller and a safety-enforcing control barrier function [3]), and adjusts its acceleration accordingly, while both vehicles continuously report telemetry to the server at 1 Hz. The yellow blocks in Figure 2 illustrate the V2X communication processes enabled by VECTOR. This serves as a clear proof-of-concept demonstration of our framework.Summary. VECTOR makes the following contributions:(1) A scalable V2X communication framework via ROS that enables data exchange between connected vehicles and infrastructure, supporting both open-loop and closed-loop testing and experimentation for traffic operations.(2) Proof-of-concept case study demonstrating how following vehicles can monitor a pilot vehicle’s speed via V2X communication to smooth stop-and-go traffic waves.Future work includes to examine the feasibility of extending VECTOR to support additional closed-loop applications, such as incident detection [1] and traffic state super-resolution [6], by leveraging real-time vehicle and infrastructure data streams. Furthermore, communication latency tests need be conducted across multiple scenarios to evaluate the system performance under various V2X traffic conditions.
