Manage and display virtual walls about valetudo HOT 9 CLOSED

@matthiasharrer thanks for the help!
I have pushed my latest code for parsing the PersistData_1.data file. see here: https://github.com/JohnRev/Valetudo/tree/persist
I'd still want to work on it a bit before submitting a proper PR, but feel free to merge those into your fork.

The /api/map/latest will contain an additional field called "persistdata" containing an array of the walls (x1, y1, x2, y2) and an array of the zones (x1, y1, x2, y2, x3, y3, x4, y4), where x1,y1 is the lower-left corner and x3,y3 is the upper-right corner (this is how they are stored in the data file).

As for the origin --- I am not sure.
What I do know is that when saving zones with the mirobo commands, a coordinate of 25600 get saved as 0 in the Persist data file, making me believe that (25600,25600) ==> (0,0) is referring to the dock position (similar to how Valetudo does it). This conversion is also for the go to and zoned cleaning commands. Anyway, it's just a centimeter or so of difference :)

from valetudo.

@JohnRev I have a PersistData_2.data also the robot recreated the map on the last run and I don't understand why. I thought with persistent maps enabled it shouldn't. Hmm ...

from valetudo.

Both my PersistData_1.data and PersistData_2.data are exactly the same and have the same md5sum, so I'm not sure why there's two of them.
What do you mean by the map is recreated?
As far as I can tell, the "persistent maps" help the rockrobo keep a memory of the cleaned region after reboot.
A new cleanup will "update" the scanned region, so that if a door is opened or closed, or if there are any changes in the rooms, the robot will update and save those changes.
Would be worth checking if this is the same behavior in the official Xiaomi app, which I have never used.

EDIT: PersistData_1.data and PersistData_2.data do not necessarily need to have the same data inside.
One contains the information from the robot's previous run.
I am guessing this may be related to the use_new_map and use_old_map miio commands.
More testing needed.

from valetudo.

-rw-r--r--  1 root root  16565 Dec 31 17:09 PersistData_1.data
-rw-r--r--  1 root root  16577 Dec 31 09:06 PersistData_2.data

On my robot they differ in size.

from valetudo.

Cool. Worth checking. Mind emailing them to me?

from valetudo.

I've already sent the second data yesterday. I can send you both.

from valetudo.

@JohnRev working on the zone resizing / moving I refactored / modularized the drawing logic a bit. I think it is still quite complicated but I tried to at least add some comments in order to explain some of the more complicated things (https://github.com/matthiasharrer/Valetudo/tree/map-rework).

I could also try to implement the virtual walls / no-go zones for the /zone map, if you can make a pull request with the additional api routes.

Regarding the centering of the zones, I think this could be handled server side as is done with the cleaning zones. (Where is the origin for the cleaning zones? Also 25600 or 25500?)

from valetudo.

@JohnRev
I have pushed a draft for rendering the nogo-zones and virtual walls.
https://github.com/matthiasharrer/Valetudo/tree/display-nogo-zones

They seem to be a little bit off from what I remember the Mi Home App displayed when I set them.
This could be due to me not setting the map center correctly (As the map is 1024*1024 I actually don't know what the correct center should be. Right now I am assuming 512, 512 but I think thats not 100% correct).
I also don't know if the flipped GridMap / NavMap is correctly handled in this draft.

Regarding the API for the persistant data ..
I think it would be better to create new routes for the walls/nogo zones because of the following reasons:

• "Performance": When polling the map and the path, we don't need to refresh the walls/nogo zones every time
• I think I could "quite easily" implement editing the walls / nogo zones just like the cleaning_zones, and with an additional endpoint saving the persistant data could be easily implemented I assume (just calling the miio commands?)

from valetudo.

@matthiasharrer I agree with you regarding the api. I moved it to a new endpoint.
Yeah, the nodes are a bit off. This is probably due to the center (or the 25500 vs 25600 discrepancy).
If I add 100 to the returned values, they seem to fit in the right place (ie: let pt = block.readInt16LE(offset) + 100; instead of let pt = block.readInt16LE(offset); ... but more work is needed to figure this out I guess.

Implementing the virtual walls/nogo zones from within the same interface would be wonderful. I guess yes, we'd just have to get the coordinates and send them with the miio command save_map

from valetudo.