diff --git a/source/_nav.rstinc b/source/_nav.rstinc index 6263690..353db44 100644 --- a/source/_nav.rstinc +++ b/source/_nav.rstinc @@ -7,6 +7,9 @@ Install and Launch Problems and Solutions Additional Scripts + OpenCDA Service Layer + Neural Network Trajectory Prediction + AIM Trajectory Planning .. toctree:: :hidden: diff --git a/source/wiki/aim-trajectory-planning.rst b/source/wiki/aim-trajectory-planning.rst new file mode 100644 index 0000000..92898bc --- /dev/null +++ b/source/wiki/aim-trajectory-planning.rst @@ -0,0 +1,38 @@ +Trajectory Planning for Autonomous Intersection Management +========================================================== + +The article `"Trajectory planning for autonomous intersection management" `_ +describes the development of a method for managing the movement of autonomous vehicles +at intersections without the use of traditional traffic lights. The authors argue that +as the number of autonomous vehicles on the road increases, classical traffic control +schemes become inefficient because they do not account for the individual trajectory +of each vehicle. This leads to increased emissions and a high risk of accidents, +highlighting the need for a system that would transform the intersection into a hub +of collective intelligence and increase its throughput. + +The proposed approach is based on generating coordinated trajectories for autonomous +vehicles taking into account their current state and potential conflict zones. The +algorithm prevents collisions and minimizes delays, providing smoother intersection +traversal compared to phase-based control. From a methodological standpoint, this +approach is well suited to the task, as it works directly with the spatiotemporal +movement of vehicles. However, the system relies on an idealized motion model: exact +knowledge of vehicle states, reliable inter-vehicle communication, and the absence of +human drivers, which limits the practical applicability of the results. + +The article gives insufficient attention to the scalability of the algorithm under +high traffic density, robustness to sensor errors and V2X communication delays, and +the impact of mixed traffic. These factors significantly affect the performance of +AIM in real-world conditions, but they remain outside the scope of the analysis. + +The research results are based on simulations that demonstrate reduced waiting times +and increased throughput compared to traditional control methods. The authors interpret +the obtained data correctly; however, the conclusions should be viewed as a demonstration +of potential benefits rather than proof of the method's readiness for practical +deployment, since the experiments were conducted in a simplified environment. + +The trajectory planning algorithm proposed in the article can serve as a baseline +approach for implementing and testing autonomous intersection management within the +CAVISE project. The project architecture allows for the integration of such cooperative +driving methods and enables studying their behavior under real-world conditions, +including the effects of background traffic, sensor perception errors, and V2X +communication delays. diff --git a/source/wiki/nn-trajectory-prediction.rst b/source/wiki/nn-trajectory-prediction.rst new file mode 100644 index 0000000..43a47cb --- /dev/null +++ b/source/wiki/nn-trajectory-prediction.rst @@ -0,0 +1,174 @@ +Analysis of Neural Network Architectures for Multi-Task Trajectory Prediction in Autonomous Driving Systems +========================================================================================================== + +Introduction +------------ + +The presented models GNN_mtl_gnn and GNN_mtl_mlp are implementations of deep neural +networks for the Multi-Task Learning (MTL) problem in the context of trajectory control +for autonomous vehicles at intersections. + +Architectural Overview +---------------------- + +General Concept +~~~~~~~~~~~~~~~ + +Both models follow a unified multi-task learning paradigm, where a single network +simultaneously solves several related prediction tasks. The key difference between +the architectures lies in how they handle spatial dependencies between traffic participants. + +Input and Output Parameters +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Input data:** + +* Input vector dimensionality: 5 features per object +* Includes: coordinates (x, y), speed, heading, vehicle class + +**Output data:** + +* Output dimensionality: 60 values (30 × 2) +* Interpretation: trajectory prediction over 30 time steps, where 2 coordinates (x, y) + are predicted for each step + +GNN_mtl_gnn Model: Graph Neural Network Approach +------------------------------------------------- + +Architectural Composition +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The model consists of several sequential processing blocks. + +**1. Feature Encoding Block** + +linear1: 5 → 64 + ReLU + +linear2: 64 → hidden_channels + ReLU + +This block performs the initial transformation of raw features into a high-dimensional +hidden representation space. + +**2. Residual Learning Block** + +linear3: hidden_channels → hidden_channels + ReLU + skip connection + +linear4: hidden_channels → hidden_channels + ReLU + skip connection + +The use of residual connections allows the network to train effectively on deep +architectures by preventing the vanishing gradient problem. Each layer learns to +predict the residual function relative to its input. + +**3. Graph Convolution Block** + +conv1: GraphConv(hidden_channels → hidden_channels) + ReLU + +conv2: GraphConv(hidden_channels → hidden_channels) + ReLU + +This is a critically important architectural component. Graph convolutional layers +aggregate information from neighboring nodes in the graph via the ``edge_index`` +structure. The model captures interactions between vehicles. + +**4. Trajectory Prediction Head** + +linear5: hidden_channels → 60 + +The final fully connected layer projects the hidden representation into the space +of predicted trajectories. + +Algorithm +~~~~~~~~~ + +1. **Initialization:** Each vehicle is represented as a graph node with a 5-dimensional + feature vector +2. **Feature encoding:** Input data is sequentially transformed through two linear layers, + increasing representational capacity +3. **Representation enrichment:** Two residual blocks deepen the feature space while + preserving gradient flow +4. **Graph aggregation:** Convolutional operations propagate information across the graph, + where each node updates its representation based on the states of its neighbors, + weighted by graph topology +5. **Trajectory decoding:** The final linear projection generates coordinates of future positions + +Advantages of the Approach +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* **Explicit interaction modeling:** The graph structure naturally encodes spatial + relationships between agents +* **Permutation invariance:** The ordering of vehicles does not affect the result +* **Scalability:** The architecture efficiently handles a variable number of traffic participants + +GNN_mtl_mlp Model: Multi-Layer Perceptron Approach +--------------------------------------------------- + +Architectural Differences +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The GNN_mtl_mlp model is identical to GNN_mtl_gnn in all aspects except one critical change: + +conv1: Linear(hidden_channels → hidden_channels) + ReLU + +conv2: Linear(hidden_channels → hidden_channels) + ReLU + +The graph convolutional layers are replaced with standard fully connected (Linear) layers. +This means that the ``edge_index`` parameter is ignored, and each vehicle is processed +independently. + +Algorithm +~~~~~~~~~ + +The algorithm is analogous to the GNN version, with one key difference at step 4: + +1. **Independent processing:** Instead of graph aggregation, standard matrix transformations + are applied without considering the interaction structure + +Role in the Experiment +~~~~~~~~~~~~~~~~~~~~~~ + +This model serves as a baseline for evaluating the importance of graph structure. +Comparing the performance of the two models allows quantifying the contribution of +relational information to prediction accuracy. + +Technical Implementation Details +--------------------------------- + +Reproducibility +~~~~~~~~~~~~~~~ + +Setting ``torch.manual_seed(21)`` ensures deterministic weight initialization, which +is critical for a valid comparison between models. + +Nonlinearities +~~~~~~~~~~~~~~ + +The use of ReLU activations after each transformation layer introduces the nonlinearity +necessary for modeling complex dependencies in the data. + +Residual Connections +~~~~~~~~~~~~~~~~~~~~ + +The ``+ x`` operations implement skip connections, allowing gradients to pass directly +through blocks, which stabilizes training of deep networks. + +Application in AIM Systems +-------------------------- + +In the context of Autonomous Intersection Management, these models address the problem +of predicting future vehicle trajectories based on their current state and relative positions. + +**Typical usage scenario:** + +1. The central intersection management system receives data about all approaching vehicles +2. A graph is formed where edges connect potentially interacting agents +3. The model generates trajectory predictions over a horizon of ~3–5 seconds +4. The planning system uses the predictions to optimize intersection traversal and + prevent collisions + +Conclusion +---------- + +The presented architectures demonstrate two approaches to the trajectory prediction +problem: one with explicit interaction modeling through graph neural networks, and one +without it through classical multi-layer perceptrons. Both models employ modern deep +learning techniques (residual connections, multi-task learning) and are specialized +for real-time operation in safety-critical autonomous vehicle control systems. diff --git a/source/wiki/services.rst b/source/wiki/services.rst new file mode 100644 index 0000000..4186590 --- /dev/null +++ b/source/wiki/services.rst @@ -0,0 +1,110 @@ +OpenCDA Service Layer +========== + +Behavior Service Orchestration +------------------------------- + +A behavior service system has been introduced for simulation participants, including +Road-Side Units (RSU) and vehicles. + +The ``BehaviorService`` interface defines the protocol that every service attached to +a participant must implement. It describes the service lifecycle: + +* ``on_attach`` - initialize the service for a particular participant instance +* ``process`` - process incoming messages and return a typed result +* ``on_detach`` - release service resources before the participant is destroyed + +``BehaviorServiceRegistry`` is a global registry that supports: + +* registration via the ``@BehaviorServiceRegistry.register`` decorator +* class lookup by service name +* a ``create_service`` factory method + +The registry automatically discovers and loads built-in services from the ``services/`` +subpackage. + +A ``DummyService`` has been added for testing purposes. It accepts text messages and +returns them with an appended suffix, verifying that registration and message routing +work correctly. + +Both ``RSUManager`` and ``VehicleManager`` have been updated to support service +configuration and lifecycle management - including config loading from YAML, +attach/detach handling, and message routing by ``service_id``. This unified the +service architecture across vehicles and road-side infrastructure. + +AIM Services +------------ + +``AIMModelManager`` has been extracted from the OpenCDA core into the service layer +to align with the service-based architecture. Three new services were introduced. + +**aim-server** + +The server-side AIM service. It receives a batch of requests from vehicles, +runs ML inference, and returns predicted trajectories. + +**aim-client** + +The client-side service, running on each vehicle. It builds a request to the server +with the vehicle's current position, speed, heading, and route. +Upon receiving a response, it generates a movement command for the ``movement-controller``. + +**movement-controller** + +Accepts movement commands with a target position and controls vehicle motion. + +All inter-service communication is routed through typed ``TransportMessage`` objects, +eliminating direct dependencies between components. + +Service Priority +---------------- + +Priority-aware ordering has been added to the behavior service system. Services are +now initialized and processed in ascending order of their numeric ``priority`` field - +a lower value means the service runs first. Priority is configured in the +scenario YAML file. + +Attack Framework *(Draft)* +--------------------------- + +A framework for simulating adversarial attacks on simulation participants has been +introduced. + +Core abstractions: + +* ``AttackProtocol`` - interface for a concrete attack, composed of stages (``AttackStageProtocol``) +* ``AttackManager`` - orchestrates attacks, manages registries, and collects results +* ``AttackRegistry`` - registry of registered attacks +* ``StageRegistry`` - registry of attack stages +* ``AttackContext`` - execution context passed to an attack at runtime +* ``AttackResult`` - result produced by a completed attack + +**Capability System** + +A capability binding mechanism (``CapabilityBindings``) has been introduced, linking +named capabilities (``Capability``) to concrete service methods. This allows attacks +and external components to interact with a service through a stable interface, +without knowledge of its internal implementation. + +Supported capabilities: + +* ``request.observe`` - observe incoming requests +* ``request.submit`` - submit requests +* ``response.observe`` - observe responses +* ``response.submit`` - submit responses +* ``command.submit`` - submit movement commands +* ``state.observe`` - observe service state + +**BehaviorService Extensions** + +The ``BehaviorService`` protocol has been extended with a ``get_state()`` method that +returns an immutable snapshot of the current service state. State objects have been +implemented for the existing services: + +* ``AIMServerState`` - tracked and processed vehicle IDs and counts +* ``AIMClientState`` - attachment status and next target position + +**Example Attack** + +``AIMClientResponseSniffer`` has been added as a demonstration attack. It uses a +``Sniffer`` stage to intercept AIM server response messages addressed to clients.