Discussion on DFNs interfaces¶

This page is a discussion to fix once and for all the interfaces and the way DFNs are going to be release inside the InFuse repo. I'll develop the example of DEM as it is the only DFPC that is "ready" at the moment. But I'm pretty sure that this can be generalized easily. For a reminder, the different DFNs of the DEM building DFPC can be found here (diagram DFPC_DEM_BUILDING.html).

So the DEM DFPCs contains 3 DFNs:

• PcTransform to transform the point cloud from sensor frame to world frame
• Rasterizer to project the cloud on a cartesian grid
• MapFuser to fuse it into our internal grid

At the moment the three DFNs + the ASN1 layer are in the same library. However, it is important to separate ASN1 from core as ASN1 might not always be the communication standard. A way to do this is to build 2 libraries as follows:

 
 

 

This way, libatlaas.so (or .a, but I think .so makes more sense here) contains the code of the three DFPC, while libatlaasASN1.so contains interfaces in ASN.1. It can be easily tested in ROS, in different ways. I think the way that makes more sense is a separate nodes with the DFN classes as attributes, as follows:

 

 

The advantage with this is that it separates clearly the different layers, and make it easy to write something that tests the different DFNs (e.g. I wrote 1 ROS node per DFN, making the stacking easy, the whole DEM DFPC can actually be put in one rosnode/genom3 module to accelerate/not spam the network with data).

Integration with InFuse archi¶

The way DFNs are integrated in InFuse relies on the DFNCI, as shown below for the example of PCTransform:

 

 

It is divided into 3 classes:

• DFNCI: Abstract class that each DFN will extend
• PcTransformInterface: Definition of the interface for the DFN. The functions "input" and "output" are used to update the io of the DFNs.
• PcTransformImplementation1: Definition of the DFI, i.e. one possible implementation of the DFN. It is where the process and configure functions are defined.

There are different ways to integrate our code into this architecture. The most simple for us would be either make the DFI depend or inherit from atlaas, as below:

 

 

This has 2 main advantages:

• Makes integration easy
• Keep the integral structure of the lib

However:

• It makes 3 DFNs depend on atlaas on its entirety. It makes sense in a way for rasterizer and fuser that will never be used outside of DEM building. But for a DFN as generic as PcTransform it feels weird to make it depend on atlaas.
• It make the DFI a simple interface. The core computation and algorithm is in atlaas.

 

The other way to go would be to make atlaas disappear and break it into DFNs without having a "unified" DEM library, as below:

 

This makes the library notion disappear but integrates the code well inside the InFuse architecture. This is how existing DFNs have been integrated by Strathclyde so far.