Table of Contents:

1. Deadline

11:59:59 PM, Nov 01, 2025.

2. Problem Statement

In this project, you will implement the navigation (planning and control) stack from Project 2a on a simulated VizFlyt quadrotor. The starter code and the map can be download from here. The map is inside mapSplat.txt file and start and goal locations are already loaded in the environment file.

3. Environment

The map is known prior-art through a map file format from Project 2a. An example map file for the experiment is given in the starter code. The map of this environment is shown in Fig. 1. The coordinate frames are also defined as shown in Fig. 1 and the start and goal locations are marked as red and green circles respectively. If the start/goal location are given as 0 in the Z axis, that means you need to takeoff/land in that location respectively. In this case, you are expected to fly at a height of 0.5 (scaled units of Splat Frame) after takeoff and before landing. Although the boxes in Fig. 1 are not 1 unit in height (Z), you have to assume that it covers the entire area as given in map1.txt, this means that you are not allowed to fly over the boxes.

Fig 1: Sample environment for testing in VizFlyt world given in `mapSplat.txt`. Perspective view of the environment with coordinate axes. Red and green circles show start and goal locations respectively, dashed circle show being the obstacle.

4. Implementation

You will be using a VizFlyt simulated Quadrotor for the experiments. The goal is to navigate through a known map given the oracle position (you will assume that your odometry and controls are perfect in this case). Essentially, you will be implementing a path planner, waypoint trajectory generator and a position controller. To do this, you will modify your code from Project 2a and integrate it with VizFlyt package (more details on Turning setup are given in install.md file in the starter package and WPI’s Turning documentation can be found here). You are free to perform this project either with a position controller or a velocity controller. The goal is to navigate though the scene as fast as possible. Show your quadrotor pose in the map in matplotlib through the run..

A video tutorial on Turning access by your TA Deepak is shown below and can be downloaded from here.

Fig 2: Video tutorial of Turing Access.

4.1. Collision Handling

Your quadrotor should fly as fast as possible. However, a real quadrotor is not allowed to collide with anything (video). Therefore, we have zero tolerance towards collision - if you collide, you crash, you get zero for that test. For this part, collisions will be counted as if the free space of the robot is an open set; if you are on the boundary of a collision, you are in collision.

As you program your controller, you’ll know how well it works, it will have overshoots. Additionally, trajectory smoothing may also deviate the actual trajectory from the planned path. Therefore, you should make good use of the margin parameter and set your speed carefully. Please be aware that the robot is assumed to be a cuboid with a tall vertical height. You should make sure that no part of the robot collides with any obstacles.

5. Submission Guidelines

If your submission does not comply with the following guidelines, you’ll be given ZERO credit.

5.1. File tree and naming

Your submission on ELMS/Canvas must be a zip file, following the naming convention YourDirectoryID_p2b.zip. If you email ID is abc@wpi.edu, then your DirectoryID is abc.For our example, the submission file should be named abc_p2b.zip. The file must have the following directory structure. The file to run for your project should be called YourDirectoryID_p2b/Code/Wrapper.py. You can have any helper functions in sub-folders as you wish, be sure to index them using relative paths and if you have command line arguments for your Wrapper codes, make sure to have default values too. Please provide detailed instructions on how to run your code in README.md file.

NOTE: Please DO NOT include data in your submission. Furthermore, the size of your submission file should NOT exceed more than 500MB.

The file tree of your submission SHOULD resemble this:

YourDirectoryID_p2b.zip
├── maps
|   └── mapSplat.txt
├── p2phaseb_colmap
|   └── *
├── p2phaseb_colmap_splat
|   └── *
├── main.py
├── control.py
├── environment.py
├── path_planner.py
├── quad_dynamics.py
├── simulator.py
├── tello.py
├── trajectory_generator.py
├── install.md
├── Other files and folders
|   └── Any subfolders you want along with 
├── Report.pdf
├── Video.mp4
└── README.md

5.2. Report

For each section of the project, explain briefly what you did, and describe any interesting problems you encountered and/or solutions you implemented. You must include the following details in your writeup:

  • Your report MUST be typeset in LaTeX in the IEEE Tran format provided to you in the Draft folder and should of a conference quality paper. Feel free to use any online tool to edit such as Overleaf or install LaTeX on your local machine.

5.3. Video

Record the splat view (robot camera seeing the front when it executes the trajectory) in VizFlyt. Also include side by side your plot of the robot pose with obstacles in matplotlib. Make sure the video is in .mp4 format and submit it in the zip file and name the video as Video.mp4. Show the RRT* tree, planned path and trajectory as in Project 2a in the matplotlib plot.

6. Allowed and Disallowed functions

Allowed:

  • Any functions regarding reading, writing and displaying/plotting images in cv2, matplotlib
  • Basic math utilities including convolution operations in numpy and math
  • Any functions for pretty plots and visualizations
  • Any assets for visualizations
  • Quaternion libraries
  • Any library that perform transformation between various representations of attitude
  • Any code for alignment of timestamps

Disallowed:

  • All functions disallowed in P2a

If you have any doubts regarding allowed and disallowed functions, please drop a public post on Piazza.

7. Collaboration Policy

NOTE: You are STRONGLY encouraged to discuss the ideas with your peers. Treat the class as a big group/family and enjoy the learning experience.

However, the code should be your own, and should be the result of you exercising your own understanding of it. If you reference anyone else’s code in writing your project, you must properly cite it in your code (in comments) and your writeup. For the full honor code refer to the RBE595-F02-ST Fall 2025 website.

8. Acknowledgements

This fun project is inspired by ENAE788M: Hands-On Autonomous Aerial Robotics at the University of Maryland, College Park and MEAM620: Advanced Robotics at the University of Pennsylvania.