Hand-in lab assignment 3

1.3. Hand-in lab assignment 3#

This section describes the requirements for Lab 3.

Important

  • For this assignment you should work through the manual and its exercises up to and including Section 9. You do not need to hand in the solution to any of the exercises in this manual. However, it is in your own interest to complete all of the exercises you find throughout the text: you will need all of the insight you acquire in this module to successfully complete the others.

  • You will work on this hand-in assignment with your assigned lab partner. Carefully read the minimum submission requirements listed in Section 1.3.1 to avoid penalties. The hand-in task for this lab assignment will be described in Section 1.3.3, for which you have to commit code to your group’s new Git repository.

  • The deadline for this assignment is Wednesday, October 16, 23:59 . To submit, do not send anything to the Teaching Assistants (TAs) or lecturers, but ensure that you and your partner’s work is in the master branch in your group’s private Lab 3 repository.

  • You may only hand in your own work, and you are responsible for not sharing your code with students outside your group. Only use the Gitlab repository we will provide to collaborate with your partner. If we believe you have used material from other groups, or you have submitted material that is not yours, it will be reported to the exam committee. This may ultimately result in a failing grade or an expulsion.

  • Finally, if you find errors, ambiguously phrased exercises or have questions about this assignment, please use the Brightspace lab support forum.

1.3.1. Minimum submission requirements#

Your solution must be uploaded to the master branch in the private Git repository of your Lab 3 group, hosted at: https://gitlab.ro47003.me.tudelft.nl. Do not use an account on gitlab.com, github.com nor bitbucket.com (or any other such service).

The deadline for the submission is Wednesday, October 16, 23:59 . Before that deadline, it is obligatory that

  • your group’s work must have been placed in the group’s private repository on the TU Delft Gitlab server provided by us. You will be given a new repository for this lab, so do not reuse the repository from the previous lab,

  • all files created for the hand-in assignment must be included in the master branch on Gitlab, which is the only branch that will be checked,

  • both lab partners must have contributed at least one Git commit to the master branch using their own TU Delft Gitlab account which adds non-comment lines of code to a C++ source file, or to a ROS launch or config file, that is part of your completed solution. Tip: You can use git annotate <filename> to see who committed which lines.

If code is submitted that was written with ill intent, e.g. to manipulate files in the user’s home directory that were not specified by the task, which collects user passwords or exhibits similar malware-like behavior, you will immediately fail the course.

Danger

These minimum submission requirements should be easy to fulfill for any student actively participating in the lab assignments. Note that these requirements do not say anything about the completeness or quality of your code, but they are a hard requirement (ie: a lower bar) that demonstrate a sufficient minimum effort before the deadline.

If you fail to fulfill these minimum submission requirements, the penalty described in the course information will be applied.

1.3.2. Feedback#

After the submission deadline, you will receive peer-feedback on the following points of your solution:

  • The quality of your code: is the code well organized and not overcomplicated?

  • The quality of your solution: does the code do what it is supposed to do?

  • The quality of your documentation: does the readme explain how to use the code and is the code itself well commented?

Of course, you will also be required to give peer-feedback on the solutions of several of your fellow students.

1.3.3. Assignment#

For this hand-in assignment you will need to write a ROS node that makes a simulated Mirte robot follow a line. You need to create a ROS package which should include the source and header files for the control node, as well as the launch and configuration files required.

In Section 9 you’ve seen how to start the Mirte simulator, get sensor input, and publish a message to make Mirte move. The following sections describe the tasks of the hand-in assignment, which you should include in your submission. You will create a single ROS package named simple_control, that contains all files required for the three tasks. In the end, you will have Mirte following the line in the simulated world.

Complete the tasks described in this section together with your lab partner. You have completed the solution when it complies with all the task deliverables listed below. It is okay if you don’t succeed at perfectly solving everything, as this should give you feedback on your own understanding. However, take into account that both partners must fulfill the minimum submission requirements.

Tip

Discuss with your lab partner how you will collaborate and divide the work on the programming tasks before you start adding files to your repository as both your contributions will be needed to fulfill the minimum submission requirements.

1.3.3.1. Task 1 - Keep your repository up-to-date#

  • Create a new overlay workspace, for example lab3_ws

  • Clone the provided Gazebo Mirte simulator’s Git repository within your workspace’s src directory

  • Also clone your lab group’s Git repository within your workspace’s src directory

  • Within your lab group’s Git repository, create a ROS C++ package called simple_control

  • The directory structure of the workspace should look like this:

lab3_ws
 ├─ src
    ├─ ro47003_mirte_simulator
    │  ├─ ...
    ├─ <your_lab_Git_repository_name>
       ├─ LABGROUP.md
       ├─ README.md
       ├─ simple_control
           ├─ package.xml
           ├─ CMakeLists.txt
           ├─ src
               ├─ ...

In the next tasks, you will develop the simple_control package. Note that your lab group’s Git repository should not contain the whole workspace, but only the code of the simple_control package and any requested documentation.

When you hand in your solution to the tasks, ensure that you include all necessary files, and only the necessary files in your Git repository.

Task deliverables

  • The README contains both your student names and numbers;

  • The README states any resources from which you copy-pasted code, such as ChatGPT;

  • The README text should be written for students following this RSP course, so you should not need to explain Singularity, the Virtual Machine, etc. You should assume only packages in the provided Singularity image are available, and thus should not require package installation instructions besides your own simple_control package.

  • Your repository should include files you created to complete this assignment including configuration files and source code. If other files that you did not create should be included, this will be stated explicitly in the task description.

  • By following the instructions in your README and with your provided files, a capable student should be able to reproduce your result and be able to check that you completed all tasks.

Important

  • The repository should not contain any debug code, backup copies of files, unnecessary files or directories, or binary files such as rosbags.

1.3.3.2. Task 2 - Launch file to record a bag file#

The first task is to create an XML launch file with the name record.launch.xml that launches:

  • the Mirte simulation in Gazebo,

  • the Mirte teleop keyboard,

  • a rosbag record node that only records the messages on the one topic /mirte/cmd_vel to a bag file (so don’t record all topics with -a). Note that recording a rosbag from a launch file requires adding an <executable> tag, similar to the example in this documentation.

Now launch your record.launch.xml launch file and drive Mirte around using the keyboard. You can follow the black line or any other route, but it should be closed, meaning Mirte should end up in the same location where she started.

At the end of this task you should have a bag file with commands for Mirte to perform a closed trajectory.

Important

Make sure only one topic is recorded and it’s the correct one. You can check what topics are in the bag file with the command ros2 bag info <bagfile>. The bag file should be saved under the directory with the name rosbag directly under your main simple_control package directory. The name of the bag should be: teleop.bag.

Important

Do not track this bag file, or any other bag files in your local Git repository. If you accidentally added it to your local repository, do not push your repository until you have removed that commit from your branch. A good practice is to record all bag files in one dedicated directory, say bag/, and than add a line with that directory name to your .gitignore file.

Task deliverables

  • The record.launch.xml file in the appropriate directory in your package

  • The package properly configured such that the launch file can be started via ros2 launch simple_control record.launch.xml

  • README instructions on how to launch the launch file.

1.3.3.3. Task 3 - Launch file to play the previously created rosbag#

This second task will allow you to replay the trajectory you recorded in the previous task. To do this, create an XML launch file with the name play.launch.xml that launches:

  • The Mirte simulation.

  • A rosbag play node, that plays the teleop.bag file that you have just recorded.

Now launch your play.launch.xml launch file and take a look in Gazebo and see how the Mirte moves.

Task deliverables

  • The play.launch.xml file in the appropriate directory in your package

  • The package properly configured such that the launch file can be started via ros2 launch simple_control play.launch.xml

In your README.md, answer the following questions and explain:

  • Does the robot follow the same trajectory as the initial one?

  • Does the robot stop in the same position as where it started?

  • If there is a difference, what do you think causes this?

1.3.3.4. Task 4 - ROS C++ node to detect lines and control Mirte#

The fourth and final task is to create a ROS node in C++ to control the robot reacting to the line following sensors. You will create a node called simple_control_node and place it in your simple_control package created earlier.

Feel free to store some of your code in different source files, to create libraries and to use header files. In fact, while not strictly necessary, you are encouraged to do so.

The simple_control_node should subscribe to the two topics carrying mirte_msgs/msg/Intensity messages, then it should analyze the sensor data and publish geometry_msgs/msg/Twist messages to the corresponding topic to control Mirte. The mirte_msgs/msg/Intensity is defined in the mirte_msgs package, provided by us.

Here is a simple algorithm you can use to follow the line with Mirte:

if left_intensity is less than right_intensity:
    turn to the left
if right_intensity is less than left_intensity:
    turn to the right
if left_intensity and right_intensity are similar and low:
    stop
else:
    drive forward

You need to use at least three ROS parameters to control the speed of Mirte:

  • linear_velocity_forward to control the linear velocity of Mirte when it is driving forward.

  • linear_velocity_steering to control the linear velocity of Mirte when it is turning.

  • angular_velocity_steering to control the angular velocity of Mirte when it is turning.

You can try out different values for the speeds, usually linear_velocity_steering should be lower than the other two. Also only values higher than 0 should be used. To facilitate this, add an RCLCPP_INFO logging statement to display the values of the three parameters when you read them (note: not when you use them).

Finally, you need to create an XML launch file in your package named simple_control.launch.xml that launches:

  • The Mirte simulation.

  • Your simple_control_node.

  • In addition, your launch file should set the three parameters on the simple_control_node to some predefined values.

Once you have completed this assignment, you should be able to launch your simple_control.launch.xml launch file and see the Mirte following the line in the simulation.

Solution requirements

Assuming that you do not have a directory ~/lab3_ws yet, the following commands should download your code and compile your workspace:

$ source /opt/ros/humble/setup.bash
$ cd ~
$ mkdir -p lab3_ws/src
$ cd lab3_ws/src
$ git clone <your repository url>
$ git clone git@gitlab.ro47003.me.tudelft.nl:students-2425/ro47003_mirte_simulator.git
$ cd ..
$ colcon build
$ source install/local_setup.bash

After compiling, we should be able to directly launch all required nodes, with the single command

$ ros2 launch simple_control simple_control.launch.xml

These strict requirements are needed because it allows us to perform automated testing. We are planning to use this to provide you some automated feedback and tips. Make sure you test these build steps in your VM and make sure they work.

Task deliverables

  • Your code should compile and run inside the provided Singularity image.

  • All files needed to compile and to use your node should be part of the master branch of your Gitlab repository, see the minimum submission requirements at the start of this manual. This means that you should include files to setup the build process like the CMakeLists.txt and package.xml of your package and of course your C++ source, C++ header and launch files. Note: Do not track any bag files, or any other files that are not needed to compile and run your node.

  • It is not allowed to make modifications to the packages or files we provide.

  • The packages provided by us should not be committed to your repository.

  • Ensure that your code contains clear comments. At a minimum, each function, class, and method in your program should have a comment explaining what it does.

  • Provide appropriate documentation with instructions how to build and run your work in a README.md file.