I generated plenty of routes (~90.000+) using SUMO's ACTIVITYGEN/DUAROUTER with a configuration file and different durations (--duration-d 1, --duration-d 7, ...).
The resulting .rou.xml is successfully executed by SUMO without serious errors. Just some warnings about invalid departPos.
But when using Veins, I receive the following error message:
<!> Error in module (Veins::TraCIScenarioManagerLaunchd)
Scenario.manager (id=6) at event #2327172, t=25619.2: Model error:
ASSERT: condition count == drivingVehicleCount false in function
processVehicleSubscription,
veins/modules/mobility/traci/TraCIScenarioManager.cc line 640.
I removed the ASSERT condition and displayed both values. count is always higher than drivingVehicleCount.
The included "veins" example is running without any problems.
I am using:
SUMO 0.22.0
OMNeT++ 4.6
Veins 4 alpha 2.
In addition, I tested Veins 3.0 and receive the same error message.
Did somebody encounter the same problem?
Commenting out the ASSERT is totally fine.
In SUMO any vehicle can have one of five states (according to statesvehicleStates_sm.uxf): first, it is loaded, transitions to running when it starts driving, then transitions to arrived when it arrived at its destination. In addition, running vehicles can temporarily become teleporting or parking.
Veins subscribes to these state changes to keep track of the number of driving vehicles. To make sure that the bookkeeping is correct, it compares its own count against SUMO's reported number of active vehicles.
I do not know why the numbers do not match sometimes. It only seems to occur in large congested networks.
Related
In VEINS 4.4, one can access the current location of the vehicles at the application layer (e.g. TraCIDemo11p) via "Mobility" module which is defined through TraCIMobility.
I followed the same approach to access the Mobility module at the lower layer (MAC1609_4.cc), where I added following statement at the stage 0 of the initialize function:
TraCIMobility* mobility = TraCIMobilityAccess().get(getParentModule());
However, I am not getting any compilation error, but when OMNET throws errors when the simulation starts and it gives following error.
Error in Module (MAC1609_4)
RSUExampleScenario.node[0].nic.mac1609_4(id=12) at event # 2, t = 0.1:
Assert: condition traci false in function get,
\veins/modules/mobility/traci/TraCIMobility.h line 193
I have searched around for different possible solutions, but, I am still unable to solve this problem.
Related posts are:
How to access TraCI command interface from TraCIDemoRSU11p in Veins Car2X simulator?
Transmission of vehicular status in Veins
RoadId() from the BaseWaveApplLayer.cc (VEINS, OMNET++)
How to get Coordinates of each vehicle in VEINS?
You are trying to access a TraCIMobility sub-module in the parent module of the Mac1609_4. This, however, is not the Car but the Nic80211p, which has no such sub-module, hence, the failing assertion.
It should work when you go up one additional layer in the hierarchy, as you then use the Car module as root to find the corresponding sub-module:
TraCIMobility* mobility = TraCIMobilityAccess().get(getParentModule()->getParentModule());
See the Car module and the Nic80211p module for reference:
https://github.com/sommer/veins/blob/veins-4.4/src/veins/nodes/Car.ned
https://github.com/sommer/veins/blob/veins-4.4/src/veins/modules/nic/Nic80211p.ned
I'm using VEINS4.4, OMNeT++ 5.0 and SUMO 0.25
My project involves vehicles to exchange 5 types of messages and # of vehicles is more than 200 , and i some of messages not received by others and when i traced the problem , i discovered that they lost because 'A packet was not received due to biterrors or packet was not received correctly, sending it as control message to upper layer'.
I have found solution in one of sites and i have applied in my code ,and it solved the problem little bit because some messages were lost and now other vehicles received it ,but i have still some other messages are lost and not received by others with same previous error. I need to get rid of this problem, please how ?
The solution that mentioned in one of sites was to add jitters in sending:
1) To add this in initialize :
if (sendBeacon) {
scheduleAt(simTime()+ intuniform(1,3)* (par("beaconInterval").doubleValue()), sendRequestEvt);
}
2) Add this to handle self message :
scheduleAt(simTime()+(par("beaconInterval").doubleValue()), sendRequestEvt);
i have put dblrand() instead of intuniform(1,3) and no differrences
I am using veins4.6 with sumo 0.30 and omnet++5.1.1 in ubuntu 14.04. I have created a custom network with a cross(one intersection with 4 roads) and ran the simulation with 200 vehicles. I did not observe this behaviour for 4vehicles. I have seen it with 50 vehicles too. I need to get the count of total lost packets for my masters project. So I was looking at statistics and found that RXTXLostPackets is not zero. As far as I understood from documentation it should be zero if allowTxDuringRx=false. Default is false(PhyLayer80211p.ned). As I did not change any code yet, I was confused if that is expected behaviour.
What I have done so far.
from Mac1609_4::handleLowerControl, statsTXRXLostPackets is updated when Decider80211p responds with RECWHILESEND.
In Decider80211p::processSignalEnd, if value of whileSending is true RECWHILESEND is sent to mac layer as control message.
In Decider80211p::processSignalEnd, if(frame->getWasTransmitting() || phy11p->getRadioState() == Radio::TX) , this frame was considered as received while sending and sets the value for whileSending as true.
The wasTransmitting varilable is set to true in Decider80211p::switchToTx and Decider80211p::processNewSignal functions.
currentFrame->setWasTransmitting(true);
currentFrame->setBitError(true);
in Decider80211p::processNewSignal:
if (phy11p->getRadioState() == Radio::TX ) {
frame->setBitError(true); --> tried disabling both these values and the RXTXLostPackets was zero.
frame->setWasTransmitting(true);
DBG_D11P << "AirFrame: " << frame->getId() << " (" << recvPower << ") received, while already sending. Setting BitErrors to true" << std::endl;
}
There is one thread with similar issue with the fix of adding this line in processSignalEnd function. But looks like veins4.6 does not use curSyncFrame anymore.
Veins - Unexpected behavior with lost packets in certain vehicles
if (!frame->getWasTransmitting()){
curSyncFrame = 0;
}
I could not clearly understand the issue. The code and configuration files I have used are here. https://github.com/Rajeswar59/veins_learning.
Can anyone please take a look and help me with this. Thanks in advance.
edit: I went through the logs. This is what I could understand as of now.
https://drive.google.com/open?id=0BzjDW8PQhkSmSEUtZ2lpcld4ZXc --> some portion of logs are here.
---> order of sending
#13332 0.247987176594 node[30] --> node[48] id=22266
#13375 0.247987796864 node[18] --> node[20] id=22447
#13384 0.247987864534 node[20] --> node[30] id=22573
From logs I have concentrated on node 18. Two nodes that transmitted before 30 are 32 and 4. These 2 messages are received successfully by all 3 nodes. When a message arrives decider tries to set channel state as busy in processnewsignal and set idle after processing packet. This calls mac1609_4.cc channelBusy and channelIdle functions respectively. So the channelIdle variable is set accordingly. Also if channel is to be set busy it will stop contention and calculate currentBackoff if any packet is waiting to be transmitted. If channel is being set idle at the end of reception, startContent is called. Based on this only the lastIdle variable is set which is used to calculate nextMacEvent. So when the last successful message was received all the nodes which have a packet to send decide nextMacEvent and it is sent as self message in Mac1609_4.cc. on receiving the nextMacEvent self message we will start transmitting without checking if any other node has started transmission. We can not identify that probably because we are setting channel busy when we receive messages after some propagation delay. So between last successful transmission and nextMacEvent other nodes also take decision to transmit without checking current channel state. That's why the node has some receive events while sending. As far as my understanding goes before transmission we should sense current state of channel and retry backoff accordingly. We do not check this at the nextMacEvent. It looks like a collision behaviour but should we not check the current state of channel when backoff counter reaches zero and retry. Please correct me if I am wrong anywhere.
Thanks for your patience.
Any help or advice??
My Learnings(probably last update):
After Some digging, these are my learnings if it helps some one. The basic CSMA mechanism says before attempting for transmission, the node has to sense the channel, initiate transmission if the channel is sensed idle for AIFS time, or go in to back off if channel is busy. In veins the channel busy status is stored in idleChannel variable whose status is checked in Mac1609_4:channelBusySelf() function before initiating transmission (nextMacEvent in Mac1609_4::handleSelfMsg). The idleChannel is updated in Mac1609_4::channelBusy and Mac1609_4::channelIdle functions when a message reception starts and when message reception ends respectively. So when a previously transmitting node sends a packet, all the recieving nodes will receive the packet with varying delay i.e., starts receiving at different times and update their channelIdle variable. After that they calculate best time to transmit and starts transmission. It does check if channel is idle or not but as the channelIdle status is updated at next reception and because of transmission delay it takes some time between transmission start at sender and reception start at receiver side, both the transmitting nodes cant see other transmission. As far as I understand this is called a collision when more than two nodes start transmission at the same time. So the BitError statistic is set and statsTXRXLostPackets is also set. So while calculating totalLostPackets we can take only one of these two values.
I use Veins-4a2 and I have modified the scenario of the demo example. When I executed the simulation, I had this error:
Error in module (Veins::ObstacleControl) RSUExampleScenario.obstacles (id=2) at event #22, t=0.037209: Model error: ASSERT: condition (intersectAt.size() % 2) == 0 false in function calculateAttenuation, veins/modules/obstacle/Obstacle.cc line 127.
Why this error was happened? Can you please help me to
There is a known bug in Veins versions up to 4.4, where sometimes a corner case is triggered that results in the number of walls between sender and receiver being off by one. To guarantee that either correct results or no results are returned, the simulation is aborted if such a case is detected.
If this happens only a few times during a large simulation, you might simply want to remove this ASSERT statement.
If this happens a lot, your obstacle definitions are likely wrong (e.g., a building with only two walls)
I tried to solve the problem, but I got a different table than the table that xilinx shows. I attatched both my answer and real answer. Xilinx shows that "out" is 'U' until 36ns, after 36ns, it is '1'. Can anyone help me about why the "out" graphics is not assigned any value before 36ns?(I think it should be assigned first at 20 ns).
my answer
question
This turned out to be a really good question. I initially thought you had done something wrong when simulating, but then I ran my own simulation and got the same result.
It turns out that the a <= b after x assignment uses something called the "inertial time model" by default. In this mode scheduled events will be cancelled if b changes again before x time has passed. The purpose is to filter pulses shorter than the specified delay. In your case this is what the simulator will do:
At t=0, out is scheduled to change to 1 at t=20.
At t=12, tem1 or tem2 changes to 0. The scheduled change at t=20 is cancelled and a new change to 0 is scheduled at t=32.
At t=16, tem1 or tem2 changes back to 1. Again the scheduled change is cancelled and a new change is scheduled at t=36.
After this tem1 or tem2 remains at 1, so the change at t=36 is executed and out finally changes from U.
You can change to the "transport delay model" using out <= transport tem1 or tem2 after 20 ns; In this case your drawn waveform will match with simulation.