Robotics Software Tips and Tricks

Intro

This page lists various software tips, tricks and tools that can come in handy during robot development. Feel free to add your tips and tricks to this list!

Single repository version management

Learn git! https://git-scm.com/book/en/v2

Merging vs rebasing

Merging combines two branches by creating a new commit that merges changes, preserving the history of both branches. Rebasing writes commit history by applying changes from one branch onto another, creating a linear history without merge commits. Please simply use 'merging' in your robotics code, the full history is preserved and could help to backtrack things.

Multiple Repository version management

Robots often use multiple repositories at the same time. Managing all these repositories by hand or with custom scripts can be tricky. Fortunately, various tools can be utilized.

VSCTool/wstool

VCStool can read .rosinstall files and clone all the repositories in those files. An example with the older wstool can be found in the https://gitlab.tue.nl/robotics/robots/curain the develop branch. See the Docker file where wstool is invoked to clone multiple repositories as specified in the .rosinstall file

TUE-env

TUE-env was created by the Robocup @Home student team. It consists of a number of bash scripts which install so-called targets which specify what to install in a .yaml file. See for example the .yaml file of Amigo. If you adopt tue-env, you must probably create your own targets, as those of the Robocup team are probably not useful to you.

Git Submodule

Git submodules are one way git allows having a repository in another repository. You could, for example, have one 'robot' meta-repository, which has several sub-repositories integrated as git submodulus. Git Submodulus allow you to fetch and update upstream changes of the submodulus.

Git Subtree

Git Subtrees can be used to 'copy' one commit of an existing repository to your repository.

Subtree vs Submodule

For an interesting discussion on subtrees or submodulus, see https://stackoverflow.com/questions/31769820/differences-between-git-submodule-and-subtree. Because development in robot software usually takes place in multiple repositories, keeping a link which can be updated easily to the original repository using submodules seems useful.

System dependency management (Docker/containerization)

Robot software is often built for specific OSes, build configurations and dependency configurations. This limits usability by different users, who will run other OSes, systems and who will not have all the required dependencies. Of course, these users could switch to the correct build system and tools, but often, this would result in conflicts with their existing software.

To combat these drawbacks; one could opt for virtual machines. However these run often quite heavy usually degrade performance noticeably.

Containerization is one of the lightest forms of abstracting the software and its dependencies from the host OS. Docker is often used for containerization purposes. If your software runs in Docker, every user that also wants to run your software, can do so by having a working Docker installation, either on Windows, Ubuntu or MacOS. Docker results in very little performance degradation.

An example of Docker usage is the cura-mega-legacy package. This package installs all the software components needed to run CURA in a Docker image. See the Dockerfile and the docker-compose.yaml in the root of CURA.