[Rock-dev] ROCK loging and dataset creation.

Sylvain Joyeux bir.sylvain at gmail.com
Wed Sep 9 22:38:51 CEST 2015


> |        frame_left_ptr->received_time = base::Time::now();
> |        frame_right_ptr->received_time = frame_left_ptr->received_time;
> So they have the same timestamp assigned to them.

Two problems:
 - the 'time' field is what the rest of the toolchain interprets as
the timestamp, so that's the field that needs to be synchronized
between the two frames
 - the exporter should use the 'lg' time, which should be the sample's
logical time (i.e. the timestamp) while 'rt' is the time of
acquisition on the logger side.

Sylvain

On Wed, Sep 9, 2015 at 2:23 PM,  <Evangelos.Boukas at esa.int> wrote:
> Thanks for your replies Matthias and Sylvain,
>
> I will look into the "estimator" and the "stream aligner". There are two
> main problems that i am tackling here.
> 1) When data are synchronized (in hardware and ROCK), how can we export them
> with the rock exporter so we create a dataset other devs might want to use
> (rock-independently)?
> 2) When we have cameras that are hardware synchronized, but we use two
> components ("camera-firewire") to read them, how can we give them exactly
> the same timestamp?
>
> Let's handle the 1st problem. An easy example I have is the following:
> The bumblebee stereo camera has a stream containing both left and right
> images so we are sure that the left-right cameras are "hardware
> synchronous":
> The bb2 driver deinterlaces the two frames and exports them to the
> appropriate port.. (sorry if the rock terminology is wrong, I'm quite new)
>
> The images are synchronous (obviously because of the camera hardware) and
> the "camera_firewire" orogen component outputs a single message to the
> "camera_bb2" orogen component.
> In the "camera_bb2" source you find that:
> |        frame_left_ptr->received_time = base::Time::now();
> |        frame_right_ptr->received_time = frame_left_ptr->received_time;
> So they have the same timestamp assigned to them.
>
> When I log the data and then replay them with the rock replay, I get exactly
> the same times on both "time" and "received_time", in the struct viewer, for
> both cameras.
>
> Then, when I export the images with rock-export  (#TIME prefix) i get two
> images (left right) with the following names:
>
> Loccam_2015_08_28_17_22_23_600342_0.png, with 2015_08_28_17_22_23_600342
> being the timestamp.
> Loccam_2015_08_28_17_22_23_601391_2.png, with 2015_08_28_17_22_23_601391
> being the timestamp. (the timastamps differ on a range 2000-3000
> microseconds)
>
> Now, if I understand how the rock-exporter uses some kind of time to convert
> it to the string in the line 118 of /log_tools/lib/log_tools/exporter.rb:
> |        name.gsub("#TIME",Time.at(rt).strftime("%Y_%m_%d_%H_%M_%S_%6N"))
>
> So, I guess that the problem is in this "rt" from the above code line. It
> seems like it is not one of those that the stream struct has...
>
> Thanks,
> Evangelos.
>
>
> From:        "Sylvain Joyeux" <bir.sylvain at gmail.com>
> To:        Evangelos.Boukas at esa.int
> Cc:        "rock-dev at dfki.de" <rock-dev at dfki.de>, Rob.Hewitt at esa.int
> Date:        09/09/2015 14:53
> Subject:        Re: [Rock-dev] ROCK loging and dataset creation.
> ________________________________
>
>
>
>> Even thought the images are actually synchronised (I can see it from the
>> product), the timestamps i am getting are not the same because of the
>> aforementioned struct properties.
>
> I am not sure I understand what it means. Can you be more explicit
> (like, give an example) ?
>
> Sylvain
>
> This message and any attachments are intended for the use of the addressee
> or addressees only.
> The unauthorised disclosure, use, dissemination or copying (either in whole
> or in part) of its
> content is not permitted.
> If you received this message in error, please notify the sender and delete
> it from your system.
> Emails can be altered and their integrity cannot be guaranteed by the
> sender.
>
> Please consider the environment before printing this email.


More information about the Rock-dev mailing list