getting velodyne stack ready for API review

[Jack O'Quin]

I am getting the velodyne stack ready for an API reveiw. You are all
welcome to participate in the on-line review, which will be announced
here and on ros-users.

Meanwhile,I'm doing some cleanup, and plan to make some small changes
to the API. The differences should be minor and I intend to fix all
the references in the svn repository.

If you have working copies of velodyne packages checked out, please
try to keep them up to date with svn to avoid conflicts with any
changes I make. If you have substantial changes that have not yet been
committed, please commit them so I'll be aware of what you are doing.

[Jack O'Quin]

On Nov 11, 2:14 pm, "Jack O'Quin" <jack.oq...@gmail.com> wrote:
> Meanwhile,I'm doing some cleanup, and plan to make some small changes
> to the API. The differences should be minor and I intend to fix all
> the references in the svn repository.

I had to make some more changes to the velodyne stack so it would
compile with the latest ROS "unstable" release (precursor to the
upcoming Diamondback).

People working with "cturtle" should not see any difference (unless I
made a mistake).

But, some of the older <velodyne_common/data.h> interfaces are now
*deprecated*, because they cannot be supported in the next release.
Specifically,

* Data::getHeader() no longer works after cturtle because Header
moved to std_msgs.

* There is a new Data::getHeaderFields() that mostly replaces
getHeader() for programs using the old interface.

I have updated the released packages in trunk to conform to those
changes. The sandbox packages all still compile under cturtle, but
will break if built using unstable. I plan to convert the gradually,
making an effort not to interfere with ongoing class projects. At the
end of the semester, we will need to finish converting them all.

> If you have working copies of velodyne packages checked out, please
> try to keep them up to date with svn to avoid conflicts with any
> changes I make. If you have substantial changes that have not yet been
> committed, please commit them so I'll be aware of what you are doing.

This is still a good idea: commit early and often.