Autoware won't start on a downward slope

[VRichardJP]

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I'm convinced that this is not my fault but a bug.

Description

This is a problem I have observed on site so I wasn't sure what was the cause, but I could easily reproduce it with the planning simulator.

In this example, the vehicle has to cross a short hilly road:

When the vehicle starts from 0km/h on the upward slope, there is no problem. But if it has to start from the downward slope, then it will simply not move. There is no problem if the vehicle has some velocity.

I understand the longitudinal controller adjusts target acceleration based on the slope, but here the vehicle will simply not start at all. I remember that when this happened on our vehicle, the control command sent by Autoware to the vehicle was stuck at target velocity = 0.25, target acceleration = -0.4.

Considering the longitudinal controller is PID based, I would expect the vehicle to reach desired velocity/acceleration even if the slope compensation overshoots. Setting enable_slope_compensation: false in the pid.param.yaml config file fixes the issue (so it is related to slope compensation logic)

The video below shows the issue, reproduced with the planning simulator:

downward_slope-2023-10-24_14.28.44.webm

Expected behavior

Vehicle should be able to start from downward slope.

Actual behavior

Stuck

Steps to reproduce

Planning simulator + hilly lanelet

Versions

No response

Possible causes

No response

Additional context

No response

[brkay54]

There is no gravity in planning_simulator, this should be the cause of this behavior in the planning simulator. Because while the vehicle in the slope, there is no force in the x direction. IMO, It is a problem of the simulation.

[VRichardJP]

@brkay54 I think it is a problem if the slope compensation may stop the vehicle forever. With the PID alone, the vehicle struggles to reach the desired acceleration, but at least it never get stuck.

A few weeks ago I also had the same issue on a different vehicle. There was a stop line on a road going slightly down. Autoware would often stop at the stop line and never restart. I never understood why autoware was sending negative acceleration values while it was supposed to accelerate. But now I think it was caused by the slope compensation.

[brkay54]

@VRichardJP Thank you for the comment and sorry for the late reply.

@brkay54 I think it is a problem if the slope compensation may stop the vehicle forever. With the PID alone, the vehicle struggles to reach the desired acceleration, but at least it never get stuck.

Yes, I think it is a problem too. However, the problem you mentioned above (stucks in psim) is a different issue. This issue is the result of not implementing gravity in psim. Just I want to clarify it.

A few weeks ago I also had the same issue on a different vehicle. There was a stop line on a road going slightly down. Autoware would often stop at the stop line and never restart. I never understood why autoware was sending negative acceleration values while it was supposed to accelerate. But now I think it was caused by the slope compensation.

For the issue that arises in real vehicle tests, I also agree with you. We saw the same problem on our tests too. It is normal to send negative acceleration values in a downward slope but sometimes it can not move the vehicle.

To avoid this problem, what we did was increase the engage acceleration value. (here).

However, it was not a good solution. I think to avoid getting the vehicle stuck, we should add another functionality. This functionality should handle this getting stuck problem. IMO, we should add another state to pid_controller called starting (currently we have 4 state: stopped - stopping - driving - emengency). In the starting state, if everything is okay and the vehicle is not moving, it should force the vehicle to move smoothly.

[VRichardJP]

I didn't check the current algorithm in details, but I think the PID controller should be able to compensate for overshot slope compensation, no?

For example, if target acceleration is +0.25m/s2, PID output +0.2 throttle and slope compensation adds a -0.4. Then initially the brakes are pushed. However if the vehicle does not move with that, then the difference between PID target and actual acceleration will quickly accumulate into the PID integral value. Eventually, the PID output will increase enough to compensate for the overshot slope compensation. But here it does not happen (so I guess the implementation is not exactly that).

Note that in this case, the PID controller should also be able to start the vehicle in the planning simulator. Actually, the simulator is a good example of slope compensation overshooting since there is no gravity.

[zulfaqar-azmi-t4]

However, the problem you mentioned above (stucks in psim) is a different issue. This issue is the result of not implementing gravity in psim

With regards to the PSIM, it currently supports pitch angle consideration from PR4941. But recently we found some bug, which should be solved with the following PR#5501.

However if the vehicle does not move with that, then the difference between PID target and actual acceleration will quickly accumulate into the PID integral value. Eventually, the PID output will increase enough to compensate for the overshot slope compensation. But here it does not happen (so I guess the implementation is not exactly that).

The topic was discussed in the Planning Control WG yesterday (meeting notes). TIER IV have decided to fix this issue, and we will open a discussion thread soon to present our solution.

on the side note, @VRichardJP, internally we dont really have a suitable map to test, therefore, is it possible to share your vector map with us, so that we can test our proposal later?

[danielsanchezaran]

Thank you for reporting this issue @VRichardJP I have oppened an issue to discuss possible solutions here

[VRichardJP]

@zulfaqar-azmi-t4
Unfortunately, I don't think I can share that map. But if you like I could create a hilly lanelet2 map on which the issue can be reproduced.

[mehmetdogru]

@zulfaqar-azmi-t4

You can use these maps LeoDrive created for test catalogs, some of them has precise slopes so might be useful:

https://drive.google.com/drive/folders/17a_99Gn6EdIrq8xrybN47hnKBPadECGj?usp=sharing

[danielsanchezaran]

@VRichardJP this merged PR introduces a way to enable error integration, even if the ego vehicle is starting from a complete stop. The feature is disabled by default. But it can be enabled by setting the enable_integration_at_low_speed parameter to true; you can also tune how long you want the PID to wait (while the vehicle does not move or moves at a very low speed) before integrating the error by changing the time_threshold_before_pid_integration. The parameters can be found here: https://github.com/autowarefoundation/autoware_launch/blob/main/autoware_launch/config/control/trajectory_follower/longitudinal/pid.param.yaml You can read more about it here: https://github.com/autowarefoundation/autoware.universe/blob/main/control/pid_longitudinal_controller/README.md#pid-control

I believe this feature should be enough to compensate for errors in the slope compensation that were causing your vehicle to not start moving. Please let me know if this solves the issue and the ticket can be closed.

PD: you might be interested in this PR #5616 that deals with a slope compensation error during simulation (Psim)

[VRichardJP]

@danielsanchezaran thanks for the PR.

I am curious what happens if the vehicle is kept stopped, not engaged. Does it fill the I term? Does it reset on vehicle engage? If so it means the vehicle may start suddenly when engaging the vehicle while autoware is in auto mode (is it possible?)

[danielsanchezaran]

@danielsanchezaran thanks for the PR.

I am curious what happens if the vehicle is kept stopped, not engaged. Does it fill the I term? Does it reset on vehicle engage? If so it means the vehicle may start suddenly when engaging the vehicle while autoware is in auto mode (is it possible?)

@VRichardJP Do you mean: What happens if you set a start and a goal for the vehicle, but do not press the "Auto" button (or send the engage command)? In that case, the timer won't start. As you can see in this video: #5549 (comment) the timer only starts ticking when I press "Auto" (for the video example I set a time threshold of 5 seconds) and the integration does not start until the time threshold is reached.

[danielsanchezaran]

@VRichardJP can we close this issue? I believe #5549 solves the problem

[VRichardJP]

Yes I think it is ok!