えいあーるれいの技術日記

ROS2やM5 Stack、Ubuntuについて書いています

ROS2-HumbleのRaspbian-Bullseye (32bit/64bit)向けビルドを公開しました。

ROS2にHumbleが追加されて2ヶ月…

Raspbian + ROS2 に新たなラインナップ「Humble」を追加しました。こちらは、32bit・64bit両対応となっています。

github.com


Ubuntuがまだ重く、Raspbianでしか動かない専用バイナリが多く配布されていたbuster世代と比べると、Ubuntuも軽快に動くようになり、専用バイナリすら配布されていないBullseyeでROS2をあえて動かすメリットはあまりないです。

しかしながら、GUIが軽快に動くことを考えるとRaspbianも使えなくはない?と考えています。

例えば最近日本に上陸したRaspberry Pi Zero 2 W。このボードでしっかりとROS2が動きます。

前回の記事↓

ar-ray.hatenablog.com

レスポンスの早いRaspbian OSと高機能なC++ APIが揃ったROSライブラリを組み合わせれば、構成機能の選択肢が増えていいのかなーと思ったりしています。

ちなみに、micro-rosではRaspbianがサポートされているのにRaspbianではROS2をサポートしていません…


インストール方法

以下のコマンドは、次の環境を想定しています。

  • OS : Raspberry Pi Bullseye 64bit
  • 状態 : ほぼ初期状態 (wgetすら通らなかった気がします)
curl -O https://raw.githubusercontent.com/Ar-Ray-code/rpi-bullseye-ros2/main/install.bash
bash install humble aarch64 0.1.0 /opt/ros
# > パスワードを入力

※デフォルトのオプションでは、32bit版humbleをインストールするようになっているので注意です。

インストール後は、自分のワークスペースを作成してパッケージをビルドします。

joyパッケージやcv_bridgeなどはros2.reposに入っていない関係上、ビルドしていないため、その都度GitHubからダウンロードしてビルドする必要があります。


ビルド方法

残念ながら、私の力では最新のバージョンをインストールすることはできません。そもそも安定したバージョンを求めるならば、Ubuntuの方をインストールしてaptで入手したほうが効率も良いでしょう。

それでも、最新のROS2を入手したければ自力ビルドをします。

リポジトリにはbuild.bashなるものがありますが、何故かHumbleは自動で依存関係順にビルドしてくれなかったので使えません…

colconコマンドオプションの --continue-on-error (エラーになっても可能なパッケージのビルドは続行)や --packages-skip-build-finished (ビルド済みとみなせるパッケージのビルド確認をスキップ) --packages-skip-up-to (ビルド対象から除外)を活用して効率よくビルドしていきます。

ビルド順番や除外パッケージなどの詳細はBuild-memo.mdを参照してください。

除外対象パッケージ

以下は、ビルドが重すぎたり依存関係を解決できなかったがゆえに除外せざるを得なかったパッケージです。

いずれもRaspberry Piで動かすにはリソース不足になるパッケージであるため、ほとんど無視して大丈夫だと思います。

また、rqt系はインストールは通るものの、Qt関連のリンクエラーで動きません。

  • rviz_ogre_vendor
  • rviz_rendering
  • rviz_common
  • rviz_rendering_tests
  • rviz_visual_testing_framework
  • rviz2
  • rosbag2_transpor
  • rosbag2_transport
  • rosbag2_py
  • ros2bag
  • rqt_bag


32bit版の注意

特に理由がなければ32bit版をビルドする意味もないのですが、32bit版では atomic のリンクエラーが起こります。

該当パッケージの修正済みCMakeListsのURLを載せます。


サポート外のプラットフォームにインストールさせる作業は、そのパッケージの依存関係などを詳しく知るきっかけになったり、デバッグ力を向上すると思います。

ただし下手すると1週間・1ヶ月と余暇を潰す可能性があるので、趣味の場合は特に要注意ですね…

depthai-coreの環境構築とCMakeの書き方

安価で高画質・高機能なステレオカメラで人気のOAK-Dカメラをご存知でしょうか?

このカメラは、4Kカメラ・ステレオカメラ・AI演算アクセラレータ(Myriad Xイメージプロセスユニット)を搭載しており、物体認識・追跡が可能なサンプルプログラムが揃っています。


高機能なのは勿論のこと、特別な設定なしで深度を測定可能なカメラにしてはかなり安い3万円以下となっているのも魅力的で、値上がりしたRealSenseの代替になりうるポテンシャルを持っています。(レーザー照射という点で性質は異なりますが…)

日本では、スイッチサイエンスなどに在庫があり、結構手軽に購入できます。

www.switch-science.com


C++API叩きたい…!

OAK-Dカメラは、Pythonで使うのが最も楽でオススメです。

環境構築も簡単だし、使用例・記事もたくさん上がっています。

公式のサンプルであれば、depthai-pythonを見ると良さそうです。

github.com


しかし、私はC++で扱いたいなーと結構思ったりします。

というのも、ROSのラッパーにしたり、ロボット・組み込みを想定するのであれば、ROSであればComposableNodeにできるC++にするのが好ましいからです。

一応、GitHub - luxonis/depthai-rosというパッケージはありますが、いろいろな機能を取捨選択するならAPI直接叩きに勝るものはないのかなーと考えたり…


そこで、OAK-DのC++APIであるdepthai-coreを見たのですが、めっちゃ複雑でわかりにくすぎました…

github.com

Pythonプログラムは道を整備すればするほど簡単になりますが、C++はその逆が起こるのはなぜなのか…


テンプレート化

なんとしてもC++APIを叩いてやると決めたので、(できる限りシンプルな)プロジェクトのベースを作りました。(結果、半日かかりました)

github.com

流れとしては、bash setup_depthai_core.bashで依存関係を全て解消しつつ、depthai-coreのビルドを行い、

そのライブラリを使って個人のプログラムをコンパイルさせるという感じです。


depthai-coreで最も悩まれるであろうCMakeListsについて少し詳しく説明します。

(意外と指定項目は少なかったです。)

cmake_minimum_required(VERSION 3.5)
project("dai_core_template")

set(CMAKE_CXX_STANDARD 14)

if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang")
  add_compile_options(-Wall -Wextra -Wpedantic)
endif()

set(depthai_DIR depthai-core-lib)

find_package(OpenCV REQUIRED)
find_package(depthai CONFIG REQUIRED)

include_directories(${OpenCV_INCLUDE_DIRS})


# set compile target -------------------------------------------------------
set(TARGET stereo_hconcat)

add_executable(${TARGET} examples/${TARGET}.cpp)

target_include_directories(${TARGET} PUBLIC
  $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
)

target_link_libraries(
  ${TARGET}
  ${OpenCV_LIBS}
  depthai::opencv
)

【注意すべき点?】

  • CMAKE_CXX_STANDARDは14に設定しています。(最初は指定していなかったのですが、めっちゃ文法エラーが出てきたので、14に引き上げました。)

  • set(depthai_DIR depthai-core-lib)は、depthai-coreがインストールされている場所を示しています。ここでは、CMakeListsのあるディレクトリと同じ階層にdepthai-core-libを作成し、そこにdepthai-coreのビルドファイルをインストールしました。(自動インストールスクリプトに記述)

  • target_link_librariesdepthai::opencvを追記します。depthai::opencv自体にOpenCVが含まれているので、もしかしたらその上のOpenCVはいらないかもしれません。


ROS2を使用する場合は、ament_cmakeを使ってROS関連の設定を追記していくだけです。

実行

サンプルにstereo_hconcatを入れています。

ステレオ画像を横にくっつけて1枚の画像にするプログラムです。

pipelineを引数に渡すdai::Device device;はスマートポインタにして宣言しないといけないことが分からず、解決に時間がかかりました…

Raspberry Pi Zero 2 Wの動作確認(ROS-Humble)

2022年6月21日にswitch-scienceよりRaspberry Pi Zero 2 Wが発売されました。(以下、zero2と記載)

www.switch-science.com

zero2については、1ヶ月ほど前から入荷するかもという情報が出ており、KSYのキャンペーンでも優先購入のキャンペーンが記憶に新しいです。


そして、私はその Raspberry Pi Zero 2 W を手に入れました❗

かなり待ち遠しかったです。


研究・工作・動作検証といろいろな用途に使っていきます。



Raspberry Pi Zero 2 とは

Raspberry Pi Zero 2は、前世代のRaspberry Pi Zeroのレイアウトを引き継いだスペックアップ版です。これまでシングルコアだったCPUが他のRaspiシリーズと同じ4コアになっています。

海外では半年以上前に流通しているため、基本情報についてはそれらの記事を見たほうが詳しいと思います。


日本でもユーザグループが性能の検証を行っています。

www.raspi.jp


【スペック】

  • CPU:Cortex-A53の1GHz、4コア、64bit

  • RAM:512MB

  • Wi-Fi:802.11 b/g/n (2.4GHz Only)

  • Bluetoorh:4.2,BLE

  • VideoCore IV GPU


Raspi 3Bに近い性能と言われています。

Zero <<<< Zero 2 W <≒ 3B < 3B+ << 4B

↑こんな感じ


他の記事↓(大体は3B+と比較されている)

medium.com

www.cnx-software.com


Bullseye + libcamera

とりあえず、ROS2が入っているLite版のRaspbian-bullseyeが手元にあったのでそのまま使って起動しました。

久しぶりのminiHDMIとmicroB→A変換コネクタだったので、ちょっと探しました。zeroを持っていない人は買い忘れに注意です。


zeroはCUIも重かった記憶がありましたが、zero2は起動後のCUIのレスポンスがなかなか良かったです。

Tab補完もレスポンスが早く助かりました。


zero2は従来のRaspiと同様にVideoCore IVというGPUがあります。このGPUの機能をフルに活用することでカメラのデータから画像処理などの作業をCSIカメラ→GPU(RAM)→CPUの順にデータを転送し、圧倒的軽量を実現することができます。

カメラで撮影した画像・映像を編集できるカメラなんてものも作れそうです。

6. Camera Hardware — Picamera 1.13 Documentation


libcamera-app に含まれる libcamera-still (jpeg圧縮) や libcamera-vid (H.264圧縮) などのGPUエンコードが必要なアプリは直接サポートされないため、自前でビルドしています。

↓以下のGitHubリポジトリからアクセスして手順通りビルドします。

github.com


libcamera-vidでストリーミング。

実行したところ、CUI画面に撮影している映像が!

CUIレンダリングとはこれ如何に。(それGUIじゃん…)


ストリーミングはチョット重い…(zero2にとどまらず重い気もする)


ROS2の起動など

私は、RaspibanでROS2を動かすことができます。(HumbleとGalacticがサポート済)

github.com


…ということはやることは一つ!zero2でROS2は動くのか!?

実はzeroでも動かしたことがありますが、その時は、ロードに1分以上かかり、とても使えるような状態ではなかったです。


実行速度なんて測っても面白くはないですが、timeコマンドでros2cliの実行速度を見てみました。

Raspberry Pi 4 Model Bは2~3秒程度で環境やコマンド呼び出しに対応するので、zero2がどれだけ迫れるかに期待です。

確認項目はとりあえず2つ

  • source /opt/ros/galactic/setup.bashコマンド
  • ros2 topic listコマンド

ビルドについてはどうせ重い&フリーズすることが分かっているので行いません。


結果

time source /opt/ros/galactic/setup.bash

real    0m3.617s
user    0m2.681s
sys 0m0.985s

3.5秒くらい


time ros2 topic list

real    0m6.427s
user    0m5.289s
sys 0m0.619s

かなり遅く感じる。6.5秒


ros2-daemonが絡むコマンドは結構重い感じでした。

ちなみに、早いと褒めていたTab補完もROS2では激重です。エイリアスに登録or暗記orコピペ推奨です。

また、Pub-Subプロセスの実行中はRAMの総使用量が500MB中100MB程度になっていました。GUIで使ったらもっとカツカツになりそう…

以上のデータより、zeroと違ってROS2を使える水準にはなっていると思います。

(間違ってもケチって開発環境としてzero2だけを学生に渡してはいけません。不幸になるだけです。)


TurtleSimも動きました。しかしネットワークの状態なのか、zero2の限界なのかかなりカクカクでした…


まとめ

zero2は、3Bと遜色ないスペックを持ちながら小型化を実現したかなり強いデバイスです。

IoTや小型ロボット、GUIを搭載したコントローラ・パネルなどの様々な用途への活用が期待されます。

ただし、500MB RAMとWi-Fiが2.4GHz帯にしか対応していないところは注意が必要です。


早く半導体不足と円安の荒波が過ぎ去り、たくさん買える日が来てほしい❗


関連商品リンク

I-O DATA アイ・オー・データ Raspberry Pi Camera V2  UD-RPCAMERA


感想(0件)

Image-Processing-Node-EditorにPyPI用設定を追加しました。

Image-Processing-Node-EditorにDockerfileを追加しました - えいあーるれいの技術日記の続きです。(結構空いてしまいました…)


かずひとさんが画像処理を行う面白いプログラム「Image-Processing-Node-Editor」を公開されたようです。

Image-Processing-Node-Editorはdearpyguiをベースとしたエディタで、フィルタや物体検出などの各画像処理を入出力が可視化されたブロックとして扱うことができます。

画像処理ノードを線で繋いでいくのでもちろんコードを書く必要はありません。

作者は「処理の検証や比較検討での用途を想定」と説明していますが、カーネルエディタも作れば、画像処理の勉強になるのではないかと考えています。


このプログラムはGitHubで公開されており、すでに120以上のスターがついています(!?)。これからの開発に期待です。

github.com

PyPIパッケージ化?

このアプリを公開されたときに、「youtube-dl」のようにコマンドラインで一発で実行できれば便利なのでは…?と思い、PyPIパッケージ化の話を提案してみたのがきっかけでした。

考えられていなかったみたいなので、勝手にプルリクを出しました。

(1回目のプルリクは、フォルダの差分が大きすぎたので、閉じて再度プルリクを送ることにしました。)


rclpyのsetup.pyの記述やPyamlQtを弄っていたので、分かっていた部分は多かったものの、初めて知ったところも結構あったので、そこらへんについて解説できたらいいなと思います。

Linuxで対話型アプリを作りたいなら、PySide2とPyPIパッケージの作り方を知っておけばなんとかなる印象です。

どちらもググれば結構でてくるし、Linuxじゃなくても動くのでオススメです。


pipでのインストールについて

python3のライブラリをpipでインストールできることは誰もが知っている常識?だとは思いますが、設定を書くことでどのディレクトリからでも呼び出し可能なパッケージ化ができます。

必要なのは、setup.pyと各Pythonファイルが格納されているディクトリに対する__init__.pyのみ。

__init__.pyを各ディレクトリに配置するのが多少面倒ではありますが、__init__.pyの中身は空でも問題ないので、実質setup.pyが書ければそれでOKです。


以下にsetup.pyの書き方を示します。

(ほとんどがテンプレートそのまま引っ張って一部書き換えを繰り返しているだけなので、ところどころ省きます)

from setuptools import setup, find_packages
import re
import os
from os import path
from os.path import splitext
from os.path import basename
from glob import glob

package_keyword = "ipn_editor"

def get_version():
    with open( "__init__.py", "r") as f:
        version = re.search(
            r'^__version__\s*=\s*[\'"]([^\'"]*)[\'"]',
            f.read(), re.MULTILINE
        ).group(1)
    return version

def package_files(directory):
    paths = []
    for (path, directories, filenames) in os.walk(directory):
        for filename in filenames:
            paths.append(os.path.join('..', path, filename))
    return paths

extra_py_files = package_files("node") + package_files("node_editor")
extra_py_files = ','.join(extra_py_files)

readme_path = path.abspath(path.dirname(__file__))
with open(path.join(readme_path, 'README.md'), encoding='utf-8') as f:
    long_description = f.read()

setup(
    name = "ipn-editor",
    packages=find_packages(),
    py_modules=[splitext(basename(path))[0] for path in glob("./*")],
    package_data={  "node_editor": ["font/YasashisaAntiqueFont/*",
                                      "font/YasashisaAntiqueFont/IPAexfont00201/*",
                                      "setting/*",
                                      extra_py_files
    ]},
    include_package_data=True,

    version = get_version(),

    # 中略
    entry_points = {
        "console_scripts": [
            "ipn-editor=main:main",
        ],
    }
)


へぇーーとなったところをいくつか挙げます。


get_version 関数

実はYOLOXのリポジトリから拝借しています。(元がどこからかは分かっていません)

バージョン指定はsetup.pyに書くものですが、__init__.pyに変数として定義を記述することができるので、他のファイルとの同期が取りやすいメリットがあります。

正規表現ちゃんと使いこなせるようにならないとなーー。


# __version__ = "0.1.0"から"0.1.0"を取得
def get_version():
    with open( "__init__.py", "r") as f:
        version = re.search(
            r'^__version__\s*=\s*[\'"]([^\'"]*)[\'"]',
            f.read(), re.MULTILINE
        ).group(1)
    return version


package_data

package_dataとは、Python以外のファイルをモジュールとして読み込むことで、pip内で相対パス呼び出しを行っても問題なく呼び出せるようにするためのシステムです。

ただし、これが結構厄介。


Pythonのファイル追加は、__init__.pyを追加すれば、py_modules=[splitext(basename(path))[0] for path in glob("探索開始ディレクトリ")],再帰的に読み込まれます。

しかし、モジュールはフォルダよりも下の階層を再帰的に読み込んでくれません。

そのため、自作スクリプトを組んで再帰的にフォルダを追加するか、手動で入力しないといけません。

以下のスクリプトで追加していきました。

extra_py_files = package_files("node") + package_files("node_editor")
extra_py_files = ','.join(extra_py_files)
#(省略)
    package_data={  "node_editor": ["font/YasashisaAntiqueFont/*",
                                      "font/YasashisaAntiqueFont/IPAexfont00201/*",
                                      "setting/*",
                                      extra_py_files


entry_points

rclpyではおなじみentry_points

呼び出し名=ファイルの.py抜き:開始時に呼び出される関数の順に記述してきます。

これも、同じディレクトリ内に__init__.pyが必要だったはず

    entry_points = {
        "console_scripts": [
            "ipn-editor=main:main",
        ],


インストール方法

現在は、PyPIへの登録は行われていないため、URLを使う必要があります。

# 不足パッケージは追加でインストール
pip install numpy
pip install Cython
pip install -e git+https://github.com/samson-wang/cython_bbox.git#egg=cython-bbox


その他

  • 「Image-Processing-Node-Editor」という名前が自分には長すぎたため、「IPN-Editor」という名付けをしました。半ば強制させたような感じになっていますが、他のアプリ起動でも似たような感じになっているので、OK(?)

  • pipでインストール時はipn-editorという名前ですが、インポート時は、nodenode_editorという名前になってしまっているそうです。

    • py_modulesにプロジェクトのホームディレクトリを選択したからこその現象です。
  • 私が、事前にPyPIテストのためにテストリポジトリを作っていたところ、作成者本人がアップできないという事態になりました。自分のパッケージでなければ、testPyPIでも作らないが吉ですね。

  • PyPIパッケージとしてアップする場合はこのURLの記事を見ながらいつもアップしています。


Windows用の実行ファイルも整備されているようで、かなりサポートが手厚くなっているようです。

個人的には、画像をつなげて遊ぶ的な使い方で教育用途でも使えそうだと感じたので、サーバー経由でサービス化しないかなぁなんて思ったりもしました。

Image-Processing-Node-EditorにDockerfileを追加しました

かずひとさんが画像処理を行う面白いプログラム「Image-Processing-Node-Editor」を公開されたようです。

Image-Processing-Node-Editorはdearpyguiをベースとしたエディタで、フィルタや物体検出などの各画像処理を入出力が可視化されたブロックとして扱うことができます。

画像処理ノードを線で繋いでいくのでもちろんコードを書く必要はありません。

作者は「処理の検証や比較検討での用途を想定」と説明していますが、カーネルエディタも作れば、画像処理の勉強になるのではないかと考えています。


このプログラムはGitHubで公開されており、すでに70以上のスターがついています。これからの開発に期待です。

github.com


私は、このプログラムにDockerfileとPyPI化のためのファイル追加を行いました。

ここでは、Dockerfileの使い方と簡単な説明を行います。


Docker・Dockerfileとは

DockerとはLinuxのコンテナ技術を活用した仮想環境構築ツールです。DockerfileとはDocker上で動く仮想コンテナを構築するための定義ファイルです。

VirtualBoxなどの仮想マシンと異なり、DockerはOSとコンピュータリソースが共通化されているため、素早い環境構築や起動・終了、リソースの流用が簡単に行えます。

他の仮想環境と同様にLinuxのバージョンや環境の影響を受けない・与えないので、アプリケーションを起動するためのコマンドがDockerを内部で呼び出して実行することもあります。


私のノートPCはUbuntu22ですが、残念ながらonnxruntimeなどのいくつかのパッケージがまだ対応していません。そこで、Dockerfileを作成して、Ubuntu20を仮想的に再現することで動かすことにしました。


実行方法

とても簡単です。

事前準備

  • 事前に管理者権限で動くDocker(NVIDIAの場合は、nvidia-docker2が必須です)
  • X11-forwardingの /etc/ssh/sshd_config が "XForwarding yes"になっているかの確認
    • Windowsの場合は、別のアプリケーションを使用するため、設定が異なります。
  • USB接続が可能なWebカメラ
    • /dev/video0 に接続されているものとします

以下は、Ubuntu環境におけるコマンド

# ビルド
git clone https://github.com/Kazuhito00/Image-Processing-Node-Editor.git
cd Image-Processing-Node-Editor/
docker build docker/nvidia-gpu -t ipn_editor

# 実行
xhost +
docker run --rm -it --privileged --device /dev/video0:/dev/video0:mwr -e DISPLAY=$DISPLAY -v $(pwd):/workspace --gpus all -v /tmp/.X11-unix:/tmp/.X11-unix ipn_editor


Dockerfile

DockerfileはGitHub(Image-Processing-Node-Editor)にあります。

nvidiaとありますが、NVIDIA-GPUがなくても動作します。

GitHubにあるDockerfileを以下に示します。

FROM python:3.8.13

# Add timezone ----------------------------------------------------
ENV TZ=Asia/Tokyo
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
ENV DEBIAN_FRONTEND=noninteractive

# NVIDIA -------------------------------------------------------------
ENV NVIDIA_VISIBLE_DEVICES ${NVIDIA_VISIBLE_DEVICES:-all}
ENV NVIDIA_DRIVER_CAPABILITIES ${NVIDIA_DRIVER_CAPABILITIES:+$NVIDIA_DRIVER_CAPABILITIES,}graphics

# xserver ------------------------------------------------------------
RUN apt update && apt -y upgrade && \
apt install -y xserver-xorg && \
apt -y clean && \
rm -rf /var/lib/apt/lists/*

# PyPI environment ---------------------------------------------------
RUN pip install --upgrade pip

# For error avoidance
RUN pip install --upgrade cython numpy

RUN pip install \
opencv-python==4.5.5.64 \
onnxruntime-gpu==1.11.1 \
dearpygui==1.6.2 \
mediapipe==0.8.10 \
protobuf==3.20.0 \
filterpy==1.4.5 \
lap==0.4.0 \
cython-bbox==0.1.3 \
rich==12.4.4

WORKDIR /workspace
CMD ["python3", "main.py"]

流れとしては、Python3.8 (Ubuntu20)上に次の流れで環境を構築していきます。

  • タイムゾーンの設定(xserverでの処理待ち防止)
  • NVIDIA-GPUの場合のGUI環境設定
    • NVIDIA-GPUでなくても取り除く必要はないです
  • xserver (GUIX11-Forwardingするのに必須)
  • Python-pipの環境構築
    • Cythonとnumpyのみ、先行でインストールする必要があります。
  • CMDの設定により、Docker実行直後のアプリ起動設定(アプリの終了後にシャットダウン)


xserverまでの流れはほとんど共通化できそうです。


実行

実行の際は、結構長いコマンドになります。それぞれ解説します。


コマンド:docker run --rm -it --privileged --device /dev/video0:/dev/video0:mwr -e DISPLAY=$DISPLAY -v $(pwd):/workspace --gpus all -v /tmp/.X11-unix:/tmp/.X11-unix ipn_editor


Dockerはdocker run [オプション] 実行コンテナ名 [初期実行ファイル]で実行されます

オプション

  • --rm:終了後にコンテナを削除して実行前に戻す。
  • -it:標準入力のための最小限の設定(iとtはそれぞれ意味がある)
  • --privileged: すべてのデバイスへのアクセス権限を付与
    • 後述する--deviceをすべてカバーしているので、どちらかはいらない。(セキュリティ的にはよくない)
  • --device /dev/video0:/dev/video0:mwr:--privilegedがない場合に/dev/video0を入力デバイスとして設定
  • -e DISPLAY=$DISPLAY:x11-forwarding設定・xサーバの指定
  • -v $(pwd):/workspace:ファイルのマウント先。この場合は、現在のディレクトリをDockerコンテナ内の/workspaceにマウント
  • --gpus all: NVIDIA固有の設定。GPUをすべて認識させる。
  • -v /tmp/.X11-unix:/tmp/.X11-unixx11-forwarding設定


初期実行ファイル

なにも指定されていない場合は、Dockerfileで定義されたpython3 main.py/workspaceで実行されます。

開発する時は、アプリが勝手に起動すると困る場合があります。この場合は、別のアプリで上書きすることができます。

/bin/bashを指定することで、ターミナルが入力ができるようになります。


PyPI編はまた次で。