[ros-users] Map Topic Idea

Mon Mar 25 16:10:20 UTC 2013

I wish I had time to actually work on this right now.  Failing that I will
just suggest:

Please don't break backwards compatibility.  It makes unnecessary work for
lots of people down the road, and doesn't save that much work now.  It's
hard enough migrating from one ROS release to the next already, let's not
(knowingly) make it worse.

My suggestion is to make a new message, called CompressedOccupancyGrid.  It
would look exactly like OccupancyGrid, but would have an "encoding" byte
which would support PNG and maybe some other lossless encoding method that
is more optimized for speed rather than compression size.  (A simple
run-length encoding might do pretty well.)

Next step might be to make a library for subscribing/publishing
OccupancyGrid and/or CompressedOccupancyGrid so that code doesn't need to
be repeated and so nodes can have a consistent message API going forward.
 Maybe map publishers advertise "map" and "map/compressed" and only publish
to whichever topic gets subscribed to.  Subscribers would look for
"map/compressed" and "map" and subscribe to compressed if available and
uncompressed if not.  This way new code would work with old code but be
fast if possible.

Dave

On Mon, Mar 25, 2013 at 8:28 AM, Jack O'Quin <jack.oquin at gmail.com> wrote:

> These are all good ideas. I think the original suggestion of
> transmitting deltas is worth consideration, too. There are common use
> cases involving large maps with only small changes being applied.
>
> People also need maps for multi-story buildings, hierarchical maps,
> and other applications that don't quite fit the current map interface.
>
> The Geographic Info project has done some  experimental work on
> outdoor Earth-oriented maps with latitude and longitude coordinates.
> While the representations and coordinates differ, those interfaces are
> at least indirectly relevant.
>
>  https://github.com/ros-geographic-info
>
> I suggest creating a Special Interest Group to discuss current
> practices and propose extensions to the standard ROS map interfaces.
>
>  http://www.ros.org/wiki/sig
>
>
> On Mon, Mar 25, 2013 at 9:54 AM, Damon Kohler <damonkohler at google.com>
> wrote:
> > There's a basic implementation here:
> >
> >
> https://code.google.com/p/rosjava/source/browse/google_map_transport/src/main/java/com/google/google_map_transport/MapTransport.java?repo=google
> >
> > In this case, I'm also scaling the image if necessary.
> >
> > On Mon, Mar 25, 2013 at 3:48 PM, Dereck Wonnacott <dereck at gmail.com>
> wrote:
> >> 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
> >
> > +1
> >
> >> 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.... :/
> >
> > +1
> >
> >> ~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 at 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 at 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 at 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 at code.ros.org
> >>> >> https://code.ros.org/mailman/listinfo/ros-users
> >>> >>
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > ros-users mailing list
> >>> > ros-users at 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 at 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 at code.ros.org
> > https://code.ros.org/mailman/listinfo/ros-users
>
>
>
> --
>  joq
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130325/1f680dd1/attachment-0004.html>