The Veins tutorial has all the necessary information to run a basic simulation of a vehicular network. A high level overview of Veins is given in the Veins documentation. The next steps depend on what you want to do.
For creating own simulations, you will need to learn how to use OMNeT++. Excellent tutorials, videos, and a comprehensive user manual are available on the documentation pages on the OMNeT++ website.
If you know how to use OMNeT++ and want to write custom simulation modules (e.g., for new applications), you might find an API documenation of the Veins simulation module library helpful.
It can be created from the IDE, by clicking Project > Generate NED Documentation..., or from the command line, by running
To start reading the module documenation, open
doc/index.html in your browser.
If you use one of the available road traffic scenarios, there is no need to learn much about SUMO. If you want to run your simulations on custom road maps, you will need to learn how to use SUMO, though. SUMO comes with an excellent tutorial (Hello SUMO) and an extensive online user manual, available on the documentation pages on the SUMO website.
If you want to implement new TraCI commands for interacting with (or getting data from) the running road traffic simulation, the SUMO TraCI documentation has a list of available commands.
We are trying to build an interactive repository of questions and answers on Stack Overflow. If you cannot find an answer to your question on there, feel free to add it to the list (tagging it as OMNeT++ and Veins so fellow users can benefit from an answer). Your participation in answering existing questions or improving answers would also be highly appreciated. There is also a wealth of answers on the OMNeT++ Google Group (if you seek help with network simulation, not road traffic simulation, as well as using OMNeT++ in general as opposed to Veins in particular).
Before you ask, though, please make sure you've read through and followed the Veins tutorial closely. If you need help with the tutorial, make sure to state which steps worked and which step is giving you problems. If you need help with more advanced topics, please make sure to mention that you were able to follow the tutorial.
Please follow this with steps to reproduce the problem, i.e., which versions of OMNeT++ and SUMO you are using. Be aware that, during the development of Veins, various parts and versions of its components have been copied into other model libraries and frameworks. If you are using one of these instead of Veins, please give the name and version of the framework you are using. Finally, if you are experiencing a crash, make sure you include the actual error message from the debug logs (see next question).
Simulations using Veins run three programs in parallel: OMNeT++ runs the network simulation, SUMO runs the road traffic simulation, and sumo-launchd acts as a proxy between both. Consequently, the first step should be finding out which program crashed.
Debug output for sumo-launchd can be found on the console, as well as in its log file. Please refer to its --verbose and --logfile parameters for controlling how much (and where) information is written.
Debug output for SUMO (both stdout and stderr) is captured by sumo-launchd and stored in its log files (see above).
Finally, debug output for OMNeT++ can be found on the console (immediately before the "simulation terminated" line). You can get more in-depth information by enabling debug-on-errors and running the simulation with a debugger attached (see below).
When running in the OMNeT++ GUI, a simulation is paused while OMNeT++ is animating message transmissions and method calls. Turn off "animate method calls" in "Options > Simulation Options > Animation" and the simulation will run as smoothly as you would expect. If you do not need to interact with your simulation, running it in the OMNeT++ command line environment (Cmdenv) instead of graphically will also speed up execution.
By default, simulations are compiled in debug mode. As usual, this generates slower code -- in the case of Veins, up to an order of magnitude. To create a release mode command line build, set the environment variable 'MODE=release'. Binaries should now be in 'out/gcc-release' -- if they are not, something went wrong.
First off, check the output of the sumo-launchd to see whether it registered a connection attempt and whether it was able to launch SUMO. If this doesn't help, check your personal firewall and make sure that processes on your machine are allowed to connect to each other via TCP.
The general consensus on the mailing list is that this is due to a conflict of two different versions of python being installed (one comes with OMNeT++, one might have been installed already) and a mix of both python installations being used.
People have reported success with either uninstalling one version of python, running
python sumo-launchd.py, or
If you want to create a stack trace for the point where your simulation raises an error, you will first need to instruct OMNeT++ to break into a debugger (instead of aborting the simulation) when this happens.
To do this, set
debug-on-errors = true in your omnetpp.ini file.
If you know how to run your simulation from a terminal window, you can load the simulation in gdb using the included
You can then start your simulation with the
run command and create a stack trace with the
If you do not know how to run your simulation from a terminal window, you can learn the required commands by launching your simulation from the OMNeT++ IDE and closely watching the first lines appearing in the Console view.
If you do not want to run your simulation from a terminal window, you can use the simple graphical debugging interface provided by the OMNeT++ IDE. To run your simulation using this interface, follow the steps outlined in the video below. After your simulation stops, you can then use the "Copy Stack" command in the Debug view to copy a stack trace of the selected process to your clipboard.
SUMO and OMNeT++ use different coordinate systems. First, coordinates (0,0) are assigned to the bottom left corner for SUMO, to the top left corner for OMNeT++. Secondly, some SUMO maps use non-normalized coordinates (e.g., going from x=700000 to x=700010); the simulation canvas in OMNeT++ always includes (0,0). Finally, some SUMO maps use negative coordinates; simulations in OMNeT++ are restricted to using positive coordinates only.
For these reasons, coordinate transformation needs to take place when both simulators are coupled. The Veins TraCI modules transparently perform this transformation (using internal methods omnet2traci and traci2omnet).
This is why the coordinates returned by them are different from the ones you see in SUMO.
Vehicle movement is governed by SUMO. Its documentation has nice tutorials on creating custom road networks. When using this network in Veins, just make sure to list all required filenames in the .launch.xml configuration file of sumo-launchd.
Starting with Veins 4, it is possible to combine modules of both Veins and other simulation module libraries into one simulation. Some examples of ready-made combined frameworks (e.g., for including LTE or ETSI ITS-G5) can be found on the modules page.
Note that such other module libraries for wireless communication typically rely on their own modules to know where (and, for example, how far apart) the simulated hosts are. Thus, the mobility simulated in Veins will not automatically be reflected in these module libraries.
A special exception is the INET Framework:
Veins can be configured using either the
--with-inet option to
./configure or the corresponding OMNeT++ project features from the IDE.
If Veins detects that a host contains its
TraCIMobility module from the INET Framework module library it will update the host position in there as well.
This makes it possible to create a car using the complete INET Framework stack -- for example using TCP/IP or UDP over Wi-Fi.
If you are not already familiar with the OMNeT++ tutorials, you might want to do these first to get a feeling of how to implement protocols in OMNeT++. In order to get to know the specifics of Veins, the small sample protocol (in src/modules/application/traci/TraCIDemo11p.cc) and simulation (in /examples/veins) that come with Veins should serve as a good starting point.
It seems like the version of the Eclipse CDT that the OMNeT++ IDE builds on does its own error checking (independent of the compiler) when opening files.
This is one of the cases where the CDT reports an error in the source code, while the OMNeT++ IDE will compile the same source code just fine.
The only workaround I know is to choose to "build anyway" when this error message pops up.
This can be done by configuring a "Region of Interest (ROI)" for the TraCIScenarioManager. If you specify one or more rectangular areas as ROIs, only vehicles in these areas will be simulated in OMNeT++.
Please point your readers to the IEEE Transactions on Mobile Computing article highlighted in the Publications section. It contains all the necessary background information, an extensive list of references to related approaches, as well as a link to this website.