Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve timestamp granularity of different measurements within a scan #16

Open
wants to merge 1 commit into
base: ros2
Choose a base branch
from

Conversation

tobiasneumann
Copy link

The current message for a RadarScan just stores one time stamp for all returns.
And this time stamp is not clearly defined.

Proposed change

  • Add the field stamp_offset to RadarReturn, which will be used relatively to the time stamp of the time stamp in the field header of RadarScan.
  • Define the time stamp of the field header of RadarScan to be of the first return.

RadarScan: clearify that the stamp in the header should be the first measurement of this scan.
@@ -1,6 +1,8 @@
# All variables below are relative to the radar's frame of reference.
# This message is not meant to be used alone but as part of a stamped or array message.

builtin_interfaces/Duration stamp_offset # Offset to the stamp in the RadarScan message.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Define this better. offset representing what? The time it takes for the total scan to be accumulated? The offset due to time sychronization? etc

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This field should have the same meaning as time_increment of sensor_msgs/LaserScan.
The stamp_offset should be the offset to the time stamp of the first measurement on a collected scan which is defined in the header in the RadarScan message.

When you have a rotating radar scanner, a RadarScan would consist on a collection of RadarReturns that are from different measurements.
With this change the returns can have a precise time stamp.


I wanted to add an alternative description to this reply.
But I have problems finding other words to describe it (at least not in a substantial way), because I think it is already quite clear.
The ambiguity of the meaning of this sentence might be more introduced by that this message is not supposed to be used by itself, so it needs to be seen as a member of radar_msgs/RadarScan which time stamp is referenced in the comment.

What do you think about the following description?
It basically says the same, but might does it in a clearer way?

Suggested change
builtin_interfaces/Duration stamp_offset # Offset to the stamp in the RadarScan message.
builtin_interfaces/Duration stamp_offset # The offset relative to the time stamp set in the header of the outer message
# containing a collection of these returns.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to actually describe what its representing. You mention its the offset from the last point in the measurement for the first (e.g. accumulation time).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't meant to referencing the previous return.
Just the time stamp of the header (of the RadarScan message)

So the time stamp of a RadarReturn would be calculated by

<RadarScan>.header.stamp + stamp_offset

So the RadarScan would store the "base" time stamp.
And every RadarReturn would store the offset to this time stamp.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't explain it to me, explain it in the message precisely :-)

msg/RadarScan.msg Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants