Moved initialisation of laser pose

[neomanic]

Hey! Thanks for your good work on this port.

I was completely baffled because it worked first go, but the odometry was reversed. My laser tf is pointing backwards, so I assumed this had something to do with it.

Eventually I figured out that the laser pose tf was being requested based on last_scan, but at the time the object is created, that scan hasn't arrived yet, so the laser tf ends up being unity. I can see how this could be missed in testing if your laser faces forward.

My solution moves the pose initialisation until after the first scan is received. I can't see any downsides to this, but I don't know the code all that well.

[artivis]

Hi, thanks for the great feedback !

I must admit that I did not pay much attention to the node itself of this package since I'm using the 'core' within the laser_odometry_rf2o plugin.
If you have some spare time I'd be interested knowing if this plugin (used with the laser_odometry package) handles your use-case.

In any case thanks for the PR, I'll take care of it during the week-end 👍.

[neomanic]

I’m just using the package direct at the moment, but I’ll give it a try if it works fairly smoothly. Can’t spend too much time at the moment; have to move on to navigation now.

…

On 21 Jun 2018, at 5:41 pm, Jeremie Deray ***@***.***> wrote: Hi, thanks for the great feedback ! I must admit that I did not pay much attention to the node itself of this package since I'm using the 'core' within the laser_odometry_rf2o plugin. If you have some spare time I'd be interested knowing if this plugin (used with the laser_odometry package) handles your use-case. In any case thanks for the PR, I'll take care of it during the week-end 👍. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.