Probably a case of improve your wifi connection. You don't say what your wifi networking is , or how it is layed out or configured.
Not all WIFI equipment is equal. Using good quality hardware, with good quality and well supported drivers can really really help you get stable connections.
Also, your WIFI channel is really important, maybe move your WIFI to a new channel, making sure you don't share a channel with someone watching netflix all day?
Also, do a survey of the surrounding channels , do you have a neighbouring network on say channel 3 or 4, which will give you co-channel interference of both channel 1 and 6 :-(.
Can you move to 5GHZ range, which give you lower range, but can give you a clear channel to communicate on.
If your operating at longer ranges, then locking you wifi card to set bit rate can really help with stablity, WIFI will roll back and forward is transmission rates depending on error rates, so you can be quite happy transmitting at 2mb/s and then roll forward 6mb/s where the connection then becomes unstable. Some wifi drivers allow you to lock maxium rates , and if you hooked into a Access Point, some can also be locked to lower speeds too, giving and overall lower bandwidth, but more stable connection with less packet loss.
Tell us more about your setup, optimising your wifi is always a good idea.
If you have multiple nodes on wifi, try getting as much stuff onto a wired network if you can, and use dedicated wifi infrastructure for your ros project. If you have multiple nodes, makes sure every node can 'hear' every other node, because if they can't then your wireless layer will quicky fall apart. :-(.
The publisher-subscriber connection by default is set to RELIABLE. https://index.ros.org/doc/ros2/Concep... , so in terms of that, there is not much to gain anymore. it's already at the desired settings.
But keep in mind, that large sets of data will require a lot of packages to be sent. With a package loss rate of 20%, it's very unlikely that such a message will go through, even if you retry a few times. it's like saying that 80% success rate of a package, send 100 packets, -> 0.8 ^ 100 = very low.
im sure im not completely correct with this statement, but i think this train of thought is valid. large packages suffer the most from spotty connections.
thanks. I am on ROS1. I found something about using transporthints to subscribe to an "unreliable" topic, but don't know if that can help me. also could not find much data about compressing an occupancyGrid topic. since a 256x256 grid is 65kB per message, but usually most mapping packages produce 2-bit data, and most of the map is empty. I saw it can be compressed 100:1
yeah it probably is already done somewhere. Intuitively I would think of image compression and sending the resulting compressed byte data through as a byte array and decompressing it at the other end.
http://docs.ros.org/en/melodic/api/se... ,maybe something like this? I assume png or jpeg compression would compress it quite well