riebl / artery

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

Creating new simulation for multi-lane platoon #275

Closed HuyTyskland closed 1 year ago

HuyTyskland commented 1 year ago

Hello everyone,

Currently, I am working on simulating multi-lane platoon under ETSI ITS G5 standard. Because the platoons in Artery is a single-line platoon, that is why I wanted to create a different scenario. I have been spending a few days on reading through the code. However, I haven't been able to see where I can start with.

It would be great I have some instructions as a starting point.

Best regards, Huy Nguyen.

riebl commented 1 year ago

Hi @HuyTyskland,

To which feature are you referring when you say platoons in Artery are on a single lane? Actually, Artery contains (not yet) much regarding platooning at all. Before starting with Artery, I recommend drafting your platooning idea first:

When you can answer these questions to yourself, you can start thinking about the SUMO commands you have to issue and add an platooning service to your simulated vehicles in Artery, which implements the messaging and behaviour logic.

HuyTyskland commented 1 year ago

Hello @riebl ,

First, thank you very much for your response. My general aim is to establish a new scenario with communication within a platoon along with communication between non-platoon vehicles and the platoon leader. My difficulties regard the following aspect:

  1. A new scenario: road, infrastructure, PHY medium (path loss, signal attenuation, etc.), etc.. I know how to do that with SUMO. However, I am not sure where should I put those files and more important, how to link them with Artery.
  2. Platoon formation: since I work with a different platoon formation (no longer single-lane), I need to redefine how a platoon (with the number of platoon members) is formed. I notice that in PLEXE, this can be done in traffic/ folder. I haven't been able to find a similar code in Artery.
  3. Traffic injection: Besides the platoon, I also need to inject non-platoon vehicles in the scenario.
  4. Message exchange: since I aim to evaluate the platooning communication statistics (busy rate, packet loss, etc.), I choose to exchange only CAM with a changing frequency.

If you don't mind, would you kindly advise me on the following matter too:

  1. Artery vs. (Vanetza & PLEXE) for a beginner: should I continue on Artery or should I use the combination between another great work of yours Vanetza and PLEXE ( I understand this framework a little bit more clearly)?
awillecke commented 1 year ago

Hi,

regarding your first point, I've made some notes here as a starting point.

AFAIK Artery does not support platooning apart from the TraCI functions to control (e.g. getLeader) the vehicles in SUMO which use a platoon controller as car-following model. Also, the PLEXE controllers were merged into SUMO a while ago (https://github.com/eclipse/sumo/pull/5102) and they should be controllable via setParameter.

So basically, platooning should be possible with Artery, however, it is not straight forward. To get a running platoon, you would need to define a scenario, spawning vehicles that use a CACC car-following model and are equipped with a CaService. Also, you would need to implement a service that feeds the required data from the CAMs to the controller in SUMO via TraCI. Furthermore, you would need to set up the formations by yourself. Here, the storyboard feature could be helpful.

A few years back, I ported PLEXE 2.0 to Artery (https://github.com/awillecke/artery/tree/plexe_for_artery/) for some research project, however, I did not keep up with Raphael's and Michele's progress. So it is quite outdated but might be helpful regardless. If you want to try it, you might need also the old PLEXE-SUMO version, as I'm not sure whether my port is compatible with a recent SUMO including the merged controllers.

Best regards Alex

riebl commented 1 year ago

I agree with @awillecke that Plexe is definitely the more capable platooning library than plain Artery. After all, Plexe has been designed for platooning explicitly. All your requirements @HuyTyskland can be achieved with Artery, but there is little out-of-the-box functionality for platoons in Artery.

AFAIK, Plexe introduces its own message set that is not directly linked to ETSI ITS-G5. Also, the Veins network stack does not send CAMs but custom periodic messages. In a nutshell, Veins is oriented towards IEEE 1609, whereas Artery clearly focuses on ETSI ITS. I don't think that Plexe supports a Vanetza integration in its current shape.

It is probably impossible for me to give you unbiased advice on which tools you should use. However, an evaluation of your available options for platoon simulations might already be a nice chapter of your thesis :-)

HuyTyskland commented 1 year ago

Hello @awillecke and @riebl ,

Thank you very much for your response and sorry for this late reply.

@awillecke , I also noticed those features and characteristics that you mentioned. Right now, I am weighing different options based on your suggestion. I appreciate your instructions and repository. I will dig deeper into them since right now, since I do not fully understand all of them.

@riebl I agree that Veins and Plexe vs. Artery were made based on different standards. That was one of the reasons for this issue, since each framework has its advantages, regarding the idea of my thesis.

I will continue updating my work and hope to contribute to platooning research.

Best regards, Huy Nguyen.

HuyTyskland commented 1 year ago

hello @awillecke , I have a question about the way Omnet++ works with Enter_Method(). As you suggested, I read the ExampleService and also other service files. I saw Enter_Method() was used with the purpose as below:

The second issue is how to let the simulation kernel know that a method call across modules is taking place. Why is this necessary in the first place? First, the simulation kernel always has to know which module's code is currently executing, in order for ownership handling and other internal mechanisms to work correctly. Second, the Qtenv simulation GUI can animate method calls, but to be able to do that, it needs to know about them. Third, method calls are also recorded in the event log.

The solution is to add the Enter_Method() or Enter_Method_Silent() macro at the top of the methods that may be invoked from other modules. These calls perform context switching, and, in case of Enter_Method(), notify the simulation GUI so that animation of the method call can take place. Enter_Method_Silent() does not animate the method call, but otherwise it is equivalent Enter_Method(). Both macros accept a printf()-like argument list (it is optional for Enter_Method_Silent()), which should produce a string with the method name and the actual arguments as much as practical. The string is displayed in the animation (Enter_Method() only) and recorded into the event log.

I still don't understand when these methods/functions are called. If you or other people have some time, would you mind help me on this one? This is to help me understand the purpose of methods such as indicate, trigger or handleMessage. In general, I want to understand when a function in a C++ file of .ned module is called. (with or without Enter_Method).

Best regards, Huy Nguyen.

awillecke commented 1 year ago

Hi @HuyTyskland,

  1. the handleMessage function is a core function of OMNeT++ modules to realize event-based simulation.
  2. the trigger function of each service is called by the middleware of the node every updateInterval milliseconds.
  3. indicate is called by the PortDispatcher (which is initialized by the middleware) whenever a message on the service port is received.

Basically, OMNeT++ instanciates classes by following the network definition. In the case of Artery, this is usually some kind of "world", such as the artery.inet.World here, which can be found here. There, it is defined which modules shall be loaded initially. The loaded modules then decide, based on their parameterization, how the simulation behaves further. E.g. choosing another TraciManager for spawning certain kinds of vehicles, adding more modules and instanciating classes for them.

To really understand which module is loaded, which class is used and how they function, you'll need to follow the structure of the NED files, their parameters (in the .ned and the omnetpp.ini) and then, read the code of their implementation.

Best regards Alex

HuyTyskland commented 1 year ago

Hello @awillecke ,

Thank you very much for your guidance. I will continue on that notes.

Best regards, Huy Nguyen.

HuyTyskland commented 1 year ago

Hello @riebl and @awillecke , I just found a very helpful source written by @riebl , Christina Obermaier, and Hendrik-Jörn Günther. It is the book called "Recent Advances in Network Simulation" in which there is a chapter about a tutorial on Artery. I recently found from this issue As far as I know, this chapter in this book has not been added to the Artery website yet. I think it would be very helpful for beginners like me to have a more detail source like that. The Artery chapter of this book and the instruction of How to create a simulation by @awillecke are great source of tutorial guidance. By this comment, I shall close this issue.

Thank you very much, Huy Nguyen.