Collective Perception Service implementation

[sodevel]

As part of my master thesis, i have written a Collective Perception Service implementation for Artery, it is based on ETSI TR 103 562 v2.1.1. The implementation features all three Generation Rules (excluding the special case for person and animal objects) and most of the Redundancy Mitigation Rules. I am interested to integrate the implementation into the upstream project.

The implementation has a catch though, it requires a small modification of the Collective Perception Message format. Instead of using an 8 bit identifier, the Perceived Object Container uses a 32 bit identifier for the contained objects. Together with the Artery modification to assign the OMNeT++ node id as station id instead of a random number, this simplifies the identification of objects accross different vehicles. Actually, this results in perfect identification, hence all confidence based Redundancy Mitigation Rules are pointless and have been skipped.

Basically, the implementation is comprised of 3 parts:

1. Artery Core changes: Patching of the message format, assignment of the node id as station id (for V2X enabled vehicles and plain vehicles), support for compound module based services, some added API required to gather information to create CPMs, some other small enhancements
2. CP Service utilities: Generic Smart-Pointer-Wrapper for CPM fragments and helpers for CPM containers, boost::units definitions for required units
3. CP Service implementation: Compound module based, one core module, one module for each Generation Rule and Redundancy Mitigation Rule

Some things should be cleaned up and optimized, but i don't want to invest a lot of work if this doesn't has a chance to get integrated. So my question is, what would be the best approach to get this started? Right now i have two feature branches, one covers 1. and is only 20 commits, these should be retained to simplify the integration for my former university. The other branch contains the rest and has 170 commits, i don't see any other chance to simplify this but squashing this in one commit.

[riebl]

Hi @sodevel,

thanks for considering contributing your work upstream, an effort I rarely see, unfortunately!

Are there any ETSI plans for a CPM update with 32-bit identifiers? Maybe @kenog has some information about this topic?
I just don't want to break any "standard" code without good reason. Alternatively, would it be feasible without too much effort to create a "SodevelCpm" with your non-standard extensions? This would allow us to have both messages side-by-side if ETSI does not plan to adopt the longer identifiers.

[kenog]

Hi @sodevel, hi @riebl,
unfortunately, I haven't had much time to attend the drafting sessions lately. Therefore, I am also not 100% sure. However, the current draft of TS 103 324 (v0.0.34) mentions a range of 0-65535 for the ObjectId. If I remember correctly, this is due to privacy concerns, which also mandate to choose the IDs at random now - as opposed to round robin which was the idea back in the TR.
The ASN.1 on the other hand has apparently not been updated yet and still demands a range of 0 - 128.

We could therefore go with 16-bit ObjectIds as this seems to be ETSI's plan. But this could be a problem since in Artery, the StationIds are 32-bit and randomly chosen if I remember correctly. Maybe it would be possible to restrict the range of the RNG to 16 bit? Not sure if that is feasible.
With the adaption @sodevel mentioned, using the OMNeT++ ModuleIds, this could be even harder since their generation is not in our hands :/ I am not sure anymore why we choose to use them. I think the only problem was to uniquely identify perceived objects and get access to their respective EnvironmentModelObjects, wasn't it? Wouldn't that work with randomly generated IDs as well? Sorry if that's an obvious question.

Best regards
Keno

[sodevel]

The difficulty is, that a sending entity must identify identical objects it has received by CPMs and its own sensors. Although the Artery sensor model is perfect and it should be possible to calculate the absolute position of an object from data received by CPM (maybe with some rounding error), each entity detects objects at a different point in time. Therefor, the positions will be off a bit and some kind of tracing needs to be done to identify identical objects.

Because this is not that easy and was quite off-topic for my work, we used the fact that we have an unique identifier for each entity and violate the specification in two points:

1. We assign a fixed known ID for each station
2. We use this ID as object ID inside CPMs, to be able to do this we increased the object ID size from 8 bit to 32 bit to fit our IDs

The CP Service itself and the patching of the message format are enabled by a CMake option, so the sources do not need to be modified in the repository. The changed ID assignment approach is currently fixed but it shouldn't be to hard to enable this only by e.g. a #ifdef.

Please see #251 for further details and discussion.