[ros-users] Map Topic Idea

[Jack O'Quin]

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