Definition of the control output command is little confusing

brkay54 commented 1 year ago

Checklist

[X] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] I've agreed with the maintainers that I can plan this task.

Description

cc. @TakaHoribe @mehmetdogru Hello everyone I want to report a confusion about the low side of the controller.

Firstly, I want to clarify two things about the commands we send to the low-level controller:

Reference acceleration: the acceleration vehicle should gain while driving on the road.
Thrust: The command we send to the vehicle to accelerate to the reference acceleration.

In the current implementation, we are calculating the reference acceleration in pid_longitudinal_controller by using the FF (acceleration from the planning side), PID output, slope, and delay compensation. However, the compensation side should be made in thrust calculation.

Purpose

Split the thrust and reference acceleration.

Possible approaches

I want to propose a solution for handling this difference:

The mission of the pid_longitudinal_control is the calculate the reference acceleration for the vehicle by using the velocity feedback (also because of this, we should make FF control optional)
We should make the raw_vehicle_cmd_converter more capable, I am planning to add the following features:
Start/Stop calibration: like here, this node should handle the start stop situation.
Stop hold and hill take off
Slope compensation
Maybe compensation for the actuators' delays. I am thinking about it, please feel free to share your opinion.

Also, users should be able to select the output of the autoware, raw_vehicle_cmd_converter will be able to give output as an actuator command or Ackermann Control Cmd.

If you have any comments, please feel free to share them with me!

Definition of done

Currently working on a vehicle to implement these features.

takayuki5168 commented 1 year ago

@brkay54 Hi, can I ask you more about the reason for splitting into the reference acceleration and thrust? I don't understand the motivation.

I think the delay compensation cannot be removed from the PID-based feedback controller. If the controller does not know the delay and the target velocity inside the controller is without the delay, how do we apply the delay to the controller's output?

brkay54 commented 1 year ago

@brkay54 Hi, can I ask you more about the reason for splitting into the reference acceleration and thrust? I don't understand the motivation.

Hi @takayuki5168, my motivation is to make more configurable control output for Autoware users. Some users may try Autoware on more primitive ECUs, so we should give them a place to help to integrate it into their vehicles.

I think raw_vehicle_cmd_converter is a good place for this purpose because it sends actuator commands. I propose that we should make it more configurable. For example; brake and gas are not the same mechanism so the user can define some parameters for both like delay. But I don't know how to implement it yet. On the other side, I want to add the features I mentioned above.

Also, in Autoware, all modules use acceleration without gravity. For example, in the controller, we are using acceleration from the planning side as FF output but it does not include gravity or the same for state estimation. So, I propose that control modules in Autoware do not take into account the gravitational things, It only sends the reference acceleration for the vehicle. And, raw_vehicle_cmd_converter implement these autoware2vehicle things for the user.

I think the delay compensation cannot be removed from the PID-based feedback controller. If the controller does not know the delay and the target velocity inside the controller is without the delay, how do we apply the delay to the controller's output?

Yes, you are right. I am currently thinking about that. Maybe, Autoware should handle only the state estimation delay and delay for the actuators handled by ECU or raw_vehicle_cmd_converter. As I said, I am still thinking about it. However, it is better to start by implementing the other features I mentioned above. The delay compensation should be a future improvement.

brkay54 commented 1 year ago

@takayuki5168 To handle delay compensation in different node, we can create a control command array in the longitudinal controller. Hence, raw_vehicle_cmd_converter can handle the delays for different actuators.

I will create detailed work about it.

TakaHoribe commented 1 year ago

@brkay54 Thank you for raising the issue.

The concept of these nodes is clear:

longitudinal/lateral controller: calculates a control command to follow the target trajectory
- common features that do not depend on the vehicle/DBW interface should be implemented here.
raw_vehicle_cmd_converter: converts the control command to the vehicle-specific signals (e.g. throttle, brake, gas, voltage, torque)

The "vehicle adaptation design" section in this document could be useful for the explanation. https://autowarefoundation.github.io/autoware-documentation/main/design/autoware-architecture/control/#vehicle-adaptation-design

my motivation is to make more configurable control output for Autoware users. Some users may try Autoware on more primitive ECUs, so we should give them a place to help to integrate it into their vehicles.

Therefore, the current design for the configuration is:

For users who want to use the generalized command (target velocity, acceleration), they can use the output of the control module directly.
For users who want to use the vehicle-specific command (gas, throttle, voltage), they can use the raw_vehicle_cmd_converter to convert the control module output to their specific command.

Does this solve your confusion?

However, the compensation side should be made in thrust calculation.

I'm not sure I'm seeing your real issue, but this is true. Some compensation (e.g. delay compensation) should be done in the raw_vehicle_cmd_converter since it can consider the vehicle-specific information. For example, now the delay compensation is applied for the acceleration, but there may be different time delays in throttle and brake. The information is only known by the raw_vehicle_cmd_converter. To achieve this, using the control command array sounds reasonable. What do you think?

TakaHoribe commented 1 year ago

@brkay54

The mission of the pid_longitudinal_control is the calculate the reference acceleration for the vehicle by using the velocity feedback (also because of this, we should make FF control optional)

I don't get why the FF should be optional. The mission of the longitudinal controller is to make the reference acceleration to follow the target trajectory. It does not care about the algorithm. (Of course the FF can be optional for some users who want to turn off the feature.)

Stop hold and hill take off

Slope compensation

Would you explain more why you think these features should be in the raw_vehicle_cmd_converter? Because, if these features can be generalized (these features can be designed without vehicle-specific information), it should be implemented not in the raw_vehicle_cmd_converter. Some example cases are helpful for me to understand well.

brkay54 commented 1 year ago

@TakaHoribe Thank you for the explanation, it is beneficial!

* For users who want to use the generalized command (target velocity, acceleration), they can use the output of the control module directly.

* For users who want to use the vehicle-specific command (gas, throttle, voltage), they can use the raw_vehicle_cmd_converter to convert the control module output to their specific command.

Does this solve your confusion?

However, the compensation side should be made in thrust calculation.

As you said, the longitudinal controller sends the necessary acceleration vehicle should get to come close to trajectory acceleration but It is not responsible to reach that acceleration value, it only sends the reference acceleration the vehicle should be to reach that velocity.

If the user's vehicle is supporting the acceleration command, the user can use it directly because the vehicle can already calculate its own thrust value to reach that acceleration. However, the vehicle may not support the acceleration commands, so another module is needed to create thrust value, it is raw_vehicle_cmd_converter.

What I want to propose is that the PID controller only calculates the reference acceleration values in some time horizon, and if the vehicle is not capable, raw_vehicle_cmd_converter should calculate necessary vehicle-specific outputs by using the reference acceleration values in the time horizon.

While raw_vehicle_cmd_converter calculates the necessary thrust, it should make the compensations that are needed because of the environment and vehicle, like slope, brake, and gas pedal delays. The PID controller should not be responsible for these calculations because if these calculations are made, the output won't be acceleration it will be thrust value I think it increases the complexity of the design.

I'm not sure I'm seeing your real issue, but this is true. Some compensation (e.g. delay compensation) should be done in the raw_vehicle_cmd_converter since it can consider the vehicle-specific information. For example, now the delay compensation is applied for the acceleration, but there may be different time delays in throttle and brake. The information is only known by the raw_vehicle_cmd_converter. To achieve this, using the control command array sounds reasonable. What do you think?

Yes, it makes sense, actually, this is what I am trying to propose.

The mission of the pid_longitudinal_control is the calculate the reference acceleration for the vehicle by using the velocity feedback (also because of this, we should make FF control optional)

I don't get why the FF should be optional. The mission of the longitudinal controller is to make the reference acceleration to follow the target trajectory. It does not care about the algorithm. (Of course the FF can be optional for some users who want to turn off the feature.)

For our environment, we are trying to drive the car on a very hilly road, because the FF is calculated for the 2D environment like I said here, it makes unstable in some parts of the map. (because the slope is increasing and decreasing continuously)

Stop hold and hill take off

Slope compensation

Would you explain more why you think these features should be in the raw_vehicle_cmd_converter? Because, if these features can be generalized (these features can be designed without vehicle-specific information), it should be implemented not in the raw_vehicle_cmd_converter. Some example cases are helpful for me to understand well.

For the slope compensation, of course, it can be implemented in the PID controller but like said above after it is implemented there, the output won't be reference acceleration anymore.

For stop hold and hill take off, I am open to another method but it needs some operations on the brake and gas pedal, after setting the reference acceleration, the vehicle moves backward while in time we take off the brake and press the gas. So I think we implement these features in raw_vehicle_cmd_converter.

stale[bot] commented 1 year ago

This pull request has been automatically marked as stale because it has not had recent activity.

autowarefoundation / autoware.universe