gitinstalled. 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
gitautomatically), 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
gitdeploying 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
gityou can still download
ZIPfiles from the Download section. Be aware that this is, however, highly discouraged.
subversionto version their code. Then there is a
gitmirror of the SUMO
svnmaintained by Planet SUMO using
git-svnfrom which we fetch SUMO updates. If something goes wrong in the original
subversionrepository and the developers delete and re-build the repo, then
git-svngets "lost", and thinks that old commits are completely new commits, causing
gitto 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.
gitand 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-sumofolder you will see there is nothing inside but a
sumofolder, 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
PATHto point to the new
~/src/plexe-sumo/sumo/bin) or create a symbolic link like
cd ~/src/plexe-sumo ln -s sumo/bin binThe choice is up to you.
packetLossRateparameter of the
UnicastProtocolclass. You might also want to have a look at the Veins documentation to understand the implemented channel, PHY, and MAC models.
examples/sinPlatoonfolder anymore: The new examples include a sinusoidal and a braking scenario, so the name
sinPlatoondid not match anymore. Now you find the main example in the
examples/platooningfolder, plus another example in
examples/enginethat will show you the new engine model.
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
lldb) from your terminal and then attach to the PID of the Plexe-SUMO instance.
.o), every time you switch mode you are recompiling everything from scratch. To speed up this process I recommend using ccache.
ccachecaches 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),
ccachewill memorize in its cache the two different
source.oobject files. When invoking the same commands again, if
ccachewill 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 cleanto delete all object files and re-compile it again. Very fast ah?
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