静脉:如何验证重新路由是否使用用户设置算法
Veins: How to verify if rerouting is using user set algorithm
我正在使用 veins 4.6 并尝试评估由于不同的路由协议而导致的发射变化。通过探索 SUMO 网站,我已经成功地为实验奠定了基础。现在我使用的是 veins 演示应用程序,配置有一些小改动。这是我的 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 在重新路由后遵循不同的路径,但在这两种情况下都是相同的。
Tripinfo 结果如下,讨论here "tripinfo_rerouteNo" 清楚地表明节点已被重新路由。
现在我的脑海里一直在转:
- 是否成功应用了路由算法(在 erlangen.sumo.cfg 中设置)或者在这两种情况下都使用了默认的 Dijkstra?
- 路由算法应用成功,但结果相同,因为网络不够拥挤/没有足够的替代路径可供选择。所以我应该改变网络,多起事故计数等
- 我不明白重新路由在这里是如何工作的。
我被困在这里,任何指示将不胜感激。
从外部很难判断应用了哪种路由算法,但我认为 2. 是正确的解决方案。不同的算法在处理边缘权重动态变化与计算速度的方式上基本不同,但在大多数情况下它们应该给出相同的结果。您可能希望尝试使用 scale
选项轻松增加流量,或将 device.rerouting.period
设置为 10(秒)这样的值以启用车辆的定期重新路由以查看更多效果。将 weights.random-factor
设置为较大的值也会有所帮助。
可以使用如下示例网络进行验证:
在我的测试用例中,我将车辆的起始位置设置为最左边的底部车道,目的地是同一边缘的上车道。没有实施 uTurn,因此车辆必须通过交叉路口,并且每种算法的 FCD 都大不相同。
我正在使用 veins 4.6 并尝试评估由于不同的路由协议而导致的发射变化。通过探索 SUMO 网站,我已经成功地为实验奠定了基础。现在我使用的是 veins 演示应用程序,配置有一些小改动。这是我的 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 在重新路由后遵循不同的路径,但在这两种情况下都是相同的。
Tripinfo 结果如下,讨论here "tripinfo_rerouteNo" 清楚地表明节点已被重新路由。
现在我的脑海里一直在转:
- 是否成功应用了路由算法(在 erlangen.sumo.cfg 中设置)或者在这两种情况下都使用了默认的 Dijkstra?
- 路由算法应用成功,但结果相同,因为网络不够拥挤/没有足够的替代路径可供选择。所以我应该改变网络,多起事故计数等
- 我不明白重新路由在这里是如何工作的。
我被困在这里,任何指示将不胜感激。
从外部很难判断应用了哪种路由算法,但我认为 2. 是正确的解决方案。不同的算法在处理边缘权重动态变化与计算速度的方式上基本不同,但在大多数情况下它们应该给出相同的结果。您可能希望尝试使用 scale
选项轻松增加流量,或将 device.rerouting.period
设置为 10(秒)这样的值以启用车辆的定期重新路由以查看更多效果。将 weights.random-factor
设置为较大的值也会有所帮助。
可以使用如下示例网络进行验证:
在我的测试用例中,我将车辆的起始位置设置为最左边的底部车道,目的地是同一边缘的上车道。没有实施 uTurn,因此车辆必须通过交叉路口,并且每种算法的 FCD 都大不相同。