Excellent feedback, Thanks everyone!

~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 8:13 PM, Michael Gratton <mikeg@cse.unsw.edu.au> wrote:
On 26/03/13 03:10, Dave Hershberger wrote:
> 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.

+1! While ROS clearly has no API/ABI stability contracts from release to
release, the fewer breaking changes the better. Especially with such a
rapid release cycle.

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

This sounds like the best approach to me.

//Mike

--
Michael Gratton <http://www.cse.unsw.edu.au/~mikeg/>
UNSW School of Computer Science and Engineering.



_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users