Our short term goal is to implement simple and reliable replacement of gantryctl in HPE project.

The
replacement should be free of any project specific dependencies like homography or server
configuration. Ideally the new gantry module should be applicable for other projects and also for the
trainer application in live view.

Therefore I propose the design of Data Acquisition Machine, a software managing sensors (2D/3D
cameras, profilometers, line scanners) and motion controllers (FESTO in gantry axis, robot) in order
to acquire the data. The aim of this design is to define a very general and simple interface to be
applied in all related implementation. The design ensures easy extensibility. Initially we can
implement only the functionality and hardware handling needed for HPE and the trainer. Later we
can add new hardware and functionalities needed for other applications, the interface itself however
will not require any updates.

First I will describe the interface of the DAM and it’s usage, then I will propose implementation of the
the DAM.

Data Acquisition Machine is a bare minimum software without any application specific dependencies,
no product configuration, no connection to data sources like DB, ETCD, MQTT etc. It only moves
sensors to specified positions and grabs the data.

All the operations to be performed are defined as instructions. Instruction contains a list of
consecutive hardware commands (goto, take_image, start_streaming, start_scanning, etc.).
Commands in the instruction are specified along with required parameters, for example goto [x,z,y,r],
take_image [gantry_center], start_streaming [camera1, stream1].

Commands are executed by DAM in asynchronous manner. The caller thread is not being blocked.
After all commands in the instruction have been executed (or if the execution broke due to an error)
the DAM calls a handler function and passes the results: command status (cmd_ok, cmd_error) and
grabbed data, for example reference to image.

It’s up to the DAM caller how to organize the commands and instructions.

 For HPE each instruction will most likely contain 2 commands: goto and take_image. The
caller will pass the image to the inference immediately after grabbing.
 In case of profilometer usage the instruction could be: goto [start_pos], start_prfilometer,
goto [end_pos], stop_profilometer.
 In live view in the trainer app, each instruction will probably contain only one command.
When live view is open the command start_streaming is must be called. If user presses
button to move gantry then the only goto command must be executed.

DAM exposes only 3 functions:

1. initialize(configuration)
Connects to sensors and motion controllers defined in passed configuration. The
configuration is what we usually have in sifecfg.rml.
2. execute(instruction, callback)
Executes passed instruction and invokes passed callback function once the execution is
finished or broken
3. abort()
Aborts instruction execution
DAM is a Finite State Machine implementing related state handler for each supported command.

Implementation

DAM can be implemented based on idem4 with usage of existing modules.