hakoniwa-base対応

[mitsut]

.devcontainerの環境を残しつつ、hakoniwa-base環境へ提供できるような環境に変更する。

hakoniwa-baseフォルダ構成とスクリプト、テンプレートファイル

├── docker
│   ├── appendix.         --->(xxxlatest_version.txtのコピー先)
│   ├── docker_dev        --->(make_dockerfile.bashでDocker関連のファイルのコピーする先）
│   ├── docker_runtime    --->(make_dockerfile.bashでDocker関連のファイルのコピーする先）
│   ├── template
│   │   ├── make_dockerfile.bash　　　　
│   │   ├── dev
│   │   │   └── ecu-multiplay
│   │   │       ├── Dockerfile
│   │   │       ├── dev_latest_version.txt
│   │   |       ├── env.bash
│   │   │       ├── image_name.txt
│   │   │       └── workspace
│   │   │           ├── build.bash
│   │   │           └── install.bash
│   │   └── runtime
│   │       ├── ecu-multiplay
│   │       │   ├── Dockerfile
│   │       │   ├── runtime_latest_version.txt
│   │       |   ├── env.bash
│   │       │   ├── image_name.txt
│   │       │   └── workspace
│   │       │       └── run.bash
│   ├── attach.bash
│   ├── build.bash
│   ├── create-image.bash
│   ├── run.bash
└── workspace
    ├── dev
    └── runtime

[mitsut]

本コンテナーでやりたいことを考える

Dev

• 単体のコンテナでもできること
  • ATK2,A-COMSTACK,A-RTEGENのインストール
  • ビルドのツールチェーン
  • A-RTEGENのHelloAutosarWithComサンプルでの構成でECU1,ECU2をビルドできる環境を作る
  • 手動でシミュレーションを実行できる（core,conductorが必要）
• hakoniwa-baseでできること
  • Runtimeのrun.bashで使うパラメータの設定を決める

Runtime

• ECU1,2の実行バイナリ
• A-RTEGENのHelloAutosarWithComサンプルでの構成で箱庭環境を実行する

[mitsut]

Run.bashの仕様を考えてみる

Unityを使った例だと、シミュレーションの開始はUnity側の操作になるが、ecu-militiplayではターミナルからの操作になるので

• hako-masterの起動
• ECU1(hako-proxy)の起動
• ECU2(hako-proxy)の起動
  を行う
  runtimeではさらに、hako-cmdでstartも合わせて起動するようにする。（devではhako-cmdを手動起動する）
  各ECUのログはターミナルのログ出力を見てもらうようにする

[mitsut]

Dockerfileを考える

ここも環境変数でdevとruntimeに分けると1つのdockerfileで行けるのでは？

• runtime環境
  • ros:foxy を使用する
  • Linuxのruntimeで必要なモジュールを入れる
  • athrillのビルド済み
  • hakoniwa-core-copp　, hakoniwa-ros2pdu はビルド済みをDockerfileに組み込めれば良い？
  • rootless(hako user)
  • ECU1,ECU2のATK2バイナリはdev環境でビルド済みになっているはず（workspaceのプロジェクトにある）
• dev環境で追加するもの
  • Linuxのdevで必要なモジュールを入れる
  • ツールチェーン
  • cfg
  • ATK2, A-COMSTACK, A-RTEGEN（ビルドしたバイナリはruntimeでも使いたい）
  • hakoniwa-core-cpp-client
  • hakoniwa-ros2pdu

コンテナのフォルダ構成

/home
├── hako(ユーザ環境devとruntimeでworkspaceへのlnを変えても良いかも)
│   ├── schema
│   ├── a-comstack
│   ├── a-rtegen
│   │   └── sample
│   │       ├── general
│   │       │   ├── EcuM
│   │       │   └── HelloAutosar
│   │       └── sc1
│   │           └── HelloAutosarWithCom
│   │               └── hsbrh850f1k_gcc
│   │                   ├── ecu1
│   │                   └── ecu2
│   ├── atk2-sc1
│   └── workspace
│       ├── sampleもしくはHelloAutosarWithComをコピーする？
│       └── hakoniwa-ecu-multiplay
└── toppers（ツールチェーンなどでdevの時はソース、runtimeもしくは固定しても良い時はバイナリダウンロードが良さそう）
　　   ├── toppers-cfg
　　   ├── hakoniwa-core-cpp-client
　　   ├── hakoniwa-ros2pdu
　　   ├── athrill-device
    └── athrill-target-rh850f1x
        ├── athrill
        ├── build_linux
        ├── params
        └── src

[mitsut]

Workspaceを考える

基本としては、devはビルド環境、runtimeは実行時のファイルとログファイル

• dev環境

HelloWorldWithCom
├── HelloAutosarWithCom_ECU1.yaml
├── HelloAutosarWithCom_ECU2.yaml
├── hsbrh850f1k_gcc
│   ├── common.sh
│   ├── ecu1
│   │   └── build
│   └── ecu2
│       └── build
とする。`build/atk2-sc1`においてもいいし、athrillの実行に合わせてコピーできるようにする
- a-rtegen/sampleをworkspaceにマウントする
- デバッグやお勉強的意味合いで、ATK2, A-COMSTACK, A-RTEGENはlnしておくのは残しておく(devconatinarで実装)