utility function for converting javascript date to ros timestamp?

[eric-schleicher]

I'm publishing topics for events that are captured by the browser. for these events, it makes sense for the browser to generate the timestamp for the message header value.

It looks like ROS timestamps are two integer values with the first being second since epoch and the latter being nano seconds for the edge second.

If there a helper function in roslobjs to handle this? I looked and didn't see one.

If not i don't mind implementing it, as with modern browsers performance.now() can give nano accurate stamping, but it does this from the beginning of the current page load. A helper function would help here it would need to blend new Date() and performance.now() to get a useful value.

If someone can give a little guidance on how to make a contributions, wouldn't mind writing that.

[adolfo-rt]

Hello Eric,

I'm new in this organization, so not very familiar with the codebase yet. A quick search for now in the repo, which is the usual ROS function for querying current time didn't yield any relevant hits. So it might not exist.

The typical mechanism for adding a feature is to fork the repository, develop your feature in a branch, and then submit a pull request for review (more).

[eric-schleicher]

thanks @adolfo-rt, familiar with the typical git flow, but wanted to understand what preference maintainer would have for where/how this functionality should be incorporate.

I solve my problem short term, but if there is interest and some guidance on extending the the library, please let me know.

[jihoonl]

Hi @eric-schleicher, timestamping is basically handled in rosbridge to keep the rostime consistency when it receives a data with header.

Also, it questions me that how you can keep the time consistency between robot and browser. It would cause timing issues (e.g tf is super sensitive with time stamps) if two systems are not sharing identical time.

Could you describe more about the usecase?

[eric-schleicher]

The objective of my system is to maintain synchronization/correlation in "true" time (excluding transit time) between:

• Depth information coming from (source A) as stamped topic.
• Hyper accurate pose information as stamped pose topic (source B). the context for this data is a javascript roslibJS context with access to GPS/NTP/RTC.

I'm trying to resolve the *robust* way to translate from the javascript context to the ROS convention of stamp.sec & stamp.msec to put in the message, specifically so that i'm not dependent on event to serialization, send time, recieve time, deserialization. As an accumulated block of time can be be quite significant from a browser, even if the auto-gen timestamp from rosbridge is handshake time.
In this system, Source A, Source B and ROS Host (C) are not hardwired networked to together.

In external imaging LIDAR/drone applications this type of exercise is typcially handled with GPS based timing on all sources, where the atomic time at the point of data creation is the basis of the stamping.

I'm attempting to do the same, but have a deeper stack to travel because of the the javascript context.

I have a choice to test out here a conceptually more reliable solutions GPS timestamps, or something clever which doesn't require additional hardware... e.g. the browser's performance.now() provides 5 microseconds precision timing which can be normalized against the host time to provide a normalized stamp.

[jihoonl]

I see. Thank you for detailed explanation! Like you described, this would be useful to integrate sensors through roslibjs. :)

It looks like rosbridge is actually capable of converting time from json to ros message instead of overwriting[Here].

So, I think all we have to do is to encode browser time to json format in roslibjs. Could you create Time in roslibjs.core folder that can convert browser time(e.g time by performance.now()) to json time object? (e.g - {"secs":1234, "nsecs":1234}). Then, this json object will be interpreted as a time object in rosbridge.

[eric-schleicher]

yes, i will do this. i have a number of other priorities, but as i come in to clean up my own code, I'll implement as outlined

[jihoonl]

Awesome. Thanks. :)

[eric-schleicher]

It's been discovered that ros bridge doesn't respect provided header timestamps.

See RosBridge Issue #354