Basler camera timing errors

[rolfvdhulst]

When we (RoboTeam Twente) were testing our vision filters, we noted that often the Basler camera's produced a lot of consistent timing errors. We will probably submit a patch later to fix/amend these issues. I don't know how the other camera's were implemented, but it may be noted that likely doing a strategy along the lines of 'grab latest image' from a camera can be problematic if the image is not timestamped. I added two graphs here that show the typical raw velocity data of a robot kicking the ball of the basler camera (top) vs a kick from the 2019 robocup logs (bottom). You can clearly see the structure of the noise of the basler camera is periodic.

[g3force]

After a quick look into the source code, it looks like at least basler, spinnaker (current SSL cams) and dc1394 (firewire) all do the same:

  timeval tv{};
  gettimeofday(&tv, nullptr);
  result.setTime((double)tv.tv_sec + tv.tv_usec*(1.0E-6));

For Spinnaker, there is a timestamp available, but it would need to be synchronized manually to real clock, because ssl-vision is using unix timestamps and assumes synchronized system clocks among all vision computers.

[g3force]

One difference that I see is, the basler capture module retrieves the timestamp before the image, the other two modules retrieve the timestamp afterwards, which sounds more reasonable to me.

[rolfvdhulst]

Yeah you're right. As far as I can tell from Pylon's documentation it should also be possible to set a frame limit and get the actual capture time from the Camera's System Clock (atleast for the model that we use), but then we may need to synchronize that with the time of the computer running ssl-vision again.

[rttwente]

I investigated it, but the moment at which the timestamp is set gives an insignificant error. The difference between getting the timestamp before and after the image is approximately ~10^-5 seconds, which is negligible.

[rolfvdhulst]

closed by #177