# Team Members

Jacob Buckman (Mechanical Engineering)

Frank Garcia (Electrical and Computer Engineering)

Tianrui Qiu (Mechanical Engineering)

Helene Loenvik (Cybernetics and Robotics)

# Course Milestones

## Physical Car Setup

Front View

Side View

Top-Down View

### Camera Mount

The slot on the part allows vertical adjustment of the camera's position.

The slot on the part allows horizontal adjustment of the camera's position. This part is bolted to the above part using M3 nuts, washers, and bolts.

The camera is attached to the front flat surface using velcro.

### Base Plate

Our base plate consists of two half plates with one plate placed on top of the other one, giving us some extra vertical place for other components.

# Final Project

## Description

We implemented an optimization algorithm that can determine the shortest path around a given track. We modified the code from an open-source project [1,2,3] that calculates such optimal path.

The following is an example of the generated optimal race line (dashed) for a race track in Berlin.

## Project Breakdown

1) We first needed to learn the structure of the given repositories. The following link helped us navigate through the code: https://graphbasedlocaltrajectoryplanner.readthedocs.io/en/latest/start/overview.html Some important instructions were attached here for reference:

Repository Folder Structure:

Code Workflow:

• The offline part generates a graph consisting of nodes - a lattice spanning the whole track - and vertices - cost-assigned splines connecting adjacent nodes.
• After graph is finished, the graph is pruned of loose ends or splines violating the vehicles dynamic constraints
• Cost value is calculated for each remaining spline in the graph (the ones not pruned).
• Example of cost is a large displacement from raceline costs more than a small displacement from raceline.
• The online part first fetches latest updates (pose estimate, object list, …) and then extracts an online node template from the offline graph.
• Only nodes belonging to the layers from the current position up to a specified planning horizon are considered in the next planning step. (also removes edges that are
intersecting objects but we are not dealing with objects)
• Dummy vehicle in code (car shown in graph simulation) is another vehicle racing on the race line at a reduced speed, which was replaced with our vehicle.
• Use the optimization[1] repo with helper[3] installed in the same directory to generate the input folders needed by the planner repo[2].

2) After we had an understanding of the code, we then proceeded to rosify it (make it compatible with ROS2)

ROS2 Workflow

• We made a csv file for the Indianapolis Motor Speedway race track and put it in the input->tracks folder in the optimization repo. Since we intended to work in a simulation, we changed the vehicle dynamics and dimensions stored in params folder to match the size of the race car in the simulation.

• The following graph shows the offline path for our warren track which consists of many meshed nodes. These lines represent the possibility the car can take at a particular location under ideal conditions.

• In the real world, the car will not be able to stick to the optimal route all the time. Therefore, we need to subscribe to the car's current position and velocity and use that information to generate a local path based on the many pre-generated routes.

The following link shows a video of the car actively calculating an optimal local path in the simulation.

Our subscriber receives the car position (in the real car this would be done using a GPS):

Our publisher publishes the optimized local path to the car:

## Accomplishments

• The following video shows our planner computing and publishing the local path as we use a manual controller to change the car's position.
https://youtu.be/KsH3drhGOBc
https://gitlab.com/franks-group/ece_148_final/-/tree/master
https://gitlab.com/franks-group/ece_148_final_trajectory_map/-/tree/main

## Future Work

1) Given more time, we would create a controller that subscribes to the trajectory planner that would publish throttle and steering commands to the simulation.

2) Once the simulation works, we would have tried to implement the algorithm on the robocar using a GPS for position feedback.

## References

1. Tumftm. “TUMFTM/global_racetrajectory_optimization: This Repository Contains Multiple Approaches for Generating Global Racetrajectories.” GitHub, https://github.com/TUMFTM/global_racetrajectory_optimization.

2. Tumftm. “TUMFTM/Graphbasedlocaltrajectoryplanner: Local Trajectory Planner Based on a Multilayer Graph Framework for Autonomous Race Vehicles.” GitHub, https://github.com/TUMFTM/GraphBasedLocalTrajectoryPlanner.

3. Tumftm. “TUMFTM/trajectory_planning_helpers: Useful Functions Used for Path and Trajectory Planning at TUM/FTM.” GitHub, https://github.com/TUMFTM/trajectory_planning_helpers.