4Wheel Drive Autonmous Driving about mpcc

[alexliniger]

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]

Thanks for your comment. I will look into this.

[prajwalthakur]

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]

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]

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

[JustMrZuo]

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]

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]

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]

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]

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

qMu is the weight for it

[prajwalthakur]

Hi ,
What branch has this cost implemented ?

[alexliniger]

In all the C++ implementations

[alexliniger]

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