Damon,

Well, that just makes all kinds of sense, would you mind sharing your
implementation details? :)


I wonder if we could support this in a generic manor by adding an
'encoding' to nav_msgs/MapMetaData<http://www.ros.org/doc/api/nav_msgs/html/msg/MapMetaData.html>

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.

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.... :/

~Dereck



“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


On Mon, Mar 25, 2013 at 5:25 AM, Damon Kohler <damonkohler@google.com>wrote:

> Rather than dealing with deltas, I've been simply PNG compressing the
> occupancy grid data. That helps a lot.
>
> On Sun, Mar 24, 2013 at 8:58 PM, David Lu!! <davidvlu@gmail.com> wrote:
> > This is useful discussion topic. Some people have already been exploring
> it
> > with the OccupancyGridUpdate message
> > (
> http://ros.org/doc/groovy/api/map_msgs/html/msg/OccupancyGridUpdate.html)
> > in particular Stéphane Magnenat. There was a REP partially related to
> this
> > topic
> > (
> https://github.com/stephanemagnenat/rep/blob/91dc02f8f2a82c5ef4820d2fc9f0f6d1fd1d0c20/rep-0129.rst
> )
> > but I'm not sure what the final status of it was.
> >
> >
> >
> >
> > On Sun, Mar 24, 2013 at 8:59 AM, Dereck Wonnacott <dereck@gmail.com>
> wrote:
> >>
> >> ROS users,
> >>
> >> I had an idea for improving map topics and would like to open it up for
> >> discussion and get some feedback on the idea.
> >>
> >> Problem: I like to run rviz for my mobile robot on a different computer
> >> than my robot for obvious reasons, but when gmapping maps get large they
> >> tend to saturate the network.
> >>
> >> Idea: Reduce the required bandwidth by publishing map deltas rather than
> >> full maps.
> >>
> >> Implementation details: The /map topic would publish the full map and
> >> latch that message for new subscribers.
> >>
> >> The /map-updates topic could then publish a hash of the map being
> >> published on /map and a list of changes required to bring that map up to
> >> date.
> >>
> >> When the change list size exceeds some threshold, it can publish and
> latch
> >> a new map on the /map topic. This will cause /map-updates to have a new
> hash
> >> and clear the change list
> >>
> >> The full map could be published on /map-full for backwards compatibility
> >> with older nodes.
> >>
> >> Suggestions and feedback on the idea greatly appreciated. :)
> >>
> >> ~Dereck Wonnacott
> >> Michigan Tech Robotics Lab
> >>
> >>
> >> “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
> >>
> >> _______________________________________________
> >> ros-users mailing list
> >> ros-users@code.ros.org
> >> https://code.ros.org/mailman/listinfo/ros-users
> >>
> >
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users@code.ros.org
> > https://code.ros.org/mailman/listinfo/ros-users
> >
>
>
>
> --
> :wq
>
> Google Germany GmbH
> Dienerstr. 12
> 80331 München
>
> AG Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Katherine Stephens
>
> Tax ID:- 48/725/00206
> VAT ID:- DE813741370
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>