Veins

The Platooning Extension for Veins.

FAQ

  • Why aren't there tarballs for sources anymore?: I put source tarballs for the first version because I thought it would have been quicker for people to download the sources if they don't have git installed. However, if the user makes changes to the original code and wants to upgrade a newer Plexe version, he/she would need to 1) re-download the entire source code, 2) manually re-apply the changes, and 3) re-compile the entire source code. By using git, he/she would only need to 1) download only the updates (which is done by git automatically), 2) merge his/her changes (also done with git), and 3) only re-compile the updates. Just think about the examples in the tutorial section: To run those the user would need to download two times the Plexe-SUMO code and three times the Plexe-Veins code, put the code in different source directories, and completely re-compile all the code. Another reason is for deployment on simulation clusters. Most probably you will not run Plexe simulations on your laptop, because simulating hundreds of vehicles is a heavy task which requires computational power. Your simulations will need to run on your computational cluster, and with git deploying your code on the servers will be a matter of seconds. Manually copying the entire source directory is extremely inefficient, error-prone, and will take you a lot of time. If you still want to download the code without using git you can still download ZIP files from the Download section. Be aware that this is, however, highly discouraged.
  • The latest Plexe SUMO update downloads me more than 100 MB of data: Unfortunately, SUMO developers use subversion to version their code. Then there is a git mirror of the SUMO svn maintained by Planet SUMO using git-svn from which we fetch SUMO updates. If something goes wrong in the original subversion repository and the developers delete and re-build the repo, then git-svn gets "lost", and thinks that old commits are completely new commits, causing git to re-add all commits to its history. This obviously "explodes" the repository, resulting in huge (and useless) updates. Unfortunately, I have no control on this.
  • I upgraded Plexe SUMO using git and now SUMO does not start anymore (command not found): Since SUMO version 0.25.0, the main SUMO source folder moved down one level. If you look into your plexe-sumo folder you will see there is nothing inside but a sumo folder, under which everything has been moved. Clearly now the binaries (which were under ~/src/plexe-sumo/bin) cannot be found by the system anymore. I have no idea why this has been done, but you can fix this in two ways. Either change your PATH to point to the new bin directory (~/src/plexe-sumo/sumo/bin) or create a symbolic link like
    cd ~/src/plexe-sumo
    ln -s sumo/bin bin
    
    The choice is up to you.
  • Where can I find help?: Besides the official documentation and the examples, there is no official help space. However, you might want to have a look at the OMNeT++ mailing list. There some people already asked for help on Plexe. Just put "Plexe" in the object of your question for searchability reasons.
  • I want to implement scenario XYZ. Which source files should I change?: There is no simple answer to this question. I provide you with a documentation which explains you how the simulator is built and with some example scenarios. Unfortunately, I cannot provide an example for each and every possible scenario in the world. Moreover, to implement a scenario you might need to implement your own source files. For example, if you want to implement a large scenario with a distributed protocol to organize platoons, you will need to implement the protocol and how vehicle reacts to protocol directives. My suggestion is to 1) understand the DES philosophy and how OMNeT++ works, 2) understand how Veins and SUMO work, and 3) read the Plexe documentation to understand Plexe. Once you understood the concepts behind the simulator, it will be straightforward to implement new scenarios.
  • I changed some simulation parameters expecting vehicles to crash, but they don't: Are you sure they should crash? CACCs can react very fast to changes in dynamics thanks to their wireless data-sharing principle. In the sample simulations vehicles send beacons with a rate of 10 Hz, and if those packets are not lost (which is the case for the sample scenarios) they might be perfectly capable of "handling the situation". Please refer to the original papers for the controllers implemented in Plexe to understand the proposed control algorithm, its parameters, and its characteristics [1,2,3].
  • Why are there no packet losses in the example scenarios?: In the sample scenario you have only 8 vehicles, using a transmit power of 20 dBm, a physical layer datarate of 6 Mbps, and they send only 10 packets per second. Under these conditions, the channel load is minimal, and the stochastic BER model will not loose any of those packets. To have packet losses you can either increase the number of vehicles in the simulation, or change the packetLossRate parameter of the UnicastProtocol class. You might also want to have a look at the Veins documentation to understand the implemented channel, PHY, and MAC models.
  • I can't find the examples/sinPlatoon folder anymore: The new examples include a sinusoidal and a braking scenario, so the name sinPlatoon did not match anymore. Now you find the main example in the examples/platooning folder, plus another example in examples/engine that will show you the new engine model.
  • I would like to debug Plexe-Veins and Plexe-SUMO: The first required step is to compile Plexe-Veins and/or Plexe-SUMO in debug mode, depending on which one you want to debug (maybe both at the same time). To do this:
    cd ~/src/plexe-veins
    make -j <number of cores of your PC> MODE=debug
    cd ~/src/plexe-sumo
    ./configure --enable-debug
    make clean
    make -j <number of cores of your PC>

    Then you can debug Plexe-Veins or Plexe-SUMO in two ways. The first is through the IDE. For Plexe-Veins, if you imported the source project inside the OMNeT++ IDE, you can create a new debug configuration by clicking on Run, Debug configurations.... Click on OMNeT++ Simulation and the on New launch configuration. Given a new name to the configuration and set the working directory to the folder where your omnetpp.ini is (e.g., /veins/examples/platooning), choose the configuration (e.g., Sinusoidal) and the run number (e.g., 2). Click on Cmdenv, then on Apply, then on Debug. This will start your simulation in debug mode in the GUI where you can set breakpoints, step into the code, look at variables' value, etc. For Plexe-SUMO, you need to create a project inside the Eclipse CDT IDE, and then create a new debug configuration as in the OMNeT++ IDE. This time, however, you need to choose a C/C++ Attach to Application configuration because Plexe-SUMO is launched by Plexe-Veins automatically and not by the Eclipse IDE.

    The second way is from command line. For Plexe-Veins simply launch your simulation using ./debug instead of ./run. This will launch gdb that can be used to perform debugging. For Plexe-SUMO you will need to launch gdb (or lldb) from your terminal and then attach to the PID of the Plexe-SUMO instance.

  • When I switch branches or compile in debug mode, recompiling everything takes a lot: Due to the fact that recompiling in debug mode substitutes your object files (.o), every time you switch mode you are recompiling everything from scratch. To speed up this process I recommend using ccache. ccache caches your object files depending on the compiler invocation. For example, if you invoke g++ source.cc -o source.o (release) and then g++ -g source.cc -o source.o (debug), ccache will memorize in its cache the two different source.o object files. When invoking the same commands again, if source.cc is unchanged, ccache will not invoke the compiler but simply take the cached version of source.o. This dramatically decreases your compiling time. You will still need to build the source code in release and debug mode once, but then the process will be much faster (just let it compile the source code just before leaving your office for lunch (or dinner)!). To feel the difference, install ccache, then build Plexe-Veins. Now type make clean to delete all object files and re-compile it again. Very fast ah?
  • The OMNeT++ IDE returns the error libplexe-veins.so not found when running the simulation: For some reason I still have to figure out, the OMNeT++ IDE searches for the Veins shared library with a name like lib + name of the OMNeT++ project + .so. However, the build procedure always generates a shared library named libveins.so, which is why you get the error. The "quickest-and-dirtiest" solution is to rename your project in the OMNeT++ IDE as veins.
  • On MacOS the SUMO GUI crashes immediately after starting the simulation: This is probably due to an upgrade to libFOX. Please see the building for MacOS section for a fix.

References

  • [1]: J. Ploeg, B. Scheepers, E. van Nunen, N. van de Wouv, and H. Nijmeijer, "Design and Experimental Evaluation of Cooperative Adaptive Cruise Control," Proceedings of IEEE International Conference on Intelligent Transportation Systems (ITSC 2011), Washington, DC, October 2011, pp. 260-265. [paper at ieeexplore.ieee.org]
  • [2]: R. Rajamani, H. S. Tan, B. K. Law, and W. B. Zhang "Demonstration of Integrated Longitudinal and Lateral Control for the Operation of Automated Vehicles in Platoons,," IEEE Transactions on Control Systems Technology, vol. 8 (4), pp. 695-708, July 2000. [paper at ieeexplore.ieee.org]
  • [3]: S. Santini, A. Salvi, A. S. Valente, A. Pescapè, M. Segata, and R. Lo Cigno, "A Consensus-based Approach for Platooning with Inter-Vehicular Communications," Proceedings of 34th IEEE Conference on Computer Communications (INFOCOM 2015), Hong Kong, China, April 2015, pp. 1158-1166. [paper at ccs-labs.org]