Build status on master branch:
Build status on master branch, using Drake and Director master branches:
This is a project repository for robotics research and applications using Drake and Director. This repository is meant as an internal tool for the Robot Locomotion Group and is not supported for external use. Documentation on how to operate the Kuka robot hardware can be found here.
The only supported way to build Spartan is with Docker. See build with Docker instructions here.
Director relies on LCM for message passing. Since LCM uses UDP multicast a valid multicast route must always be defined. Follow the instructions here under the section "Using LCM on a Single Host." Basically you just need to run:
sudo ifconfig lo multicast sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
After restarting your computer these settings can be lost depending on your network configuration.
You can run ctest in the build directory to run tests. Additionally, the
environment file adds some commands to run tests for sub-projects:
run_tests_drake run_tests_director
The above commands move into the build directory of the sub-project and run its tests. You can pass additional arguments to the test driver (ctest). For example, to print a list of available tests:
run_tests_director -N
To run tests in verbose mode:
run_tests_director -V
To run a specific test matching a name or regex:
run_tests_director -R testPyDrakeIk
To run tests in parallel:
run_tests_drake -j12
This project intends to track the master branches of these submodules, but the submodules are updated manually and only on demand, so they may not be completely up to date all the time.
It is ok to set the submodule reference to a personal branch hosted on a personal fork, as long as the changes in the branch are on track to be merged upstream in the near term, and as long as you are willing to rebase your branch onto upstream master on a frequent basis.
You can add executable scripts to the scripts/bin folder. These scripts will appear in your PATH via the sourced environment file.
- If you get an error related to an
LCM Self Test(e.g. in a director test), then it is likely your network is not allowing LCM packets to return via loopback. See https://lcm-proj.github.io/multicast_setup.html. - If you get an error related to being unable to find a shared library
liblcm.soafter callingmake, you may not have called. build/setup_environment.sh(or, equivalently,use_spartan). These commands work only after callingcmake, so run the CMake configuration -- then source the environment setup file -- then runmake.
- C++ code should follow the Google style guide https://google.github.io/styleguide/cppguide.html
- Python code should follow the Google style guide https://github.com/google/styleguide/blob/gh-pages/pyguide.md
CI is provided by Jenkins, presently running on a DRC laptop running Ubuntu 16.04 with nvidia-375 and CUDA 8, plus docker and nvidia-docker. Two Jenkins jobs test our build:
- A nightly-plus-whenever-it-is-updated build of the master branch. Master is tested by following the build-and-test routine described below.
- A whenever-it-is-requested build of PR branches, which can be requested by including the phrase "Jenkins please test" in a comment on the PR. The branches are tested by merging them into master (if possible) and then following the build-and-test routine described below. For now, tests can only be demanded by gizatt, manuelli, and peteflorence. Anyone else can request a test, but one of those admins will have to confirm to Jenkins that the test can be run. This feature uses [this tool](https://github.com/jenkinsci/ghprb-plugin) under the hood, so admins can use the command ok to test to accept a PR for testing, and add to whitelist to add the author of the PR to the whitelist forever.
Jenkins clones a completely fresh copy of the repository into a working directory, run git submodule update --init, and then runs:
python ${WORKSPACE}/setup/docker/docker_build.py
python ${WORKSPACE}/setup/docker/docker_run.py --entrypoint "/home/jenkins/spartan/setup/docker/run_jenkins.sh"
If any step of this returns a nonzero error code, the build is considered failed. That includes failures in initializing any submodule; errors provisioning or launching a docker container; or errors detected by the run_jenkins script, which contains its own error checking on the CMake configuration and the build. Eventually, we'll be able to test a full simulation stack too!