ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

I do this routinely to build on one machine (my laptop) and deploy to a target machine (the robot).

First, make sure all of the packages you're building have install directives set up in your CMakeLists.txt For more information, refer to the catkin docs.

The rest of these instructions assume you use catkin-tools to build your workspace. You can do all of this with catkin_make, but I don't use it, so I can't give you instructions.

  1. Choose a directory to deploy your code to. It needs to exist on both your build machine (or build container) and your target machine. If it's in your home directory, the user names have to be the same in both environments. I usually create a directory in /opt and use sudo chown to give it to my user.
  2. On the build machine, set up your catkin workspace for install builds:

    catkin config --install catkin config --install-space /opt/my_workspace

  3. Build your workspace with catkin build. Catkin will do the normal build, but it will also install everything to the install space. All your libraries will be in /opt/my_workspace/lib/, all your executables from each package will be in /opt/my_workspace/share/<pkg_name>/ and all of the files you install the share directory, like launch files, will be in /opt/my_workspace/share/<pkg_name>/. If you've ever poked around in /opt/ros/, you'll notice that this is exactly how the binary packages you install with apt-get are laid out.

  4. Copy your install space from build machine to target machine. You can do this with scp or rsync for physical machines. Since you're using Docker, you can probably build this step into your Dockerfile.

The one downside to this is that the install space isn't totally portable--you have to deploy the files to the same path as you installed them to when you built them. There are ways around that (that's how the ROS build server works), but it's probably not worth the trouble. If you need that kind of power, you should just spin up a ROS build farm and make Debians.

I do this routinely to build on one machine (my laptop) and deploy to a target machine (the robot).

First, make sure all of the packages you're building have install directives set up in your CMakeLists.txt For more information, refer to the catkin docs.

The rest of these instructions assume you use catkin-tools to build your workspace. You can do all of this with catkin_make, but I don't use it, so I can't give you instructions.

  1. Choose a directory to deploy your code to. It needs to exist on both your build machine (or build container) and your target machine. If it's in your home directory, the user names have to be the same in both environments. I usually create a directory in /opt and use sudo chown to give it to my user.
  2. On the build machine, set up your catkin workspace for install builds:

    catkin config --install --install

    catkin config --install-space /opt/my_workspace

  3. Build your workspace with catkin build. Catkin will do the normal build, but it will also install everything to the install space. All your libraries will be in /opt/my_workspace/lib/, all your executables from each package will be in /opt/my_workspace/share/<pkg_name>/ and all of the files you install the share directory, like launch files, will be in /opt/my_workspace/share/<pkg_name>/. If you've ever poked around in /opt/ros/, you'll notice that this is exactly how the binary packages you install with apt-get are laid out.

  4. Copy your install space from build machine to target machine. You can do this with scp or rsync for physical machines. Since you're using Docker, you can probably build this step into your Dockerfile.

The one downside to this is that the install space isn't totally portable--you have to deploy the files to the same path as you installed them to when you built them. There are ways around that (that's how the ROS build server works), but it's probably not worth the trouble. If you need that kind of power, you should just spin up a ROS build farm and make Debians.

I do this routinely to build on one machine (my laptop) and deploy to a target machine (the robot).

First, make sure all of the packages you're building have install directives set up in your CMakeLists.txt For more information, refer to the catkin docs.

The rest of these instructions assume you use catkin-tools to build your workspace. You can do all of this with catkin_make, but I don't use it, so I can't give you instructions.

  1. Choose a directory to deploy your code to. It needs to exist on both your build machine (or build container) and your target machine. If it's in your home directory, the user names have to be the same in both environments. I usually create a directory in /opt and use sudo chown to give it to my user.
  2. On the build machine, set up your catkin workspace for install builds:

    catkin config --install

    catkin config --install-space /opt/my_workspace

  3. Build your workspace with catkin build. Catkin will do the normal build, but it will also install everything to the install space. All your libraries will be in /opt/my_workspace/lib/, all your executables from each package will be in /opt/my_workspace/share/<pkg_name>/ and all of the files you install the share directory, like launch files, will be in /opt/my_workspace/share/<pkg_name>/. If you've ever poked around in /opt/ros/, you'll notice that this is exactly how the binary packages you install with apt-get are laid out.

  4. Copy your install space from build machine to target machine. You can do this with scp or rsync for physical machines. Since you're using Docker, you can probably build this step into your Dockerfile.

The one downside to this is that the install space isn't totally portable--you have to deploy the files to the same path as you installed them to when you built them. There are ways around that (that's how the ROS build server works), but it's probably not worth the trouble. If you need that kind of power, you should just spin up a ROS build farm and make Debians.

Debian packages.

I do this routinely to build on one machine (my laptop) and deploy to a target machine (the robot).

First, make sure all of the packages you're building have install directives set up in your CMakeLists.txt For more information, refer to the catkin docs.

The rest of these instructions assume you use catkin-tools to build your workspace. You can do all of this with catkin_make, but I don't use it, so I can't give you instructions.

  1. Choose a directory to deploy your code to. It needs to exist on both your build machine (or build container) and your target machine. If it's in your home directory, the user names have to be the same in both environments. I usually create a directory in /opt and use sudo chown to give it to my user.
  2. On the build machine, set up your catkin workspace for install builds:

    catkin config --install

    catkin config --install-space /opt/my_workspace

  3. Build your workspace with catkin build. Catkin will do the normal build, but it will also install everything to the install space. All your libraries will be in /opt/my_workspace/lib/, all your executables from each package will be in /opt/my_workspace/share/<pkg_name>//opt/my_workspace/lib/<pkg_name>/ and all of the files you install to the share directory, like launch files, will be in /opt/my_workspace/share/<pkg_name>/. If you've ever poked around in /opt/ros/, you'll notice that this is exactly how the binary packages you install with apt-get are laid out.

  4. Copy your install space from build machine to target machine. You can do this with scp or rsync for physical machines. Since you're using Docker, you can probably build this step into your Dockerfile.

The one downside to this is that the install space isn't totally portable--you have to deploy the files to the same path as you installed them to when you built them. There are ways around that (that's how the ROS build server works), but it's probably not worth the trouble. If you need that kind of power, you should just spin up a ROS build farm and make Debian packages.