Closed Ennar1991 closed 3 years ago
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!
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.
since the new update the power level (maximum) is not saving too
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.
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.
It has worked the way you described. So this is only a cosmetic issue, and can be closed.
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
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.