静脉:如何验证重路由是否使用了用户设置算法

时间:2018-11-08 19:50:58

标签: c++ simulation omnet++ veins sumo

我正在使用4.6静脉,并尝试评估由于不同的路由协议而导致的排放变化。通过浏览SUMO网站,我已经为实验奠定了基础。目前,我正在使用带有少量配置更改的静脉演示应用程序。这是我的 erlangen.sumo.cfg 文件的内容:

<?xml version="1.0" encoding="iso-8859-1"?>
<configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://sumo.sf.net/xsd/sumoConfiguration.xsd">

<input>
    <net-file value="erlangen.net.xml"/>
    <route-files value="erlangen.rou.xml"/>
    <additional-files value="erlangen.poly.xml"/>
</input>

<time>
    <begin value="0"/>
    <end value="400"/>
    <step-length value="1"/>
</time>

<routing>
    <routing-algorithm value="CHWrapper"/>
    <device.rerouting.probability value="1"/>       
</routing>

<emissions>
    <device.emissions.probability value="1"/>
</emissions>

<report>
    <no-step-log value="true"/>
</report>

<gui_only>
    <start value="true"/>
</gui_only>

<output>
    <fcd-output value="erlangen.fcd.xml"/>
    <emission-output value="erlangen.emission.xml"/>
    <tripinfo-output value="erlangen.trip_info.xml"/>
    <vehroute-output value="erlangen.route_followed.xml"/>
    <summary value="erlangen.summary.xml" />
</output>
</configuration>

路由文件( erlangen.rou.xml )的内容如下:

<routes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://sumo.dlr.de/xsd/routes_file.xsd">

<vType id="passenger" vClass="passenger" accel="2.6" decel="4.5" sigma="0.5" length="2.5" minGap="2.5"  
maxSpeed="120" guiShape="passenger/sedan" color="1,0,0" emissionClass="HBEFA3/LDV_G_EU4">   
    <param key="has.emission.device" value="true"/>
    <param key="has.rerouting.device" value="true"/>
    <param key="device.fcd.probability" value="1"/>
</vType>

<flow id="flow0" type="passenger" from="3013106#1" to="29900564#1" begin="0" period="3" number="30" />

erlangen.net.xml 保持不变,并且在 omnetpp.ini 中,我将 *。connectionManager.maxInterfDist 从2600m更改为仅100m。

使用这些配置,我已经使用A *和CHWrapper算法运行了仿真,但是两者的输出都是相同的。在下图中,可以看到节点25-29在重新路由后遵循不​​同的路径,但是在两种情况下都是相同的。

enter image description here

Tripinfo结果如下所示,如所讨论的here“ tripinfo_rerouteNo”清楚地表明节点已被重新路由。

enter image description here

现在我的脑海里浮现着以下动静:

  1. 是成功应用了路由算法(在erlangen.sumo.cfg中设置),还是在两种情况下都使用了默认的Dijkstra?
  2. 路由算法成功应用,但结果相同,因为网络拥塞不足/没有足够的备用路径可遵循。因此,我应该拥有变更网络,具有多个事故计数等。
  3. 我不知道这里如何进行重新路由。

我被困在这里,任何方向将不胜感激。

2 个答案:

答案 0 :(得分:2)

从外部很难说已经应用了哪种路由算法,但是我认为2.是正确的解决方案。不同的算法在处理边缘权重与计算速度的动态变化方面的方式基本上是不同的,但是在大多数情况下,它们应该给出相同的结果。您可能希望尝试使用scale选项来轻松增加流量,或者将device.rerouting.period设置为10(秒)之类的值,以便定期重新路由车辆以查看更多效果。同样将weights.random-factor设置为较大的值也可以提供帮助。

答案 1 :(得分:0)

一个人可以使用以下示例网络进行验证:

enter image description here

在我的测试案例中,我将车辆的起始位置设置为最左边缘的底部车道,而目的地为同一边缘的上边缘。没有实施uTurn,因此车辆必须通过路口,并且每种算法的FCD都有很大差异。