<div dir="ltr"><div style>Damon,</div><div style><br></div>Well, that just makes all kinds of sense, would you mind sharing your implementation details? :)<div><br></div><div><br></div><div style>I wonder if we could support this in a generic manor by adding an 'encoding' to <a href="http://www.ros.org/doc/api/nav_msgs/html/msg/MapMetaData.html" style="text-decoration:none;font-family:Palatino,serif;font-size:14px;line-height:16px">nav_msgs/MapMetaData</a><span style="color:rgb(51,51,51);font-family:Palatino,serif;font-size:14px;line-height:16px"> </span></div>
<div style>then nav_msgs/OccupancyGrid's data[] could be encoded in a wide number of formats. Perhaps we can use openCV to do the encoding/Decoding as well. </div><div style><br></div><div style>This would break backwards compatibility, but it seems like the right way to go since adding the encode/decode should be a trivial fix for dependent packages to come up to date.... :/</div>
<div style><br></div><div style>~Dereck</div><div style><br></div></div><div class="gmail_extra"><br clear="all"><div><br>“The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.” - Michelangelo</div>
<br><br><div class="gmail_quote">On Mon, Mar 25, 2013 at 5:25 AM, Damon Kohler <span dir="ltr"><<a href="mailto:damonkohler@google.com" target="_blank">damonkohler@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rather than dealing with deltas, I've been simply PNG compressing the<br>
occupancy grid data. That helps a lot.<br>
<div><div class="h5"><br>
On Sun, Mar 24, 2013 at 8:58 PM, David Lu!! <<a href="mailto:davidvlu@gmail.com">davidvlu@gmail.com</a>> wrote:<br>
> This is useful discussion topic. Some people have already been exploring it<br>
> with the OccupancyGridUpdate message<br>
> (<a href="http://ros.org/doc/groovy/api/map_msgs/html/msg/OccupancyGridUpdate.html" target="_blank">http://ros.org/doc/groovy/api/map_msgs/html/msg/OccupancyGridUpdate.html</a>)<br>
> in particular Stéphane Magnenat. There was a REP partially related to this<br>
> topic<br>
> (<a href="https://github.com/stephanemagnenat/rep/blob/91dc02f8f2a82c5ef4820d2fc9f0f6d1fd1d0c20/rep-0129.rst" target="_blank">https://github.com/stephanemagnenat/rep/blob/91dc02f8f2a82c5ef4820d2fc9f0f6d1fd1d0c20/rep-0129.rst</a>)<br>
> but I'm not sure what the final status of it was.<br>
><br>
><br>
><br>
><br>
> On Sun, Mar 24, 2013 at 8:59 AM, Dereck Wonnacott <<a href="mailto:dereck@gmail.com">dereck@gmail.com</a>> wrote:<br>
>><br>
>> ROS users,<br>
>><br>
>> I had an idea for improving map topics and would like to open it up for<br>
>> discussion and get some feedback on the idea.<br>
>><br>
>> Problem: I like to run rviz for my mobile robot on a different computer<br>
>> than my robot for obvious reasons, but when gmapping maps get large they<br>
>> tend to saturate the network.<br>
>><br>
>> Idea: Reduce the required bandwidth by publishing map deltas rather than<br>
>> full maps.<br>
>><br>
>> Implementation details: The /map topic would publish the full map and<br>
>> latch that message for new subscribers.<br>
>><br>
>> The /map-updates topic could then publish a hash of the map being<br>
>> published on /map and a list of changes required to bring that map up to<br>
>> date.<br>
>><br>
>> When the change list size exceeds some threshold, it can publish and latch<br>
>> a new map on the /map topic. This will cause /map-updates to have a new hash<br>
>> and clear the change list<br>
>><br>
>> The full map could be published on /map-full for backwards compatibility<br>
>> with older nodes.<br>
>><br>
>> Suggestions and feedback on the idea greatly appreciated. :)<br>
>><br>
>> ~Dereck Wonnacott<br>
>> Michigan Tech Robotics Lab<br>
>><br>
>><br>
>> “The greater danger for most of us lies not in setting our aim too high<br>
>> and falling short; but in setting our aim too low, and achieving our mark.”<br>
>> - Michelangelo<br>
>><br>
>> _______________________________________________<br>
>> ros-users mailing list<br>
>> <a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
>> <a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> ros-users mailing list<br>
> <a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
> <a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
:wq<br>
<br>
Google Germany GmbH<br>
Dienerstr. 12<br>
80331 München<br>
<br>
AG Hamburg, HRB 86891<br>
Sitz der Gesellschaft: Hamburg<br>
Geschäftsführer: Graham Law, Katherine Stephens<br>
<br>
Tax ID:- 48/725/00206<br>
VAT ID:- DE813741370<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br></div>