alexliniger / MPCC

Model Predictive Contouring Controller (MPCC) for Autonomous Racing
Apache License 2.0
1.34k stars 371 forks source link

4Wheel Drive Autonmous Driving #91

Closed prajwalthakur closed 4 months ago

prajwalthakur commented 7 months ago

Hi, thanks for your work and this repository. I have been seeing papers where MPCC and standard MPC have been compared in racing scenarios. I have not yet seen the use of MPCC in more general autonomous driving. Is there a particular reason for it? I am not able to think of any. I am talking about a scenario where the task for 4-wheel drive could be to track the reference trajectory. where the max speed could be 20km/hr~30km/hr ,and the task for MPCC would be just to follow the reference trajectory.

alexliniger commented 7 months ago

MPCC is special in the sense that it is a path following controller, it does not require a trajectory from a higher level controller, or can deal with a very simple type of trajectory. A tracking MPC on the other hand follows the trajectory of the higher level planner and thus the trajectory given to the tracking MPC needs to be high quality to successful work.

Thus, depending on what you want to achieve a tracking MPC (which is simpler) is enough or using a path following style MPC (like MPCC) has advantages. For single car racing, path following controller make a lot of sense since the higher level path planner can be avoided or a simple path planner is enough for obstacle avoidance. For autonomous driving, it is possible to set up a similar pipeline, however I can not give you an example. Nutonomy/Aptiv/Motional had some quite MPC heavy approaches, maybe looking for papers from them would be an idea. But this is also not the topic most AV companies are publishing.

Regarding the second question, given the new changes and the addition of ADCodeGen it should be quite straight forward to implement this. And you not even need a full state trajectory but a simple path you would like to follow is enough.

prajwalthakur commented 7 months ago

Thanks for your comment. I will look into this.

prajwalthakur commented 7 months ago

Hi , in 4WD do we have to track the yaw explicitly as well .if yes , Any suggestions on how can I include the yaw error in mpcc formulation ?

alexliniger commented 7 months ago

i once implemented a cost on the relative yaw to the reference path, it is quite easy. If this is of interest i can try to find the code and add it to the code base.

prajwalthakur commented 7 months ago

Hi , yeah that would be great . Could you add it in the code base please ?

JustMrZuo commented 5 months ago

As it stands, mpcc doesn't involve much in the actual execution of the lower level drivers, compared to ros' movebase framework. So at the level of the algorithmic framework alone, would the introduction of 4Wheel Drive make a big difference?

prajwalthakur commented 5 months ago

you are right , not much of a big difference. But in this ig it be better to track desired yaw as well , Otherwise car can orient itself in weird way , which might not be a desirable behaviour.

JustMrZuo commented 5 months ago

It seems to me that implementing heading angle tracking should not be complicated from a programming point of view, and that the bigger problem may be how to deal with the trade-offs between lag error, deviation error, and heading angle deviation in the cost function at a later stage. Meanwhile, the introduction of pre-sighting point updating for error computation by MPCC may exacerbate the problem to some extent.

alexliniger commented 5 months ago

As said from a code perspective it is straight forward, it is basically a quadratic loss between the yaw of the car and the correctly wrapped heading of the track which is just the atan2 of the gradients of the track spline.

The cost also adds some damping into the system, if the car is away from the reference path it only approaches it slowly. Finally, I think it also makes a lot of sense as a terminal cost. We used it in some of the follow up papers that are based on the curvilinear/frenet coordinate system, where the angle cost arrives very naturally.

I will try to find the code or reimplement it if I find time, which is currently the biggest issue.

alexliniger commented 5 months ago

Ok the heading cost is actually already implemented, I just forgot that I added it.

qMu is the weight for it

prajwalthakur commented 5 months ago

Hi , What branch has this cost implemented ?

alexliniger commented 5 months ago

In all the C++ implementations

alexliniger commented 4 months ago

I am closing the issue, you can re-open it if you have further questions