For my simulation I want to find out the count of lines in a single road. I search sumo and viens and there is nothing there. I can retrieves all lanes count in map but what about lanes(lines) in a single road?
You can simply parse the sumo network. It is a quite straightforward XML file. For your specific question there is even support in the sumolib which is a python library coming with sumo.
net = sumolib.net.readNet("netfile")
edge = net.getEdge("edgeID")
numLanes = edge.getLaneNumber()
You can also look here: http://sumo.dlr.de/wiki/Tools/Sumolib
Related
Currently, I am generating vehicles from SUMO and importing into veins. However, now I want to use large number of vehicles (from 100 to 1000) and I want their random generation (e.g., random start time and random speed).
Can anyone help that i) how can I create/generate vehicles from veins instead of SUMO? and ii) how to randomly select start time and speed of vehicles?
Best Regards,
Yasir
This is what https://github.com/sommer/veins/blob/veins-5.1/src/veins/modules/mobility/traci/TraCIVehicleInserter.ned was designed for. Whenever the number of active vehicles in OMNeT++ is less than a configured number, it starts a new vehicle using one of the existing route definitions.
You can use python to generate route files with random seed/random start time.
Refer to runner.py file in https://github.com/eclipse/sumo/blob/master/tests/complex/tutorial/traci_tls/runner.py and to the tutorial in https://sumo.dlr.de/docs/Tutorials/TraCI4Traffic_Lights.html
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 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.
I need to implement TDMA and FDMA based slot assignment protocol. I have written the code for TDMA slot assignment but very much confused about the FDMA part.
Will someone please help me in writing the code for FDMA for a simple scenario. In which two nodes are using full duplex radios and working on two different frequencies. If node1 needs to communicate to node 2 thn node 2 must shift its frequency to node 1 frequency.
I have not worked with the radios yet. In TDMA part i am using senddirect for sending messages.
Kindly help me with the code of FDMA?
You have to use multiple radios in a single host. A good starting point is the example in inet path examples/manetrouting/multiradio. Run the simulation configuration MultiRadio within omnetpp.ini.
I have a mobility model created by SUMO with area around 2 KM * 2 Km for real map.
I want to compute the results for only part of this model. I read that I can use roiroad or roirect.
Roirect take (x1,y1-x2,y2) as Traci coordination, however, I want to use roiroad to take exactly the cars in specific road.
My question is: if the roiroad function take a string of road name , from where in sumo that I can get this value.
should I construct the map again with Netconvert and using --output-street-names
Edges in SUMO always have an ID. It is stored in the id="..." attribute of the <edge> tag. If you convert a network from some other data format (say, OpenStreetMap) to SUMO's XML representation, you have the option to try and use an ID that closely resembles the road name the edge represents (this is the option you mentioned). The default is to allocate a numeric ID.
Other than by opening the road network XML file in a text editor, you can also find the edge ID by opening the network in the SUMO GUI and right clicking on the edge (or by enabling the rendering of edge IDs in the GUI).
Note that, depending on the application you simulate, you will need to make sure that you have no "gaps" in the Regions Of Interest (ROIs) you specify. When a vehicle is no longer in the ROI its corresponding node is removed from the network simulation. Even if the same vehicle later enters another (or the same) ROI, a brand new node will be created. This is particularly important when specifying edges as ROI (via the roiRoads parameter). Keep in mind that SUMO uses edges not just to represent streets, but also to represent lanes crossing intersections. If you do not specify these internal edges, your ROIs will have small gaps at every intersection.
Note also that up until OMNeT++ 5.0, syntax highlighting of the .ini file in the IDE will (mistakenly) display a string containing a # character as if it were a comment. This is just a problem with the syntax highlighting. The simulation will behave as expected. For example, setting the roiRoads parameter to "-5445204#1 :252726232_7 -5445204#2" in the Veins 4.4 example as follows...
...will result in a Veins simulation where only cars on one of the following three edges are simulated:
on the edge leading to the below intersection; or
on the edge crossing the below intersection; or
on the edge leaving the below intersection.