frankaemika / libfranka

C++ library for Franka research robots
https://frankaemika.github.io
Apache License 2.0
232 stars 156 forks source link

Expose private headers for research #103

Closed ntorresalberto closed 6 days ago

ntorresalberto commented 3 years ago

Hi, We're currently working in a project related to rtt-franka-hardware-integration, which uses some private header files like robot_control.h in order to access franka::RobotControl class here.

Which leads to some hacky mechanisms in order to include these private headers.

I don't know if this is unexpected usage, but you already seem to have a research_interface:: namespace that could be used for this too.

I think it would be great to formalize the exposition of these headers either as an include subdirectory franka/research/franka_control.h in the same package or as a separate package libfranka-research-dev sort of way. The first one seems easier to setup.

Basically I'm trying to figure out if this is something you would be open to and if so, how to implement it. I recently worked on the rpm packages so if there's interest I could try to tackle it when I get some time.

AndreasKuhner commented 6 days ago

Hey @ntorresalberto , this might be a bit late... but is there still something going on..? Maybe we could consider something for future releases :grinning:

Cheers, Andreas

ntorresalberto commented 6 days ago

I'm no longer involved in the project but by the looks of it, franka::RobotControl seems to still be a virtual interface defined in a private header (src/robot_control.h).

It's old code now, so I don't know whether this is the only/best way to achieve it but, at that point in time, they needed a std::unique_ptr < franka::RobotControl > franka_control in order to use different franka::Robot::Impl objects (see here).

The proposal from this issue was to formalize that use case by exposing franka::RobotControl into the research_interface:: interface. However, as I'm no longer working on it and so I can't tell if it'd be useful anymore.