Position injection to the AMCL node after the robot leaves the station.

[gestom]

Position injection to the AMCL node after the robot leaves the station.
This is especially useful when initiating an autonomous run after restarting the localization. Eliminates the need to provide a position estimate by hand after restarting the patroller or in case the AMC localization failed.

[hawesie]

What's the status with this?

[gestom]

Integrated to the undocking action and merged.

[hawesie]

Is it documented so we can all use it? Or does it just work from the data in the docking/calibration?

[gestom]

No extra steps are needed. The only assumption is that the robot position at the charging station is 0,0,0.

[gestom]

This can be achieved by starting the mapping process when the robot is at the charging station and it's odometry is reset.

[hawesie]

What happens if 0,0,0 isn't the charging station?

[gestom]

Yes, one might argue, that the position of the charging station should be a parameter.

However, if we want (for any reason) to automatically create new maps by running SLAM during the patrolling runs (or create the new maps later on from the recorded rosbags), the g-mapping will use the odometry position as an initial robot position in the map created. Since the SCITOS G5 platform suffers from systematic odometry error (that is probably impossible to correct in firmware, see Issue #19 ), its odometric pose differs significantly from the real one each time the robot starts its patrol. This causes misalignment of the individual maps which causes the map stitching process to be computationally expensive and imprecise (as pointed out in Issue #19). Therefore, it is very desirable to set the robot odometry pose to some predefined value. Unfortunatelly, the current robot interface does not allow that. All we can do is to reset the odometry to 0,0,0.

As far as I know from today's skype meeting on the marathon, the STRANDS partners have reported running the long-term patrollers over long periods of time. Since the position injection has been put on the repository more than two weeks ago and everyone is using the latest version of the software, I guess that everyone has their station at 0,0,0. Otherwise the charging would cause the autonomous patroller to fail at undocking and noone would be able to run autonomously for more that ~12 hours.

When we have mentioned the position injection during the GA in Birmingham, everyone was OK with that. I have made another comment of assuming that the charging station position is at 0,0,0 when creating a pull request for the position injection more than two weeks ago and noone objected.

[hawesie]

I'm totally behind this, but I just wanted to check that everyone is/was aware that 0,0,0 should be their charging station (as I wasn't explicitly aware of this).

[bfalacerda]

So, the map_saver should start with the robot docked. After that everything goes as before. Right @gestom? I'll add it to the README of this repo if that's the case.

Also, this is not resetting odometry to 0,0,0, it's just giving a very precise pose estimate to amcl right? From what you said, it looks like resetting odometry is more important, given that g-mapping takes odometry position as the initial one. Is that also being done?

[gestom]

Yes, correct, map saver should start with odometry being reset. We have the odometry reset implemented in a script that is run prior to the patrolling. I will implement the odometry reset in the visual charging.