add a sot_loader with the minimal functionalities.

[MaximilienNaveau]

Main idea:

The idea here is to simplify the work of the dynamic_graph_bridge.

The role of the dynamic_graph_bridge is currently the following:

• Dynamically loading the SoT.
• Execute the SoT controller by either:
  • generating a geometric controller in a thread to visualize a position controller output.
  • simply execute 1 iteration of the SoT controller.
• Implements the ROS1 interface using entities.
• Implements the user interface using ROS1.

The user has to handle the python terminal spawning in the Robot/DG interface.

From the above tasks I extracted the following ones:

• Dynamically loading the SoT.
• Execute 1 iteration of the SoT controller.
• Handle the embeded python interpreter.

The idea is to ease the addition/modification of robots inside the software stack.

How did I tested:

Implemented unit-test for the current class.

Is there unit-tests:

See tests/tools/test_sot_loader.cpp

[nim65s]

Hi,

I agree those features should be part of this package, and I like the way you added those.

What do you plan to do next ? I think the next steps would be to add a few tests here, and deprecate those features in dynamic_graph_bridge. Some refactoring of the packaging on robotpkg is also to be expected, as python is no longer optional if we merge this, but I can handle that

[MaximilienNaveau]

My plan is to add some unit-tests here. And mainly work on a dynamic_graph_ros2 package (maybe a dynamic_graph_bridge branch?). Or another package. I am not sure what is the best way...

[olivier-stasse]

You can have a look here https://github.com/olivier-stasse/dynamic_graph_bridge/tree/foxy

[MaximilienNaveau]

@olivier-stasse can you give me access to your fork for the continuation of the implementation?

[MaximilienNaveau]

@olivier-stasse can you give me access to your fork for the continuation of the implementation?

Or should I fork your fork and PR on it?

[olivier-stasse]

@olivier-stasse can you give me access to your fork for the continuation of the implementation?

Or should I fork your fork and PR on it?

If this PR is merged, I would say that probably cherry-picking what you like and make a PR directly on a foxy branch of dynamic_graph_bridge would be more efficient.

[MaximilienNaveau]

Ok I will do that

[MaximilienNaveau]

I pushed the unit-tests and I guess this is ready to be reviewed. The API might change depending on @olivier-stasse and @florent-lamiraux feedback.

[MaximilienNaveau]

CI fails because of the linters running on the bad python file. I guess a workaround would be to simple rename this file bad_python_script.py → bad_python_script

Ah good point!! I did not thought of this to prevent failure of the linters.

[MaximilienNaveau]

We should discuss about the device name retrieval at some point...