I am doing some simulations using the Veins framework (with the RSU scenario). I defined two accidents for node[*0] as shown in the code below. However, node[*0] sends WSM message to neighboring nodes (i.e., vehicles and RSU) only for the first accident. When it arrives to the second accident, it stops for a while but does not send any message. I further tested this by scheduling more accidents, but the message is still sent/broadcasted only for the first accident. My question is, why node[*0] is not sending WSM message when it arrives to each of the other scheduled accidents? I would greatly appreciate it if someone could help me clarifying this issue. Thank you.
*.node[*0].veinsmobility.accidentCount = 2
*.node[*0].veinsmobility.accidentStart = 60s
*.node[*0].veinsmobility.accidentDuration = 40s
*.node[*0].veinsmobility.accidentInterval = 70s
The application used in the Veins example simulation is https://github.com/sommer/veins/blob/veins-5.2/src/veins/modules/application/traci/TraCIDemo11p.cc#L96. As you can see, it uses a bool member to track whether it has already sent a message and, if it has, refuses to send another.
Related
I am working on a project where an RSU sends beacons to the cars in its range .When this beacon is received by the car it should send its id back to the RSU.I made a custom message file with just the vehicle id in it.This is how i am handling the beacons now.
void MyVeinsApp::onBSM(DemoSafetyMessage* bsm)
{
findHost()->getDisplayString().setTagArg("i", 1, "green");
if(sentMessage==false){
sendDown(bsm);
//scheduleAt(simTime() + 2 + uniform(0.01, 0.2), wsm->dup());
sentMessage=true;
}
}
This does not work for me at all.Is there any way I can send messages from cars to RSU?
I am not an expert but i recently started working on a similar project with yours. So your message includes a parameter like, let say, vehicle_id and upon receiving a beacon you have to send the message to the RSU with the id include. To do such thing you have to first of all fill the message with the vehicle id like
bsm->setVehicle_id(findHost()->getIndex());
When you create a new message file with variables inside it and then building it the program also creates the get() and set() functions in order to handle those parameters.
Now for the RSU to simply acquire the message variable you have sent it must call the get() function like:
RSU_vehicle_id=wsm->getVehicle_id();
So now you have a variable that includes the received vehicle node id.
I highly suggest you to offer a couple of day just to understand the principles behind the Veins tutorial and how it handles all its aspects.
Let me give a brief context first:
I have a scenario where the RSUs will broadcast a fixed message 'RSUmessage' about every TRSU seconds. I have implemented the following code for RSU broadcast (also, these fixed messages have Psid = -100 to differentiate them from others):
void TraCIDemoRSU11p::handleSelfMsg(cMessage* msg) {
if (WaveShortMessage* wsm = dynamic_cast<WaveShortMessage*>(msg)) {
if(wsm->getPsid()==-100){
sendDown(RSUmessage->dup());
scheduleAt(simTime() + trsu +uniform(0.02, 0.05), RSUmessage);
}
}
else {
BaseWaveApplLayer::handleSelfMsg(wsm);
}
}
A car can receive these messages from other cars as well as RSUs. RSUs discard the messages received from cars. The cars will receive multiple such messages, do some comparison stuff and periodically broadcast a similar type of message : 'aggregatedMessage' per interval Tcar. aggregatedMessage also have Psid=-100 ,so that the message can be differentiated from other messages easily.
I am scheduling the car events using self messages. (Though it could have been done inside handlePositionUpdate I believe). The handleSelfMsg of a car is following:
void TraCIDemo11p::handleSelfMsg(cMessage* msg) {
if (WaveShortMessage* wsm = dynamic_cast<WaveShortMessage*>(msg)) {
wsm->setSerial(wsm->getSerial() +1);
if (wsm->getPsid() == -100) {
sendDown(aggregatedMessage->dup());
//sendDelayedDown(aggregatedMessage->dup(), simTime()+uniform(0.1,0.5));
scheduleAt(simTime()+tcar+uniform(0.01, 0.05), aggregatedMessage);
}
//send this message on the service channel until the counter is 3 or higher.
//this code only runs when channel switching is enabled
else if (wsm->getSerial() >= 3) {
//stop service advertisements
stopService();
delete(wsm);
}
else {
scheduleAt(simTime()+1, wsm);
}
}
else {
BaseWaveApplLayer::handleSelfMsg(msg);
}
}
PROBLEM: With this setting, the simulation is very very slow. I get about 50 simulation seconds in 5-6 hours or more in Express mode in OMNET GUI. (No. of RSU: 64, Number of Vehicle: 40, around 1kmx1km map)
Also, I am referring to this post. The OP says that he got faster speed by removing the sending of message after each RSU received a message. In my case I cannot remove that, because I need to send out the broadcast messages after each interval.
Question: I think that this slowness is because every node is trying to sendDown messages at the beginning of each simulated second. Is it the case that when all vehicles and nodes schedules and sends message at the same time OMNET slows down? (Makes sense to slow down , but by what degree) But, there are only around 100 nodes overall in the simulation. Surely it cannot be this slow.
What I tried : I tried using sendDelayedDown(wsm->dup(), simTime()+uniform(0.1,0.5)); to spread the sending of the messages through out 1st half of each simulated second. This seems to stop messages piling up at the beginning of each simulation seconds and sped things up a bit, but not so much overall.
Can anybody please let me know if this is normal behavior or whether I am doing something wrong.
Also I apologize for the long post. I could not explain my problem without giving the context.
It seems you are flooding your network with messages: Every message from an RSU gets duplicated and transmitted again by every Car which has received this message. Hence, the computational time increases quadratically with the number of nodes (sender of messages) in your network (every sent message has to be handled by every node which is in range to receive it). The limit of 3 transmissions per message does not seem to help much and, as the comment in the code indicates, is not used at all, if there is no channel switching.
Therefore, if you can not improve/change your code to simply send less messages, you have to live with that. Your little tweak to send the messages in a delayed manner only distributes the messages over one second but does not solve the problem of flooding.
However, there are still some hints you can follow to improve the performance of your simulation:
Compile in release mode: make MODE=Release
Run your simulation in the terminal environment Cmdenv: ./run -u Cmdenv ...
If you need to use the graphical environment by all means, you should at least speed up the animations by using the slider in the upper part of the interface.
Removing the simtime-resolution parameter from the omnetpp.ini file solves the problem.
It seems the simulation kernel has an issue when the channel delay does not match the simulation-time resolution.
You can verify the solution by cloning the following repository. Note that you need a functional installation of the OMNeT++ framework. Specifically, I test this fix in OMNeT++ 5.6.2.
https://github.com/Ryuuba/flooding
I'm doing a scenario where there is 1 route at the beginning and then it splits into 3, then merges into 1 again. I'm stopping the car in the first lane, the second car stops also, the third one reroutes in the middle lane, the fourth goes to the queue, the fifth reroutes, the sixth goes to the queue, the seventh reroutes.....why is it behaving like that? I can't understand where to change this "balancing" or "threshold". Any suggestion?
The Veins 4.6 sample application behaves as follows:
if a vehicle is stopped (and has been driving) and has not yet sent a warning message, it sends a message containing its current road (TraCIDemo11p.cc, line 82)
if a vehicle receives a warning message, it tries to find a new route through the road network that avoids this road (TraCIDemo11p.cc, line 48); in addition, if it has not yet sent a warning message, it re-sends the received message (TraCIDemo11p.cc, line 54)
So, if you use this sample application and observe that some vehicles do not change their route, this can be attributed (among others) to either of the following effects:
they never received a message that told them about the congestion
they received a message, but couldn't find a route through the road network that would avoid the congestion
Why a vehicle did not receive a message can again be attributed (among others) to any of the following:
a warning message was transmitted to them, but they could not receive it (e.g., due to interference)
a warning message was transmitted through the network before they started their trip (remember, warning messages are not repeated by the example application)
I used veins 4a2 and OMNET++ (4.6). I like to know the content of messages exchanged between vehicles in the veins example.
I have consulted waveshortmessage.msg, WaveShortMessage_m.cc and WaveShortMessage_m.h but I have not found messages content.
In waveshortmessage.msg, what means this line "string wsmData = "Some Data"" please?
And in TraCIDemp11p.cc, what means "blockedRoadId" declared in sendMessage function?
The demo application that comes with Veins 4.4 (and 4a2 as well) and that is used for the Veins tutorial reacts to messages that contain the name of a road to avoid because a car has stopped there for longer than 10s (and vice versa: the demo application sends a message when a car is stopped for longer than 10s).
The demo application is defined in TraCIDemo11p. It uses a demo message type, WaveShortMessage, as the container to inform other cars about a blocked road. For this, it stores the name of the blocked road (variable blockedRoadId) in the wsmData field of the message.
I've created a real time game for Google Play Game Services. It's in the later alpha stages right now. I have a question about sendReliableMessage. I've noticed certain cases where the other peer doesn't receive the message. I am aware that there is a callback onRealTimeMessageSent and I have some code in my MainActivity:
#Override
public void onRealTimeMessageSent(int i, int i2, String s) {
if(i== GamesStatusCodes.STATUS_OK)
{
}
else
{
lastMessageStatus=i;
sendToast("lastMessageStatus:"+Integer.toString(lastMessageStatus));
}
}
My games render loop is checking every iteration the value of lastMessageStatus and if there was something other than STATUS_OK I'm painting a T-Rex right now.
My question is is checking the sent status really enough? I also could create source code where the sender has to wait for an Acknowledged message. Each message would be stamped with a UUID and if ack is not received within a timeout then the sender would send the message again? Is an ACK based system necessary to create a persistent connection?
I've noticed certain cases where there is some lag before the opposite peer received the reliable message and I was wondering is there a timeout on the sendReliable message? Google Play Services documentation doesn't seem to indicate in the documentation that there is a timeout at all.
Thank you
Reliable messages are just that, reliable. There are not a lot of use cases for the onRealTimeMessageSent callback for reliable messages because, as you said, it does not guarantee that the recipient has processed the message yet. Only that it was sent.
It may seem annoying, but an ACK-based system is the best way to know for sure that your user has received the message. A UUID is one good way to do this. I have done this myself and found it to work great (although now you have round-trip latency).
As far as timeout, that is not implemented in the RealTime Messaging API. I have personally found round trip latency (send message, receive ACK in callback) to be about 200ms, and I have never found a way to make a message fail to deliver eventually even when purposefully using bad network conditions.