tylerferrara
commented
2 years ago This is a great to bring up, as it effects robot meetings. A meeting may not be finished until all parent, and child have had successful merges, in addition with passing extra consensus information.
My Question:
How might a caller of the the map merge service be able to distinguish the state of the merge? Might we look for a return type (int):
0 - success
1 - not_acceptable [attempt retry]
2 - failure [don't retry]Or, should all retries be attempted by the merge service? Maybe attempt the service can try to merge 3x, or it becomes a failure[return type 2].
Regardless of how we handle this, it should be documented.
@cj-mclaughlin Thoughts?
nikopoulospet
Hi all, just wanted to bring up a few issues with how we are currently handling multi-robot merge failures (self-merge with gmapping should presumably pass).
I am currently in the process of running experiments to tell when this happens, but essentially - there are definite scenarios in which merges are most likely to fail, and thankfully in these scenarios, it should be OK to proceed without a merge.
Example of 'Acceptable' Failed Merge: 1) Map-merging extremely early into exploration. These maps have very few distinctive features, which makes merging inconsistent. Additionally, as so little area has been explored by each robot, little is lost if the merge is not performed. In these scenarios, a failed merge is ok, and each robot should proceed with their own map.
However, there are certain cases in which a failed merge is NOT okay, and merges should be re-attempted until success.
Example of 'Unacceptable' Failed Merge: We are at the data-dump state. We must deliver a completed map, and thus merges should be reattempted.
TLDR; In the state machine, there should be case-specific handling of merge failures. Merges in exploration (especially early-on) may be 'expected' to fail in some scenarios, however data dump merges on the other hand, should never fail.