Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a standard graph representation/transformation for rail environments #19

Open
mmarti-tsch opened this issue May 31, 2023 · 3 comments · May be fixed by #90
Open

Add a standard graph representation/transformation for rail environments #19

mmarti-tsch opened this issue May 31, 2023 · 3 comments · May be fixed by #90
Assignees
Labels
enhancement New feature or request

Comments

@mmarti-tsch
Copy link
Contributor

Many solution approaches (both RL and planning) did operate on a graph representation of flatland.
We have a least two versions of graphs somewhere, one of them based on the netcetera graph.

We should have a "standard" graph transformation function for flatland. Maybe placed in utils.
(For example, a modified version of the netcetera graph).

@mmarti-tsch mmarti-tsch added the enhancement New feature or request label May 31, 2023
@mmarti-tsch
Copy link
Contributor Author

It would also be nice if we had a standard "compact" graph representation of flatland, where only certain cells are encoded as nodes (e.g. the decision cells).
Many approaches to solving flatland can profit from a more concise/compact representation of the problem.

@hagrid67
Copy link
Contributor

hagrid67 commented Jun 28, 2023

I will promote flatland-contrib/graph_utils.py into the main flatland, and create a few examples of "contracted paths" and decision cells etc using the existing directed edges representation. I'll try to do some basic documentation to help seed the discussion.
working in branch - iss0019-add-graph-repr

@hagrid67 hagrid67 self-assigned this Jun 28, 2023
@aiAdrian
Copy link
Contributor

aiAdrian commented Jul 3, 2023

I have as well implemented a transformation from flatland (grid) into a graph representation:
https://github.com/aiAdrian/flatland_railway_extension/blob/master/flatland_railway_extension/FlatlandGraphBuilder.py

The FlatlandGraphBuilder converts Flatland's grid cell-based topology into a directed graph g. The graph consists of nodes and edges. An edge is defined by "from-node" u and "to-node" v such that for the edge e = (u, v). A node in the graph is defined by position and direction. The position corresponds to the position of the underlying cell in the original flatland topology, and the direction corresponds to the direction in which an agent reaches the cell. Thus, the node is defined by (x, y, d), where x is the index of the horizontal cell grid position, y is the index of the vertical cell grid position, and d is the direction of cell entry. Based on the grid cell position and the cell entry direction, the connection to the neighboring cell can be estimated. The estimation is done using the pure flatland navigation technique. In the flatland (2d gird), not every of the eight neighbors cell can be reached from every direction. Therefore, the entry direction information is key. In the graph g only edges exist where a feasible transition from node u to node v exist. An edge has several attributes, such as the length of the edges, the resource which can be mutually exclusive used, the flatland action to be chosen to get from node u to node v. The length of the edge is 1 as long as no infrastructure is used. If an infrastructure is used, the infrastructure defines the edge length, which is the by the infrastructure defined length of the flatland cell that lies under node u. The resource is defined as the flatland cell that lies under the node u. The flatland action is the action that must be selected so that an agent at node u (i.e. position and direction) can get to node v.

With the help of the graph it is very easy to calculate the shortest connection from node A to node B. The API makes it possible to solve such tasks very efficiently. Moreover, the graph can be simplified so that only decision-relevant nodes remain in the graph and all other nodes are merged. A decision node is a node or flatland cell (track) that reasonably allows the agent to stop, go, or branch off. For straight track edges within a route, it makes little sense to wait in many situations. This is because the agent would block many resources, i.e., if an agent does not drive to the decision point: a cell before a crossing, the agent blocks the area in between. This makes little sense from an optimization point of view.

The implementation uses networkX, so there are also many graph functions available.

@chenkins chenkins linked a pull request Nov 29, 2024 that will close this issue
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants