Mnaveau/use shared pointer

[MaximilienNaveau]

Description

Modify the API to use std::shared_ptr. This should prevent potential memory missuses.

How I Tested

I import the python bindings and tested the addresses.
TODO test on a real robot!

I fulfilled the following requirements

• All new code is formatted according to our style guide (for C++ run clang-format, for Python, run flake8 and fix all warnings).
• All new functions/classes are documented and existing documentation is updated according to changes.
• No commented code from testing/debugging is kept (unless there is a good reason to keep it).

[MaximilienNaveau]

@Lhumd and @jviereck can I ask you guys to test the python bindings on solo12?
There is a demos/demo_solo12 file implemented by @jviereck that should work.

Can you let me know?

[jviereck]

Thanks for your changes @MaximilienNaveau .

After compiling and sourcing the workspace, I am getting this error:

$ ipython
In [1]: run demo_solo12.py
if_name: enp5s0f1
Using Ethernet (enp5s0f1)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
~/dev/blmc_testing/workspace/src/odri_control_interface/demos/demo_solo12.py in <module>
     23 # Read the values once here. The returned values are views on the data and
     24 # update after the call to `robot.parse_sensor_data()`.
---> 25 imu_attitude = robot.imu.attitude_euler
     26 positions = robot.joints.positions
     27 velocities = robot.joints.velocities

TypeError: No Python class registered for C++ class std::shared_ptr<odri_control_interface::IMU>

[MaximilienNaveau]

Ok I know what the problem is

[MaximilienNaveau]

This commit should fix the issue, sorry that was a dumb mistake.
Let me know when you have the chance to check this back

[MaximilienNaveau]

@jviereck @Lhumd this is finally mature, can you take look at the code an see if I didn't do something too crazy?
Thanks

[Lhumd]

@jviereck @Lhumd this is finally mature, can you take look at the code an see if I didn't do something too crazy?
Thanks

There is a problem with reading IMU data and I think it comes from here. It would be better to have a successful test on Bolt and then merge it.

[jviereck]

Thanks for the changes!

Did you check if the code works with the python bindings/python examples? Should I try it on the real robot?

[jviereck]

Did you check if the python bindings work? I had troubles when I wanted to use the integers before as it looks like the python binding was expecting long as type. That's why I implemented the motor_numbers as RefVectorX[l] before.

[MaximilienNaveau]

Ok you should try it and let me know if the python bindings are working or not.
If not I will provide a setter/accessor for VectorXl in the python bindings

[MaximilienNaveau]

The yaml parsing goes well and the objects are returned properly in python at least.
I am checking the construction of the robot by hand.

[jviereck]

Trying the latest branch, I am getting this error now:

In [1]: run demo_solo12_from_yaml.py
if_name: enp5s0f1
Using Ethernet (enp5s0f1)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
~/dev/blmc_testing/workspace/src/odri_control_interface/demos/demo_solo12_from_yaml.py in <module>
     32 # update after the call to `robot.parse_sensor_data()`.
     33 imu_attitude = robot.imu.attitude_euler
---> 34 positions = robot.joints.positions
     35 velocities = robot.joints.velocities
     36 

TypeError: No to_python (by-value) converter found for C++ type: Eigen::Ref<Eigen::Matrix<double, -1, 1, 0, -1, 1> const, 0, Eigen::InnerStride<1> >

[MaximilienNaveau]

@jviereck can you check again?

[jviereck]

With the above change (see last commit from me) I am able to run the python example on the real robot!

[MaximilienNaveau]

Cool, python bindings are working, hence we need to figure out why the imu is buggy on bolt.

[jviereck]

hence we need to figure out why the imu is buggy on bolt.

Shall this PR be merged already or do you want to figure out what's the problem on bolt first?

[MaximilienNaveau]

I want to know if the imu behavior comes from the master_board_sdk or the odri, investigation happens here:
open-dynamic-robot-initiative/bolt#5

[MaximilienNaveau]

Things work fine on bolt Debug and Release!
So I think we should merge and fix further bugs with additional PRs.