Future messages appear when ros nodes running on Windows

[Xiaowen]

Hello,

After I built two ros nodes that can run on Windows by using MinGW cross compiling environment, I found that, when starting roscore on Linux system, and running the two nodes on Windows, some messages seemed to be received in future. A message should not be received beforing it is sending out. But the timestamp in messages showed the future time. And then I made the nodes that was windows built by the visual c++ build environment to run on windows, only one or two out of 1000 messages were received in future.

Some answers on the internet say it is caused by the clock's out of sync. But after I use Chrony to make computers' clock synchronized, less future messages occure but still exist. Besides, both the nodes running on Windows, they are not machines across. Is it caused by the ros time?

Looking for your answer.

rgds,

Xiaowen

[Dominique Vaufreydaz]

Ntp (included natively in windows) should be a good idea (as for the Linux computer). One question : what is the time
difference ? Is there a problem in time zone definition ?

Doms.

[Xiaowen]

It showed that the message sending out time was 1353592834.982286, but the receiving time was 1353592834.064294.  If the receiving time become  1353592835.064294, that would be fine.

Besides, i have set "UTC=no" in  /etc/default/rcS, so Linux uses local time instead of utc. And I do not think the future messages are caused by the machines' out of sync as both the nodes running on Windows, only roscore runs on Linux.

Xiaowen

[Dominique Vaufreydaz]

Hello,

> It showed that the message sending out time was 1353592834.982286, but the receiving time was 1353592834.064294. If the receiving
> time become 1353592835.064294, that would be fine.
> Besides, i have set "UTC=no" in /etc/default/rcS, so Linux uses local time instead of utc. And I do not think the future messages
> are caused by the machines' out of sync as both the nodes running on Windows, only roscore runs on Linux.

I did not get why you could conclude with such assertion. Nothing ensure that your windows
are time synchronized just because they are windows (I had a lot of synchronisation failed on
the standard microsoft ntp server) To me, it is the first check to do.
Ask manually for a synchronisation on the windows with an ntp server (the same can be a good
choice) and do the same on the linux (using ntpdate). Anyway, it is the first check to do and
the base of distributed computing. After that, one can envision another cause.

Best regards. Doms.

[Daniel Stonier]

Im on my tab, so cant write much right now.

The windows rostime code isnt very special. On old windows machines this code will run, but i suspect its not very reliable (alot of posts can be found about this). For newer windows we might be able to inject better code.

Ill point you at the right code segment tomorrow if you wish to play with it.

Of course, could also be a bug. In which case bug patches gladly accepted ;)

Cheers,
Daniel

[Xiaowen]

Oh, I just want to tell you that I saw the post (Daniel has already answered about the problem) and followed the advice in it, setting start_sec and start_nsec to static in the time.cpp ( in   ~/mingwros/src/ros_comm/utilities/rostime/src ).  The obtained timestamps look good. All the receiving times are late to the sending out times.

The post website : http://code.google.com/p/win-ros-pkg/issues/detail?id=2

And about the ntp, may be it can solve the big offset between the clock, but as both the nodes are running on the same machine( a node get the current time from the system that it runs on ), it cannot be the clocks' sync causes the time to jump backward. 

 

rgds,

Xiaowen

[Dominique Vaufreydaz]

Hello,

> And about the ntp, may be it can solve the big offset between the clock, but as both the nodes are running on the same machine( a
> node get the current time from the system that it runs on ), it cannot be the clocks' sync causes the time to jump backward.

I did not get that your code run on a *single* Windows. Sorry for the misunderstanding.

Doms.

[Daniel Stonier]

On 23 November 2012 02:53, Xiaowen <sun...@gmail.com> wrote:

Oh, I just want to tell you that I saw the post (Daniel has already answered about the problem) and followed the advice in it, setting start_sec and start_nsec to static in the time.cpp ( in   ~/mingwros/src/ros_comm/utilities/rostime/src ).  The obtained timestamps look good. All the receiving times are late to the sending out times.

The post website : http://code.google.com/p/win-ros-pkg/issues/detail?id=2

I'd forgotten about that. What is a concern is that this particular code hasn't been patched, either in win_ros or upstream. It should have been. I'll check on it today sometime.

Cheers,

Daniel.

 

And about the ntp, may be it can solve the big offset between the clock, but as both the nodes are running on the same machine( a node get the current time from the system that it runs on ), it cannot be the clocks' sync causes the time to jump backward. 

 

rgds,

Xiaowen

On Thursday, 22 November 2012 16:57:16 UTC+1, Doms wrote:

Hello,

> It showed that the message sending out time was 1353592834.982286, but the receiving time was 1353592834.064294.  If the receiving
> time become 1353592835.064294, that would be fine.
> Besides, i have set "UTC=no" in  /etc/default/rcS, so Linux uses local time instead of utc. And I do not think the future messages
> are caused by the machines' out of sync as both the nodes running on Windows, only roscore runs on Linux.

        I did not get why you could conclude with such assertion. Nothing ensure that your windows
        are time synchronized just because they are windows (I had a lot of synchronisation failed on
        the standard microsoft ntp server) To me, it is the first check to do.
        Ask manually for a synchronisation on the windows with an ntp server (the same can be a good
        choice) and do the same on the linux (using ntpdate). Anyway, it is the first check to do and
        the base of distributed computing. After that, one can envision another cause.

        Best regards. Doms.

--
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/

Yujin R&D: http://rnd.yujinrobot.com/