Costmap rendering

[v-kiniv]

Continuation of the discussion started here.
Short description: cost map rendering is broken and not consistent when using RWS or Rosbridge. Coloured costmap renders ok when using RWS but not ok when using Rosbridge, and vice versa.

Top image - RWS, bottom - Rosbridge:

Chrome 122.0.6261.94 (Mac), Non-Coloured

Firefox 123.0 (Ubuntu), Non-Coloured

Firefox 123.0 (Ubuntu), Coloured

Here is the bag I've recorded, I tried to strip non-relevant topics and keep it short to decrease size. I noticed that the robot model is stuck when playing from the bag, but it's consistent between RWS and Rosbridge.

Download rec.bag.7z from Google Drive (123 MB, too large for Github attachment)

[MoffKalast]

Thanks for the bag data. Unfortunately I wasn't able to reproduce the issue with it, nor with any of my bags I've looked at. I'm really puzzled as to why, but it seems that whatever the bag publisher does fixes this somehow. I did however manage to reproduce it on a live robot:

Rws:

Rosbridge:

Rviz:

Looking at the diffs of both received message objects it seems that what's encoded as -1 by rosbridge is instead sent as 255 by rws. I have a feeling there's an unintended signed vs unsigned byte conversion in there somewhere.

I've tested both with cbor compression and without and it doesn't seem to make any difference, so I'm while I'm not sure what the core issue is, I can accommodate those values when processing and seems to render as it should now.

I've put up a fix to #66 if you can test it out. Might be worth looking into why this happens on the rws side at some point.

[v-kiniv]

I have a feeling there's an unintended signed vs unsigned byte conversion in there somewhere.

Yep, you were spot on. int8 was treated as char. Fixed in v-kiniv/rws#21, now Vizanti map(Non-Coloured) behaves the same on RWS and Rosbridge.
However, now both RWS and Rosbridge have broken "Coloured Costmap":

[MoffKalast]

Yep, you were spot on. int8 was treated as char.

Ha neat, it was a bit suspicious that int8 and uint8 in binary map to -1 and 255. If the map values were all in range of 0-127 we'd never even figure out this mismatch since the result would've been the same 😄

Yep, you were spot on. int8 was treated as char. Fixed in v-kiniv/rws#21, now Vizanti map(Non-Coloured) behaves the same on RWS and Rosbridge.

Ah good, in that case I suppose we can leave the old setup as-is here since it should be more correct.

now both RWS and Rosbridge have broken "Coloured Costmap":

I think that's actually working as intended, the problem is that we have two different types of data being sent as OccupancyGrid and only the topic name to tell them apart.

The usual map data is just clear/occupied with values that display as a map, the costmaps however are distance maps that encode the distance is to the nearest obstacle for faster path planning, and they use a different number range. Rendering one as the other is possible, but produces odd results.

Vizanti does automatically switch newly added grid visualizers with "cost" in their topic name to costmap rendering, but that's as far as that detection goes.

Rviz produces roughly the same result on type mismatch, though it does seem to use a different range and colours all costmap distances black which would be neat to add here too at some point since it looks kinda cool but isn't something that's being used as intended anyway:

[v-kiniv]

Ah good, in that case I suppose we can leave the old setup as-is here since it should be more correct.

Yep

I think that's actually working as intended, the problem is that we have two different types of data being sent as OccupancyGrid and only the topic name to tell them apart.

OK, so I said it's broken because I checked only on Chrome(Mac), but now I also checked on Firefox and Chromium on Ubuntu 20.04 and there the costmap is rendered ok - bold black borders(non-coloured map) and bold cyan borders(coloured map) on obstacles.

So it's broken only on Chrome on MacOS:

First I thought maybe it's hidpi related, because it looks like costmap "inflation" around obstacles is not there, but nah, I have 4k resolution and 200% scaling inside Ubuntu VM as well.
Not sure if you intend to support Mac, just wanted to make clear why I thought it's broken.

Another thing that added to the confusion is that you have separate costmap and occupancy, I was expecting that when I enable "Costmap colouring" option I would get occupancy+coloured costmap like Rviz does, but it's a matter of choice of course.

Occupancy+Coloured costmap in Rviz:

[MoffKalast]

Chrome on MacOS

Hmm, I mean afaik Firefox and Chromium should behave the same way on MacOS as on other OSes, it's only iOS that forces them to be reskinned Safari.

Based on that picture, the right render looks pixel perfect the same as the one on the left, I don't think that's the costmap topic you're rendering. There tends to be a considerable delay when switching which can be annoying, since the new map needs to be received and processed. I think there shouldn't be much overhead to cache the last received message and reprocess it immediately when the switch is thrown to make it more obvious what's going on.

Another thing that added to the confusion is that you have separate costmap and occupancy, I was expecting that when I enable "Costmap colouring" option I would get occupancy+coloured costmap like Rviz does, but it's a matter of choice of course.

Ah yes it is a bit more low level indeed, rviz has some plugins that group and autodetect the correct setup. Physically though they are completely separate topics and the base Map renderer in rviz works practically the same way: single topic, single display mode. It would be a good idea to rename "Costmap rendering" to "Colour scheme" for familiarity and have it be a dropdown with raw mode as a debug option too, then it'll be completely identical UI-wise.

For your bag setup you'd need the following separate visualizers to reproduce the usual slam_toolbox plugin setup:

• /map topic, costmap rendering disabled
• /global_costmap/costmap topic, costmap rendering enabled
• /local_costmap/costmap topic, costmap rendering enabled, higher opacity

It might be good to add some more heuristics for this detection (e.g. slam_toolbox widget that merges all three + service proxy buttons for its API), but not every slam stack has the same name convention and I wouldn't want to favor one over another too much in principle to not contribute towards vendor lock-in. E.g. back on Noetic there is an alternate slam package iris_lama_ros which has /distance as the costmap topic for example.

Not sure if you intend to support Mac, just wanted to make clear why I thought it's broken.

Well there has been some effort put into Safari compatibility since that's the only option on iOS (e.g. no fetch or xhr requests are used because Apple's ATS blocks them over HTTP and you can't use HTTPS offline without an imported root cert which is a major hassle to set up), but I currently don't have any devices capable of running Safari to test on, nor is it possible to VM it, so it's mostly up to those that use it to help with compatibility fixes for the time being.

[MoffKalast]

There, I've extracted the colour mappings from rviz so rendering should now be almost identical, with a little more transparency for unoccupied pixels which looks nicer imo. Also added raw mode as it serves as an impromptu dark mode for maps and caching for instant switching. Should be less confusing now I hope 😄

Can be tested as part of #68

[v-kiniv]

Based on that picture, the right render looks pixel perfect the same as the one on the left, I don't think that's the costmap topic you're rendering.

You're right, I didn't notice that in Chrome on Mac the Topic option was set to /map instead of /global_costmap/costmap. When I set the correct topic it works the same way as on Ubuntu, sorry for the confusion.

Can be tested as part of #68

Not sure, but I think you have typo here and here and meant to set alpha value to non-zero value, because right now it looks like this:

And if you'd set alpha to something like 128

let color = [0, 255, 0, 128]; // Green for illegal positive values
// ...
color = [0, 0, 0, 128]; // Black for value 0

the result would be:

Anyway, new rendering style looks much better, maybe it's because I used to Rviz.

[MoffKalast]

Yeah I'm still not sure about that alpha value here, but it shows up a bit weird in some cases if it's high enough, since the costmaps stack and it does seem to really be zero in rviz2:

I think it makes most sense to keep the original three options as close to rviz as possible, but thing is though... it would be pretty easy to just add a few extra new ones if you have any specific colour schemes you'd like to see. One that might be interesting is walls-only, which would be the original broken version that only shows hard obstacles.

[v-kiniv]

So, my intention was to get something like this:

Basically, occupancy, local and global costmap combined. But it's a separate layers in Vizanti, and my tweak with non-zero alpha produced kinda combined layer, but it's more like a side effect than a proper solution.

I think we can close the issue, as discrepancy in map render between RWS and Rosbridge was fixed and the "broken costmap" was just wrong widget settings on my end.