Manage and display virtual walls

I am creating this issue as a follow-up for #44. In #44, we discovered that the “new map format” after firmware 1780 on gen2 is still the same ppm file, but just encrypted differently. For valetudo to keep working correctly, we need to patch rrlogd as in https://github.com/Hypfer/Valetudo/issues/44#issuecomment-446178528 or using @cryptomilk’s firmwarebuilder additions https://github.com/dgiese/dustcloud/pull/162.

For this issue, I’d like to specifically focus on the no-go zones and the virtual walls. I have already posted an explanation about where and how these are stored (see: https://github.com/Hypfer/Valetudo/issues/44#issuecomment-450562996 and https://github.com/Hypfer/Valetudo/issues/44#issuecomment-450565679).

I have pushed a demo on how to display these no-go zones and virtual walls in Valetudo (in the new /zone map url). A few issues:

• The map drawing logic is confusing me. Someone with better knowledge could probably get this done faster than me
• The virtuual zones are centered at (25600, 25600), and not (25500, 25500) as it is often common in map parsing scripts. Is this going to be a problem?

My changes can be found here; https://github.com/JohnRev/Valetudo/tree/PersistData . For now, this will only display the stored no-go zones and walls on the map. We can not manage them from Valetudo just yet, and I am not sure if I will have enough time to implement this myself.

[JohnRev]

@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 😃

[JohnRev]

@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