search

DIT168-V2V-responsibles / v2v-protocol

GNU General Public License v3.0
7 stars 3 forks source link

LeaderStatus Timestamp field clarification #18

Open maansthoernvik opened 6 years ago

maansthoernvik commented 6 years ago

Timestamp field of the LeaderStatus message could use further clarification when it comes to the used time zone and if we should adjust for summer time. UTC/CEST, etc?

gusperlee commented 6 years ago

Is that what timestamp is supposed to display though? Is it not just a 0-1000 ms repeating clock?

On Thu, 26 Apr 2018, 13:17 Måns Thörnvik, notifications@github.com wrote:

Timestamp field of the LeaderStatus message could use further clarification when it comes to the used time zone and if we should adjust for summer time. UTC/CEST, etc?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/DIT168-V2V-responsibles/v2v-protocol/issues/18, or mute the thread https://github.com/notifications/unsubscribe-auth/AYHx6rPy0w1nI0qzBl6PluOJgwxHIr8mks5tsazWgaJpZM4Tk-8_ .

maansthoernvik commented 6 years ago

"The time stamp (the time that the message has been sent) of the leading vehicle, represented as UNIX Epoch time in milliseconds." Is what was agreed on, currently 1524837650121 (as of writing this). Otherwise there would have been no point in extending the timestamp to a 64bit int.

maansthoernvik commented 6 years ago

If car 1 reads 980ms and car 2 reads 20ms, how would you know if they are 40ms or 960ms apart?

gusperlee commented 6 years ago

Currently we really have no way of knowing. Is it required though? Can you not base the timestamp of each car on the received timestamp from the leader?

On Fri, 27 Apr 2018, 16:02 Måns Thörnvik, notifications@github.com wrote:

If car 1 reads 980ms and car 2 reads 20ms, how would you know if they are 40ms or 960ms apart?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/DIT168-V2V-responsibles/v2v-protocol/issues/18#issuecomment-384979450, or mute the thread https://github.com/notifications/unsubscribe-auth/AYHx6u0lvBJNce-GXG1xVG2rVNvW3ijMks5tsyUKgaJpZM4Tk-8_ .

maansthoernvik commented 6 years ago

From a protocol perspective, yes. If you just use the timestamp as a basis for your own, then what would you really gain from using it at all? It is supposed to serve as a way to see the delay in messages passed from Leader -> Follower so that the Follower can make any adjustments it needs to follow correctly. Take for example a leader who is starting to send left turn indications, not only does the follower need to log the distance until it should start turning left as well to follow in the leader's footsteps (or tracks really). But also account for the delay to execute the turn correctly. All theoretically of course, I don't think anyone has been able to get much use out of the timestamp due to the unruly nature of the car's communication services. Sometimes the delay is > 500ms sometimes it's 10ms...