Apollo: Longitudinal controller calibration and debugging

[bbidault2]

Hello,

I have several questions regarding the longitudinal controller calibration file and the debug informations.

1. I believe the longitudinal controller is configured in file control.conf and lincoln.pb.txt, I have trouble understanding some of the elements of this file.

• What are the brake_deadzone and throttle_deadzone ?
• What is the station_pid used for ? Does _station_ stand for _stationary_ ? Does this PID determines the behavior of the vehicle when it starts moving ?
• What is the calibration_table and what is it used for, how does it work ? Does Apollo include a calibration script to calibrate the controller for my vehicle ?

EDIT : the calibration_table seem to be generated by a set of python scripts located in /modules/tools/calibration.

• Depending on the kp value of the low_speed_pid controller, the vehicle will either go too slow and come to a stop (if kp is small) or go much faster than expected (if kp is high).

1. When doing rostopic echo /apollo/control, I can see the debug information for the longitudinal controller, although I have a hard time interpreting it.

simple_lon_debug {
    station_reference: 1.45842000403
    station_error: 1.23437740756
    station_error_limited: 1.23437740756
    preview_station_error: 1.40005740595
    speed_reference: 0.801999986172
    speed_error: 0.226802970228
    speed_controller_input_limited: 0.350240710985
    preview_speed_reference: 0.84399998188
    preview_speed_error: 0.268802965936
    preview_acceleration_reference: 0.436101042652
    acceleration_cmd_closeloop: 0.141147006527
    acceleration_cmd: 0.577248049179
    acceleration_lookup: 0.577248049179
    speed_lookup: 0.577000021935
    calibration_value: 18.061075906
    throttle_cmd: 18.061075906
    brake_cmd: 0.0
    is_full_stop: false
    slope_offset_compensation: -0.000468702950871
  }

Could you detail what all these informations correspond to, and how they are determined. Is there documentation out there that explains how the controller works ?

$ git status 
On branch r2.0.0
Your branch is up-to-date with 'origin/r2.0.0'.

Please feel free to ask for details if my question is not clear enough. Thank you.

EDIT : @kals-amit, after seeing your issue #3279, it sounds like you could answer some of my questions. Would you mind explaining how to use the python script in /modules/tools/calibration.
I believe I am supposed to use data_collector.py then process_data.py. Although, the resulting files result.csv and filename.csv.result are empty. What arguments do you give to data_collector.py?
Thank you.

[silverland79]

I have the same question, Expecting answers.

[ubercool2]

I am also wondering on which vehicle has this controller been tested?

It seems that it is just doing a simple PID controller with some accounting for dead zone when breaking/applying throttle. I have never seen a vehicle that would have a linear response over 0-80mph range and would do speed control with only one PID controller.

In addition how do you tune parameters for PID and make sure that your controller is reposnsive yet it does not overshoot?

[bbidault2]

I am going to try and answer my own questions from the observations I have made these past few days.

• I did not know the expression _deadzone_ but it most probably refers to the throttle and brake deadband.
• The station controller _" track the station error between the vehicle trajectory reference and the vehicle position"_ (/docs/howto/how_to_tune_control_parameters.md).
• For a given speed and a desired acceleration, the calibration table return a throttle or brake command. As mentioned previously, it can be generated thanks to a set of python scripts located in /modules/tools/calibration.

I am still looking for answers regarding my second question.

@ubercool2 I believe this controller was tested on a Lincoln MKZ only. The PIDs are configured in /modules/control/conf/lincoln.pb.txt.

[Capri2014]

@ubercool2 @bbidault2 Sorry for the late reply.

1. Deadzone is deadband, essentially it describes the non-working zone for actuators.

2. The statement about the station error is right.

3. The similar controllers been tested on various vehicle platforms, including different sedans, minibus and more vehicle types. -- with different calibrations. The PID is used to handle the linear part while the calibration is used for non-linear part. @ubercool2 So you are right you will never see a vehicle a linear response over 0-80mph range and if you see closer to the code you will not see this assumption in Apollo controller design either.

[ubercool2]

@Capri2014 deadzone is a term no-one knows in automotive industry. The term should be called dead band. Also it is not a band where actuators do not work but it is a section where the motor torque value is so small that the movement of the steering handle is not influenced by the steering motor.

Regarding:

The similar controllers been tested on various vehicle platforms, including different sedans, minibus and more vehicle types. -- with different calibrations. The PID is used to handle the linear part while the calibration is used for non-linear part.

1. How do I use this controller? In particular how do I obtain calibration values?
2. @bbidault2 thinks that this has been tested on Lincoln MKZ only. Where I think that this controller would work because Dataspeed's DBW interface already implements a really awesome low-level lat and lon control.

Can you be a bit more specific about which sedans, minibus and more vehicle types are you talking? And with which DBW interface?

@ubercool2 So you are right you will never see a vehicle a linear response over 0-80mph range and if you see closer to the code you will not see this assumption in Apollo controller design either.

1. I actually tried to have a closer look at the code but what you state is actually not obvious at all. Mostly also because it is not documented.

[Capri2014]

@ubercool2

1. deadzone or deadband are just two control terminologies people always use it one or another. Sorry if I use deadzone instead of headband and this cause confusion to you.
   a. https://link.springer.com/article/10.1007/s11012-016-0563-3.
   b. https://pdfs.semanticscholar.org/e7ec/ae5fb3b0b96331a1bd4052b9e1db9649cce7.pdf
   c. https://pdfs.semanticscholar.org/7f1c/dbcf0b4be692f8bbb4d31329d9932f1f018a.pdf

2. The application of the controller, specific about "sedans, minibus and more vehicle types" is beyond the scope of this open-sourced code and sorry that I can not elaborate more on that. But one fact is that this controller did work well on the non-Dataspeed's DBW interface cars. 　

3. Lacking of documentation is one significant problem in Control/Canbus/Tooling part. Another thing I should admit is that a lot of the open issues are not answered in time. We are aware of that and we will try our best to document more. Thanks and in the meanwhile we would appreciate if the community would help adding more comments or documents.

[bbidault2]

@ubercool2

How do I use this controller? In particular how do I obtain calibration values?

You can run the controller by running the control script, ./script/control.sh. As I mentionned previously, the calibration table can be generated with a set of python scripts located in /modules/tools/calibration, it comes with documentation, /docs/howto/how_to_update_vehicle_calibration.md.

@Capri2014, thank you for the confirmations. Could you go over my second question (describing the longitudinal controller debug messages) and I will close the issue.

[Capri2014]

@bbidault2 Sorry this one previously did not have my name labeled so I had a hard time founding it back.

In short the debug messages just help to capture how good the longitudinal tracking is for offline analysis. We have station-velocity-acceleration loop with first two as close loop and last as open loop.
And for every loop, error = reference - feedback. Preview is off for 2.0 so you can ignore things about it as of now. Finally when we got acceleration, we use acceleration and current speed as the lookup table input and output is either throttle or brake.

station_reference: 1.45842000403
station_error: 1.23437740756
station_error_limited: 1.23437740756
preview_station_error: 1.40005740595
speed_reference: 0.801999986172
speed_error: 0.226802970228
speed_controller_input_limited: 0.350240710985
preview_speed_reference: 0.84399998188
preview_speed_error: 0.268802965936
preview_acceleration_reference: 0.436101042652
acceleration_cmd_closeloop: 0.141147006527
acceleration_cmd: 0.577248049179
acceleration_lookup: 0.577248049179
speed_lookup: 0.577000021935
calibration_value: 18.061075906
throttle_cmd: 18.061075906
brake_cmd: 0.0
is_full_stop: false
slope_offset_compensation: -0.000468702950871

[bbidault2]

Thank you @Capri2014, that help.
For people who would have similar difficulties, I would recommend to log and graph the controllers outputs, it helps a lot to understand how it works.

[Capri2014]

@bbidault2 It is actually used to log and graph, if you turn on "PnC monitor" under dream view, you can see both the real time plot for planning/control ( under different tabs)

[quuen]

@bbidault2 The resulting files result.csv and filename.csv.result are empty.I also find this issue. Have you solved this problem?Could you tell me some ways to solve it?