I'm working with veins and OMNeT++ in a scenario that has different types of nodes (cars, pedestrians, and others). For evaluation purposes, I'm getting the std::map using the TraCIScenarioManager::getManagedHosts method based on this post (I also answered one of my related questions).
Now, I want to check the type of each node in the scenario. To be clearer, I want to obtain some kind of list that indicates the type of each node (is it a pedestrian? Is it a bus?). Is there any way to obtain this from the map? Is there any attribute that identifies the node type?
I already can identify the type of nodes through messages adding specifics tags to it, but now I need to obtain the type of node independent of the arrival of messages.
I really appreciate any help you can provide.
TraCIScenarioManager::getManagedHosts returns a std::map<std::string, cModule*> which maps each SUMO identifier to one OMNeT++ cModule*. Depending on how cars, buses, etc differ in your simulation, I can think of multiple ways of figuring out what type of SUMO object a host models.
Maybe they are named differently in SUMO? Then you can use the std::string to tell them apart.
Maybe they are named differently in OMNeT++? Then you can use getFullName() of the cModule* to tell them apart.
Maybe they use different C++ classes as models for their application layers? Then you can use something like getSubmodule() of the cModule* to get a pointer to their application layer module and check if a dynamic_cast<ApplicationOfACar*> of this pointer is successful.
Related
I am trying to write a system to help communication between processes written in golang. The other programmers are expected to provide two identical types to both processes while the system focusses on transporting data encoded by encoding/gob, yet it has to check for whether two types are identical or not in order to avoid human mistakes.
The thing is, is there any way in go that allows me to check whether the two types provided to either processes are exactly the same in each single field name and type, or do I need to figure one out myself?
I want to implement an protocol with two radios switched on different frequencies. Can I just add an additional PhyLayer80211p module in the Nic80211p module?
If so, how do I address them? If I see it correctly, the findModule method used in Mac1609_4.cc:37 has no attribute to specify which Phy-module he should return. That way i can't specify which of the two radios should be set to RadioState TX (as well as which frequency it is set to).
Would it differ automatically between the two channels if i just send a message two the right gate to the phyModule and set them on seperate frequencies before? e.g.
sendDelayed(mac, RADIODELAY_11P, lowerLayerOut); vs. sendDelayed(mac, RADIODELAY_11P, lowerControlLayerOut);
Any other tips? Thanks!
In my default Veins scenario (the one in the example) I need a second antenna on my car. In Car.ned I entered the following code (doing copy and paste from connections block):
nic2.upperLayerOut --> appl2.lowerLayerIn;
nic2.upperLayerIn <-- appl2.lowerLayerOut;
nic2.upperControlOut --> appl2.lowerControlIn;
nic2.upperControlIn <-- appl2.lowerControlOut;
veinsradioIn2 --> nic2.radioIn;
Now I have two antennas on my node (and they work!). But how can I decide who sends and who receives? In this way I just changed the topology of the network, but I can't handle the communications! I need to reach this scenario: node->node (first antenna) and node->RSU (second antenna). I think I should work on TraCIDemo11p.cc and TraCIDemoRSU11p.cc, but the code is immense and I get lost too easily. The final target is to make sure that these two antennas work with different protocols, but at the moment I make do with the same protocol and with these two different channels I mentioned earlier.
It's a bit difficult to give a concise answer to your question, because it has multiple components, but here are some important things you should look at:
First off: right now, what you've done is specified a car with two network interfaces (nic and nic2) and two separate applications (appl and appl2). I think, by your description, that is not what you want. I would suggest that your first step is to create an application interface that has connections to two network interfaces. This means creating the corresponding .ned file. You can use ./veins/modules/application/traci/TraCIDemo11p.ned as an example. Make sure to define your application object appl (in Car.ned) as that .ned file and connect both of these in the way you described. You'll then have 8 channels from your application to the two network interfaces (I'd call them appl.nic1LayerIn, appl.nic1ControlIn, appl.nic2LayerIn and so on).
After that, you will want to write logic that decides whether a particular message should go to the one network interface, or to the other, and put that code in your application's source. To communicate with the different network interfaces you'll just use the respective channels. To see how this works you'll need to dig in the veins source code a little bit: the code interacting with the channels is not directly in the TraCIDemo11p source, but somewhere in a super class there-of (I think it is BaseWaveApplLayer, but I'm not 100% sure). You could either modify those files to work with multiple antennae, or create new source files -- I'm not sure which one is less code, though.
Another thing to remember is that you'll need to provide the corresponding settings in the omnetpp.ini too (*.**.nic2..., analogous to *.**.nic...). I'm not sure what veins will do with two antennae at the same position (it might lead to some weird effects), but I also don't remember where the antenna position is specified.
I want to transmit a given car's vehicular data such as it's vType, instantaneous speed and position to a RSU in a scenario in Veins.
How can I obtain the data from SUMO and send it through MiXiM methods to an RSU node?
To achieve your goal you have to use the TraCIMobility component of Veins.
You can do that by first getting a pointer to that component in the initialize() method of your node
cModule *tmpMobility = getParentModule()->getSubmodule("veinsmobility");
mobility = dynamic_cast<Veins::TraCIMobility*>(tmpMobility);
ASSERT(mobility);
Once you have the mobility component you can query it for various data.
The type of data that it can provide can be found in TraCIMobility.h
For example in your case you could do:
mobility->getCurrentSpeed().length()); /* will provide velocity vector */
mobility->getAngleRad()); /* will provide angle of movement */
Then you can attach this data to your message and send it to the RSU of your choice.
If this exact solution does not work for you that could be due to me using a different Veins version than yours.
However you will certainly find what you need in TraCIDemo11p.cc or TraCIDemoRSU.cc of your Veins project.
Also, TraCICommandInterface is something you should have a look at.
In the official Veins website under the Documentation section it is said:
Application modules can use the TraCICommandInterface class and
related classes, conveniently accessible from TraCIMobility, to
interact with the running simulation. The following example shows how
to make a vehicle aware of slow traffic on a road called Second
Street, potentially causing it to change its route to avoid this road.
mobility = TraCIMobilityAccess().get(getParentModule());
traci = mobility->getCommandInterface();
traciVehicle = mobility->getVehicleCommandInterface();
traciVehicle->changeRoute("Second Street", 3600);
Some of the other vehicle related commands are setSpeed or setParking.
Similar methods are available for the whole simulation (e.g.,
addVehicle, addPolygon), roads (getMeanSpeed), individual lanes
(getShape), traffic lights (setProgram), polygons (setShape), points
of interest, junctions, routes, vehicle types, or the graphical user
interface.
How to use these modules is demonstrated in the source code of the
Veins tutorial example. Again, a list of all 80+ available methods can
be found in TraCICommandInterface.h or the autogenerated module
documentation.
A potentially related question/answer here: https://stackoverflow.com/a/29918148/4786271
I've been reading some books on windows programming in C++ lately, and I have had some confusing understanding of some of the recurring concepts in WinAPI. For example, there are tons of data types that start with the handle keyword'H', are these supposed to be used like pointers? But then there are other data types that start with the pointer keyword 'P'. So I guess not. Then what is it exactly? And why were pointers to some data types given separate data types in the first place? For example, PCHAR could have easily designed to be CHAR*?
Handles used to be pointers in early versions of Windows but are not anymore. Think of them as a "cookie", a unique value that allows Windows to find back a resource that was allocated earlier. Like CreateFile() returns a new handle, you later use it in SetFilePointer() and ReadFile() to read data from that same file. And CloseHandle() to clean up the internal data structure, closing the file as well. Which is the general pattern, one api function to create the resource, one or more to use it and one to destroy it.
Yes, the types that start with P are pointer types. And yes, they are superfluous, it works just as well if you use the * yourself. Not actually sure why C programmers like to declare them, I personally think it reduces code readability and I always avoid them. But do note the compound types, like LPCWSTR, a "long pointer to a constant wide string". The L doesn't mean anything anymore, that dates back to the 16-bit version of Windows. But pointer, const and wide are important. I do use that typedef, not doing so will risk future portability problems. Which is the core reason these typedefs exist.
A handle is the same as a pointer only so far as both ID a particular item. Obviously a pointer is the address of the item so if you know it's structure you can start getting fields in the item. A handle may or may not be a pointer - basically if it is a pointer you don't know what it is pointing to so you can't get into the fields.
Best way to think of a handle is that it is a unique ID for something in the system. When you pass it to something in the system the system will know what to cast it to (if it is a pointer) or how to treat it (if it is just some id or index).