User manual
Version: v4.5.2
1
err = ftkGetLastFrame ( lib , serialNbr , frame );
2
if
( err == FTK_OK && frame -> imageLeftStat == QS_OK )
3
{
4
QImage * greyPicture (
new
QImage ( frame -> imageHeader .width , frame -> imageHeader .height ,
5
QImage :: Format_Indexed8 ) );
6
for
(
int
row( 0 ); row < greyPicture -> height (); ++ row )
7
{
8
memcpy ( greyPicture -> scanLine ( row ),
9
frame -> imageLeft row * frame -> imageHeader . imageStrideInBytes ,
10
greyPicture -> bytesPerLine () );
11
}
12
}
Listing 7.1: Example of reading the picture using the
.
7.3.1 The fusionTrack events
The application firmware is able to send ‘events’ to the host PC. Those events have a type (defined in [1]),
and optional data. Depending on the event type, they are periodically sent (the temperature-related events
for instance), or sent on a specific condition on the device (when the temperature is too low or to high for
example). The
SDK
provides a mechanism allowing the user to read those events.
7.4 Fiducial detection and marker tracking
Passive and active
fiducials
are detected by the fusionTrack using different methods.
The fusionTrack collects IR light for a period of time called integration time. This is an electronic shutter.
The value of this integration time can be tuned via option.
For passive
markers
, during the whole integration time, IR illuminators are lit and the retro-reflecting
coating of the passive
fiducials
reflects the IR light to the fusionTrack sensors.
For active
fiducials
, the fusionTrack emits an IR signal which triggers the LED emission on the connected
marker
.
In both cases, the IR light is detected by the fusionTrack sensors in the same way. The fusionTrack
SDK
then builds
fiducials
by combining pairs of
raw data
, wrong combinations are rejected using the epipolar error
explained in Section 7.9. The reconstructed
fiducials
are finally combined into
markers
, using the provided
geometry and applying the matching tolerance and a registration error cut to reject fake combinations.
The reconstructed
markers
are
tracked
from one frame to the next: this means a found
marker
on frame
n
will be looked for in frame
n
+
i
around its last known position. This allows to save CPU cycles as the
tracked
markers
do not undergo the whole reconstruction sequence.
The legacy
marker
reconstruction algorithm suffered from several flaws:
- a valid
marker
could be missed (i.e. not reconstructed) if, during the looking for
fiducial
i
, an additional
fiducial
lay at about the same distance. The algorithm was able to see the
marker
could not be
reconstructed due to the registration error but didn’t look for another possibility;
- the ‘Matching Tolerance’ option (see Section 8.1.1) was not implemented correctly, resulting in the
applied cut to be dependent on the compared distance in a non-trivial way. Due to the implementation,
a simple fix was not possible;
- the
first
found candidate was chosen as the correct one. With large tolerances, this could lead to
wronly reconstructed
markers
.
Atracsys / 2020-06-17 / 16:48:00
35 / 113
