Error with Regions of Interest

[akhilsimha]

I am trying to use the regions of interest feature in the Luxembourg SUMO Traffic (LuST) Scenario (https://github.com/lcodeca/LuSTScenario). I just selected a region in the map and then included in the regions_of_interest.xml as below:

<?xml version="1.0" encoding="UTF-8"?>
<regions>
	<!-- define regions of interest (RoI) here.
	Only vehicles entering a RoI will be equipped with a middelware.
	When leaving the RoI the middlewares are removed again.
	Leave regions empty to consider the whole scenario as RoI.
	-->
	<polygon name="center_junction">
    	<point x="6560.00" y="7460.00" />
    	<point x="6560.00" y="5400.00" />
    	<point x="8060.00" y="5400.00" />
    	<point x="8060.00" y="7460.00" />
	</polygon>

</regions>

I have included the .xml file in the omnetpp.ini file as below:

*.traci.nodes.typename = "RegionOfInterestNodeManager"
*.traci.nodes.regionsOfInterest = xmldoc("regions_of_interest.xml")

But after the simulations start, an error is thrown:

ASSERT: Condition 'mObjects.size() == mObjectRtree.size()' does not hold in function 'addVehicle' at /home/user/artery/src/artery/envmod/GlobalEnvironmentModel.cc:123 -- in module (traci::Core) World.traci.core (id=7), at t=1141s, event #972432

My queries are:

1. How can I rectify this error?
2. What does center_junction and spawn signify in the .xml file? Is it just a name given to the region?

[riebl]

Hi @akhilsimha7,

this error message belongs to our environment model and is thus unrelated to the ROI feature. I will check if there is a bug when both are employed. However, I am currently abroad and can only check after my return.

[awillecke]

I also encountered this issue recently. Normally, the BasicNodeManager first adds, then removes, and finally updates all nodes and emits traci.node.add, traci.node.remove and traci.node.update in that order. The GEM processes these signals, calling addObject, removeObject, and finally refresh where the mObjectRtree is rebuilt.

This works if adding, removing, and updating/refreshing are always processed in that order. However, with the ExtensibleNodeManager (and the RegionOfInterest in this case), updating nodes might also cause the addition and removal of nodes. The order of addition and removal operations is determined by the order of nodes in m_vehicles or m_persons.

In a case where one vehicle leaves and a second enters the RoI in the same step, it can cause an error, as traci.node.remove and traci.node.add are not emitted and processed in the assumed order by the GEM. When the first vehicle is processed, the object is removed from mObjects, leaving the mObjectRtree tainted. When the second vehicle is processed, addObject will check mObjects.size() == mObjectRtree.size() and assert.

A simple and naive approach to fix this would be just to rebuild the tree in the rare case it is tainted when an object is added.

[riebl]

Thanks @awillecke for your detailed explanation of the current regions of interest issues! I would like to refactor the ExtensibleNodeManager so it also follows a strict add-remove-update order. I will have a look at the current implementation as soon as possible.