Persistant Maps, No-Go Zones and Virtual Barriers

[Hypfer]

This issue shall gather information on persistent maps, how they behave etc.

They require a recent firmware and are enabled either by miio set_lab_status with payload [1] or via filesystem access: echo -n "1" > /mnt/data/rockrobo/lab.cfg

To begin, here are a few questions:

• Is there any reason not to enable them?
• How does one force a rebuild? Is that even possible?
• Any change in behavior?

[Hypfer]

if lab status is 1 and the robot is rebooted, get_map_v1 returns a complete, yet empty map response:

{"header_length":20,"data_length":128,"version":{"major":1,"minor":0},"map_index":1165,"map_sequence":1,"image":{"position":{"top":512,"left":512},"dimensions":{"height":0,"width":0},"pixels":[],"xBorderCoordinatesInMM":{"left":25600,"right":25600}},"path":{"current_angle":0,"points":[]},"charger":[25422,25600],"robot":[25600,25600]}

I assume that we need to use a different command to pull the map if lab_status is 1. The robot does report its lab status on a status request so we should in theory be able to support both.

As soon as a new cleanup is started, get_map_v1 returns a newly built map like before.

[Hypfer]

I'm experiencing the following behaviour on Gen2 1748 after reboot:
get_persist_map_v1: {error: { code: -10000, message: 'Get Persist Map failed'}}
get_persist_map_v2: {result: 'unknown_method' }
get_persist_map: {result: 'unknown_method' }
get_fresh_map: {result: 'unknown_method' }
get_persist_map: {result: 'unknown_method' }

get_fresh_map_v1 uploads the freshly generated map.

Spamming use_old_map returns either {error: {code: -10000, message: 'Use Old Map failed'}} or {error: { code: -10001, message: 'Process busy' }}

Maybe this is happening because i've enabled lab mode after the full cleanup?
I will do a full cleanup tomorrow and check again.

Also, this issue is related: marcelrv/XiaomiRobotVacuumProtocol#15

[h3ifri]

Hi all!

I'm using Gen2 with 1768. I'm not happy with persistent mode.

The base is in the hallway with 6 doors to different rooms, every room and the hallway is configured as a zone. To generate the map, I opened all doors an run a full cleanup.

Then I started zone cleaning and on it's way to the zone the vac passed other rooms with closed doors. The map is updated, and there is no longer an entry into the room. If I try to clean a room where the door was closed (the door is open again), the vac is moving to the zone, but doesn't find a way to enter it. The vac does not see the the door is open again. I have to reset the map with mirobo raw-command reset_map.

[Hypfer]

Oh so thats what reset_map does.
We should definitely add support for this in the Web Interface before we start supporting persistent maps.

[h3ifri]

I forgot to say, it's not possible to use zone cleaning after the reset_map command.

I don't know if it's possible, but it would be nice to reset the map to a defined "version", in my case where all doors are open.

[h3ifri]

Maybe use_old_map is the thing I'm looking for. When enabled, it seems that the previously generated map is used, but I'm not 100% sure.

[cryptomilk]

The interesting commands in the AppProxy I found are:

get_map
get_map_v1
get_map_v2

get_fresh_map
get_fresh_map_v1
get_fresh_map_v2

get_persist_map
get_persist_map_v1
get_persist_map_v2

get_clean_record_map
get_clean_record_map_v2

use_new_map
use_old_map

reset_map
save_map

set_lab_status

[cryptomilk]

@funth1ngs If the zone is bigger so the robot starts to clean outside of the door, it will drive there and then see that the door is open. It can't enter a room with closed doors. Make the zones a bit bigger :-)

[ngltr]

Hi all, Thank you for all the work down with valetudo.

Using gen2 with firmware 1748 and valetudo 0.3.0 freshly installed with persistent map enabled here what I am experiencing:

save_map creates the file /mnt/data/rockrobo/usermap0 by copying /mnt/data/rockrobo/lastmap
reset_map removes these two files (and also other files)

When it starts a new cleanup, the robot:

• uses the map stored in /mnt/data/rockrobo/usermap0 (I tried to replace it with an other one and it works as expected),
• Locates himself on the map (even if you have deplaced it in an other place)
• Starts the cleanup

[hagenuck1]

Im having the issues with not entering rooms with Valetudo, 1720 & persistent Maps, too. But zoned cleaning is working fine after cleaning the corridor or running a home assistant script which has gotos before and behind each door.

But the problem with closed doors exists for me, too. Only way to solve this is to manual control the robot into the zone. The problem with zones bigger than the room is, that the robot trying to get cleaned everything in the zone (including not existent room; rooms which he shouldn’t reach) and drives through the whole house to get there.

A button to reset (or better save a copy which can be loaded again) would be awesome, as the robot sometimes creates duplicate ares, which aren’t existent and the whole map is „destroyed“.

[ngltr]

Only way to solve this is to manual control the robot into the zone.

You can also start a full cleanup close to the open door, and the robot will update its map with the door open. Then save the map and run the zone cleanup

[cryptomilk]

If the robot remembers a closed door and you try to send it there, it wont see a path and fail. If you increase the zone that the robot starts cleaning infront of the door he has a path can go there and then recognize that the door is open!

[Hypfer]

Okay so every time save_map is sent, its payload contains all the defined virtual walls and no-go zones.
To clear those, we just have to send an empty array.

Is there a way to fetch the current settings or is this value write-only?

[cryptomilk]

I don't know about a command, you could parse the PersistData1 file. @JohnRev wrote a parser for the file, see: https://github.com/JohnRev/Valetudo/commits/PersistData

[Hypfer]

Nvm we can just use the map data for that since it contains all of those.

[posixx]

Is there any progress in no-go zone / virtual barrier implementation? One of our roborocks get's stuck every time a cleaning is ran. I don't want to use any tape or somthang as this is below the TV-set.

[matthiasharrer]

In the latest master there is a implementation which shows the configured nogo-zones on the map.
It is, however, still not possible to configure the nogo zones using valetudo.

Please feel free to send a PR :)

[posixx]

Ok, ts there any way to configure them otherwise??

[matthiasharrer]

Not while having valetudo installed ..
You can configure them using stock firmware and Mi Home App and they will survive flashing a new firmware afterwards so you can then use them with valetudo.

[fvollmer]

It seems like mirobo from https://github.com/rytilahti/python-miio could be used, but the feature isn't documented yet. I guess this should work together with valetudo?
rytilahti/python-miio#438

[matthiasharrer]

That's true but you will have the issue of finding out the coordinates ( #102 )

[matthiasharrer]

For this to work and not break users with gen1 / labmode disabled we have to think about:

• Turn on / off lab-status => set_lab_status
• Find out if it's a gen1 / gen2 => miIO.info
  • This command also returns wifi connection state which could replace the long regex ;)
• Find out if labmode is on => The response to the get_status command contains 'lab_status': 1 if it's turned on.

[Hypfer]

miIO.info only returns if the robot is provisioned and has an active cloud connection, though.
#27 (comment)

[matthiasharrer]

Hm that's a pity ..
What is currently working in unprovisioned mode?
I guess all the labmode stuff is not working anyways is it?
Is there any difference between an unprovisioned gen1 and gen2?

Maybe the robot type could be unprovisioned / gen1 / gen2

[Hypfer]

iirc miIO.info is the only one not working.

We can however just fetch the info from /mnt/default/device.conf. model=roborock.vacuum.s5
The file is in fact already read by valetudo since it contains did + cloudKey for the dummycloud functionality