Overview

Before embarking on this subteam bootcamp, please ensure you’ve completed these instructions: https://uwarg-docs.atlassian.net/wiki/spaces/AD/pages/2241298916

This bootcamp is in effect starting 2023-09-06 . If you are doing the Autonomy bootcamp, you are at the right place!

Setup

Git and GitHub

Git is a powerful version control system that Autonomy uses to organize many members contributing to the same codebase. Think of it as undo/redo, copying and renaming files to save an older version, and branching all rolled into one.

GitHub is a source code hosting and sharing website owned by Microsoft.

Forking the repository:

1. If you haven’t already, create an account on GitHub. You can use either your UW email or something else. Otherwise, log in with the GitHub account you would like to use with WARG.

2. Visit: https://github.com/UWARG/autonomy-bootcamp-2023

3. Click on the Fork button (towards the top right, above the About section).

4. Click on the green Create fork button.

5. GitHub redirects you to your own copy of the repository.

Cloning the repository:

1. If you haven’t already, download and install Git:

   1. Git should already be installed on Linux and MacOS.

2. Windows (Linux and MacOS users skip step): Set line endings.

   1. Check: git config --get core.autocrlf

      1. If it is true or input , you do not need to set anything.

   2. Set: git config --global core.autocrlf [setting] .

      1. --global is optional, and replace [setting] with either true or input

      2. When in doubt, use input

   3. Additional information here:

3. Configure Git with your name and email:

   • --global if you want to use it as the default, otherwise it will just be for the current repository.

   • You can use your anonymous GitHub no-reply email.

4. Go to GitHub and navigate to your copy of the repository, under your account. Do not go to WARG’s copy of the repository!

5. Click on the green Code button.

6. In the dropdown, you can copy either the HTTPS or SSH link.

   1. Windows and MacOS: Copy the HTTPS link (although you can copy the SSH link if you desire).

   2. Linux: Copy the SSH link.

      1. If you really want to use HTTPS on Linux, you have to install the Git Credential Manager or create a Personal Access Token on GitHub. How to do this is left as an exercise for you.

7. If you’re using the SSH link (HTTPS link users skip this):

   1. If you haven’t already, create a new SSH key and add it to your GitHub account:

      2. If you add a password to your SSH key, you will have to type it in every time you use Git to interact with GitHub (e.g. cloning, pulling, pushing). You can always delete and create a new SSH key if you change your mind later.

8. Pick a parent directory to clone (download the code) into.

   1. Example: Cloning in C:\Users\Username\ will create a folder and then populate it: C:\Users\Username\autonomy-bootcamp-2023\[bootcamp files]

9. Open the console in the parent directory.

   1. Windows: Command prompt or Powershell.

   2. Linux and MacOS: Terminal.

10. Clone the repository: git clone [link you copied] , where [link you copied] is the link you copied in step 6.

    1. HTTPS link users: You will be prompted to log into your GitHub account. Do so.

11. Done!

Python and virtual environment

Python is the programming language this bootcamp uses.

A Python virtual environment is a self contained environment with a specific Python version and package versions. Different virtual environments can be used for different projects to maintain consistency.

1. If you haven’t already, download and install Python 3.8:

   1. If you already have Python 3.7 or below installed, you must install Python 3.8 (you do not need to uninstall the other version(s)). This is because of a package dependency which requires Python 3.8 or greater.

      1. Python 3.8.10 or later is recommended, otherwise you will have pip issues.

   2. If you have Python 3.9 or above installed, you’re probably fine. Probably. Autonomy code is designed and tested on Python 3.8 so use a different version at your own risk.

2. Open the console in the repository root.

   1. Windows: Use command prompt or PowerShell, not Git bash (the console that gets installed with Git).

   2. Example: C:\Users\Username\autonomy-bootcamp-2023

3. Create a virtual environment called venv by running: [python] -m venv venv/ , where [python] is Python 3.8 (e.g. python , python38 ).

   1. You can check which version of Python it is by running [python] --version

   2. If you move the repository to a different path after creating a virtual environment, you will have to delete the venv directory and repeat this step. Additionally, if your virtual environment breaks for any reason, you can always delete the venv directory and repeat this step for a fresh environment.

   3. If you want to call the virtual environment by a different name, replace venv/ with the name you want. Virtual environments are identified by their path, so different projects with the same venv virtual environment name is fine.

      1. Example: C:\Users\Username\autonomy-bootcamp-2023\venv\ and C:\Users\Username\computer-vision-python\venv\ are different.

4. Activate the virtual environment:

   1. Windows command prompt: venv\Scripts\activate.bat

   2. Windows Powershell: .\venv\Scripts\Activate.ps1

      1. If you get an error with: running scripts is disabled on this system

      2. Run: Set-ExecutionPolicy Unrestricted

      3. This allows you to run any Powershell scripts at will. For more detail:

   3. Linux and MacOS: source venv/bin/activate

5. You should now see (venv) in the prompt line.

6. Confirm the virtual environment uses Python 3.8: python --version

   1. Literally use python , none of the fancy stuff above.

   2. Example output: Python 3.8.10

7. Open requirements.txt

   1. MacOS: Remove +cu117 from both torch and torchvision

   2. Windows and Linux:

      1. If you have a CUDA capable GPU but don’t want to use it for some reason, change +cu117 to +cpu for both torch and torchvision

      2. If you don’t have a CUDA capable GPU, don’t change anything.

8. Download and install required packages: pip install -r requirements.txt

   1. This will install in your virtual environment under venv . The rest of your system is unaffected.

9. Done!

Directory

Now that you have everything needed to start, take a quick look at what you’re working with.

The repository is divided into 3 sections:

• modules/ 's free floating files contains the common classes that will be passed around the interfaces.

• modules/bootcamp/ is where you will write your code.

• modules/private/ is the black box to control. The bootcamp is completable without ever looking here. In fact, we encourage you to hold off until after completing all the tasks.

Each file has a docstring header that will contain one of the following:

• BOOTCAMPERS DO NOT MODIFY THIS FILE. : Do not modify this file! Your submission will not be accepted if these files are modified.

• BOOTCAMPERS TO COMPLETE. : Search for BOOTCAMPERS MODIFY BELOW THIS COMMENT (there may be multiple) and follow the instructions.

Do not commit extra files! Your submission will not be accepted if you have extra files.

Do not import any additional libraries. The bootcamp is completable as is.

Development

Every time you want to change code in your repository.

1. If you haven’t already, activate the virtual environment:

   1. Windows command prompt: venv\Scripts\activate.bat

   2. Windows Powershell: .\venv\Scripts\Activate.ps1

   3. Linux and MacOS: source venv/bin/activate

2. You should now see (venv) in the prompt line.

3. Code away! Run the tests! Please try to follow our style guide:

   1. Ask questions if you need help!

4. Make a commit:

   1. Check which files have changed: git status

   2. Run: git add [files you changed] , where [files you changed] are the files you want to add to the commit.

      1. Use git add . if you want to add all of them (the dot means wildcard in Git).

   3. Run: git commit -m "Your commit message"

   4. When you’re ready to push your latest commits to GitHub: git push

      1. No harm in doing this after every commit.

5. When you’re done, make sure to either close the terminal or run:

   1. Windows command prompt: venv\Scripts\deactivate.bat

   2. Everything else: deactivate

   3. This is important to avoid going to a different project and then accidentally polluting your current project’s virtual environment.

Optionally, you can also create new branches if you want to be more organized. You can search for git branch information online.

Windows Subsystem for Linux (WSL)

We do not recommend using WSL at this time because of several environment issues. You are free to make the attempt if you’re willing to encounter them (and if you solve them, please tell us). All Autonomy projects are currently cross platform so using Windows is perfectly fine.

CUDA issues:

If you have a CUDA capable GPU, you may encounter this error: Can't initialize NVML in torch/cuda/__init__.py:497

The current workaround is to hide the GPU: export CUDA_VISIBLE_DEVICES=-1

This is not ideal since you are removing a hardware advantage.

MobaXterm display issues:

If you are using MobaXterm, we suggest using a different display server. MobaXterm's display window flashes and moves towards the bottom right as OpenCV redraws the image.

This issue does not occur with a different display server: Xming version 6.9.0.31 (most recent we could find) and running: export DISPLAY=:0

This may not be necessary depending on whether you have WSLg already.

Submission and pull request

Once your submission is ready for review, open a pull request (PR) from your fork to the WARG repository.

1. Navigate to WARG’s copy of the repository:

2. At the top, click Pull requests.

3. To the right, click the green New pull request button.

4. Under Compare changes, click the “compare across forks” link.

5. The 3rd from the left: Click the head repository dropdown and select your repository (you can search for your username).

6. The 4th from the left: Click the compare dropdown and select the branch you want to submit.

   1. Do not open more than 1 pull request! The branch you select should contain (or eventually contain) all tasks which will be reviewed.

   2. Once you have an open PR, you can keep updating the same branch as you get feedback. You do not need to open another PR.

7. Click on the green Create pull request button.

8. Once you have an open PR and are ready for review, go to your Discord bootcamp thread and send this message: @Autonomy Lead My PR for the bootcamp is ready: [link to your PR on GitHub] .

   1. The @Autonomy Lead ping is bright pink.

9. The Autonomy Leads and/or bootcamp maintainers will review your PR (a message will be sent on Discord, and the comments will be on GitHub).

10. Read the feedback and go back to development. If any of the feedback is unclear or confusing, don’t hesitate to ask for clarification (make sure to send a message on Discord as well for visibility (e.g. I asked some questions as replies on GitHub ).

    1. Please do not resolve any of the comments that the reviewers may leave! It causes confusion for the reviewers since they use the resolved/unresolved state to confirm that the code meets the quality to their satisfaction. Instead, you can use a reaction or respond to the comment for your own tracking purposes.

    2. If you are ready for another review, repeat step 8 (you do not need to open a new PR).

11. Once your review is fully complete and you’re done with the bootcamp please follow the steps in to onboard to the team.

Tasks

Do not raise exceptions. The only exception are assertions, and only for quieting the linter (e.g. assert value is not None on Pylance). An assertion used in this way must be impossible to fail.

Task 1: Implementing ML inference

From the repository root, try running pytest modules/bootcamp/tests/test_detect_landing_pad.py . You will notice that all the unit tests fail, because of the raised NotImplementedError exception.

Your task is to implement the code in run() to correctly identify landing pads. You can remove or comment out the NotImplementedError line.

Once your code is correctly implemented, all tests should pass.

Task 2: Running the simulator

The simulator is composed of 5 pipelined stages:

• Simulation: Simulates a physical drone.

• Detection: Detects landing pad on camera image.

• Geolocation: Converts bounding boxes to locations.

• Display: Displays the camera image and drone information.

• Decision: Commands the drone.

Information moves from each stage to the next, and the loop is completed with commands from Decision to Simulation. Simulation requires a command to be sent from Decision every time step, making the simulator synchronous (in lock step, as opposed to asynchronous). The Decision stage is where you’ll write code for task 3 and task 4.

From the repository root, try running python -m modules.bootcamp.tests.run_decision_example . It should take about 12.5 seconds wall clock time for the drone to complete its first command (it will be obvious when it does). If the simulator is running too slowly, try increasing the time step size in modules/bootcamp/tests/run_decision_example.py (reducing the FPS). Take a look at modules/bootcamp/decision_example.py as well.

The simulator should exit after the drone lands, which occurs about 100 seconds after start. Ctrl-c to stop the simulator early. If the simulator exits early or has some error, then you should go through your task 1 code again and make sure there aren't any bugs. You are encouraged to use the debugger and/or print statements in conjunction with the simulator, as long as you do not breakpoint or step into modules/private/ .

Task 3: Making the drone move to and land at a waypoint

From the repository root, try running python -m modules.bootcamp.tests.run_decision_simple_waypoint . You will notice that the simulator starts but doesn’t do anything before exiting. This is because of the raised NotImplementedError exception.

The drone reports a status, which you will use to implement the drone decision logic to decide which command to send:

• Halted: The drone is not moving.

• Moving: The drone is moving.

• Landed: The drone has landed and the simulator is ending.

In addition, the drone report also contains its position and global destination (if applicable).

• The report’s destination is the same as the report’s position for Halted and Landed.

There are 4 types of commands:

• Null: Default. Does nothing but required to advance the simulator.

• Set relative destination: Move distance relative to current position of the drone. Requires drone to be halted. The destination must also be within the flight boundary.

  • The flight boundary is a square from (-60.0, -60.0) to (60.0, 60.0). The drone’s initial position is (0, 0).

  • The drone halts when it reaches the destination.

• Halt: Makes the drone stop immediately at its current position.

• Land: Lands the drone at the current position and ends the simulation. Requires drone to be halted.

If an invalid command is sent, it is ignored with a warning.

Your task is to implement the code in __init__() and run() to travel to and land at the designated waypoint. You can remove or comment out the NotImplementedError line.

Once your code is implemented, the simulator should exit after the drone lands, which should occur within 60 seconds of start. The difference between the coordinates of the drone position and waypoint under the text file in log/ should be less than 0.1 . You can also confirm with the screenshot.

Task 4: Putting it all together

From the repository root, try running python -m modules.bootcamp.tests.run_decision_waypoint_landing_pads . You will notice that the simulator starts but doesn’t do anything before exiting. This is because of the raised NotImplementedError exception.

You can copy and paste your code from the __init__() and run() methods of decision_simple_waypoint.py to see what happens. Do not copy the entire file, as the class name and descriptions are different.

Your task is to implement the code in __init__() and run() to travel to the designated waypoint, calculate which landing pad is closest (L-2 norm for the math nerds), and land at that landing pad. You can remove or comment out the NotImplementedError line.

Once your code is implemented, the simulator should exit after the drone lands, which should occur within 60 seconds of start. The difference between the coordinates of the drone position and the landing pad under the text file in log/ should be less than 0.1 . You can also confirm with the screenshot.