Shared or common functionality for the communication via DDS is bundled in the cpm library (cpm_lib). This library is written in C++ and is used by the vehicle, the LCC and the Middleware. The HLC, on the other hand, is supposed to be more or less independent from the implementation language of the library. Programmers of the HLC programs should not be troubled with its implementation details. Thus, it was decided to create a Middleware which performs most of the communication tasks that otherwise would have to be implemented in some form in the HLC, which might not be able to use a C++ library.

The Middleware coordinates the communication with the DDS domain of the vehicle, LCC and further participants with the HLC. It is responsible for sending timed pre-aggregated vehicle information to the HLC. These can be interpreted as a start signal for starting the computation using this data. It sends the commands generated by the HLC as a reaction to this start signal to the vehicles. Any timing task is performed by the Middleware, so period and offset for the interaction with the HLC are set here (and can be set when starting the application using command line parameters).  The HLC is informed about the current time, in case that is necessary for its own computations.

Figure: Communication from other participants to the HLC filtered by the Middleware

Figure: Communication from the HLC to other participants

The middleware also manages further internal timing according to the current simulated and real time, propagates the LLC's start and stop signals and waits for the HLC to finish its computation in the simulated case. It is also responsible for logging communication or timing errors.

The HLC only needs to integrate and configure a reader and a writer to listen to the Middleware and send commands. Thus, as long as the programming language is supported by RTI DDS, the programmer does not need to know the implementation details of the communication.

Functionality

• Logging
• Waiting for the HLC to join the domain & send a ready message
• Periodically calling the HLC to request commands for the vehicle
• Forwarding vehicle state information to the HLC periodically (always the newest information is sent) + timing information s.t. the HLC does not need to care about getting the right timestamps itself
• Forwarding commands sent by the HLC to the vehicle
• Forwarding stop signals to the HLC
• Receiving (some) parameters from the parameter server

Command Line Parameters

Parameter Usage Example

./middleware --vehicle_ids=1,7,8 --node_id=middleware --wait_for_start=true --dds_domain=1 --simulated_time=false

If you want to start your script using a bash script, you can do it like this:

/opt/MATLAB/R2019a/bin/matlab -logfile matlab.log -sd $script_dir -batch "$script_name(1, ${vehicle_id})"

Important parameters

• node_id: Identification string of the middleware instance in the DDS network
• period_nanoseconds: Length of each period in which the HLC is triggered, in nanoseconds
• simulated_time: True if the current setup uses simulated time, else false
• wait_for_start: Whether the middleware should wait for the LCC's start signal, should be true (false only for debugging purposes)
  
• vehicle_ids: IDs of the vehicles the HLC(s) that the middleware 'controls' are responsible for (usually just one ID)
  
• vehicle_amount: Set amount of vehicles instead of vehicle ID, sets IDs 1 - vehicle_amount (restricted to 256)
• dds_domain: Domain ID of the domain in which the LCC, vehicle etc. participate
  
• domain_number: Local domain ID of the middleware and the HLC
  
• dds_initial_peer: Should be explained in Lab Control Center (Usage) (TODO)
  

Other parameters

• offset_nanoseconds: Set the offset of the communication w.r.t. ~1970 (TODO, real time) or 0 (simulated time); should usually not be changed
  
• use_param_server: Irrelevant parameter, false is default (true currently not required, would break the middleware)
• log_topic: Topic name of the logging topic (logs that are collected by the LCC)
• hlc_state_topic: Topic name of the vehicle state list topic for the vehicle information sent to the HLC
• vehicle_state_topic: Topic name of the vehicle states sent by the vehicles
• hlc_trajectory_topic: Topic name of the trajectory commands sent by the HLC
• vehicle_trajectory_topic: Topic name of the trajectory commands sent to the vehicles
• hlc_speed_curvature_topic: Topic name of the speed curvature commands sent by the HLC
• vehicle_speed_curvature_topic: Topic name of the speed curvature commands sent to the vehicles
• hlc_direct_topic: Topic name of the direct control commands sent by the HLC
• vehicle_direct_topic: Topic name of the direct control commands sent to the vehicles

Communication between HLC and Middleware

The IDL type for the DDS communication of HLC and middleware is mentioned here and located here: https://git.rwth-aachen.de/CPM/Project/Lab/software/blob/master/hlc/middleware/idl/VehicleStateList.idl

What the HLC scripts need to include

• Send a ReadySignal message after initialization - only the ID string matters, which must be of the form "hlc_" + vehicle_id, where the latter is the ID of the vehicle the HLC is responsible for
• Receive VehicleStateList messages, which include the current states and observations of the vehicle as well as the current time - this signal is supposed to be the start signal for the HLC, so computation should start using this data after the message was received. Make sure to ignore signals received during computation, if that takes longer than a single period
• Send vehicle command messages as a result of the communication including the vehicle ID to the Middleware, which propagates these to the vehicle
• React to stop signals sent by the LCC and propagated to the HLC by the Middleware

TODO: Mention IDL type / what it does / what the middleware expects, refer to Matlab tutorial