Prepare directory structure to receive additional python clients.
No functional change, just directory layout shuffling.

How to test:

1. The python-related workflows still work:
   • python_its-client.yml => Python its-client
   • docker.yml => Run the its client container => Run Python docker action

Into the config file, if you put a position to static: false AND you declare the other fields (latitude, heading,...), the its client stays on static mode (not using the GPS).

New features:

• its-status: new python client to publish ITS status messages that match the status schema

How to test:

1. build and install python/its-status with standard setuptools procedure;
2. create a configuration file, using its-status.cfg as startup point, adapt with your MQTT broker and credentials, enable the stdout emitter;
3. subscribe an MQTT client to your broker, on the status topic, e.g. with mosquitto CLI clients:

   $ mosquitto_sub -h BROKER -p PORT -u USERNAME -P PASSWORD -i ID -t 'status/#'
   

4. run its-status using your custom configuration file:

   $ its-status -c /path/to/its-status.custom.cfg
   

Expected results:

1. The its-status package is installed;
2. You have a custom configuration file with your MQTT settings;
3. The MQTT client is connected to your MQTT broker;
4. The its-status program runs, and the messages are visible both on the its-status' own stdout, as well as on the MQTT client.

New features

• python: add configuration items to fake altitude, heading, and speed

How to test

1. Create a test config file, replace the MQTT settings to match your setup:

   [broker]
   host=test_host
   port=18
   tls_port=88
   username=test_user
   password=test_password
   client_id=test_client_id
   
   [position]
   static=true
   latitude=44.50779
   longitude=2.209381
   heading=130.7275
   speed=0.103
   altitude=131.693
   
   [log]
   directory=.
   default_level=DEBUG
   

2. Start the its-client with that config file:

   $ its-client -c /path/to/config/
   

3. Check the values emitted in the MQTT broker shall match the values from the config file:

   $ mosquitto_sub -h test_host -p 18 -v -t '#'
   

Notes: the black change can be seen in this job.

New features

• schema: Provide CPM schema version 1.2.0
• rust: apply changes to the data concerned structures: CollectivePerceptionMessage, PerceivedObject

Closes #34

How to test

1. Check the schema validity

   schema/validate schema/cpm_schema_1-2-0.json
   

   => it must be valid JSON => it must be valid against its own schema "https://json-schema.org/draft/2020-12/schema"

2. Build and run unit tests

   cargo clean; cargo build --all; cargo test --all
   

   => Build must be successfull => All tests must pass

3. Run the example application

   	 cargo run --bin its-client -- --mqtt-host france1 --mqtt-port 11883 --mqtt-username <username> --mqtt-password <password> --mqtt-client-id ora_itsclient_test
   

   => Binary must run and behave correctly

New features

• schema: Provide CPM schema version 1.1.3
• rust: apply changes to the data concerned structures: CollectivePerceptionMessage, PerceivedObject

Closes #34

How to test

1. Check the schema validity => it must be valid JSON => it must be valid against its own schema "https://json-schema.org/draft/2020-12/schema"
2. Build and run unit tests

   cargo clean; cargo build --all; cargo test --all
   

   => Build must be successfull => All tests must pass

3. Run the example application

   	 cargo run --bin its-client -- --mqtt-host france1 --mqtt-port 11883 --mqtt-username <username> --mqtt-password <password> --mqtt-client-id ora_itsclient_test
   

   => Binary must run and behave correctly

New features

• ROI based CPM subscription
• CPM message reception monitoring

How to test

1. Start the client and filter its output on CPM

   PYTHONPATH=.. ./main.py --mqtt-host <broker_ip> --mqtt-port <mqtt_port> --mqtt-username <username> --mqtt-password <password> --mqtt-client-id <unique_id> --log-level INFO --geo-position=static | grep cpm
   

   => You must see logs about CPM queue subscription

   2022-04-15 17:18:51,232 INFO: we subscribed on topic 5GCroCo/outQueue/v2x/cpm/+/1/2/0/2/2/2/0/2/3/1/0/3/1/1/2/0/0/0/#

2. Send fake CPM You can use this script to generate a CPM that is inside the client's ROI => You must see logs about CPM reception

   2022-04-15 17:22:56,240 INFO: message received on topic 5GCroCo/outQueue/v2x/cpm/ora_car_fake-6176/1/2/0/2/2/2/0/2/3/1/0/3/1/1/2/0/0/0/3/2/3/0 2022-04-15 17:22:56,241 INFO: crunch-cli cpm received_on ora_broker_3101/5GCroCo/outQueue/v2x/cpm/ora_car_fake-6176 123456789/1650036176/lat:43.50779/lng:1.209381 at 1650036176242 2022-04-15 17:22:56,242 INFO: {"origin": "self", "source_uuid": "ora_car_fake-6176", "type": "cpm", "message": {"generation_delta_time": 1650036176, "number_of_perceived_objects": 1, "perceived_object_container": [{"time_of_measurement": 123, "object_confidence": 99, "distance": {"y_distance": 167, "x_distance": 1105}, "object_ref_point": 0, "speed_confidence": {"x_speed": 127, "y_speed": 127}, "distance_confidence": {"y_distance": 102, "x_distance": 102}, "object_id": 162, "speed": {"x_speed": 0, "y_speed": 0}}], "protocol_version": 1, "station_id": 123456789, "station_data_container": {"originating_vehicle_container": {"heading": 0, "vehicle_length": 1023, "confidence": {"heading": 127, "vehicle_length": 4, "yaw_rate": 8, "speed": 1}, "vehicle_width": 62, "yaw_rate": 32767, "speed": 0, "drive_direction": 2, "longitudinal_acceleration": 161}}, "management_container": {"confidence": {"altitude": 15, "position_confidence_ellipse": {"semi_major_confidence": 4095, "semi_major_orientation": 3601, "semi_minor_confidence": 4095}}, "reference_position": {"altitude": 800001, "latitude": 4350779, "longitude": 1209381, "station_type": 5}, "generation_delta_time": 9805, "message_id": 14, "sensor_information_container": [{"sensor_id": 0, "detection_area": {"vehicle_sensor": {"ref_point_id": 0, "y_sensor_offset": 0, "x_sensor_offset": -24, "vehicle_sensor_property_list": [{"horizontal_opening_angle_start": 3486, "horizontal_opening_angle_end": 114, "range": 600}]}}, "type": 3}]}, "version": "1.0.0", "timestamp": 1650036176}}

3. Stop the client (not to flood the data files)
4. Check that CPM reception has been monitored

   cat /data/its_client/monitoring.csv | grep cpm
   

   => CPM reception must have been monitored

   crunch-cli cpm received_on ora_broker_3101/5GCroCo/outQueue/v2x/cpm/ora_car_fake-6176 123456789/1650036176/lat:43.50779/lng:1.209381 at 1650036176242

5. Check the reception.txt data file

   cat /data/its_client/reception.txt | grep cpm
   

   => Received CPM payload must be present

   {"origin": "self", "source_uuid": "ora_car_fake-6176", "type": "cpm", "message": {"generation_delta_time": 1650036176, "number_of_perceived_objects": 1, "perceived_object_container": [{"time_of_measurement": 123, "object_confidence": 99, "distance": {"y_distance": 167, "x_distance": 1105}, "object_ref_point": 0, "speed_confidence": {"x_speed": 127, "y_speed": 127}, "distance_confidence": {"y_distance": 102, "x_distance": 102}, "object_id": 162, "speed": {"x_speed": 0, "y_speed": 0}}], "protocol_version": 1, "station_id": 123456789, "station_data_container": {"originating_vehicle_container": {"heading": 0, "vehicle_length": 1023, "confidence": {"heading": 127, "vehicle_length": 4, "yaw_rate": 8, "speed": 1}, "vehicle_width": 62, "yaw_rate": 32767, "speed": 0, "drive_direction": 2, "longitudinal_acceleration": 161}}, "management_container": {"confidence": {"altitude": 15, "position_confidence_ellipse": {"semi_major_confidence": 4095, "semi_major_orientation": 3601, "semi_minor_confidence": 4095}}, "reference_position": {"altitude": 800001, "latitude": 4350779, "longitude": 1209381, "station_type": 5}, "generation_delta_time": 9805, "message_id": 14, "sensor_information_container": [{"sensor_id": 0, "detection_area": {"vehicle_sensor": {"ref_point_id": 0, "y_sensor_offset": 0, "x_sensor_offset": -24, "vehicle_sensor_property_list": [{"horizontal_opening_angle_start": 3486, "horizontal_opening_angle_end": 114, "range": 600}]}}, "type": 3}]}, "version": "1.0.0", "timestamp": 1650036176}}

To help our international, non-french users, use english notation for floating point, rather than the french one, in the description of the fields in the schemas.

Fixes: #42

New features:

• its-client: mirror MQTT traffic to another broker

How to test:

1. build and install python/its-clients with standard setuptools procedure;
2. Start a local broker and listen on it:

   $ mosquitto -c /dev/null -p 11883 -d
   $ mosquitto_sub -p 11883 -t '5GCroCo/#'
   

3. Uncomment and update the mirror-boker section in its_client.cfg:

   [mirror-broker]
   host = localhost
   port = 11883
   mirror-self = false
   

4. Start its-client with that config file (warning, the path to the config file is in fact the path to the directory containing the config file):

   $ its-client -c /path/to/its_client/
   

Note: do not forget to kill the MQTT broker that is in the background...

Expected results:

1. The its-client package is installed
2. The MQTT broker starts, the MQTT listeners, well, listens...
3. The its-client.cfg config file is updated
4. its-client starts, the MQTT listener reports messages both in the inQueue and outQueue.

As mentioned in PR !38 some values in parameters' description are using commas instead of dots (0,1 instead of 0.1) All schemas have to be checked for such typos

Bumps regex from 1.5.4 to 1.5.6.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bug fix:

• #57

How to test:

Pre-requisites: an MQTT broker running

1. Check the messages on your MQTT broker, displaying topic (%t) and payload (%p):

   $ mosquitto_sub -t '#' -F '%t %p'
   

2. Configure its-client to connect to your MQTT broker as a mirror broker, without mirroring self; run its-client
3. Configure its-client to connect to your MQTT broker as a mirror broker, with mirroring self; run its-client

Expected results:

1. The messages are displayed as they are emitted
2. The messages are all on the outQueue
3. The messages are all on the outQueue, and the CAM is duplicated from the one on the inQueue.

Current behaviour:

Messages published to the central broker are sent on queue inQueue (in as seen from the central broker). Currently, we also mirror that message on the local broker, on the same queue.

Expected behaviour:

Consumers expects messages on the outQueue (out as seen from the central broker), so messages sent should be mirrored locally on the outQueue.

Features:

• its-info: a new client to send ETSI information messages

How to test:

Preparatory steps: have a MQTT broker running.

1. Build and install the package in python/its-info/ with the standard setup-tools procedure:

   $ cd python/its-info/
   $ pip3 wheel .
   $ pip3 install its_info-0.0.0-py3-none-any.whl
   

   Note where the its-info is installed, e.g. ${HOME}/.local/bin

2. Update the configuration its-info.cfg to match your local setup, especially the MQTT broker settings; choose a short period, like a few seconds.
3. Run a MQTT client that listens on the info topic (or whatever you configued in its-info.cfg):

   $ mosquitto_sub -h BROKER -p PORT -u USERNAME -P PASSWORD -i ID -t info
   

4. Run the client:

   $ ${HOME}/.local/bin/its-info --config its-info.cfg
   

5. Terminate its-info (with Ctrl-C)
6. Stop and restart the MQTT client

Expected results:

1. The wheel is built and installed.
2. The configuration file is set for your local setup.
3. The MQTT client listens for messages.
4. The its-info clients runs (it's silent), the MQTT client display info messages.
5. The info message is no longer updated.
6. The MQTT clint displays the last info message that was retained in the broker.

Features:

• switch from a signal(7) to a timerfd(2) to drive the main loop
• run plugins in their own individual threads

How to test:

See #43

Expected results:

See #43

The method collective_perception_message.rs::mobile_perceived_object_list() requires the optional container OriginatingVehicleContainer to be present

The problem is that perceived object are managed as MobilePerceivedObjects which need a heading that is not provided in perceived object
For our first need there was an arbitrary heading computing based on the vehicle that perceived the object

Problem is that CPM are not only detected by vehicles but also RSU that do not have a heading

Two problems here:

1. POs detected by something else than a vehicle are not accessible as an empty vec is returned
2. We need to decide what to do about the MobilePerceivedObject's heading member (the best way is probably to set is as an `Option)