I just edited my map and i can run it with 100 car using SUMO.. Now i want to launch this map and these cars with omnet++ i created launch file .. and going to ini file and set the launch file
Config DSRUU-City]
description = "DSRUU"
*.numHosts = 100
*.manager.launchConfig = xmldoc("..\\_maps\\Mapsprojec\\City.launchd.xml")
*.**.nic.phy80211p.decider = xmldoc("..\\_maps\\Mapsprojec\\config.xml")
*.**.nic.phy80211p.analogueModels = xmldoc("..\\_maps\\Mapsprojec\\config.xml")
*.playgroundSizeX =3000
*.playgroundSizeY =3000
*.playgroundSizeZ = 50m
**.roiRects = "0,100-2200,2000"#x,y-X,Y
My problem, When i run the simulation, i can't see the cars as node inside the omnet++ although i can see them in the sumo gui in the same time .. So how i can solve this issue ... So i should see the cars as node in the omnet++ and as car in the sumo ? .. Thanks in advance ...
Make sure to enable the drawing of annotations in your omnetpp.ini by adding (or modifying) the line:
*.annotations.draw = true
Related
I am new to Omnet and Inet.
I am modifying the network TsnLinearNetwork which is part of the Inet Library and looks like the following:
Client <-------> Switch <-------> Server
The client sends a continuous packet stream which the switch forwards to the server.
I am trying to set up a Periodic Gate which changes its state, so that the packets won't get forwarded, if the gate is closed.
The 1st second the gate should be closed and the 2nd second it should be open.
As a result the gate status changes which I configured in the omnetpp.ini file.
In contrast to that, the packets are forwarded even on a closed gate state.
I played around with the omnet.ini parameters without any success.
I am expecting that the packets are discarded when the periodic gate state is closed.
Like the documentation points out:
PeriodicGate
This module allows or forbids packets to pass through depending on whether the gate is open or closed. The gate is open and closed according to the list of change times periodically.
So here my questions:
Why are the packets forwarded even on a closed gate state?
How can I achieve that behaviour?
omnetpp.ini
[General]
[simpleStart03]
network = simpleStart
sim-time-limit = 2s
*.client.numApps = 1
*.client.app[*].typename = "UdpSourceApp"
*.client.app[0].display-name = "random traffic"
*.client.app[*].io.destAddress = "server"
*.client.app[0].io.destPort = 1000
*.client.app[0].source.packetLength = 1000B
*.client.app[0].source.productionInterval = 500us
*.client.hasOutgoingStreams = true
*.client.bridging.streamIdentifier.identifier.mapping = [{stream: "random traffic"}]
*.client.bridging.streamCoder.encoder.mapping = [{stream: "random traffic", pcp: 0}]
*.server.numApps = 1
*.server.app[*].typename = "UdpSinkApp"
*.server.app[0].io.localPort = 1000
*.switch.bridging.streamCoder.decoder.mapping = [{pcp: 0, stream: "random traffic"}]
*.switch.hasIngressTrafficFiltering = true
*.switch.bridging.streamFilter.ingress.numGates = 1
*.switch.bridging.streamFilter.ingress.numMeters = 1
*.switch.bridging.streamFilter.ingress.numStreams = 1
*.switch.bridging.streamFilter.ingress.classifier.mapping = {"random traffic": 0}
*.switch.bridging.streamFilter.ingress.meter[0].display-name = "random traffic"
*.switch.bridging.streamFilter.ingress.meter[*].typename = "SingleRateTwoColorMeter"
*.switch.bridging.streamFilter.ingress.meter[0].committedInformationRate = 40Mbps
*.switch.bridging.streamFilter.ingress.meter[0].committedBurstSize = 10kB
*.switch.bridging.streamFilter.ingress.gate[*].typename = "PeriodicGate"
*.switch.bridging.streamFilter.ingress.gate[0].display-name = "random traffic"
*.switch.bridging.streamFilter.ingress.gate[0].initiallyOpen = false
*.switch.bridging.streamFilter.ingress.gate[0].durations = [1s,1s]
*.switch.bridging.streamFilter.ingress.gate[*].initiallyOpen = false
omnetpp.ned
import inet.networks.tsn.TsnLinearNetwork;
network simpleStart extends TsnLinearNetwork
{
}
omnet Version: 6.0.1
Inet Version: inet4.4
This issue was stated as a bug
https://github.com/inet-framework/inet/issues/830
The bug is that the classifier doesn't check that the selected gate index can be pushed with the packet or not. In case the selected branch has back pressure then the default branch should be selected. If the default branch also has back pressure then an error should be raised.
This Commit fixes the issue and this commit changes the order of the submodules.
I am working on SUMO VEINS and OMNEST.
To run sumo files on OMNEST, the input of sumo files (.xml) are inputted in veins_launchd, which in turn finds an unused port, starts sumo and bridges the connection between sumo and OMNEST.
I want to control the vehicle's behavior (Speed change) on real time (during the simulation).
For this purpose, I have written a Traci script in python language, which calls sumo config file and controls vehicle speed on real time
My issue is,
I do not know how to make this Traci script (python) to run on OMNEST via veins.
Where should I give this python file as input so that I can visualize the output in OMNEST.
My working environment is Linux
Based on some research, I figured out 2 methods.
1. TraCIScenarioManager module
2. Veins_Python
Method1: I understood by using TraCIScenarioManager module, OMNEST can directly connect to the running sumo.
But I don't know where should I make the necessary changes inside veins module to use TraCIScenarioManager instead TraCIScenarioManagerLaunchd
Method2: Regarding veins_python, I downloaded the source file from github and did the configuration steps as mentioned.
I used windows10 and
Versions: Veins5.0, OMNeT++ 5.5.1 and Python3.6
But I got the below error while configuring Veins_Python.
enter image description here
I also tried with the recent versions of software on windows 10
Versions: Veins5.2, OMNEST-5.6.2 and Python3.10
Still I get the same error.
My Sumo Traci script is
import traci
import time
import traci.constants as tc
import pytz
import datetime
from random import randrange
import pandas as pd
def getdatetime():
utc_now = pytz.utc.localize(datetime.datetime.utcnow())
currentDT = utc_now.astimezone(pytz.timezone("Asia/Tokyo"))
DATIME = currentDT.strftime("%Y-%m-%d %H:%M:%S")
return DATIME
def flatten_list(_2d_list):
flat_list = []
for element in _2d_list:
if type(element) is list:
for item in element:
flat_list.append(item)
else:
flat_list.append(element)
return flat_list
sumoCmd = ["sumo-gui", "-c", "osm.sumocfg"]
traci.start(sumoCmd)
packVehicleData = []
packTLSData = []
packBigData = []
while traci.simulation.getMinExpectedNumber() > 0:
traci.simulationStep();
timestep = traci.simulation.getTime()
vehicles=traci.vehicle.getIDList();
trafficlights=traci.trafficlight.getIDList();
for i in range(0,len(vehicles)):
vehid = vehicles[i]
x, y = traci.vehicle.getPosition(vehicles[i])
coord = [x, y]
lon, lat = traci.simulation.convertGeo(x, y)
gpscoord = [lon, lat]
spd = round(traci.vehicle.getSpeed(vehicles[i])*3.6,2)
#Packing of all the data for export to CSV/XLSX
vehList = [getdatetime(), vehid, coord, gpscoord, spd]
print("Vehicle: ", vehicles[i], " at datetime: ", getdatetime())
print(vehicles[i], " >>> Position: ", coord, " | GPS Position: ", gpscoord, " |", \
" Speed: ", round(traci.vehicle.getSpeed(vehicles[i])*3.6,2), "km/h |", \
)
#Pack Simulated Data
packBigDataLine = flatten_list([vehList, tlsList])
packBigData.append(packBigDataLine)
##----- CONTROL Vehicles ----##
#***SET FUNCTION FOR VEHICLES***
#REF: https://sumo.dlr.de/docs/TraCI/Change_Vehicle_State.html
NEWSPEED = 15 # value in m/s (15 m/s = 54 km/hr)
if vehicles[i]=='veh2':
traci.vehicle.setSpeedMode('veh2',0)
traci.vehicle.setSpeed('veh2',NEWSPEED)
traci.close()
#Generate Excel file
columnnames = ['dateandtime', 'vehid', 'coord', 'gpscoord', 'spd']
dataset = pd.DataFrame(packBigData, index=None, columns=columnnames)
dataset.to_excel("output.xlsx", index=False)
time.sleep(5)
It would be really helpful if you could suggest me the procedure or tutorial for executing my Sumo's traci script on OMNEST using veins.
I think what you want is not possible since traci supports only a single client (which is veins in your setup) or if you want multiple clients veins needs to be changed. You might try to send the messages inside veins though, see How to access TraCI command interface from TraCIDemoRSU11p in Veins Car2X simulator?
Pytorch-forecasting is a library for time series forecasting.
I wonder how to fix seed to get the reproducibility of my experiments.
Right now I'm using this function before the start of the training.
import pytorch_lightning as pl
pl.seed_everything(42)
However, it doesn't work. It is caused by dropout because when I set dropout = 0 it had worked.
# configure network and trainer
pl.seed_everything(42)
trainer = pl.Trainer(
deterministic=True,
gpus=[0],
gradient_clip_val=0.1,
)
tft = TemporalFusionTransformer.from_dataset(
training,
learning_rate=0.03,
hidden_size=128,
attention_head_size=2,
dropout=0.3,
hidden_continuous_size=32,
output_size=7,
loss=QuantileLoss(),
reduce_on_plateau_patience=4,
)
trainer.fit(
tft,
train_dataloader=train_dataloader,
val_dataloaders=val_dataloader,
)
So, how do I do to fix this issue?
Thanks,
I am running Leach protocol simulations in Castalia Omnet++ with the following simulation parameters:
sim-time-limit = 100s
SN.field_x = 70
SN.field_y = 70
SN.numNodes = 10
SN.deployment = "[1..9]->uniform"
SN.node[*].Communication.RoutingProtocolName = "LeachRouting"
SN.node[*].Communication.Routing.netBufferSize = 1000
SN.node[0].Communication.Routing.isSink = true
SN.node[*].Communication.Routing.slotLength = 0.2
SN.node[*].Communication.Routing.roundLength = 20s
SN.node[*].Communication.Routing.percentage = 0.05
SN.node[*].Communication.Routing.powersConfig = xmldoc("powersConfig.xml")
SN.node[*].ApplicationName = "ThroughputTest"
SN.node[*].Application.packet_rate = 1
SN.node[*].Application.constantDataPayload = 200
After running simulations, I checked the Castalia trace file and found the following errors:
SN.node[1].Communication.Radio Failed packet (WC_SIGNAL_START) from
node 6, radio not in RX state
SN.node[1].Communication.Radio Failed packet (WC_SIGNAL_END) from node
6, NO interference
Are these errors occurs due to simulation parameters or is there any other reason?
The messages you see are not errors per se. It could be normal behaviour. The messages just tell you that when a packet from node 6 arrived at node 1, node 1 did not have its radio in RX mode (listening) so it could not receive the packet.
This is a problem only when you lose most of your info-carrying packets, or you do not have a way to recover from such losses. You do not provide information whether this is the case or not.
The MAC plays a crucial role in this. The MAC puts the radio in RX or TX or Sleep mode. In the list of simulation parameters, the MAC is absent. If we assume that you use the default value, then this is bypassMAC that does not put the Radio to Sleep mode. Only way to have this message appear is for node 1 to TX at the same time it receives the packet from node 6.
These are normal messages, not errors. You can check Radio.cc to know why these messages are generated and adjust your code.
I added extra event like accident in TraCiMobility.cc including the accident message but I can only see the data exchange between nodes for the accident message and can not see the data exchange between nodes with the new "icyroad" event.
When using only "icy road", I can see the data exchange between the nodes. Where should I add/edit in Veins so that I can see data exchange when both or more events are active?
The .ini is as follows:
*.node[*].veinsmobilityType = "org.car2x.veins.modules.mobility.traci.TraCIMobility"
*.node[*].mobilityType = "TraCIMobility"
*.node[*].mobilityType.debug = true
*.node[*].veinsmobilityType.debug = true
*.node[*].veinsmobility.x = 0
*.node[*].veinsmobility.y = 0
*.node[*].veinsmobility.z = 1.895
*.node[4].veinsmobility.accidentCount = 1
*.node[4].veinsmobility.accidentStart = 45s
*.node[4].veinsmobility.accidentDuration = 30s #30s
*.node[3].veinsmobility.icyroadCount = 1
*.node[3].veinsmobility.icyStart = 15s
*.node[3].veinsmobility.icyDuration = 30s
The sample simulation that is included in Veins 4a2 uses an application layer that only relays the first message it receives. You will need to change this to a more full-featured application layer to make this work with more than one event type.