Skip to content

Formula Student Non-linear curvature MPC developed for BCN eMotorsport team.

License

Notifications You must be signed in to change notification settings

fetty31/tailored_mpc

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

64 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Tailored MPC

Table of Contents
  1. Disclaimer
  2. Dependencies
  3. Approach
  4. Workflow
  5. Tuning
  6. Results

Here you can find the main Autonomous Systems controller for CAT15x, the BCN eMotorsport 2022-23 car. Within this repo you will find 3 different MPC controllers: time-variant, spatial-variant and lateral (also time-variant). The one used for the 2022-2023 season is the lateral approach, leaving the others for a future implementation as they demand much more testing time, which we don't ever have :(

If you want to see the performance of this controller watch THIS TRACKDRIVE.

Logo

This software is shared as part of my Final Degree Thesis. The controller actually used for competing during the 2022-2023 Formula Student season has been the lateral approach, so it's the one explained in the thesis (and the one that is driving the car in the trackdrive video).

Both other architectures were left apart due to the added tuning complexity of coupled NMPCs. However, the master approach is ready to drive :). The spatial approach is the one I found the most difficult to tune so it's not really fine tuned at the moment.

Disclaimer

This is a tailored control solution made for the CAT15x Formula Student vehicle. In order to make a proper use of this algorithm, it's the user duty to make sure the dynamic model (presented here) actually approximates the behaviour of the car.

If you use this control algorithm in a Formula Student competition the only thing I ask for is to ALWAYS REFERENCE the team BCN eMotorsport.

Dependencies

  • Ubuntu 20.04
  • ROS Noetic
  • Embotech FORCESPRO solver. A Hardware or Software Embotech's license is mandatory.
  • Eigen3
  • as_msgs: self-defined ROS msgs pkg. You may change it for yours, adapting the necessary callbacks.

Approach

For specific information on how the lateral controller work read Tailored MPC's paper.

For the sake of simplicity the different controllers are named after their more important characteristic. However, all the specified MPC controllers are curvature-based and follow a simplified non linear bicycle model.

Branches

Here's a quick explanation of this project branches:

  • master : time-dependant Non Linear MPC. Here a coupled (longitudinal+lateral dynamics) autonomous controller is specified. The main characteristics of this controller are:
    • High computational load (30ms)
    • Curvature based.
    • Handles throttle + steering commands.
    • Complex/Time consuming tuning.
    • High specialization (different parameters for each dynamic event).
    • No need for velocity profile input.
  • lateral : time-dependant Non Linear MPC. Here a decoupled (lateral dynamics) autonomous controller is specified. The main characteristics of this controller are:
    • Lower computational load (10ms).
    • Curvature based.
    • Handles steering commands.
    • Lower tuning complexity.
    • Must have a velocity profile as input for the whole horizon length (prediction horizon).
    • A longitudinal controller must run in parallel, following as close as possible the given velocity profile.
  • spatial : space-dependant Non Linear MPC. Here a coupled (lateral+longitudinal dynamics) autonomous controller is specified. The main characteristics of this controller are:
    • High computational load (30ms)
    • Curvature based.
    • Handles throttle + steering commands.
    • Complex/Time consuming tuning
    • No need for velocity profile input
    • High specialization (different parameters for each dynamic event).
    • Space dependant output, must be extrapolated into the time domain afterwards.
    • Adaptive integration step. Depending on the meters covered by the planner the spatial integration step can be bigger/lower.

NOTE: The other branches are still in an early development process. They're not ready for deployment!

Workflow

Here's a quick summary of the steps taken by the algorithm in each iteration.

In order to solve the Non Linear Optimization Problem (NLOP) defined with the solver declaration API the following procedure is followed (in this order):

  • Initial conditions: the initial conditions for all the state/control variables must be computed. Usually the only unkown initial conditions are the path tracking variables n & mu so they must be calculated using the actual car state and the planned trajectory.

  • Real time parameters & variable boundaries: the value of all the used real time parameters (or constant variables) must be given to the NLOP. A value for each parameter for each horizon stage must be set, meaning an array of m x n (where m == number of parameters and n == horizon length) must be filled. The same logic is applied to the boundaries array.

  • Memory buffer: FORCESPRO's solver enable us to control the RAM used by the solver and set memory buffers to be used by the c-generated solver software. We don't really need this tool so we let FORCESPRO full control on that aspect.

  • Solve: a call to the solver declaration must be made in order to solve the NLOP. It takes as arguments the m x n parameters array & boundaries array, a pointer to the memory handler, an array to fill with the found solution, an array to fill with solving procedure information and a reference to the Algorithmic Differentiation (AD) function (usually c-generated by FORCESPRO). If a self-developed AD tool is wanted, a reference to the c++ function should be given instead of the default one.

  • Get Solution: after the NLOP is solved, the given empty solution array will be filled with a solution for each optimization variable for each horizon stage. It becomes handy to copy this solution to some other data structures in order to work with the given solutions easily.

  • Progress Prediction: finally, a progress (s) prediction should be computed using the NLOP solution in order to use this information when setting the curvature values for the next solver call (next iteration). Basically, knowing the progress for each predicted state we can look for the closest planner points for each state and pick their curvature values for the next iteration. This heuristic procedure tends to help the NLOP convergence.

Tuning

Explanation of all parameters from the lateral branch:

Parameter Summary Value [SI]
Qs Progress rate weight 10.0
Qn Normal distance weight 550.0
Qmu Heading (track reference) weight 0.1
Qslip Slip difference weight 2.0
Qslack Track constraint slack weight 1000.0
Rd Steering rate weight 100.0
RMtv Additional moment weight 1.0
Bf Pacejka Constant 10.5507
Br Pacejka Constant 10.5507
Cf Pacejka Constant -1.2705
Cr Pacejka Constant -1.2705
Df Pacejka Constant 2208.0635
Dr Pacejka Constant 2563.599
Lf Distance from CoG to front axis 0.708
Lr Distance from CoG to rear axis 0.822
L Total car's length 2.72
W Total car's width 1.5
m Car's mass 210.0
Iz Inertial moment around z axis 180.0

Results

The technical performance of the controller is discussed here.