この記事のポイント
- Hardware DevOpsとManufacturing as Codeを実践しているYo
- ソフトウェアの開発手法を使って3Dプリントを制御しているYo
はじめに
今回はGitHubを中心としてハードウェア開発、主に3Dプリントの開発・製造プロセスについて検討し、実際に試してみました。
きっかけ
まずは動機の話をしたいと思います。結論から言ってしまえば、なにかを3Dプリントしようと思ったときに3Dモデリングの経験がないため、やりたいことを実現するのが難しいなと感じました。難しいと感じるなら得意分野に引き寄せられないかなということでやってみようと思ったのがきっかけです。
また、3Dプリントしては調整してを繰り返していたらイテレーションを回すのが大変だということもあります。要するに失敗回数（印刷回数）をできるだけ減らしつつ、どんな数値を管理できれば、より正確なものが作れるのかそれがIaC的に管理できれば良いなとも考えました。
ちなみに過去に作ったCopilotは公式のリポジトリにあった3Dデータからの印刷なので自分では作っていません。
いろいろChatGPTに相談したところどうやら、この考えはHardware DevOpsやManufacturing as Codeという概念に近いそうです。
Hardware DevOps
ところでHardware DevOpsとは何だ？ってところですが、Hardware DevOpsとはソフトウェア開発で利用されているDevOpsの考え方をハードウェア開発へ適用し、設計から製造、検証までのフィードバックループを高速化する考え方です。
端的に説明するとソフトウェア開発の手法をハードウェア開発に適用して高速で反復開発できるようにしましょうという話です。
例えば3Dプリントであれば、3DモデルをGitHubで管理するだけでなく、設計変更をPull Requestでレビューし、GitHub Actionsでモデルを検証してSTLやG-codeなどの成果物を自動生成するといった開発プロセスが考えられます。
ソフトウェアと大きく異なるのは、最終的な成果物が現実世界に存在することです。そのためHardware DevOpsではコードが正しく動くかだけでなく、寸法、材料、製造方法、製造装置なども考慮する必要があります。
Manufacturing as Codeとは
Hardware DevOpsではコードが正しく動くかだけでなく、寸法、材料、製造方法、製造装置なども考慮する必要があると説明しました。
そこでManufacturing as Codeは製造に必要な設計や条件、検証、成果物の生成方法を可能な限りコードや設定ファイルとして表現し、バージョン管理と自動化の対象にするアプローチです。
3Dプリントの場合、STLファイルをGitで管理するだけでは同じ製品を再現できるとは限りません。同じ3Dモデルであっても使用するスライサーやそのバージョン、プリンター、ノズル径、積層ピッチ、材料、インフィルなどの条件によって最終的な造形物は変化します。
要するにインプット/アウトプットだけでなく、その間にある処理系も管理して造形されるものをソフトウェアの考えで制御してしまおうということです。
検証に入るまえに本記事の肝
今回は「3Dプリントしました。はい終わり」という単純な話ではなく、物理的なものづくりをより正確に行うための手法を実践することを目的としています。
たとえば、3Dプリントで組み立て部品を作ったとしましょう。片方に直径3mmの穴があり、もう片方に直径4mmの突起があるとします。
このように設計上の寸法関係が成立していなければ、そもそも組み立てることができません。しかし、そういった不具合に気づくのは生成された後だと思います。
今回の検証ではこういった不具合を防止するためにソフトウェアの開発手法を取り入れて、生成されるものの寸法を事前に把握し、不具合に気づく仕組みが構築できないかを検証します。
もちろん、寸法どおりだとしても生成してみたらうまくハマらなかったというのはありますので絶対ではありませんが、直径3mmの穴に直径4mmの突起を差し込むなどの「明らかに無理でしょ」っていうことを検知できる仕組みを構築できれば、ゴールです。
作業の前提
ということで実際に試してみましょう。
今回のHardware DevOpsとManufacturing as Codeに活用したサービスとソフトウェアは次のとおりです。
| 種別 | サービス / ソフトウェア | 今回の役割 |
|---|---|---|
| サービス | GitHub | 設計データ、コード、履歴、開発プロセスを集約するハブ |
| サービス | GitHub Actions | 3Dモデルの検証・生成を自動化するCI |
| AI | GitHub Copilot | OpenSCADやCI/CD、製造パイプラインの実装支援 |
| CAD | OpenSCAD | コードから3Dモデルを設計し、STLを生成 |
| Slicer | PrusaSlicer | STL→G-codeの自動化を検証。最終的には採用見送り |
| Slicer | Bambu Studio | Linux上で仮想ディスプレイを利用し、CLIからSTLをスライスして製造成果物を生成 |
| Container | Docker | 製造ツールチェーンの実行環境を再現・固定 |
| Script | Python | Design ValidationやManufacturing Reportなどの処理 |
| Format | STL | 3Dモデルの形状データ |
| Format | G-code | 3Dプリンター向けの製造命令 |
| Format | 3MF | モデルと製造条件などを扱える3D製造フォーマット |
手元ではApple Silicon搭載のmacOSを利用しています。ただし、成果物の生成と検証はGitHub Actionsのubuntu-latestでも実行するため、ローカル環境だけに依存しない構成としています。
検証に使ったリポジトリは以下のとおりです。
前提条件は以上です。なお、もろもろうまく動作すると以下のようなモデルのpngとモデルデータ一式が生成されます。※モデルはGitHub Copilotに作ってもらいました
PNGの場合
STLの場合
また、Actionsでは以下のようにArtifactsが生成されます。
いざ、検証（事前準備）
まずはリポジトリをクローンします。
git clone https://github.com/ymd65536/HardwareDevOps.git
gh repo clone ymd65536/HardwareDevOps
ディレクトリを変更してVisual Studio Codeを開きます。
cd HardwareDevOps
※codeコマンドを使って起動します。（設定していない人はVisual Studio Codeのフォルダを開くから挑戦してね。）
code .
PNGを生成する
最初に生成されるモデルの2次元画像を生成してみましょう。
PNGプレビューのレンダリング
openscad -o artifacts/copilot-stand.png --imgsize=1600,1200 src/copilot-stand.scad
png形式となっているので画像ソフトまたはmacOSのFinderを使うことで開けます。
STLを生成する
では、今度は3Dデータを生成してみましょう。なお、STLとは、3DプリンターやCADで広く使われるポリゴンデータの標準ファイル形式のことです。
STLのレンダリング
openscad -o artifacts/copilot-stand.stl src/copilot-stand.scad
生成したSTLはvscode-stl-viewerで確認するかmacOSのFinderで確認できます。
モデルをpytestで検証する
3Dモデルの生成ができたところで今回の肝となる部分を試していきましょう。
今回はManufacturing Reportに記録された期待値と、生成されたSTLの寸法をpytestでチェックします。
なお、このテストで確認しているのは設計データ上の寸法です。実際の造形物が同じ寸法になることを保証するものではなく、造形誤差や材料収縮などは実物で確認する必要があります。
pytest -q tests/test_manufacturing_report.py
実行結果
6 passed in 1.10s
パスすれば、想定どおりの設計になっています。ではここで少しだけ3Dデータの数値をいじってテストを失敗させてみましょう。copilot-stand.scadというファイルがsrcというディレクトリにあるはずです。これを次のように修正してみましょう。
# 現在のコード
stand_width = 90;
# 書き換え
stand_width = 91;
もう一度pytestを実行します。
pytest -q tests/test_manufacturing_report.py
実行結果
FAILED tests/test_manufacturing_report.py::ManufacturingReportTests::test_stl_bounding_box_matches_expected_dimensions - AssertionError: 91.0 != 90.0 within 0.5 delta (1.0 difference)
1 failed, 5 passed in 1.03s
これで3Dデータが想定とは異なるものになっていることが検知できました。
GitHub Actionsで3Dモデルを生成する
ここまででモデルを生成→モデルを検証という流れをローカルで実践しました。しかし、ローカルにモデルを生成してしまうと成果物を共有することが難しくなってしまいます。
そこで今回はGitHub Artifactsという機能を使って成果物を保存できるようにしています。ArtifactsはGitHub Actionsの結果から参照できます。
ダウンロードして中身を見てみるとローカルで生成したデータと同じデータが入っていることが確認できます。
GitHub Actionsで3Dデータを生成する際の注意点
基本的にOSはubuntu-latestでやるのが良いです。macOSでもやれるので試したんですが、Homebrewが中心となるところがネックになりました。
というのも今回の検証で初めて気づいたところですが、Homebrew経由で導入したGUIアプリや未署名・未公証のソフトウェアでは、Gatekeeperの影響を受ける場合があります。
※実際にPrusaSlicerをbrewで使おうとした際にいくつかの警告に遭遇しました。
なお、後述しますが今回はPrusaSlicerの採用を見送っています。
今回の検証によって実現できること
検証は以上です。おさらいとして今回の検証によって実現できることを見ていきましょう。端的にいえば、手戻りの回数を減らし、より思い切ってさまざまなものづくりに挑戦できることだと思います。
3Dモデルを作成してSTLとして保存すれば、同じものを再び製造できるように考えていました。筆者は3Dプリント初心者というのもあって、ますます「だいたいどこのプリントでも同じものができるでしょう」と思いがちです。
つまり、ポイントをまとめると以下のとおりです。
- 実際の造形ではSTLだけでなく、使用するスライサーやプリンター、材料、積層ピッチ、インフィルなどさまざまな製造条件が最終的な成果物に影響すること
- 設計を変更するたびにモデルの生成や確認、スライスなどを手作業で繰り返していると、どの設計と製造条件から成果物が作られたのか分からなくなる可能性
- 設計変更を追跡できるようにすることが大事
補足：設計変更を追跡できるようにすることが大事
今回のおおきなポイントとしてはGitHubを使った開発ライフサイクルに3Dプリントを取り入れたという点です。追跡・発見・削減・管理の4つの観点で見てみると次のようなことがわかります。
-
追跡
- 設計データと変更履歴をGitで管理し、いつ、何を、なぜ変更したのか追跡できる
- スライサーやプリンター、材料などの製造条件を管理してどの条件から製造成果物が生成されたのか追跡できる
-
発見
- OpenSCADによって3Dモデルをコードとして表現し、設計変更をレビューできる
- GitHub Actionsで設計値やモデルを自動検証し、製造前に問題を発見できる
-
削減
- 設計データからSTLを自動生成し、手作業による成果物生成を減らす
- 製造ツールチェーンそのものを再現可能にし、開発者のローカル環境への依存を減らす
-
管理
- STLやG-code、3MFなどの製造成果物を設計データと関連付けて管理する
- 設計変更から製造成果物生成までの工程を自動化し、継続的に改善できるフィードバックループを作る
今回は単にSTLを自動生成した仕組みを作ったという話ではありません。以下のようなフィードバックループを作ったという話に近いです。
設計
↓
変更
↓
レビュー
↓
自動検証
↓
製造成果物の生成
↓
製造
↓
実物の評価
↓
設計へフィードバック
今回の検証でまだ解決していないこと
今回検証できたのは主に「設計データ上で明らかな問題を製造前に検知すること」です。実際の造形ではプリンターの精度、材料の収縮、温度、サポート、造形方向など物理世界特有の要素が加わります。
この仕組みをさらに上の段階に押し上げるためには設計値だけではなく実際に造形した結果を測定し、その結果を再びGitHubへフィードバックする仕組みについても考える必要があります。
まとめ
今回はGitHubを使ってより良い3Dデータを開発するための仕組みについて考えて実践してみました。
「このSTLはどの設計から作られたのか」だけではなく、「どのバージョンのツールを使い、どのプリンターと材料、製造条件で作られたのか」まで追跡できると3Dプリントを一度作って終わる作業ではなく、ソフトウェアのように変更、検証、製造、評価を繰り返せる開発プロセスにまで進化します。
今回の検証で最も大きな気付きはSTLをGitで管理するだけでは再現可能な製造にはならないということでした。設計データに加えて、検証ルール、製造条件、ツールチェーンまで管理して初めて「同じ条件で同じ成果物を作る」ことに近づけます。
また、今回は挑戦していませんが、GitHub Copilotに3Dデータを調整してもらってGitHub ActionsのCIで検証するといったこともやれます。バイブ3Dモデリング？！といった感じのことも安心してやれるかなと思いました。
トラブルシューティング
ココからはPrusaSlicerのお話です。（参考までに）
PrusaSlicerによる自動化もGitHub Actionsで試してみた
結論から言うと今回のLinux/Dockerベースの自動化要件では採用を見送り、最終的にはスライサーをBambu Studioへ切り替えました。
Bambu StudioのLinux CLIは完全なヘッドレス実行ではないため、Docker上でxvfb-runを利用して仮想ディスプレイを用意し、その上でCLIからSTLをスライスしています。
これにより、OpenSCADによるSTL生成からBambu Studioによる製造成果物の生成、Manufacturing Report作成までを一連のパイプラインとして実行できるようになりました。
当初はOpenSCADで生成したSTLをPrusaSlicerでスライスし、G-codeまで自動生成する構成を検討しました。いくつかの問題に遭遇しました。
PrusaSlicerにはCLIが用意されているため、一見するとGitHub ActionsなどのCI環境にも組み込みやすそうに見えます。しかし実際にLinux上で自動化を試したところ、スライサーを実行するだけでは製造環境を再現できないことが分かりました。
検証中に遭遇した問題は以下のとおりです。
- PrusaSlicerの設定を読み込むためにdatadirやプロファイルの扱いを考慮する必要があった
- Flatpakでは実行環境と設定ディレクトリの扱いがCI環境で複雑になった
- Snap版では検証時点で2.7.4が導入され、利用したいCLI仕様との差異があった
- Linuxで利用するPrusaSlicerの配布方法とバージョン固定を考慮する必要があった
- Dockerでソースからビルドする方法も試したが、ビルド依存関係の管理まで必要になった
特に印象的だったのが、次のエラーです。
Configuration wasn't found. Check your 'datadir' value.
これは単純にPrusaSlicerの実行ファイルを用意すれば解決する問題ではありませんでした。スライサーにはプリンター、ノズル、積層条件、フィラメントなどの製造条件が存在し、それらをどのようにCI環境へ再現するかまで設計する必要があります。
この検証から、Manufacturing as CodeではSTLのような設計データだけをバージョン管理しても十分ではないと考えるようになりました。
つまり再現性のある製造（Reproducible Manufacturing）は今回の検証から以下のような構成になると考えられます。
Design Data
+
Slicer
+
Slicer Version
+
Machine Profile
+
Process Profile
+
Material Profile
+
Execution Environment
= Reproducible Manufacturing
ソフトウェアでもソースコードだけでは同じ実行環境を再現できません。ランタイム、ライブラリ、設定などが必要です。3Dプリントでも同様に、設計データだけでなく「どの環境と条件で製造データへ変換したのか」を管理する必要があります。
なお、これはPrusaSlicer自体が3Dプリント用途に適していないという意味ではありません。今回求めていた「Linuxコンテナ上で製造環境を固定し、CLIから継続的に実行する」という用途では環境構築の比重が大きくなったため、本検証では最終的にBambu Studioへ切り替え、Xvfbによる仮想ディスプレイを利用してLinux上でCLIによるスライス処理を実現しました。
