Add axis calculation component for pose estimation

[DamienGilliard]

This PR concerns the computation of poses for point clouds.

It uses K-Means clustering on the normals of the point cloud to find its orientation. It currently assumes a rectangular-ish beam, potentially poorly covered n^by the poinnt cloud. roundwood is currently not supported

It was observed that from one pose to the other, the axes could flip, which will result in a greater calculated difference of pose than in reality. To remedy that, this PR also includes a "serialization" of the poses in scriptcontext's sticky dictionnary. At the first pose estimation, the dictionnary is created and the poses written in the file. At the next pose estimations, the previous pose of the same element is queried in the dictionnary, and the orientation of the axes of the current pose is adapted so the angle between the axis from one pose to the other is smaller than 45 degrees. In this case we assume that the pose of the elements will not change by more than 45 degrees (for example the elements are not flipped between two poses).

The current solution is not 100% robust, but it seems that the issue is in the K-means clustering of Cilantro, with our data. Fixing it will take some time, so I propose we start with this.

The dictionnary created looks like that:

{
    "element_0": {
        "poses_dictionnary": {
            "pose_1": {
                "origin": [
                    56.10144971401154,
                    33.40872860007549,
                    21.446926284177337
                ],
                "xDirection": [
                    -0.020814251432826152,
                    -0.9615974745539926,
                    -0.22314606467553225
                ],
                "yDirection": [
                    -0.6622281632442112,
                    0.18192425510801624,
                    -0.7268819885026674
                ]
            },
            "pose_2": {
                "origin": [
                    56.10144971401154,
                    33.40872860007549,
                    21.446926284177337
                ],
                "xDirection": [
                    -0.0008243889879861405,
                    -0.9672127241417482,
                    -0.187437519350719
                ],
                "yDirection": [
                    -0.6644083065968324,
                    0.14314808583408417,
                    -0.7335327038702278
                ]
            }
       }    


}

The z direction being (xDirection X yDirection), it redundant and not serialized

[DamienGilliard]

Hi @eleniv3d , @Petingo , (and @9and3 from his powepoint) !
This PR is not working 100% but 90%-ish. I believe I will need more time with the k-means clustering to get it perfect, but the current state is good enough to build upon, I believe. So here is the PR and if you approve I'll merge it in the new branch df2_dev

[9and3]

@DamienGilliard thanks for the PR, from my side I will have a bit of time to have a look at it the week after the 26th may (if it is not too late and not merged yet). But nice, looks like a chunk for df!

[DamienGilliard]

• Have a numbering logic that keeps the same number for all beam at iteration n. For example if beam 3 is added at step 3, it will have pose_1 = None, pose_2 = None, pose_3 = (...)

[eleniv3d]

I tested it also with Andrea's roof and there is an error when loading data for a second time coming from

new_xDirection, new_yDirection = df_poses.select_vectors(vectors, rh_previous_xDirection, rh_previous_yDirection)

1. Error running script: list index out of range

i fugured out it's idx 6 that fails. I attach the file here:

test_file_for_pca.zip

[eleniv3d]

It would be better to check that i_clouds is not empty.

so add sth like:

if not i_clouds:
            return None, None

[DamienGilliard]

You are right, even better I have set i_clouds as not optional in the metadata, so we get "i_cloud parameter failed to collect data" and the code is simply not run. Let me know if you think this is not a satisfactory solution and if I also should implement it in the code :)

[DamienGilliard]

Hey Thanks for the feed-back, I'll fix those this WE.
I was also thinking that the workflow is not right, the poses are calculated and directly added to the history when in fact we should allow the user to validate the step before adding it to the history and move on to the next step...
Here is a diagram to make it clearer (hopefully ;) ).
What do you think of it ?

Component-wise it could look like that: