plugin: add synchronisation to most plugins

[mhkabir]

This allows timesync between a PX4 FCU and mavros to be used in most plugins : #185
This is untested, so don't merge yet.

I don't have time for this ATM, so testers welcome. @thedinuka, interested?

[thedinuka]

I'll definitely run some tests. Will get back to you after.

[mhkabir]

You can simply merge the branch, and add two printf/Throttled print to one
of the plugins. Print the synchronised timestamp and ros::Time::now(). As
long as they are similar, it's fine.
On Jan 11, 2015 1:16 PM, "Dinuka" notifications@github.com wrote:

I'll definitely run some tests. Will get back to you after.

—
Reply to this email directly or view it on GitHub
#186 (comment).

[vooon]

Looks good, but testing required.

[thedinuka]

Hi,
I'm trying to understand this a bit more clearly before I run tests with it. Hope you'd be able to answer a few questions.
From what I understood, time offset is the instantaneous time difference between ROS wall time and the pixhawk time. Then what the synchronise_stamp function does is to add that offset to the time stamp attached by the pixhawk to each sensor data packet. So effectively, what

header.stamp = uas->synchronise_stamp(imu_hr.time_usec);

does is to set the timestamp on the message published by ros to the ros time at which the IMU (or other sensor) was captured as opposed to ros::Time::now(). Given that there is a finite delay in transmitting the data from PixHawk to host computer, I'd assume the header.stamp to always lag ros::Time::now().

This is what confused me a bit, because you said:

Print the synchronised timestamp and ros::Time::now(). As long as they are similar, it's fine

Hope you could shed some light on this. Thanks

[mhkabir]

The lag would be low in any case. The current wall time would be very close to the synchronised stamp anyway. (lagging by estimator time + link latency)

As I said, they should be close to each other, not the same.

[mhkabir]

It's fine with me if you can find a better way to test it :)

[mhkabir]

@dinuka You can plot the IMU in rqt_plot and move the system around.
Visualisation should be normal if synchronisation works properly :)
On Jan 12, 2015 6:40 AM, "Dinuka" notifications@github.com wrote:

Hi,
I'm trying to understand this a bit more clearly before I run tests with
it. Hope you'd be able to answer a few questions.
From what I understood, time offset is the instantaneous time difference
between ROS wall time and the pixhawk time. Then what the
synchronise_stamp function does is to add that offset to the time stamp
attached by the pixhawk to each sensor data packet. So effectively, what

header.stamp = uas->synchronise_stamp(imu_hr.time_usec);

does is to set the timestamp on the message published by ros to the ros
time at which the IMU (or other sensor) was captured as opposed to
ros::Time::now(). Given that there is a finite delay in transmitting the
data from PixHawk to host computer, I'd assume the header.stamp to always
lag ros::Time::now().

This is what confused me a bit, because you said:

Print the synchronised timestamp and ros::Time::now(). As long as they are
similar, it's fine

Hope you could shed some light on this. Thanks

—
Reply to this email directly or view it on GitHub
#186 (comment).

[thedinuka]

@mhkabir I will do those testing as soon as I get some time. Bit stuck with a few other things this week

[mhkabir]

@tonybaltovski

[tonybaltovski]

@mhkabir will do ASAP.