Monaco SUMO Traffic Scenario for Artery #355
Conversation
vehicles whose position overlap In SUMO, vehicles sometimes park on roughly the same position, leading to a cluster of obstacles with very small distances between them when calculating non-line-of-sight path loss for vehicles in GEMV2. Thus, when multiplying those distances to calculate attenuation, a floating point underflow occurs. `OverlappingVehiclesPolicy` tries to solve this by removing all but one of the overlapping vehicles. Fix OverlappingVehiclesPolicy to actually work properly Remove some debug code Extend granularity of the position grid in OverlappingVehiclesPolicy to 1m Rewrite OverlappingVehiclesPolicy to use the parking start/end vehicle handler of VehiclePolicy Remove some debug code from OverlappingVehiclesPolicy Add an initial removal step in OverlappingVehiclesPolicy to remove vehicles that have been parked before the simulation start Use the initial removal procedure to also remove newly parked vehicles Fix overlapping vehicle removal implementation Before, some overlapping vehicles were not removed. Remove debug code from OverlappingVehiclesPolicy Improve r-tree perfomance by bulk loading entries Add subscription variables for parked vehicles Extend BasicNodeManager to handle parking vehicles Add vehicle parking start/end handler to VehicleLifecycle Add parking vehicles handling to ExtensibleNodeManager Add vehicle parking start/end handler to VehiclePolicy Cleanup
The MultiVClassMultiTypeModuleMapper allows for equipping different SUMO vehicle classes separately
|
Thanks for this awesome PR! |
|
Sorry, maybe I should have added more explanations on the policy. Unfortunately, I cannot see your comments on the commits. Generally, the goal is to remove vehicles that park in the same spot geographically as a previously parked vehicle and insert them again, if they enter the traffic again. This policy's implementation is not as straightforward as SUMO does not provide functions to query the list of vehicles that are currently parked, but rather only lists of vehicles that are currently start or end parking. Furthermore, parking already starts when a vehicle is approaching the parking lot. Hence, the policy must track the vehicles that are parked (and the ones that are removed due to overlap) itself. I've added the |
| namespace traci | ||
| { | ||
|
|
||
| class MultiVClassMultiTypeModuleMapper : public MultiTypeModuleMapper |
There was a problem hiding this comment.
I like this feature but the name is not catchy at all ;-)
What do you think about VehicleClassModuleMapper? (No need to change it in this PR, I can do this afterwards)
| m_rtree.clear(); | ||
| // after the initial removal step, only upon a vehicle starting to | ||
| // park the r-tree is fully rebuild, otherwise it is not used | ||
| m_initial_run_is_done = true; |
There was a problem hiding this comment.
So we can also unsubscribe the signal listener now?
|
|
||
| traci::VehiclePolicy::Decision OverlappingVehiclesPolicy::addVehicle(const std::string& id) | ||
| { | ||
| bool is_overlapping = checkIfOverlapping(id); |
There was a problem hiding this comment.
This overlap check is only useful during initialization, isn't it? After the initialization phase (m_initial_run_is_done == true), the r-tree is only valid when a vehicle starts parking and thus this check here does not work at all if my understanding is correct.
| bool is_overlapping = checkIfOverlapping(id); | ||
| if (is_overlapping) { | ||
| auto position = getPosition(id); | ||
| m_removed_vehicles.erase(id); |
|
|
||
| // using 2D points only for now | ||
| if (std::fpclassify(position.z) != FP_ZERO) { | ||
| throw cRuntimeError("z position is not 0"); |
There was a problem hiding this comment.
Why does a non-zero z-coordinate hurt?
Hi Raphael,
we used the MoST scenario in the past for some evaluations. However, using it is not as straightforward as other scenarios and Artery has to be extended for it to function properly. I'm not sure, whether this is something you would like to integrate into Artery. However, I think it could be helpful for others who are interested in the MoST scenario as well.
This pull request contains three parts:
scenarios/most, including a configuration for theenvmodandgemv2MultiVClassMultiTypeModuleMapper: This extends the knownMultiTypeModuleMapperby allowing different types of vehicles to be treated differently, in case other market penetration rates for passenger cars and mopeds are desired for example.OverlappingVehiclePolicy: this policy removes vehicles that are parked in an overlapping manner. In MoST, parking lots are modeled in a kind of odd way as the attached picture shows. The areas are geographically small but have a large capacity. This leads to many vehicles in a small area, which has a particularly interesting effect on theenvmodas hundreds of objects are detected almost simultaneously. Hence, theOverlappingVehiclePolicychecks whether parking vehicles are overlapping each other and removes them while they are parked.All features are squashed to single commits for the PR's conciseness. However, I want to highlight that @hagau mostly wrote the implementations.