search

Hypfer / Valetudo

Cloud replacement for vacuum robots enabling local-only operation
https://valetudo.cloud
Apache License 2.0
6.58k stars 391 forks source link

Manage and display virtual walls #72

Closed JohnRev closed 5 years ago

JohnRev commented 5 years ago

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:

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.

cryptomilk commented 5 years ago

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

JohnRev commented 5 years ago

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.

cryptomilk commented 5 years ago 
-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.

JohnRev commented 5 years ago

Cool. Worth checking. Mind emailing them to me?

cryptomilk commented 5 years ago

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

matthiasharrer commented 5 years ago

@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?)

JohnRev commented 5 years ago

@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 :)

matthiasharrer commented 5 years ago

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

JohnRev commented 5 years ago

@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