Map not rendered - Githubissues

kosmonauta144 commented 3 months ago

Hi, we use Vizanti alongside RTABMAP. The map is published on topic /rtabmap/map. The map is not published regularly, but can be triggered with the service. In rviz the map is shown, but it is not in vizanti. Costmaps work perfectly normal. It's strange, because the issue occured about 2-3 weeks ago, when from day to day it stopped working. TFs and other topics are correct, but map is not seen. Do you have any idea what we should change to diagnose what's wrong and how to repair it?

MoffKalast commented 3 months ago

Well, two potential problems come to mind. There is an issue I've sometimes seen with rosbridge, where it might process latched topics immediately (when there's no web clients connected yet) and those messages won't get sent to every new client since it only counts when rosbridge subscribes, not the websocket. Then again if the map is published while the web part is connected it should definitely receive it.

There is a rendering bug in Firefox that this sounds familiar to, as maps are rendered with a worker in an offscreen canvas to reduce stutter, but oftentimes nothing ends up rendering at all. It's shouldn't be an issue in Chrome, and I have added a workaround for it a while back, though I'm not entirely certain it's a complete fix.

There are a few things to try:

check the web console (F12) for any errors
compare Chrome and Firefox
if on ROS 2, is there any difference between rosbridge and rws
there are two WIP PRs for noetic and humble that include some changes to map rendering and caching, you could test those out if the behaviour is any better
if you can reproduce this in a short rosbag that I could test with locally, that would be most practical

kosmonauta144 commented 2 months ago

We checked the web console, but no errors have occur. We checked Chrome and Firefox and there is no difference between them. On both the map is not displayed. I will check rws today, because I have not checked it yet. For WIP PRs you mean *_feature branches?

Here is the bag with publishing map on the topic and tf's. Vizanti is started after booting the system with crontab, but I don't know if it has an influence. vizanti_diagnostic.zip

MoffKalast commented 2 months ago

Thanks for the rosbag, I can reproduce the issue in ROS 2:

Switching to rws instead of rosbridge does seem to resolve it, so I would lean towards it being the aforementioned message subscribing issue:

It is odd though that it still doesn't work even if the web client is connected the entire time when map updates are sent. I'll look into it more to see if I can find a root cause, but for now this might be a viable workaround on your end.

For WIP PRs you mean *_feature branches?

Yep.

MoffKalast commented 2 months ago

Aha, I've found the culprit, it seems that the map is so large that it becomes fragmented and roslibjs doesn't handle that properly, so it doesn't get through:

[rosbridge_websocket-1] [INFO] [1712585295.277229819] [vizanti_rosbridge]: [Client e586b48c-a268-4441-b022-818c7d71858e] sending 2 parts [fragment size: 10000000; expected duration: ~0s]
[rosbridge_websocket-1] [INFO] [1712585296.590611355] [vizanti_rosbridge]: [Client e586b48c-a268-4441-b022-818c7d71858e] sending 2 parts [fragment size: 10000000; expected duration: ~0s]
[rosbridge_websocket-1] [INFO] [1712585297.866376431] [vizanti_rosbridge]: [Client e586b48c-a268-4441-b022-818c7d71858e] sending 2 parts [fragment size: 10000000; expected duration: ~0s]
[rosbridge_websocket-1] [INFO] [1712585302.253521269] [vizanti_rosbridge]: [Client e586b48c-a268-4441-b022-818c7d71858e] sending 2 parts [fragment size: 10000000; expected duration: ~0s]
[rosbridge_websocket-1] [INFO] [1712585303.525652432] [vizanti_rosbridge]: [Client e586b48c-a268-4441-b022-818c7d71858e] sending 2 parts [fragment size: 10000000; expected duration: ~0s]
[rosbridge_websocket-1] [INFO] [1712585316.171968891] [vizanti_rosbridge]: [Client e586b48c-a268-4441-b022-818c7d71858e] sending 2 parts [fragment size: 10000000; expected duration: ~0s]

Changing the max_message_size in the launch config to something at least 2x as big seems to fix it. I'll push a fix that sets it to 999999999, which should allow for about 50x as large packets. Then it's up to the network to support that :smiley:

kosmonauta144 commented 2 months ago

I changed the max_message_size as you proposed and it works great :D thank you very much :smile:

MoffKalast / vizanti

Map not rendered #70