naroacs / autonomousbicyclesimulation Goto Github PK

We should extract all the configuration parameters and put them in a single configuration file

• Bikes initial quantity and position

There is some sort of error with the events in the User.process().
When it executes the event.suceed() in line 681 it gives the following error

RuntimeError: <Event() object at 0x1c98a174710> has already been triggered

@imartinezl Can you take a look at this, please?

SystemInterface should have access to SystemData, gives answer to users search for closest station or bike.
Functions like closest_start_station (check bikes), closest_end_station (chech docks), closest_dockless_bike
It can also be used by the DemandManager to decide which autonomous bike to send for a user.

• Containers help counting the number of bikes/docks available at a given station
• Resources provide a queue to access the a given station. Can help with the case in which two people arrive at the same time at the station.

If resources are not used, then I would propose not to use containers either, and replace the container.level with a n_bikes variable to keep track of available bikes/docks.

Restrict user location to buildings when generating the ODmatrix
Now there is only a noise that scatters users in 250m around stations following a normal distribution. But they can appear in any place (eg. the river) so this should be restricted to just buildings.

• How to dynamically move bikes around the map to match a given demand.
• What is the update frequency of the demand?
• The decision to move a bike (autonomously) to another location has a intrinsic delay. Could this delay be neutralized by the demand prediction?

Visually represent the life-cycle of users, bikes, stations and trucks in the simulation.
A diagram like the one presented on https://github.com/gia-urjc/Bike3S-Simulator could help understanding the code, and also cover undesired situations (like what happens if the user cannot find an available dock to return her bike)

• Define inputs and outputs
• Define exact objectives
• Constrain its computational cost
• Can be used for all modes (SB, DL, AU), for rebalancing

• Agents => Users
• SystemData => Assets
• Source, Target?
• Unlock and Return Bikes (works for all the 3 modes) + Attach/Detach bikes
• City => SimulationEngine

We can set a initial time in the SimPy environment and keep the data structure from the OD with the timestamp. But it seems that working with timestamps is not super convenient, so maybe we can convert the timestamp in the OD matrix to seconds delayed from the initial time and work with just this integer value.

1. Battery consumption/regeneration during ride -> I think we could consider that it doesn't provide electric assistance an it's just like a regular bike
2. In the initialization the number of bikes per station should be proportional to the capacity because right now it's random and it doesn't check if it's already full -> we can have a small code for Bike Generation
3. Execute UserGeneration.py -> change the main code to read from output.csv because it's the one with updated ODs
4. Right now each class that needs access to graph generates a new one. It should be generated in main and then sent to the classes and saved as a field of the class.
5. Review and simplify the User process that then the sub-classes call as super(). We can directly move some functions to the sub-classes and datainterface can be a field of user instead of all the sub-classes
6. Consequences of interact with bike not succeeded or no bikes or docks at arrival
7. Differentiate no bikes/docks in wakable distance vs no stations at all in walkable distance -> in the later we shouldn't make a magic bike/dock request, just end the process and save that the user won't make the trip

• Define the format of the input data for the three modes of transportation.
• Some information may not be needed for certain modes, such as the stations for the dockless mode.
• The configuration loader module should handle both the processing of input data and the generation of agents, services, etc.

I've uploaded a proposal of a structure to save the data; the variables have been grouped in two types of structures:

• user trips
• bike trips
  Suggestions are welcome.

• Define functionalities
• Create map file

trucks can be seen as moving stations
they have to be inlcuded in SystemData

Review which classes have access to the environment ---> check in ( init)

Issue to take into account the energy management of bikes.
Interesting papers: https://its.papercept.net/conferences/conferences/ITSC20/program/ITSC20_ContentListWeb_3.html#tudt1_01 and https://its.papercept.net/conferences/conferences/ITSC20/program/ITSC20_ContentListWeb_4.html#webt6_07

Collect information about rebalancing policies in real bike-sharing-systems.

• Separate each class into different .py files
• Create folders to group similar .py components, for example, all the agents classes in one folder, all the bikes classes in another one, etc.
• Also, organize the repository (docs, articles, figures, src, ...)

For example, define what happens when there are no bikes in a walkable distance, the bike has already been taken when the user arrives and so on

• CamelCase for class names and fabrics
• snake_case for modules, variables, attributes, functions, and method names