How to determine the vehicle specific parameters

[brkay54]

Related discussion and issues:

• Consider using global_parameter_loader autoware.universe#143
• Load parameters that should be managed centrally as global parameters. autoware.universe#910
• Parameter management autoware_launch#66
• https://github.com/orgs/autowarefoundation/discussions/2663

Hello everyone,

In current autoware universe implementation, every module includes parameters from their own parameter files. Some of the parameters are vehicle specific parameters which would be used by another modules so it causes so many duplicated parameters. For example, both planning and control modules take the minimum-maximum jerk and acceleration parameters from their own parameter files. We want to load this kind of common parameters from one source to prevent confusion. How we should load parameters to modules from one file?

Issue about how to load the common parameters: autowarefoundation/autoware.universe#143

Also there are some module specific parameters (especially in behavior_path_planner and behavior_velocity_planner) like maximum_deceleration while lane changing. Should we assume these parameters as vehicle specific parameters? What should be borders of vehicle specific parameters?

In current universe, parameters are so complicated, I think we need to discuss a new parameter design. So please feel free to share your opinion.

[yukkysaito]

In current autoware universe implementation, every module includes parameters from their own parameter files. Some of the parameters are vehicle specific parameters which would be used by another modules so it causes so many duplicated parameters. For example, both planning and control modules take the minimum-maximum jerk and acceleration parameters from their own parameter files. We want to load this kind of common parameters from one source to prevent confusion. How we should load parameters to modules from one file?

I agree with you.
When closing to components such as planning or control, it is better to create a config in the each launcher. But some scene modules may want to define each of them. For example, when a red light comes on just before stopline in intersection, the decision to pass should be defined as the maximum_deceleration by ride quality. This cannot be common for other scene module in planning.
https://github.com/autowarefoundation/autoware.universe/tree/main/launch/tier4_planning_launch/config
https://github.com/autowarefoundation/autoware.universe/tree/main/launch/tier4_control_launch/config

If we want to make parameters between different components, it is better to create a config in autoware_launch
https://github.com/autowarefoundation/autoware_launch/tree/main/autoware_launch

Also there are some module specific parameters (especially in behavior_path_planner and behavior_velocity_planner) like maximum_deceleration while lane changing. Should we assume these parameters as vehicle specific parameters? What should be borders of vehicle specific parameters?
In current universe, parameters are so complicated, I think we need to discuss a new parameter design. So please feel free to share your opinion.

Currently, vehicle specific parameters is defined foo_vehicle_description pkg. this package is defined the size of the vehicle, the maximum acceleration that the vehicle can, etc.
But, it is dangerous to accelerate to the limit of what the vehicle can do. Also some parameters such as maximum acceleration is difference by each products (cargo, bus, taxi and etc.).
It is better not to include such non vehicle-specific information in vehicle_description.

Therefore, there will be double parameter like maximum_deceleration because it is defined by vehicle specific and product specific.

[mehmetdogru]

I believe all the vehicle related parameters should be handled from one place. The reason behind it is that if one wants to implement autoware to a custom vehicle then in so many config files so many parameters needs to be changed and it is confusing. When it is said vehicle specific params it includes maximum_deceleration as well.

So technically all the parameters which it would be needed to be altered in case of an autoware implementation of a different vehicle from the vehicle that subjects to previous odd should be gathered in one place with namespaces if necessary not to get confused with duplicated parameters. Then if you are implementing autoware to any vehicle you would just need to look at one place for vehicle specific configuration without any confusion and without any overlooked parameters.

[doganulus]

Here are some of my observations from Autoware and other fields like web design where you have to manage a large number of parameters in the wild.

• Local (package-wise) solution is relatively easy and flexible. This is good for experimentation. Probably I don't want to add new parameters to a common autoware repo when testing my new planning algorithm. Local parameters should remain in any way.
• True that a central place to manage some common parameters across packages is needed as the original poster explains and I think this is the reason for global_parameter_loader. There might be other levels like vehicle, control, and planning below the global level.
• Besides there would be a need to override the global parameter locally. I think the package should be the final decider about a parameter value (debatable but other control mechanisms are already in place to check the package quality --like Core vs Universe).
• Finally at launch, all parameter values from all packages must constitute a single mapping that can be printed as a JSON/YAML, etc. It is useful to think that all parameters are just a single JSON file. But the keys of this JSON file can be set at different levels (global, package collection, package).

From my experience, the most satisfying solution to handle such large and fluid parameter spaces is to employ a cascadable and hierarchical map data structure. JSON and YAML do the job of the hierarchical map part, but they don't specify a cascade/override mechanism normally (except for some web standards such as JSON Patch and Merge). Some other formats having those features natively are not widely used.

Cascaded stylesheets (CSS) can also be a source of inspiration in this discussion. You know the browser merges all stylesheets (parameter files) from different levels (system, user, website) and launches the rendering process. I think we need similar functionality.

[brkay54]

Hello everyone, I discussed with my colleagues and we want to propose an approach for this topic.

In our opinion, firstly we should divide parameters into two; vehicle_specific parameters (or vehicle_dynamic) and module_specific parameters.

• vehicle_specific parameters contain parameters that define vehicles operational ranges and limitations such as max_steering_angle_dps, maximum_acceleration, maximum_jerk etc. These parameters will be loaded by global_parameter_loader and nodes can be use these limitations easily without declare them.
• module_specific parameters contains the parameters that are not included by vehicle_specific parameters.

@yukkysaito

I agree with you. When closing to components such as planning or control, it is better to create a config in the each launcher. But some scene modules may want to define each of them. For example, when a red light comes on just before stopline in intersection, the decision to pass should be defined as the maximum_deceleration by ride quality. This cannot be common for other scene module in planning. https://github.com/autowarefoundation/autoware.universe/tree/main/launch/tier4_planning_launch/config https://github.com/autowarefoundation/autoware.universe/tree/main/launch/tier4_control_launch/config

With this approach, we can also define the module_specific parameters inside the package. Node still can use this type of parameters.

Currently, vehicle specific parameters is defined foo_vehicle_description pkg. this package is defined the size of the vehicle, the maximum acceleration that the vehicle can, etc. But, it is dangerous to accelerate to the limit of what the vehicle can do. Also some parameters such as maximum acceleration is difference by each products (cargo, bus, taxi and etc.). It is better not to include such non vehicle-specific information in vehicle_description.

And, we can define this vehicle_specific parameters easily for each product because all product may be run in different operational range.

[doganulus]

If we look at it closely, there is nothing special about the vehicle parameters. We could have wanted to separate planning-specific or control-specific parameters if some modules share some parameters (I think they already do). However, soon it would be a burden to do X-specific parameters; for example, why don't we have planning-freespace-specific parameters when Autoware's freespace capabilities expanded?

So this is an architectural problem. Needs a generic solution. Otherwise, it will pop out repeatedly.

The parameter system also affects other parts -- containerization, simulator integration, etc. It would be much easier if we could launch each node with a single YAML file across the system. In the current state, too much logic is embedded/hard-coded into launch files (a problem inherited from ROS); they should be dumber.

Relevant issue: autowarefoundation/autoware_launch#66

[brkay54]

If we look at it closely, there is nothing special about the vehicle parameters. We could have wanted to separate planning-specific or control-specific parameters if some modules share some parameters (I think they already do). However, soon it would be a burden to do X-specific parameters; for example, why don't we have planning-freespace-specific parameters when Autoware's freespace capabilities expanded?

Yes, they already do. Module specific parameters are same as current implementation. Each package is going to still has own parameter files. We will just put together the parameters that define vehicles operational ranges and limitations in vehicle_specific (or vehicle_dynamic) parameters.

User should define easily operational limitations. For example, changing the vehicle (Bus to taxi for example), taxi's operational ranges are different from Bus (e.g. maximum longitudinal and lateral accelerations and jerks would be higher). With this structure, user can define the operational ranges easily just like the parameter file in sample_vehicle_description. To change vehicle, user just need to update vehicle_description and vehicle_specific (or vehicle_dynamic, naming can be discussed) parameters.

As Yukihiro-san said, If user want to change parameter to increase ride quality (for example maximum_deceleration for red lights), user can still the change this parameter from packages config file.