Document is_traversable object option

[thaije]

What is your question?
How does the is_traversable logic work? What happens in the following case:

• traversable agent steps on tile with traversable obj
• non-traversable agent steps on tile with traversable obj
• traversable agent steps on tile with non-traversable obj
• non-traversable agent steps on tile with non-traversable obj

Is there a difference between stepping on a tile with such an object as human agent, or that a normal agent does this?

To what is your question related?

• I am not sure if I should use MATRX.
• I have a question about the idea behind MATRX.
• I don't know how to do something with MATRX.
• I don't know where to find something.
• I think I found a bug, but I am not sure.
• I want to contribute, but don't know where to start.
• Something else.

[jwaa]

Do you mean with 'tile' an AreaTile or just an arbitrary grid space?

[jwaa]

Just a quick check in move_actions._possible_movement shows that it does not matter what the moving object is (traversable or not), it only matters if the place it is moving to is traversable. In other words; an agent can go only to those places that have no other objects/agents or all those objects/agents have is_traversable=True.

Your four cases thus reduce to:

• agent steps on a location with traversable object => This is a legit move action. The MoveActionResult shows a succes.
• agent steps on a location with non-traversable object => This is move action is not possible. The MoveActionResult shows a failure (specifically a MoveActionResult.RESULT_OCCUPIED if the non-traversable object is an AgentBody, otherwise a MoveActionResult.RESULT_NOT_PASSABLE_OBJECT).

[jwaa]

Is there a difference between stepping on a tile with such an object as human agent, or that a normal agent does this?

No, there is (atleast should not be) no difference between how this works for a human agent or a normal agent. Because the traversability of that agent only matters for other agents, not for itself to determine where it can go.

[thaije]

@jwaa the confusion came from the following two cases:

• An intraversable human agent can step on a tile with a traversable agent.
• An agent cannot step on a tile with an intraversable human.

This seems a bit arbitrary as the objects and actions are the same, but whether the action is possible or not depends on who initiates the action.

This came from the Co-active teaming case where agents avoid you and can be blocked by a human standing in a doorway, but in the meantime you can walk all over the agents.

So the logic seems OK, not being able to step on intraversable obejcts. But in practice this can lead to weird situations such as these. For co-active teaming we fixed this by making the human agent traversable as well.

[thaije]

With tile I meant a grid tile indeed. This was the official terminology we decide on right, instead of cell?

[jwaa]

@jwaa the confusion came from the following two cases:

* An intraversable human agent can step on a tile with a traversable agent.

* An agent cannot step on a tile with an intraversable human.

This seems a bit arbitrary as the objects and actions are the same, but whether the action is possible or not depends on who initiates the action.

This came from the Co-active teaming case where agents avoid you and can be blocked by a human standing in a doorway, but in the meantime you can walk all over the agents.

So the logic seems OK, not being able to step on intraversable obejcts. But in practice this can lead to weird situations such as these. For co-active teaming we fixed this by making the human agent traversable as well.

I agree, this is a bit strange (and unexpected) behaviour if agents have different traversability settings. What would be a nice solution? Enforce a world-wide traversability setting for agents seems to be a no-go. Incorportating the traversability of the agent initiating the action might add complexity (and also unexpected behaviour).

Let's take an example. When one agent is a flying drone (is_traversable=True) and another is a UGV (is_traversable=False), with tree objects (is_traversable=False) in the world. What kind of behaviour would we expect?

• The UGV cannot move in the tile of trees.
• The UGV can move in tiles with the drone if there are no trees.
• The drone can move in all tiles, whether they have trees or UGVs
  (- The trees cannot move.)
  How can we bring such behaviour about? Do we need another bool or can we do it all with is_traversable in a transparent way?

[jwaa]

With tile I meant a grid tile indeed. This was the official terminology we decide on right, instead of cell?

True... forgot :x

[thaije]

A change that we could make for more consistency would be to also add another type of traversability, taking also the traversability of the object itself into account.

Traversability in three categories:

• Lvl 0: Intraversable to all. E.g. a wall. No other object can stand on a tile with wall.
• Lvl 1: Intraversable to other intraversable objects only (with lvl 1). E.g. the tree or UGV cannot stand on 1 tile.
• Lvl 2: Traversable: e.g. the drone. Traversable object can be located on a tile with other objects with a traversability of either lvl 1 or 2. Thus you can place 500 drones on 1 tile, or place a drone on the same tile as a UGV or tree.

If you have a very high tree, you could give it traversability lvl 0, so that even a drone could not fly on it. If the drone lands, you can give it traversability lvl 1, so a UGV cannot drive through it.

The only issue I have with this solution is on how we can explain this clearly to users.

[thaije]

I would suggest to KISS it. 😋
MATRX v2 works great for 2D worlds, but is not very suited out of the box for 3D worlds or 2.5D worlds such as what we are trying to do here with drones that fly over objects but into trees.

For the 2D MATRX worlds our traversability logic works fine, especially if shortly explained in the tutorial of #284.

The beauty of MATRX is that it is highly extendable, and if you want, you can program a 3d dimension on top, an extra type of traversability as described in #272 (comment) and make it work.
However, out of the box it is not supported, reason being there are better tools for 3D environments such as Unity or D-Sim as used here at TNO, or perhaps MATRX v3.

Closing for now, but doesn't mean we have to stop discussing it ofcourse :)