[refactor] change dynamic config param name

[minhnh]

The parameter name change is requested by #33. I thought it would be a good point to add some unit tests to the cloud processing functionalities. Following are a few issues that arose during the process that may be worth documenting somewhere:

• I believe the instruction in the b-it-bots wiki on how to run tests is wrong. The correct way to invoke tests for me was

  catkin build <package_name> --catkin-make-args run_tests

• It was necessary for me to run catkin build twice in order to not get ImportError for importing the _cpp_wrapper Boost Python library. This may be related to ros/catkin#974, which was recently patched with ros/catkin#986.
• I believe Travis is not triggering tests at the moment right @argenos? Maybe it's ok for now anyhow because of the point above.

[minhnh]

@alex-mitrevski @argenos I guess since mas_domestic_datasets is private, cloning it would be a bit tricky with Travis. How should this be resolved? I assume some SSH key would be required in the .travis.yml file, and SSH clone in the mas-perception.rosinstall?

[argenos]

I don't have time right now to take a look at this, so here are a few hints in case you want to work on it:

• I mentioned this yesterday, but maybe it makes sense that it's part of the PR discussion: If you are fine with making mas_perception dependent on the domestic datasets, then yes, add this to the rosinstall file.
• Might not be worth it to git lfs inside the docker image, unless you want the image to contain the datasets. The image size will increase unreasonably. I would clone this from Travis, then add it as a volume.
• Pro: Since Travis now (finally?) supports Xenial, we could ditch Docker. Contra: Once we upgrade to Melodic, we have to switch back to docker, afaik Travis still doesn't support Bionic, and at their pace it will probably take a long time.

[minhnh]

• The dataset in 25MB in total, now that the git history is cleaned up
• If you want CI to work with testing then we need testing data anyway. I argue it's simpler to have it within the image like the mas_stable currently. Otherwise we'd have to download it every time there's PR, which may be less scalable for larger datasets as well.
• Don't we need the docker image with the compiled packages, i.e. bitbots/bitbots-perception?
• @sthoduka are you ok with adding the dataset to the docker image? What's the size of @work dataset?

[argenos]

The “downloading” will happen anyways, except you will be pulling from Docker hub instead of using git lfs

[minhnh]

seems like there're some hacky ways to cache the docker image: https://github.com/travis-ci/travis-ci/issues/5358#issuecomment-248915326, but indeed caching docker image is not yet officially supported

[argenos]

I still don't think it makes sense to add the models to the docker image. Any image that builds upon this one will also contain the tests, whether we use them or not. Since this is just for testing, it makes more sense to add this as a volume. Loading other models would then also be easier to "override", e.g. switching a real model vs. the testing one.

[minhnh]

@argenos I am not sure how to do volumes with the current Travis-Docker setup that we have. Can you walk me through how to do this at some point next week?

[minhnh]

Ignoring themds_home_setups dependency for now to avoid Travis error, and because we are not actually running tests during builds. @sthoduka @alex-mitrevski @mhwasil please approve so I can merge.