matsim-eth / av Goto Github PK

Nice, but 4679778 is not ideal setup. It probably should already operate on a filtered Network, which is provided further up the stream through injection (per Operator?)

Provides a version that is compatible with MATSim master

Right now all the operators, dispatchers, generators, etc. depend heavily on injection and the right entry points. We need:

• More decoupling, i.e. it should be possible to set dispatchers up programmatically more easily (prbly this is the case, but not properly documented)
• Provide examples how to do that

Currently it uses the standard car router. This is not always true, and especially it should use a specific network. Check what is passed to AVRoutingModule.

You store the waiting time separately (unlike how waiting for pt is calculated in core) so I don't think you should be subtracting the marginal disutility of travel. What do you think?

Krishna

The schedule-based dispatcher (for private AVs and households) is static right now: At the beginning of the day the TripSchedules are transformed into DVRP vehicle schedules. However, since the TripSchedule objects are available now, it would make much more sense to do all the routing adaptively depending on the actual arrival and departure times.

Additionally, the different operating modes (wait at dropoff location / wait at pickup location / wait at home) can be selected more dynamically. If there, for instance, is not even enough time to go to the next pickup location directly from the last dropoff location, is does not make sense to drive home in between to wait there.

Additional operating mode: Roaming. This means, that the AV will not stay at any location, but roam around the pickup / dropoff location. All of this should be configurable through the schedule (depending on the availability of parking space) and optimized by the scheduled dispatcher.

One could even introduce utility functions in the dispatcher, so it can decide adaptively what to do. If roaming would be cheaper than staying at dropoff / pickup (due to parking costs) or than going home (because of the distance), maybe roaming is the best option. (And in case it costs too much of money, the agent would not choose the AV mode anyway)

The whole code should be tested much more thoroughly, the only existing integration test right now should use a simpler scenario instead of Sioux Falls, which takes a long time to run.

Eventually, remove this method and provide means of modifying the list of available vehicles from outside, e.g. a AvailableVehiclesProvider or an VehicleProviderByState, etc ...

Rename

The setup is somewhat strange that there is the "Generator", which calls the Dispatcher with that "addVehicle" Method. The other way would make more sense: The dispatcher knows his number of vehicles and may "sample" new vehicles from a generator. This way he may also adapt the fleet size dynamically, i.e. he can discard some vehicles in one iteration and sample new ones in the next iteration.

The whole configuration is a mess. Actually, it would be much better if everything would be integrated in the main config.xml for MATSim. But then, the config format would need to be changed (or rather extended) to allow for that.

A new extension for custom configuration is on the way!

• Currently, lifetime is fixed to 30h
• There is a problem, e.g. if a request is assigned synchronously by SingleRideAppender, after the lifetime has expired (e.g. a request starting at 30h), which led to an IllegalStateException. This has been "fixed" now by setting the lifetime to 30h + 1h
• Hence, make sure that the border cases are tested via unit tests

All the AV things (dispatcher, vehicles, ...) are in the wrong scope. They are expected to be regenerated for every iteration, however, right now they live in the Controller scope.
The problem is then as follows:

• Simulaton is running, but some vehicles are still on a leg when the simulation ends
• Since they never arrive, they are never added back through addVehicle to the dispatcher
• In the next iteration, the dispatcher has less vehicles available

Hi Guys,

I hvae recently tried the RunRobotaxiExample.java, the first time it runs fine.

Then I replaced the example network.gz and population file with my own, and the IDE gives NullPointerException in taxi modules which is another extension from MATSim.

Is there some other files that I should fix?

Best Regards,
Mike

The plan is to move the actual dispacher implementations in a different repository and leave here only the structural code and maybe one simple dispatcher (e.g. FIFO/SingleHeuristic) that can be used out-of-the-box for testing. To that end the intfrastructure should probably not be tested in the Unit Tests, but the unit tests should define own dispatchers that have a clear, simple and straightforward setup.