Launch and config files

[angry-crab]

I think the way we organize and maintain autoware repos makes customization a little bit troublesome. For example, if I want to use my own vehicle and sample configuration, I have to create/modify many repos such as sample_sensor_kit_launch, sample_vehicle_launch and etc. And perhaps I have to push my changes and change the branch of .repo file accordingly. This is quite complicated and difficult to keep track with. In my opinion, we should keep all those launch and config files under autoware_launch so that I customize my vehicle settings with changes only in one repo. The launch files under the original package folder could be kept for other usage. Please feel free to make any comment on this.

[kenji-miyake]

@angry-crab I can understand what you say, but it's a bit difficult problem.
We should take a balance of usability, maintainability, scalability, security, and so on.

For example, difficult cases are:

• The user has multiple vehicles, and one of them is super secret.
  • In this case, they can't manage the secret vehicle configuration in the same repository because they have to apply different access control settings.
• The user supports 100 vehicles and 200 sensor kits.
  • In this case, I guess it would be too cumbersome.
  • But considering the concept of Autoware, we have to support this scaled case.

In order to support such difficult cases, I think it's better to keep the current structure and accept some increase in maintenance costs.

But if you can list up such use cases and show some concrete ideas that can resolve the problems, then I think we can change the structure!

[esteve]

@kenji-miyake

The user has multiple vehicles, and one of them is super secret.
In this case, they can't manage the secret vehicle configuration in the same repository because they have to apply different access control settings.

Perhaps I'm not seeing the problem here, but the user can always create their own repository to store the secret vehicles. As far as I understand, this discussion is about how we structure files in our repositories, which I agree with @angry-crab is a difficult to maintain. Unfortunately, I can't see any benefits by keeping so much information separate, could you explain the rationale for having so many separate repositories?

The user supports 100 vehicles and 200 sensor kits.
In this case, I guess it would be too cumbersome.
But considering the concept of Autoware, we have to support this scaled case.

I'm sorry, but I don't follow, could you elaborate a bit more? Thanks

[kenji-miyake]

I'm sorry for my poor explanation. 🙏 It's difficult for me to explain complex things in English well. 😢

could you explain the rationale for having so many separate repositories?

At least, it can reduce unnecessary dependencies.

graph TD
    subgraph product_meta_repository
        autoware_repos
    end

    subgraph autoware_launch_repository
        autoware_launch_package
        vehicle_1_package
        vehicle_2_package
        vehicle_3_package
        sensor_kit_c_package
        sensor_kit_b_package
    end

    subgraph secret_vehicle_repository
        secret_vehicle_package
    end

    subgraph secret_sensor_kit_repository
        secret_sensor_kit_package
    end

    autoware_repos --> autoware_launch_package
    autoware_repos --> secret_vehicle_package
    autoware_repos --> secret_sensor_kit_package

Loading

The above one has unnecessary depends, while the below one has minimal depends.
I'm not saying that the below is better, it's just a trade-off.

graph TD
    subgraph autoware_launch_repository
        autoware_launch_package
    end

    subgraph secret_vehicle_repository
        secret_vehicle_package
    end

    subgraph secret_sensor_kit_repository
        secret_sensor_kit_package
    end

    autoware_repos --> autoware_launch_package
    autoware_repos --> secret_vehicle_package
    autoware_repos --> secret_sensor_kit_package

Loading

And there is another example.
If we manage vehicle/sensor in the autoware_launch repository, there will be multiple autoware_launch packages. Then, we can't use user's vehicle/sensor packages because the autoware_launch package conflicts.

graph TD
    subgraph product_meta_repository
        autoware_repos
    end

    subgraph awf_autoware_launch_repository
        autoware_launch_package
        awf_vehicle_package
        awf_sensor_kit_package
    end

    subgraph user_autoware_launch_repository
        autoware_launch_package_duplicated
        user_vehicle_package
        user_sensor_kit_package
    end

    autoware_launch_package -->|duplicated| autoware_launch_package_duplicated

    autoware_repos --> autoware_launch_package
    autoware_repos --> user_vehicle_package
    autoware_repos --> user_sensor_kit_package

Loading

which I agree with @angry-crab is a difficult to maintain.

Actually, the maintenance cost isn't probably as high as you think because the update period of vehicle/sensor files isn't very high. In TIER IV, we can easily maintain about 10 vehicles and sensor kits with this structure.

I'm sorry, but I don't follow, could you elaborate a bit more? Thanks

Mm, what I wanted to say is "too many files in a repository can decrease visibility".
But perhaps this wasn't a good example. So you can ignore it. Sorry for the confusion.

[kenji-miyake]

Supplementary information:
The above package-conflicting problem happens only with the source dependency system.
If we use another system like ROS's APT binary releases, we can be more flexible about repository configuration and package dependency.

However, a challenge for that is that all packages should be public if we use ROS buildfarm. It's because Autoware must allow member companies to do their business with their customized proprietary software.
I guess Snap might be a good solution to that. (But there is no concrete plan yet.)
https://snapcraft.io/docs/ros2-applications