Final Project

A MuSHR car drives through a hallway with a path planned in front of it.

Overview

Throughout this quarter, you’ve implemented each part of the sense, plan, act paradigm for autonomous robotic control. This final project will be a stress test of sorts involving all the work you’ve done so far. You’ll need to test your car’s ability to localize, plan, and follow paths in a new environment. If your previous projects were implemented efficiently and correctly, this project will likely not require any adjustments to your code.

Please complete this assignment with the same groups from projects 1-4.

Getting Started

You’ll need to update a few files to easily get started on this project, which can be obtained by pulling from our starter repository. If you followed the instructions in Project 3 to add an upstream remote, then you can just run the following:

$ git pull upstream main

Your Task

We are providing you with a map of the CSE building (Allen Center) basement hallways. Your job will be to make your car drive from one end of the hallway (near 022 and Snack Overflow) to the other end (by 014).

How To: Driving in the Hallways

You can use the same instructions from Project 4 to run each part of your code on the car. As a reminder, these commands are below. Run each of these commands on the car in a separate terminal for each one.

$ roslaunch mushr_base teleop.launch
$ rosrun map_server map_server $(rospack find cse478)/maps/cse_basement.yaml
$ roslaunch localization particle_filter_sim.launch use_namespace:=true publish_tf:=true tf_prefix:="car/"
$ roslaunch control controller.launch type:=mpc tf_prefix:="car/"
$ roslaunch planning planner_car.launch num_vertices:=1000 connection_radius:=20 curvature:=1

Then, on your workstation computer, run the following commands to start RViz and connect it to your car.

$ hostname -I # to find your workstation ip address
$ export ROS_IP=<workstation-ip>
$ export ROS_MASTER_URI=http://172.16.77.<car-#>:11311
$ rviz

Now, place your car in the hallway and use the 2d Pose Estimate button to initialize your particle filter. Finally, after ensuring that your roadmap has finished construction, use the 2d Nav Goal button to specify a target for your car. Hold down the right bumper on your controller to allow the car to be controlled autonomously.

In practice, while this method will work, it will be difficult to debug with since the workstation with RViz running on it won’t be visible from the car’s position. We recommend running a second instance of RViz on a virtual machine on a group member’s laptop. This RViz instance won’t be able to send messages to the car because of virtual machine networking issues, but it will be able to visualize all the topics needed to diagnose issues while observing the car. If you also run the ssh terminals to connect with the car from the VM, you’ll have a much quicker way to stop and restart nodes when needed. Alternatively, you can run RViz on the car itself and see the results on your virtual machine using X11 forwarding by appending -X to the ssh command. This instance of RViz will be very slow, but will be able to specify the initial pose and nav goals. If you choose to use this method, we suggest also running an instance of RViz on the virtual machine, which will be able to visualize topics but won’t be able to send messages to the car.

Hints

Below are some suggestions that can help you if you get stuck.

Processing Power

One of the limitations with the car is its small, low-powered computer. Some tasks, such as planning long paths, might take unreasonably long for the car to complete. Take a look at the parameters you use when running the planner node to help speed up the planning process. As an alternative option, you can run some nodes on the workstation instead of the car. Teleop, localization, and controller should be run directly on the car, but others can be offloaded to the workstation (note that these will not work from a virtual machine due to the networking issues discussed earlier, and may suffer from network reliability issues).

Hardware Tuning

You may find that your car’s motions don’t match up with the controls that are sent to it. To fix this, you can do some hardware tuning to make the car’s motion line up better with expected values. There is a simple process for tuning these values, and a tutorial is available on the MuSHR website.

Launch File

There are a lot of things that need to be run repeatedly on the car. If you want, you can simplify the process of starting all your code by creating a launch file that will run all the nodes you need at once. Use the existing launch files as a template to include all the launch files you need. Place your launch file in any package’s launch/ directory. Use the roslaunch docs as a reference for additional details on launch file syntax.

Additional Parameters

You may find that some parameters should be changed beyond the parameters included in our parameters.yaml files. For example, some controller types have additional parameters which are found in the get_ros_params() function of controller_ros.py. These parameters currently use a default value, but you can override them by adding the parameter into your parameters.yaml file.

Deliverables

Using GitLab, you will submit a bag file of your car completing the assigned task, as well as a writeup answering a few short questions. Use the command below to record your bag file. You should start the bag file recording before you set the 2d Nav Goal in RViz.

$ rosbag record /map /car/scan /car/particle_filter/inferred_pose /car/particle_filter/particles /tf /car/controller/path/poses /car/controller/real_path/poses /move_base_simple/goal /car/teleop/joy

Answer the following questions in final/README.md. Include your video and bag files in the final/ directory.

  1. What controller type did you choose to use for path following in the hallways (pid, pp, mpc)? Why did you choose this controller type?
  2. What roadmap parameters did you use for planning (num_vertices, connection_radius, curvature)? Why did you choose these parameters?
  3. What was the most difficult part of making your code work in the hallways?

Submission

As with the previous projects, you will use Git to submit your project (code, writeup and plots).

From your mushr478 directory, add any writeup files and changed code files. Commit those changes, then create a Git tag called submit-final. Pushing the tag is how we’ll know when your project is ready for grading.

$ cd ~/mushr_ws/src/mushr478/
$ git diff                             # See all your changes
$ git add .                            # Add all the changed files
$ git commit -m 'Finished Final Project!'  # Or write a more descriptive commit message
$ git push                             # Push changes to your GitLab repository
$ git tag submit-final                 # Create a tag named submit-final
$ git push --tags                      # Push the submit-final tag to GitLab