0.10.1 Experimental Map Restore: Charger and robot position not saved properly

[Ennar1991]

Describe the bug
Running on Gen 1 Roborock/Xiaomi Robot Vacuum.

After testing the experimental map restoring features, robot pose and charger position are saved at different locations, often outside saved map.

How to Reproduce

1. Run cleaning cycle/control manually and get perimeter of the floor you want to clean
2. Return to dock automatically
3. Save map either by MQTT command or in Valetudo RE web client
4. Start a full cleaning cycle, then stop the process immediately, to destroy map data
5. Attempt restore of map by MQTT command or in Valetudo RE web client
6. Map will be reloaded, but robot pose and charger position may be incorrect

Expected behavior
Charger position and robot pose should be exactly the same as before destruction of map and restoration.

Screenshots

Vacuum Model:
Gen1

Valetudo Version:
0.10.1

User-Agent
N.a.

Additional context
I've experimented with map restoring myself. The player process is responsible for navigation and generating map data. See: https://en.wikipedia.org/wiki/Player_Project

Manually backing up and overwriting the files in /mnt/data/rockrobo/ reproduces the map correctly, including charger position and robot pose:

appproxy.map
ChargerPos.data
last_map
RoboController.cfg
(robot.db)
slam_info.cfg
StartPos.data
(VacuumAndBrush.cfg)

Files in braces may contain config data that is irrelevant to the task. I've had a quick look into robot.db with nano, and it is a SQL database, most likely containing data about consumables.

I know this method is a very hacky way of remembering the floor perimeter, and putting allowed zones around forbidden areas is the inverse way of adding virtual walls to the Gen1 robot. But hey, if it does the job, that's fine.

[pidator]

Have you tried starting a new zoned cleaning after restoring the map? I've seen this behaviour several times after restoring, but the position always got corrected after starting the next (zone) clean run.

But I have done the restoring while robot is docked only!

[Ennar1991]

Hi pidator, thanks for the quick reply!

I haven't tried this yet, as I didnt want to destroy more data, but will try next time I clean a zone.

[truresma]

since the new update the power level (maximum) is not saving too

[rand256]

Well, charger and robot positions are stored in ChargerPos.data and StartPos.data respectively, and the "multimap" feature copies only the ChargerPos.data file upon map restoration. This is done because we can't know at which position the device would be located when user restores the map, so we want the device to locate itself not relying on StartPos.data anyway.

Maybe on gen1 devices this doesn't work as expected, but I think that copying the StartPos.data file could't help much, specifically in cases when the actual device position doesn't match the position that was stored in StartPos.data.

[Ennar1991]

This is done because we can't know at which position the device would be located when user restores the map, so we want the device to locate itself not relying on StartPos.data anyway.

I agree with that. I've wanted to set the automated restore to happen when the bot is docked, to eliminate closed doors from the map. I'm not sure if a Gen 1 bot can use its SLAM algorithm to detect if it has been moved inside the map and then return to the base, without creating a new map.

I will test when I find some time. This flat has only one floor.

[Ennar1991]

It has worked the way you described. So this is only a cosmetic issue, and can be closed.