limitation of dg::TopometricPose

[roricljy]

generalization issue related to dg::TopometricPose

• Current implementation of dg::TopometricPose only works on a dg::Path and cannot be applied to represent arbitrary point on the map because TopometricPose::node_id is defined as the previously departed node.
• It is problematic when the robot departed away from the original path. We need more general way of pose representation.

[sunglok]

I agree that dg::TopometricPose needs to be revised.
Its description is not unique on topological maps. For example, there are two nodes, A and B, whose distance is 1 meter. (A, 0.3 m, 0 deg) and (B, 0.7, 180 deg) represent the same point on the map.) Such ambiguity is potentially harmful for optimization or filtering. It is now serious issue for me.

Anyway, let's resolve your arguments.

• dg::TopometricPose may represent any point on topological maps if we relax the definition of the previously departed node as any node of the located edge. At the beginning of our localization, dg::TopometricPose::node_id may be oscillating between two terminal nodes because the localization does not guarantee the previously departed node. However, when time has passed (when the localization have converged), it may not be oscillating.
• dg::TopometricPose does not depend on dg::Path. Since my localization does not resolve ambiguity as mentioned earlier, I gave dg::Path instead of dg::Map. The localization should deal with all regions of dg::Map or lost.

[seohyunatwork]

dg::TopometricPose::edge_idx need to be revised.
Now that we have the Edge's ID, I think it will be better if we just use the ID instead of the index.

[roricljy]

I found out that currently two concepts are mixed, making problem difficult, and it's better to consider them separately.

Current definition of dg::TopometricPose is from the robot's or object's point of view and is very useful for navigation or figuring out where we are going. However, it can be problematic to refer to the location on the map.

[seohyunatwork]

OK. I see. The edge_idx focuses more on connectivity of the Edge to the Node, while the Edge ID is independent to the Node. I will follow the edge_idx concept.

[roricljy]

I change my opinion to keep the current structure of dg::TopometricPose and leave the problem of locating point on a map as an open problem. We can use dg::LotLon (metric position) temporarily to locate points.

@seohyunatwork I agree with replacing Edge index by Edge ID (if it is not high burden). It will be more convenient for Guidance module and match well with the revised Map and Node & Edge definitions. Also, I suggest to extend current dg::TopometricPose to include heading offset info.

I tried to find examples of location representation in topolmetric maps in the literature and I found one up to now:

• Map-based probabilistic visual self-localization, PAMI'15:
  The position and orientation of a vehicle restricted to a location on the map is then defined by the street segment u that the vehicle is driving on, the distance from the origin of that street segment d and the angular offset θ of the vehicle heading from the local street heading

-> It's the same with ours except that the heading info is missing in dg::TopometricPose.

[roricljy]

I left the above comment before reading @seohyunatwork's last comment. However, I think Edge ID is better than Edge idx anyway.

[roricljy]

We discussed this issue in offline and agreed to keep the current implementation for a while and leave this issue as open.