Using a velocity array in the control command

[maxime-clem]

The idea of adding a velocity array to the control command of Autoware was recently proposed and this discussion thread will be used to provide more details about this idea.

[TakaHoribe]

Thank you for creating a discussion thread, Maxime.

In my mind, the main advantage of having a velocity array in the control command is that a vehicle controller has higher-level information, which allows for more complex control to be implemented.

But I feel the velocity array is slightly too much for two reasons.

Firstly, the velocity array is equivalent to the output of the planning module (target velocity on the reference trajectory). Adding a velocity array allows the "low-level controller in the vehicle" to do more complicated processing. For example, by implementing the velocity feedback controller for the target velocity array, the target acceleration can be calculated. However, this is almost the same as what the current control module is doing, and the role of the control/vehicle modules may conflict.

Secondly, the frequency of the vehicle speed is at most 10Hz in general, and the control command is sent at about 50~100Hz. In this case, the target speed and its 1st derivative (acceleration) information may be sufficient for accurate control.

@xmfcx Any comments are appreciated. Thanks!

[TakaHoribe]

@xmfcx Ahh, sorry, I misunderstood that having a velocity array means "replacing acceleration information with target velocity array".

The first values of these would be equal to your proposal:

Thank you. I'm very clear now. Then, 90% of my concern is solved.
The remaining 10% is, calculation of the a[] and theta[] is not so easy. MPC (or controller that predicts the future) can compute them easily, but simple controllers such as pure_pursuit or PID are not able to calculate the array of the control command. So what values should the array have in this case?
(My idea is, just putting the same value in the array is sufficient.)

Is this really true? Because I thought MPC would modify its input velocity array

The mpc_controller previously used in .auto modifies the target velocity. While the trajectory_follower recently ported into .auto from T4's proposal does not modify the target velocity. This is actually related to the roles of planning and control.

I think, the target speed should not be modified in the control module. Because in the planning module, decisions are made based on the assumption that the vehicle will move according to the planned speed. Also, certain safety assessments are made for target trajectory.
If the control system is allowed to change the target speed, the consistency of the planning decisions will be broken and proper vehicle behavior will not be achieved. The controller should focus on following the target speed.
(This could be a long discussion, so let's discuss it separately if necessary.)

We would actually be passing an acceleration array too so it's just extra information, it may or may not use it. But maybe someone could make use of these for finer control.

I'm convinced. Thank you.

What are sources and targets of these messages you are talking about?

I'm talking about the control command sent from the control module (say, MPC) to the vehicle interface.

[TakaHoribe]

One more thing. What happens if the Autoware control module supports delay compensation? In this case, v[0] or a[0] does not simply mean a target velocity / acceleration at the current time (It may be a target velocity after delay time).

[xmfcx]

@TakaHoribe Thanks for your insights and inquiries!

simple controllers such as pure_pursuit or PID are not able to calculate the array of the control command. So what values should the array have in this case?
(My idea is, just putting the same value in the array is sufficient.)

I'd suggest we make the array size flexible and if

• t = 0 and dt = 0 (ms)
  • array sizes = 1
• t = 1000 and dt = 100 (ms)
  • array sizes = 10

I think, the target speed should not be modified in the control module. Because in the planning module, decisions are made based on the assumption that the vehicle will move according to the planned speed. Also, certain safety assessments are made for target trajectory.
If the control system is allowed to change the target speed, the consistency of the planning decisions will be broken and proper vehicle behavior will not be achieved. The controller should focus on following the target speed.

I agree on this 100%

One more thing. What happens if the Autoware control module supports delay compensation? In this case, v[0] or a[0] does not simply mean a target velocity / acceleration at the current time (It may be a target velocity after delay time).

So delay handling means that

• the vehicle will act with a delay due to actuators,
• transmission delay(would be very small) is also included
• this delay is assumed constant

is this correct?

For this, I would say that it is even more valuable to have the array structure. Because the vehicle wouldn't use v[0] or a[0] and it would use v[x] or a[x] where x=duration_delay / dt

But I might be understanding it wrong and it might be that v[0] or a[0] is already the values with delay compensation calculated so we should add a new value with each message that conveys the duration_delay value to the low level controller for it to make sense.

Another option would be that the actuation delay is constant and known by the vehicle and we just set this parameter once and vehicle interface would assume index 0 means the delay compensation is already included.

But I'd need to know how what end signals the vehicle interface is sending to what.

What does vehicle_interface output?

• Reference voltage levels
• Reference torque values
• Reference pedal levels for throttle/brakes
• Reference angles
• Reference accelerations
• Reference velocities

Because this really affects the role of the vehicle_interface and Autoware's responsibility in general.

[TakaHoribe]

@xmfcx

I'd suggest we make the array size flexible and if
t = 0 and dt = 0 (ms)
array sizes = 1
t = 1000 and dt = 100 (ms)
array sizes = 10

That makes sense. Thank you.

So delay handling means that
the vehicle will act with a delay due to actuators,
transmission delay(would be very small) is also included
this delay is assumed constant
is this correct?

Yes, it is correct.

v[0] or a[0] is already the values with delay compensation...

For example, the velocity controller used in .auto uses PID control + delay compensation. This module calculates the reference acceleration a with the delay compensation from the reference trajectory. Here, it cannot simply publish the value calculated here as a[delay_duration] to the later stage, because a[0]~a[delay_duration-1] is not computed.
So, option 2 you mentioned "index 0 means the delay compensation is already included" is better i think. One concern is "how to know the velocity already includes the delay compensation". But vehicle may not need to know that.

But I'd need to know how what end signals the vehicle interface is sending to what.
What does vehicle_interface output?

What do you mean about the end signals?
In my mind, the output of the vehicle_interface is vehicle-specific such as you listed above (voltage, torque, pedal position, steering angle, steering-wheel angle, steering rate, etc). We should have an abstraction module to support these multiple interfaces, which is the "adapter" module discussed in the separate page.

[maxime-clem]

Is the following message definition suitable ?

# autoware_auto_control_msgs/LongitudinalCommand
builtin_interfaces::msg::Time stamp
builtin_interfaces::msg::Duration duration   # new field
builtin_interfaces::msg::Duration time_step  # new field
# fields changed from float to float[]
float[] speeds 
float[] accelerations
float[] jerks

Do we also want to modify autoware_auto_control_msgs/LateralAckermannCommand to use an array of steering angles and angle rates ?

[boyali]

Once we have a controller and a reference trajectory, it is possible to simulate the system forward in time (forward simulation). In this case, you can get any control and state trajectory. A controller and system model forms a new closed-loop model of the controlled system. Since we have a known closed-loop model, the only input the system becomes the reference signals.

If one would like to take the uncertainty in the model into account, we can parametrize a model uncertainty function which gives us a family of the state and control trajectories into the feature.