Revision history [back]

Can you clarify what sort of integration you are looking for?

Best practices is to keep non-ROS code "non-ROS code" and to create separate, relatively small (or thin) wrappers that make use of functionality provided by libraries etc.

Doing it that way, there should be no need to import any ..

Can you clarify what sort of integration you are looking for?

Best practices practice is to keep non-ROS code "non-ROS code" and to create separate, relatively small (or thin) wrappers that make use of functionality provided by libraries etc.

Doing it that way, there should be no need to import any ..

Can you clarify what sort of integration you are looking for?

Best practice is to keep non-ROS code "non-ROS code" and to create separate, relatively small (or thin) wrappers that make use of functionality provided by libraries etc.

Doing it that way, there should be no need to import any ..

Can you clarify what sort of integration you are looking for?

Best practice is to keep non-ROS code "non-ROS code" and to create separate, relatively small (or thin) wrappers that make use of functionality provided by libraries etc.

Doing it that way, there should be no need to import any sources or existing infrastructure into a ROS-aware IDE: just develop the non-ROS code as you always do, make sure the necessary parts can be found (by CMake) and keep the ROS adapters as ROS pkgs in a ROS workspace.

CMake has all the support for such a workflow (and Catkin too).

Edit:

it sounds like in the setup you're describing, the executables would end up being the ROS nodes, and other system code would be called via libraries. Yes?

that was my suggestion yes.

As to the type of integration you mention in your comment on @PeteBlackerThe3rd: see gerkey/ros1_external_use.

Note: this is not a typical workflow / setup, so you could run into some issues. There will also not be many people able to help you, as I believe 98% of ROS (1) users would be doing the regular Catkin based approach combined with my suggestion (calling into libraries from ROS nodes).

Another alternative way to integrate with ROS is to not integrate at all.

That may sound strange, but you could just use an IPC with rosbridge_suite on the ROS side, and some JSON parsing/emitting code on the other.other. Of course this could be done the other way around as well: write a ROS node that implements / uses the ROS API that you'd like to offer / consume and use any IPC system to communicate with your existing system (gRPC, etc).

This is a commercial product, not a research project, so I need to have a clean, maintainable design.

And personal perhaps, but please refrain from such comments. You're implying that all "research project" code is not clean or maintainable. I know that is a popular opinion, but it is far from true.

Can you clarify what sort of integration you are looking for?

Best practice is to keep non-ROS code "non-ROS code" and to create separate, relatively small (or thin) wrappers that make use of functionality provided by libraries etc.

Doing it that way, there should be no need to import any sources or existing infrastructure into a ROS-aware IDE: just develop the non-ROS code as you always do, make sure the necessary parts can be found (by CMake) and keep the ROS adapters as ROS pkgs in a ROS workspace.

CMake has all the support for such a workflow (and Catkin too).

Edit:

it sounds like in the setup you're describing, the executables would end up being the ROS nodes, and other system code would be called via libraries. Yes?

that was my suggestion yes.

I was hoping there was a way to basically add some ROS functionality to our project, sort of like a 3rd party SDK, rather than essentially ROS-ifying our whole project. This is starting to look like a naive notion...

As to the type of integration you mention in your comment on @PeteBlackerThe3rd: see gerkey/ros1_external_use. (this post talks a bit about it).

Note: this is not a typical workflow / setup, so you could run into some issues. There will also not be many people able to help you, as I believe 98% of ROS (1) users would be doing the regular Catkin based approach combined with my suggestion (calling into libraries from ROS nodes).

Another alternative way to integrate with ROS is to not integrate at all.

That may sound strange, but you could just use an IPC with rosbridge_suite on the ROS side, and some JSON parsing/emitting code on the other. Of course this could be done the other way around as well: write a ROS node that implements / uses the ROS API that you'd like to offer / consume and use any IPC system to communicate with your existing system (gRPC, etc).

This is a commercial product, not a research project, so I need to have a clean, maintainable design.

And personal perhaps, but please refrain from such comments. You're implying that all "research project" code is not clean or maintainable. I know that is a popular opinion, but it is far from true.

Can you clarify what sort of integration you are looking for?

Best practice is to keep non-ROS code "non-ROS code" and to create separate, relatively small (or thin) wrappers that make use of functionality provided by libraries etc.

Doing it that way, there should be no need to import any sources or existing infrastructure into a ROS-aware IDE: just develop the non-ROS code as you always do, make sure the necessary parts can be found (by CMake) and keep the ROS adapters as ROS pkgs in a ROS workspace.

CMake has all the support for such a workflow (and Catkin too).

Edit:

it sounds like in the setup you're describing, the executables would end up being the ROS nodes, and other system code would be called via libraries. Yes?

that was my suggestion yes.

I was hoping there was a way to basically add some ROS functionality to our project, sort of like a 3rd party SDK, rather than essentially ROS-ifying our whole project. This is starting to look like a naive notion...

As to the type of integration you mention in your comment on @PeteBlackerThe3rd: see gerkey/ros1_external_use (this post talks a bit about it).

Note: this is not a typical workflow / setup, so you could run into some issues. There will also not be many people able to help you, as I believe 98% of ROS (1) users would be doing the regular Catkin based approach combined with my suggestion (calling into libraries from ROS nodes).

Another alternative way to integrate with ROS is to not integrate at all.

That may sound strange, but you could just use an IPC with rosbridge_suite on the ROS side, and some JSON parsing/emitting code on the other. Of course this could be done the other way around as well: write a ROS node that implements / uses the ROS API that you'd like to offer / consume and use any IPC system to communicate with your existing system (gRPC, etc).

This is a commercial product, not a research project, so I need to have a clean, maintainable design.

And personal perhaps, but please refrain from such comments. You're implying that all "research project" code is not clean or maintainable. I know that is a popular opinion, thing to claim, but it is far from true.