Integrating package into ROS installed from source

I have a problem with ROS installed on embedded SPARC machine from source. It is needed to integrate the geometry_msgs package and some others into our installation. Is there a general way to do that? Unfortunately, rosmake is not working on our platform due impossibility to detect OS and environment.

Asked by twdragon on 2019-02-28 06:00:27 UTC

Comments

You tagged this melodic, yet mention rosmake. rosmake is part of rosbuild, which is the build system that was deprecated many years ago and is virtually unused on Melodic (or any recent ROS release).

Can you clarify?

Also: could you provide a little more details about "integrate $pkg ..

Asked by gvdhoorn on 2019-02-28 06:04:03 UTC

.. into our installation"? Do you want to use new packages with an existing ROS installation (which happens to run on an embedded SPARC system)? Can you describe the ROS distribution that is currently installed on the target? Cross-compiled? Any particular framework used (OpenEmbedded, etc)?

Asked by gvdhoorn on 2019-02-28 06:06:11 UTC

We installed ROS Melodic on our non-standard SPARC system using limited debian-based Linux distribution. We have apt equipped with only very limited set of packages provided by CPU manufacturer. There are no ROS packages prebuilt. We installed ROS Melodic from source using pip and virtualenv.

Asked by twdragon on 2019-02-28 07:19:42 UTC

After that we tried to build our own workspace that requires geometry_msgs. And it was impossible to build it because of missing .cmake files from geometry_msgs. This is a problem because many of our packages require geometry_msgs. So it is desirable to integrate geometry_msgs into system

Asked by twdragon on 2019-02-28 07:27:58 UTC

Have you tried adding geometry_msgs to that workspace? If that would be an acceptable solution to you, that is how you could approach it. Just make sure all the (transitive) dependencies of your pkg and their dependencies are present in the workspace. You can use rosdep to check.

Asked by gvdhoorn on 2019-02-28 07:34:25 UTC

We installed ROS Melodic from source using pip and virtualenv.

and quite a bit of compilation I assume. ROS consists of much more than Python packages.

Asked by gvdhoorn on 2019-02-28 07:34:58 UTC

Also: what made you think rosmake was required / involved in all of this?

Asked by gvdhoorn on 2019-02-28 07:35:29 UTC

Have you tried adding geometry_msgs to that workspace?

Yes, I did. This solution is appropriate for single workspace but it is not for dozens. I think it could be very good solution to recompile .debs of shared ROS packages on our SPARC machines. Is here a tutorial to obtain .debs from source?

Asked by twdragon on 2019-02-28 16:15:47 UTC

Yes, I did. This solution is appropriate for single workspace but it is not for dozens.

that depends on how the logistics are handled. Using rosinstall_generator fi (which was probably used to do the initial from-source build) managing workspaces with source checkouts is quite common.

Asked by gvdhoorn on 2019-03-01 06:04:41 UTC

I think it could be very good solution to recompile .debs of shared ROS packages on our SPARC machines. Is here a tutorial to obtain .debs from source?

that could also work. I'm not aware of any tutorials, but there are a few Q&As on this site about that. git-buildpackage is a keyword.

Asked by gvdhoorn on 2019-03-01 06:05:25 UTC

If you're going to be serious about this (ie: SPARC compiled ROS pkgs), then perhaps taking a look at ros_buildfarm, buildbot-ros or meta-ros is good.

Asked by gvdhoorn on 2019-03-01 06:07:36 UTC

git-buildpackage is a keyword.

git-buildpackage is uninstallable for us because function name version_parse_and_fetch is lacking from version_parser Python module. I am trying to find a workaround now

Asked by twdragon on 2019-03-01 06:09:51 UTC

You don't necessarily need to build on-target ..

That's why I keep mentioning things like OpenEmbedded or other more cross-compilation/rootfs style approaches.

With resource-constraint embedded platforms, building off target and then transferring binaries is much more common and scalable.

Asked by gvdhoorn on 2019-03-01 06:26:55 UTC

Answers

With resource-constraint embedded platforms, building off target and then transferring binaries is much more common and scalable.

According to gvdhoorn's approach, I found a workaround of package installation in building off-target. I clone the package or package set into an empty workspace's src subdirectory and then build it with simple catkin_make install. After that I have install subdirectory which contains a set of files required to run the package. Due to ROS control system peculiarities it is enough to copy the contents of install directory onto the directory in which ROS was installed. Now rospack list shows the package and one able to use it.

Asked by twdragon on 2019-03-06 11:53:12 UTC

Comments

If you can build off-target then I would actually suggest to look into buildbot-ros or the git-buildpackage approach.

That is going to be much more scalable and managable (ie: have a package manager).

Asked by gvdhoorn on 2019-03-06 11:57:02 UTC