I want to keep a constant number of cars in my (long) simulation (OMNeT+Veins). I do not care about mobility that much so i could probably use the Veins in-built function *.manager.numVehicles = 100. The thing is that if i do not specify any(enough) vehicle flows (from SUMO) my simulation terminates instantly (because of no events). So i create some flows (that exit the simulation sooner) and Veins fills up for the cars as they dissappear.
Is there a more elegant way to do this? I'd prefer to just use the numVehicles function since it's easier and the cars move minimally so they remain in the simulation for long.
I need steady-state vehicular density (number of vehicles fixed - even if old ones leave and new ones enter to replace them at the same instant).
Thanks,
Andreas
The autoShutdown parameter can be set to false to instruct the coupling interface to keep going even though there are no more cars in the simulation. See https://github.com/sommer/veins/blob/veins-4.5/src/veins/modules/mobility/traci/TraCIScenarioManagerLaunchd.ned#L55
https://stackoverflow.com/a/71071341/7215379 has a solution. It actually is meant to keep the number of vehicles in simulation constant. You can look into the possibility of reusing it.
Related
I started (since about one week) using veins (4.4) under omnet++ (5.0).
My current task is to let vehicles adjust their transmission range according to a specific context. I did read a lot of asked questions like these ones (and in other topics/forums):
Dynamical transmission range in the ieee802.11p module
Vehicles Receive Beacon Messages outside RSU Range
How coverage distance and interference distance are affected by each other
Maximum transmission range vs maximum interference distance
Reduce the coverage area between vehicles
how to set the transmission range of a node under Veins 2.0?
My Question:
How to -really- change the transmission range of just some nodes?
From the links above, I knew that the term "transmission range", technically, is related to the received power, noise,sensitivity threshold, etc. which defines the probability of reception.
Since I am new to veins (and omnet++ as well), I did few tests and I concluded the following:
"TraCIMobility" module can adjust the nodes' parameters (for each vehicle, there is an instance) such as the ID, speed, etc.
I could, also, instantiate the "Mac1609_4" (for each vehicle) and changed some of its parameters like the "txPower" during simulation run-time but it had no effect on the real communication range.
I could not instantiate (because it was global) the "connection manager" module which was the only responsible of (and does override) the effective communication range. this module can be configured in the ".ini" file but I want different transmission powers and most importantly "can be changed during run-time".
The formula to calculate the transmission range is in the attached links, I got it, but it must be a way to define or change these parameters in one of the layers (even if it is in the phy layer, i.e., something like the attached signal strength...)
Again, maybe there is some wrong ideas in what I have said, I just want to know what/how to change this transmission range.
Best regards,
You were right to increase the mac1609_4.txPower parameter to have a node send with more power (hence, the signal being decodable further away). Note, however, that (for Veins 4.4) you will also need to increase connectionManager.pMax then, as this value is used to determine the maximum distance (away from a transmitting simulation module) that a receiving simulation module will be informed about an ongoing transmission. Any receiving simulation module further away will not be influenced by the transmission (in the sense of it being a candidate for decoding, but also in the sense of it contributing to interference).
Also note that transmissions on an (otherwise) perfectly idle channel will reach much further than transmissions on a typically-loaded channel. If you want to obtain a good measurement of how far a transmission reaches, have some nodes create interference (by transmitting broadcasts of their own), then look at how the Frame Delivery Rate (FDR) drops as distance between sender and receiver increases.
Finally, note that both 1) the noise floor and 2) the minimum power level necessary for the simulation module of a receiver to attempt decoding a frame need to be calibrated to the WLAN card you want to simulate. The values chosen in the Veins 4.4 tutorial example are very useful for demonstrating the concepts of Veins, whereas the values of more recent versions of Veins come closer to what you would expect from a "typical" WLAN card used in some of the more recent field tests. See the paper Bastian Bloessl and Aisling O'Driscoll, "A Case for Good Defaults: Pitfalls in VANET Physical Layer Simulations," Proceedings of IFIP Wireless Days Conference 2019, Manchester, UK, April 2019 for a more detailed discussion of these parameters.
I am just giving my opinion in case someone was already in my situation:
In veins (the old version that I am using is 4.4), the "connection manager" is the responsible for evaluating a "potential" exchange of packets, thus, its transmission power is almost always set to the upper-bound.
I was been confused after I changed the vehicles "Mac1609_4" transmission power and "graphically", the connection manager was still showing me that the packets are received by some far nodes which in fact was not the case, it was just evaluating whether it is properly received or not (via the formula discussed in the links above).
Thus: changing the "TxPower" of each vehicle had really an effect beside graphically (the messages were not mounted to the upper layers).
In sum, to make a transmission range aware scheme, this is what must be done:
In the sender node (vehicle), and similarly to the pointer "traci" which deals with the mobility features, a pointer to the "mac1609" must be created and pointed to it as follows:
In "tracidemo11p.h" add ->
#include "veins/modules/mac/ieee80211p/Mac1609_4.h"//added
#include "veins/base/utils/FindModule.h"//added
and as a protected variable in the class of "tracidemo11p" in the same ".h" file ->
Mac1609_4* mac;//added
In "tracidemo11p.cc" add ->
mac = FindModule<Mac1609_4*>::findSubModule(getParentModule());
now you can manipulate "mac" as in "traci", the appropriate methods are in the "modules/mac/ieee80211p/Mac1609_4.cc & .h"
for our work, the method will be:
mac->setTxPower(10);//for example
This will have an impact on the simulation in real-time for each node instance.
It may had described it with basic concepts because I am new to omnet-veins, these was done in less than one week (and will be provided for new users as well).
I hope it will be helpful (and correct)
I need to reduce the coverage area of communication between vehicles. Should I reduce values of these parameters in omnetpp.ini?
*.**.nic.phy80211p.sensitivity = -89dBm
*.**.nic.phy80211p.maxTXPower = 10mW
*.**.nic.phy80211p.thermalNoise = -110dBm
If not, which parameters can I modify please?
If by coverage area you mean communication range, the short answer is yes, you can modify these parameters to reduce the communication range (which I'd probably do by lowering the maximum transmission power). Alternatively, you can change the channel properties (in config.xml) by adding a corresponding analog model that has the behavior you're looking for. I recommend having a look at the Two-Ray Interference model and the Obstacle Shadowing model, which are part of VEINS.
In the current Veins version (i.e. 4.5) you can also reduce the maxInterfDist of the ConnectionManager which will result in overall less vehicles getting an AirFrame given to their NICs which they then try to decode. However, this only decreases the distance of the best possible communication (i.e. without buildings in LOS, etc.) and not the average distance which usually is way smaller due to fading effects and buildings.
in my opinion, the maxTXPower and maxInterfDist do not affect the coverage area between vehicles. You should modify the "..nic.mac1609_4.txPower" and "..nic.phy80211p.sensitivity". For a better understanding, you may check the answer from Christoph Sommer in this thread: how to set the transmission range of a node under Veins 2.0?
My project is to build a VANET-based smart parking simulation for a small-scale urban area. I dynamically define a route for vehicles to traverse to, then park for 'x' amount of time. Implementation for that is complete, the next step was to define a new exit route for them to exit the simulation after the 'x' amount of time is up. Reason being is that I want to simulate cars vacating parking spaces so that other vehicles may be able to avail of them (I don't want them to simply just to disappear upon reaching the end of their route)
So my question is, is it true that they just exit simulation after route is complete? Is it possible to avoid this?
Veins uses SUMO to simulate vehicle mobility. After a SUMO vehicle reaches the end of its route, it is removed from the simulation. You can, however, use SUMO to simulate a vehicle that drives to an intermediate point, parks for a set duration, then starts driving to its final destination. Such a vehicle will simply be marked as stopped/parking and will remain in the simulation.
My field of study is about travel time of cars so to evaluate my proposed methods it's very important to know how much time it takes for each individual car to reach to its destination
I use Veins 3.0, Sumo0.21.0 and Omnet++ 4.6 for simulation. I record destination of each car and base on their position, I record the exit time when a car reaches to its destination.
Is there a straightforward way to get notified when a car left the simulation?
Veins 3.0 already records several metrics in each TraCIMobility module. Among them are each vehicle's startTime, stopTime, and totalTime in the simulation.
Vehicles get removed from the simulation when they arrive. This means that, if you want to execute arbitrary code when a vehicle leaves the simulation, you can just add this code to the finish method of any module contained in the vehicle.
I'm not sure if the title is right but...
I want to animate (with html + canvas + javascript) a section of a road with a given density/flow/speed configuration. For that, I need to have a "source" of vehicles in one end, and a "sink" in the other end. Then, a certain parameter would determine how many vehicles per time unit are created, and their (constant) speed. Then, I guess I should have a "clock" loop, to increment the position of the vehicles at a given frame-rate. Preferrably, a user could change some values in a form, and the running animation would update accordingly.
The end result should be a (much more sophisticated, hopefully) variation of this (sorry for the blinking):
Actually this is a very common problem, there are thousands of screen-savers that use this effect, most notably the "star field", which has parameters for star generation and star movement. So, I believe there must be some "design pattern", or more widespread form (maybe even a name) for this algoritm. What would solve my problem would be some example or tutorial on how to achieve this with common control flows (loops, counters, ifs).
Any idea is much appreciated!
I'm not sure of your question, this doesn't seem an algorithm question, more like programming advice. I have a game which needs exactly this (for monsters not cars), this is what I did. It is in a sort of .Net psuedocode but similar stuff exists in other environments.
If you are running an animation by hand, you essentially need a "game-loop".
while (noinput):
timenow = getsystemtime();
timedelta = timenow - timeprevious;
update_object_positions(timedelta);
draw_stuff_to_screen();
timeprevious = timenow;
noinput = check_for_input()
The update_object_positions(timedelta) moves everything along timedelta, which is how long since this loop last executed. It will run flat-out redrawing every timedelta. If you want it to run at a constant speed, say once every 20 mS, you can stick in a thread.sleep(20-timedelta) to pad out the time to 20mS.
Returning to your question. I had a car class that included its speed, lane, type etc as well as the time it appears. I had a finite number of "cars" so these were pre-generated. I held these in a list which I sorted by the time they appeared. Then in the update_object_position(time) routine, I saw if the next car had a start time before the current time, and if so I popped cars off the list until the first (next) car had a start time in the future.
You want (I guess) an infinite number of cars. This requires only a slight variation. Generate the first car for each lane, record its start time. When you call update_object_position(), if you start a car, find the next car for that lane and its time and make that the next car. If you have patterns that you want to repeat, generate the whole pattern in one go into a list, and then generate a new pattern when that list is emptied. This would also work well in terms of letting users specify variable pattern flows.
Finally, have you looked at what happens in real traffic flows as the volume mounts? Random small braking activities cause cars behind to slightly over-react, and as the slight over-reactions accumulate it turns into cars completely stopping a kilometre back up the road. Its quite strange, and so might be a great effect in your wallpaper/screensaver whatever as well as being a proper simulation.