Error in DvrpModeRoutingModule
cweber9843 opened this issue · 6 comments
Hi,
I am trying to adjust the cottbus/robotaxi scenario for my own studies. To start with, I want to try to run 10 robotaxies on the "roundabout" network.
I have uploaded my modified files RunRoboRoundabout.java, inputNetworkFile, inputPlansFile, taxisFile and config.xml.
See also the complete error log.
All files on GoogleDrive.
Both the original roundabout and robotaxi scenarios run without errors.
However, when I try to combine them, i get the following error:
2023-04-28T12:02:48,611 INFO SpeedyALTData:51 find dead ends...
2023-04-28T12:02:48,612 INFO SpeedyALTData:132 calculate landmarks...
2023-04-28T12:02:48,618 ERROR MatsimRuntimeModifications:75 Getting uncaught Exception in Thread main
com.google.inject.ProvisionException: Unable to provision, see the following errors:
1) [Guice/ErrorInCustomProvider]: ArrayIndexOutOfBoundsException: Index 8 out of bounds for length 8
at AbstractModalModule.bindModal(AbstractModalModule.java:59)
\_ installed by: Modules$CombinedModule -> Modules$CombinedModule -> AbstractModule$4 -> Modules$OverrideModule -> AbstractModule$4 -> Modules$OverrideModule -> AbstractModule$4 -> Modules$OverrideModule -> AbstractModule$4 -> Modules$OverrideModule -> MultiModeTaxiModule -> TaxiModeModule -> DvrpModeRoutingModule
while locating DefaultMainLegRouter$RouteCreator annotated with @DvrpMode(value=taxi)
at DvrpModeRoutingModule.install(DvrpModeRoutingModule.java:51)
\_ installed by: Modules$CombinedModule -> Modules$CombinedModule -> AbstractModule$4 -> Modules$OverrideModule -> AbstractModule$4 -> Modules$OverrideModule -> AbstractModule$4 -> Modules$OverrideModule -> AbstractModule$4 -> Modules$OverrideModule -> MultiModeTaxiModule -> TaxiModeModule -> DvrpModeRoutingModule
while locating RoutingModule annotated with @Element(setName=@DvrpMode(value=taxi),uniqueId=158, type=MAPBINDER, keyType=DvrpRoutingModuleProvider$Stage)
while locating Map<DvrpRoutingModuleProvider$Stage, RoutingModule> annotated with @DvrpMode(value=taxi)
at DvrpModeRoutingModule.install(DvrpModeRoutingModule.java:49)
\_ installed by: Modules$CombinedModule -> Modules$CombinedModule -> AbstractModule$4 -> Modules$OverrideModule -> AbstractModule$4 -> Modules$OverrideModule -> AbstractModule$4 -> Modules$OverrideModule -> AbstractModule$4 -> Modules$OverrideModule -> MultiModeTaxiModule -> TaxiModeModule -> DvrpModeRoutingModule
while locating RoutingModule annotated with @Named("taxi")
while locating RoutingModule annotated with @Element(setName=,uniqueId=178, type=MAPBINDER, keyType=String)
at TripRouter.<init>(TripRouter.java:104)
while locating TripRouter
I tried
- different java versions (11 and 17),
- different matsim-maas versions (the current codebase from github and the MATSim-MaaS 12.0 release from Oct.14, 2020),
- Double checked plans, network and vehicle definition files for structural mismatch,
- tried to give a different routing algorithm to the controler (Dijkstra instead of A*Landmarks, but I do not think this is forwarded to dvrp?),
- finding similar issues on github.
Any hints what I am doing wrong, or how I can further debug this problem?
I can't tell from the error message, and right now don't have enough time to run this myself.
The speedy alt router for dvrp is in principle replaceable, but you are right that it does not use the config setting from controler. If you wanted to bushwhack your way forward, the approach would be:
- inline the
TaxiControlerCreator
material. - inline the
MultiModeTaxiModule
material. - inline the
TaxiModeModule
material. And there, change the routing factory.
But I am not recommending this. :-|
People tell me that "drt" is better maintained than "taxi". Can't say of that would help in this case here ...
I will ask other people to step in with help.
PS: Thank you so much for providing so much material.
Thanks for reporting this issue. There was a bug in the landmark calculation, it should be fixed now: matsim-org/matsim-libs#2559.
There is also one more error: please remove the route
element from all taxi legs
in the input plans.
This PR brings in the fix in matsim-libs to matsim-maas: #106. Please use this matsim version (or newer).
Great, thank you for looking into this so quickly.
I also suspected missing landmarks in the roundabout network, so my plan for today was to try with a bigger network, but I will now go on with the fix and report back.
Thanks again, the scenario robotaxi+roundabout runs through now.
One minor comment/question:
QSim seems to want the agents to walk:
Caused by: java.lang.RuntimeException: just encountered mode for which no scoring parameters are defined: walk
at org.matsim.core.scoring.functions.CharyparNagelLegScoring.calcLegScore(CharyparNagelLegScoring.java:114)
at org.matsim.core.scoring.functions.CharyparNagelLegScoring.handleLeg(CharyparNagelLegScoring.java:192)
at org.matsim.core.scoring.SumScoringFunction.handleLeg(SumScoringFunction.java:115)
at org.matsim.core.scoring.ScoringFunctionsForPopulation.handleLeg(ScoringFunctionsForPopulation.java:232)
at org.matsim.core.scoring.EventsToLegs.handleEvent(EventsToLegs.java:354)
at org.matsim.core.scoring.ScoringFunctionsForPopulation.handleEvent(ScoringFunctionsForPopulation.java:185)
at org.matsim.core.events.EventsManagerImpl.callHandlerFast(EventsManagerImpl.java:294)
at org.matsim.core.events.EventsManagerImpl.processEvent(EventsManagerImpl.java:119)
at org.matsim.core.events.SimStepParallelEventsManagerImpl$ProcessEventsRunnable.run(SimStepParallelEventsManagerImpl.java:344)
at java.base/java.lang.Thread.run(Thread.java:833)
But neither the original robotaxi_config.xml nor the roundabout.xml define modeParams
for walk
. When I add walk
in my modeParams
, the simulation runs through again:
<parameterset type="modeParams">
<param name="mode" value="walk" />
</parameterset>
So while I appreciate QSim to motivate the agents for physical activity, I still wonder why this situation never happened when I ran roundabout and robotaxi seperately, both without defining a modeParam
for walk
?
Matsim may need walk legs to "bushwhack" from facilities to the network. So it is in principle possible that it needs scoring values for walk even if walk is not used as a "main" mode. So maybe such a "bushwhacking walk" was not necessary in the robotaxi example, but they become necessary when combining robotaxi and roundabout. (Or not: Please spend some time checking at least in the plans file where these walk legs show up.)