search

riebl / artery

OMNeT++ V2X simulation framework for ETSI ITS-G5
GNU General Public License v2.0
202 stars 128 forks source link

envmod: introduce EnvironmentModelObject interface #334

Closed riebl closed 2 months ago

riebl commented 3 months ago

I had a little bit of time to code on Artery again and introduced the EnvironmentModelObject interface I suggested in #330.

Can you @awillecke please cross-check?

awillecke commented 2 months ago

Sorry for the delayed response, I'm quite limited on time at the moment.

I think introducing an object interface for the envmod makes sense and code-wise it looks good to me (apart from 302af6454639edbb54207fc06e2dadc0872e236c).

However, the getAttachmentPoint of the BaseEnvironmentModelObject seems a bit odd to me, since, at least in my mind, sensor attachment is not related to the basic implementation of an object, but is rather specific to the ego vehicle and sensor instance. Objects are perceived by sensors and these cannot (at least for now) detect the object's sensors and their position on the object's hull.

Would it make sense to have something like a special EgoEnvironmentModelObject that inherits from TraCIEnvironmentModelObject and has the mAttachmentPoints member, overrides the update() function to adjust their position, and implements getAttachmentPoint?

riebl commented 2 months ago

Thanks for your feedback @awillecke! I just know the problem of limited time all too well :-)

Right now it is not easily possible to get rid of the attachment points because they are required for any (vehicle) object carrying sensors. It is just a geometrical helper for points at the outside boundary of any object, i.e. it does not hurt to have these constructional points for any object even those without sensors.