Home
build details

Classical Duckietown Baseline (ROS)

Modified 2019-04-29 by Bhairav Mehta

This section describes the basic procedure for making a submission using the Robot Operating System and the Duckietown software stack .

That you have made a submission with the ROS template and you understand how it works.

You could win the AI-DO!

Modified 2018-11-04 by liampaull

You will notice one main difference as compared to the ROS template is that the launch file argument in the solution.py code now points to lf_slim.launch, which launches a slimmed-down version of the Duckietown Lane Following code. The action and image topics are both adjusted to match the inputs and outputs of the original stack.

Inside of the Dockerfile, you will also see how to build and maintain your own catkin_ws. While in this example the workspace is not used, you will surely need it to build your own code.

Running the Entire Thing Locally for Debugging

Modified 2019-04-30 by Liam Paull

You can evaluate locally using dts challenges evaluate, but you may find this restricting, especially when you want to use ROS debugging tools like the rostopic or roslogging interfaces. For convenience, we’ve also provided a standalone version of this code (which will not give any rewards or AIDO task evaluation, but provides a way to easily visualize the output and behavior of your code).

Change into the local directory of the baseline repo.

$cd challenge-aido1_LF1-baseline-duckietown/local  The interface is mainly the same, except now, the rosagent.py file itself controls the simulation. Again, you will mainly want to focus on rosagent.py, and you will again be able to see the Dockerfile for how to build and maintain your own catkin_ws. To run this, you will need to have docker-compose installed on your local machine, as unlike the AIDO submissions, this will emulate both the server and agent all on your local machine. Follow instructions here to install. Cloning the Software Repo Locally Modified 2019-04-30 by Liam Paull You may still find the above a little bit cumbersome because if you just wanted to change a single parameter in the existing code and see the result, you will have to copy the entire node over and modify all the launch files etc. Then you might discover that the parameter you modified wasn’t the right one and this was a huge waste of time. Instead, we might like to be able to just modify things locally in the software repo and see the results in the simulator. Checkout the branch local-software-repo $ git checkout local-software-repo


Then clone the software repo here:

$git clone git@github.com:duckietown/Software.git  Then follow the same workflow as above: $ docker-compose -f docker-compose-lf.yml pull
$docker-compose -f docker-compose-lf.yml build$ docker-compose -f docker-compose-lf.yml up


The first time, this will take some time because the entore Software repo gets build by catkin_build, but the build artifacts will persist and this will be much faster on subsequent runs.

You can go ahead and make changes in the Software directory and these changes will propagate into your container. This is done by mounting the Software directory as a volume which effectively overwrites the existing software repo in the container.

If you have local nodes as described in Section 1.4 - Running the Entire Thing Locally for Debugging, they will not be available now since the whole software directory is being overwritten.

If you have only modified python script files that don’t need to even be rebuilt, then you can replace docker-compose -f docker-compose-lf.yml up with

\$ docker-compose -f docker-compose-lf-no-build.yml up


Debugging and Monitoring

Modified 2018-11-10 by liampaull

With ROS, everything of interest is passed through the ROS Messaging system. There are two ways to monitor your progress:

No questions found. You can ask a question on the website.