Map drawing logic duplicated about valetudo HOT 5 CLOSED

Honestly I don't like the server side image generation.
Someone added it in a PR because it was easier to integrate into existing smarthome software and now its just.. there. I agree that having two places with code that essentially does exactly the same thing is bad, however I'd rather drop the server side image generation altogether.

https://github.com/WolfspiritM/Valetudo

This fork contains a heavily optimized client side drawing logic which should fix existing issues. I'm still waiting for the PR, though.

To reduce the data usage one could also think about sending diffs only, however the added complexity is just not worth it. The live map is nice but it gets boring pretty fast. After the first excitement has worn off it's just a tool for troubleshooting and/or checking if everything is fine.

from valetudo.

To implement persistent maps as well as virtual walls roborock apparently changed the map format which gets uploaded to xiaomi.
It is however completely unknown if and where this new map is stored inside the robots fs.

Did they change the ppm in /dev/shm? Is it something in /mnt/data? We just don't know yet.
Thats surely something you could look into.

from valetudo.

To implement persistent maps as well as virtual walls roborock apparently changed the map format which gets uploaded to xiaomi.
It is however completely unknown if and where this new map is stored inside the robots fs.

Did they change the ppm in /dev/shm? Is it something in /mnt/data? We just don't know yet.
Thats surely something you could look into.

Oh, I see. Then I guess I'm out for that task, because my device has never made it past the firewall to Xiaomi, I rooted it as soon as I received it. BTW, in my case only the GridMap file contains data, the ppm files are always 0 bytes. Maybe that's because it can't phone home, I don't know.

Concerning the map: I'll take a look at the version you linked, thanks. But anyway, I guess that's some sort of dilemma. I doubt that the folks who use the current on-device generation would like it if the feature went away, so I guess it needs to stay supported.

Could you elaborate on why you prefer the drawing to be done client-side? Like, what's the advantage that I fail to see? Thanks!

from valetudo.

Did you reduce the loglevel? That disables generation of the ppm map.

Here are a few reasons that I can think of at the moment:

• It takes cpu load off the vaccum which has a small arm cpu and moves it to the client which has GPU accelerated rendering
• No temporary image files that clutter up the already very limited amount of ram inside the vacuum
• You can do some cool stuff if you render it client-side and on the fly. Zooming for example. To achieve zooming with server side rendering, the server would need to render images for each zoomlevel.

from valetudo.

OK, awesome, thanks for all your help!

I guess this is not an issue anymore by now, so I'll go ahead and try to close it.

from valetudo.