valetudo: Map not shown ("no map data")

On my Gen1 which I received recently, I cannot get the maps working. Controlling the robot works pretty much as intended (although I don’t really understand the manual control mode), but no matter how often I let it clean, I never get any map. I’ve set up a small <1m² test parkour for the bot.

Due to the lack of logging, which is the only easy way to assess Valetudo’s behavior, I cannot tell what’s going wrong. I’ve tried the builds from the release page (0.8.2 and 0.9.0), a Dustbuilder image and even one with the original Valetudo (which didn’t work at all).

To me it seems like there is map data (last_map for instance is not an empty file), but Valetudo won’t receive it via the dustcloud fake service (at least I think Valetudo doesn’t read the files directly but receives something via the socket on 808x). That’s also the reason for the map files not being copied to userX. I’m not sure whether the map should’ve been copied to /mnt/data/valetudo/last_map, the code isn’t completely clear on that.

In any case, I’d like to get into debugging this problem, really, but for someone like me who rather NOT touches node.js, some logging would be nice to have. Perhaps you can tell me where to start hacking?

P.S.: I can unfortunately not tell more information about what firmware it has after the factory reset, as mirobo ... info yields the infamous “vacuum not connected to cloud” error message.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 66 (54 by maintainers)

Commits related to this issue

Most upvoted comments

cloud-dnsmasq working.

ps | grep cloud-dnsmasq - incorrect command

right command ps aux | grep cloud-dnsmasq

It is better to use drill to check dns.

Valetudo doesn’t read map files from filesystem nor copies it (except for manual map store function), current map should be uploaded to valetudo’s, when firmware receives from dustcloud via miio the “correct” URLs where it should upload it.

You may want to check netstat -a from SSH, where you should see the line like this:

udp 0 0 <robot's internal IP>:<random port> 203.0.113.1:8053 ESTABLISHED

If you see this, with exactly 203.0.113.1:8053, and you have iptables rules in /etc/rc.local that DNATs 203.0.113.1 traffic back to 127.0.0.1 (and they were actually run), you should have the maps. Opening map tab on the web interface will force the firmware to reupload the map (if it is connected to dustcloud).

Sometimes manufacturer’s firmware doesn’t reconnect to dustcloud immediately, so it can be connected nowhere, nor to xiaomi cloud neither to dustcloud. In this case there’s no way to force it to reconnect, it may take up to half an hour for it to do that. And if it happens that firmware managed to connect to the real cloud (generally it should never happen), it will keep that connection as long as it can. Then the simplest way is to reboot, or close internet access for the device.