Interfacing CrazyS with TravisCI

In this wiki section is illustrated the employed solution to link the continuous integration (CI) open-source platform TravisCI with the CrazyS repository. Moreover, it is described the corresponding advantages that a CI system may give when developing a ROS component like CrazyS.

In the Listing below is reported the script used to configure the CrazyS repository with TravisCI. The code is based on an existing open-source project and has been customized to make it compatible with the Kinetic Kame distro of ROS.

matrix:
 include:
   - os: linux
     dist: trusty
     sudo: required
     env: ROS_DISTRO=indigo
   - os: linux
     dist: xenial
     sudo: required
     env: ROS_DISTRO=kinetic
language:
 - generic
cache:
 - apt
env:
 global:
    - ROS_CI_DESKTOP="‘lsb_release -cs‘"
    - CI_SOURCE_PATH=$(pwd)
    - ROSINSTALL_FILE=$CI_SOURCE_PATH/dependencies.
  rosinstall
    - CATKIN_OPTIONS=$CI_SOURCE_PATH/catkin.options
    - ROS_PARALLEL_JOBS=’-j8 -l6’
    - PYTHONPATH=$PYTHONPATH:/usr/lib/python2.7/distpackages:/usr/local/lib/python2.7/dist-packages
  before_install:
    - sudo sh -c ’echo "deb http://packages.ros.org/ros/ubuntu $ROS_CI_DESKTOP main" > /etc/apt/sources.list.d/ros-latest.list’
    - wget http://packages.ros.org/ros.key -O - | sudo apt-key add -
    - if [[ "$ROS_DISTRO" == "indigo" ]]; then sudo apt-get update && sudo apt-get install dpkg; fi
    - if [[ "$ROS_DISTRO" == "kinetic" ]]; then sudo rm /var/lib/dpkg/lock; fi
    - if [[ "$ROS_DISTRO" == "kinetic" ]]; then sudo dpkg --configure -a; fi
    - sudo apt-get update
    - sudo apt-get install ros-$ROS_DISTRO-desktop-full ros-$ROS_DISTRO-joy ros-$ROS_DISTRO-octomap-ros python
    - wstool python-catkin-tools
    - sudo apt-get install protobuf-compiler libgoogleglog-dev
    - sudo rosdep init
    - rosdep update
    - source /opt/ros/$ROS_DISTRO/setup.bash
  install:
    - mkdir -p ~/catkin_ws/src
    - cd ~/catkin_ws/src
    - catkin_init_workspace
    - catkin init
    - git clone https://github.com/gsilano/CrazyS.git
    - git clone https://github.com/gsilano/mav_comm.git
    - cd ~/catkin_ws/src/mav_comm
    - git checkout crazys
    - rosdep update
    - cd ~/catkin_ws
    - rosdep install --from-paths src -i
    - catkin build
    - echo "source ~/catkin_ws/devel/setup.bash" >> ~/.
   bashrc
    - source ~/.bashrc

In order to use TravisCI, a GitHub account and the TravisCI script are all the necessary components. The script, i.e., the .travis.yml file, has to be put in the root of the active repository (for students or academics, GitHub gives the possibility to build infinite private builds, 1).

Looking at the listing, the file is split into five main parts: include, language and cache, env, before install and install. In the first part, the matrix command tells TravisCI that two machines should be created sequentially. That allows to build and to test the code with different ROS distros (Indigo Igloo and Kinetic Kame, in this case) and OS (Thrusty and Xenial, 14:04 and 16:04 versions of Ubuntu, respectively) through the include command.

The second part, language and cache, enables the installing of the required ROS packages (the needed to use CrazyS, as explained in the README.md file). It allows to customize the environment running in a virtual machine. Finally, the parts env and before install configure all variables (they are used to trigger a build matrix) and system dependencies.

When the process starts, the catkin workspace is build with all the packages under integration (the commands listed in the install section). TravisCI clones the GitHub repository(-ies) into a new virtual environment, and carries out a series of tasks to build and test the code. If one or more of those tasks fails, the build is considered broken. If none of the tasks fails, the build is considered passed, and TravisCI can deploy the code to a web server, or an application host. In particular, the build is considered broken when one or more of its jobs complete with a state that is not passed:

• errored: a command in the before install or install phase returned a nonzero exit code. The job stops immediately;
• failed: a command in the script phase returned a non-zero exit code. The job continues to run until it completes;
• canceled: a user cancels the job before it completes.

At the end of the process, email notifications are sent to all the listed contributors members of the repository. The notifications can be forwarded: on success, on failure, always or never. Finally, the CI system can be also employed to automatically generate documentation starting from the source code and to link it to an online hosting. It is very useful when the project is going to increase or a lot of people are working on it or, more generally, when it is difficult to have an overview of the developed code. Further information on how to use the CI system and how to configure it can be found in 1.

Such procedure allows to easily verify the code quality, underlying errors and warnings through automated software build (including tests), that may not appear when building on own machine. It also ensures that modules working individually (e.g., SLAM, vision or sensors fusion algorithms) do not fail when they are put together due to causes that were difficult to predict during the development phase. For all such reasons, having a software tool able to catch what happened and why it happened, and able to suggest possible solutions, is extremely desirable when working with complex platforms as Gazebo and ROS.