[robocup-small] New Referee Box Protocol

[Angelo Gurzoni Jr]

Hello there
I always get amazed to see how many bright people we have around. We need to discuss more, that's great !

I'd say the time format is not critical, so we may want to make sure we don't forget the rest of the protocol going too deep about the time format  discussion. For instance, how about having a command and button for corner/goal kick ?

About the time, though, I have the opinion that we don't need "much" (I know, this is very relative) precision, and the level we get from the SSL-Vision format versus its code complexity is a good trade-off. So why not to just use the same, to make it easy ? if it was to change, then I'd say to change both together. The NTP/ refbox having NTPD idea is great. Let's not forget, though, we most likely won't be able to get more than the millisecond order of sync with it, making anything more precise hard to attain



Cheers


-----Original Message-----
From: robocup-small-bounces at cc.gatech.edu [mailto:robocup-small-bounces at cc.gatech.edu] On Behalf Of Christopher Head
Sent: Friday, November 09, 2012 9:19 PM
To: robocup-small at cc.gatech.edu
Subject: Re: [robocup-small] New Referee Box Protocol

Well, technically the OS gives it as nanoseconds. I didn’t want to go with uint64 nanoseconds because it would only be a few bits away from a 32-bit time_t which suffers from the 2038 bug (admittedly it would be a few orders of binary magnitude, but still). Then Joydeep implied he thought milliseconds were not as fine as they could be. I like the tradeoff of using microseconds though! Joydeep, what do you think? (or anyone else)

Chris

On Fri, 9 Nov 2012 13:55:44 -0800
Ben Johnson <circuitben at gmail.com> wrote:

> I am in favor of using integers for time.
> If we use floating-point seconds, we have a potential rounding error 
> because we need so much dynamic range.  Because 1e-6 can't be 
> represented exactly in a float64, adding one microsecond to a time 
> produces an incorrect result (see the demonstration code below).
> 
> If we use floating-point microseconds, that is no better than integer 
> microseconds, but with a less elegant implementation.  Vision uses 
> integer microseconds in a uint64, and timing matters much more for 
> vision than for referee messages.
> 
> A double doesn't give significantly better resolution than one 
> microsecond (less than two bits), and since it can't actually 
> represent one microsecond exactly, I would argue that it's worse.  It 
> introduces rounding error without any advantage.
> Referee messages except for time remaining are inherently 
> high-latency, because they pass through two humans before they reach 
> the computer. Extremely high precision is not necessary.
> If for some reason we actually need better resolution, I would suggest 
> adding more bits as another field.  The purpose of floating-point 
> formats is to provide a variable exponent, which we don't need here.
> 
> It's easy to convert to a double on the receiving side, but it's hard 
> to fix rounding errors after the fact.  I would rather see the time 
> exactly as the OS originally gave it.
> 
> Rounding demonstration:
> #include <stdio.h>
> #include <sys/time.h>
> 
> int main()
> {
>     struct timeval tv;
>     gettimeofday(&tv, 0);
> 
>     double t0 = tv.tv_sec + tv.tv_usec * 1.0e-6;
>     double t1 = t0 + 1.0e-6;
>     printf("%g\n", t1 - t0);
> 
>     return 0;
> }
_______________________________________________
robocup-small mailing list
robocup-small at cc.gatech.edu
https://mailman.cc.gatech.edu/mailman/listinfo/robocup-small