ニコニコ超会議に参加してきました！イベント出展にてぬいぐるみに習字をしてもらったのですが、詳細はこちらをご覧ください。
godiva-frappuccino.hatenablog.com
やったこと
ぬいぐるみが、労働をします。
いかがだったでしょうか？よくわかりませんね。
具体的には、ぬいぐるみに習字をしてもらいました。ぬいぐるみがいきいきと働けるように場をセッティングして、通りがかった人々に喜んでもらえるよう働いてもらいました。習字の内容としては、好きな漢字を書いてもらうか、持ち物をぬいぐるみに見せるとそこから連想した漢字を一文字書いてもらうという感じでした。
可愛いですね。字はぬいぐるみらしいふわっとした質感で味のある書きっぷりですが、普段紙に文字を書かない僕より綺麗です。前日夜に「文字だけ書いて配っても後から見返すとよく分からない…」と思い急ピッチで錬成した「ぬい労」スタンプを押して、来場者の方々にお配りしていました。人が笑顔になると嬉しい…
プロジェクト進行
全体方針
今回、人間のメンバーが3人で僕とCNOとオブザーバー的な立ち位置の人が一人だった為、開発を僕とCNOで担当してプロダクトデザインをCNO中心で進めつつその他でレビュー、プロジェクト進行については僕がまとめることにしました。その中で意識したこととしては、自分の中では厳しめにスケジュールやプロダクトの実現可能性を判断したうえで、メンバー内では緩めに進める、でした。プロジェクトの焦りは大体見積もりの甘さか突然のトラブルによるものだと思ったのでそこを担保する必要があると考えたのですが、あくまで趣味のプロジェクトなのでそこを表面上も厳しくやってしまうと義務感が出て楽しめないかなと感じました。
一度ウォーターフォールっぽいガントチャートを作成したのですが、一旦作業のボリューム感を出せたらそれでOKとして、結局直前までぬいぐるみ労働組合としてのビジョンのアップデートがかかる前提でいたのでアジャイルっぽく実装進めてイメージ固めつつやりたいことも話し合う、みたいな感じで進めていました。
詳細な進め方
詳細な進め方として、会議体としても週一オンラインみたいな感じで、学生と社会人が混ざっており忙しさの質も違うので良しなに調整して進めました（社会人だと繁忙期が残業で作業しづらいとかありますが、学生は期末テストや研究室内の発表等タイミングが互いに読めなかったり土日も作業している場合があるのが難しいところですね）。本当はタスクリストとか細かく作って共有するべきかもしれないのですが、全員がプロジェクトの全体感を掴むのに脳のリソースを割くのも勿体ないなと思い、特にCNOにはぬいぐるみ労働組合のビジョンを考えてもらうことと、クライアントサイドの実装に集中してもらいたいと思い、必要なタスクリストは裏で管理していました。会議の進行は互いに進捗報告してレビュー的に話し合って、最後にToDo一覧を出すみたいな感じで進めていました。その中でToDoは毎週の作業の進捗度合いやプロダクトの方向性によって決めつつ、展示の備品周りの確認事項や申し込みのチェック等はスケジュール的にクリティカルな遅延が発生しないよう動くべきタイミングで差し込むようにしていました。
スケジュール・進捗
スケジュール感には結構余裕がありました。というのが、1月前半でこのプロジェクトが立ち上がることになって1月末に習字をやることに決まったのですが、まずその数日後にはプロトタイプを作って習字ができることの概念実証をしていました。その際xyプロッタや後述する極座標系プロッタ等の手法を比較検討していたのですが、ともかく文字が書けることは早々に確信していました。対象を漢字に絞ればデータセットが存在することも調査していたので、ハードウェアが用意できる・制御できるプログラムが用意できる・ぬいぐるみがそれっぽく動かしているように見える、といった検証ポイントをクリアすることを最優先でやっていたので何とかなりました。そして、二月後半にオフラインでの顔合わせも兼ねてデモをやる為に大阪に赴き、習字システムのサイズ感の確認と動作イメージを持って…壊れました。サーボモータが脱調してうまく字が書けず、予備のモータを…と思ったら、前日「予備のモータを持っていこう→一応2パターンのプロトタイプを持っていくからそのモータを予備として差し替えよう→これ実現したい1パターン持っていけば良いか」といった機序で予備のモータを持っていき忘れました。その日はみんなでぬいぐるみの映画を見てカフェで食事をして解散しました。
デモでの失敗を受けて、冗長構成を組むことやフールプルーフ、フェールセーフを心で理解した為、そもそも間違えないような機構の工夫や電気・ソフトウェア的にミスした場合でも破損しないような設計をし直しました。以前プラスマイナスを逆に繋いでしまうミスを円形のジャックに変えることでミスを無くしたことがあったのですが、今回はサーボの初期姿勢を勘違いしたままネジ留めしてしまって通電したときにありえない角度に動いて機構が干渉してトルク負荷が過剰にかかり脱調…といったミスだったので、ミスをして回転しすぎても機構が干渉しないように調整したり、通電までの手順を画一化して組み立て手順もシンプルにしたりしました。とはいえ運搬の際に毎回分解と組み立てが必要だったので、その辺りは注意して「確認ヨシ！」と絶叫することで対処しました。結局これが一番です（本当かなぁ）。
また、今回習字システムのアルゴリズムは僕が開発、持ち物を見て漢字を選ぶアルゴリズムはCNOが開発といった流れで進めていたので、結合テストが必要でした。とはいえ地理的に数百メートル離れていて片道15000円くらいかかるので、結合テストの為に毎回30000円使うのはあほらしいと思い、極力オンラインでテストできる環境を整えました。というのが結合テストを二段階に分けて、ソフトウェア的に動くことの確認と実際のハードウェアとの接続テストに分けました。ハードウェア無しでモックとして動かせるプログラムを用意してGitHubで共有して、一段階目の結合テストを早めに実施しつつプログラムをアップデートして、その後たまたま東京で合流できるタイミングがあったので二段階目の結合テストを実施しました。その時点でソフトウェア・ハードウェア共に動作確認ができたので、その後は当日まで一段階目のテストだけ繰り返しながらアップデートをしてもらっても問題の切り分けが可能になっているので問題ないという判断で進めることができました。とはいえ当日動くかはかなり不安でしたし、実際に2台あるArduinoの片方のドライバーがインストールされておらずCOMポートが見えない問題が発生して焦りましたが…それについては、後でドライバーインストールで解決すると分かったのですが、結局電気系統の冗長構成としてもう一台持ってきた予備のArduinoが一発で認識されたのでその場で実装内容をボードに書き込んで差し替えることで解消しました。
実現可能性の見積もり
技術的な話は後述しますが、見積もりに関してはスケジュールだけでなく実現可能性も精査していました。今回の技術的な肝となる習字システムは僕が期間内に実現させなければいけなかったのはもちろん、その前に実は出ていた食品を作るアイデアやぬいぐるみと人間による音声会話みたいなものもあり、それが実現できるか考える必要がありました。ぬいぐるみにやってほしいこととしての判断は極力CNOに任せつつ（と言いながら色々言いましたが…）、実現できるならGOを出し、難しければプロダクト的に嬉しくかつ現実的な代替案を出すといったことをしていました。例えば、今回ぬいぐるみが二人になって持ち物から想像した漢字を伝言してあげるみたいな流れになったのですが、当初はぬいぐるみは大きい子一人でやる予定でした。ただ、その場合お客さんを向いたり、漢字を想像するお題となる持ち物の方を見たりしなければいけません。しかし、これをやると100cm級のぬいぐるみをモーターで動かす必要があり、電力やトルク、ハードウェアの選定等で僕の経験の範疇を超える可能性がありGOを出せませんでした。結局、1週間くらい試した上でもう一人小さい子に頼んでその子を動かしましょうということになりました。イメージは保ちつつ、コアのアイデアを実現すればまぁいいかと思いました。
因みにぬいぐるみを二人にする案を出したことで、少し良いことがありました。二人目のぬいぐるみはお絵描きという趣味が習字に近いということで最初パペットのジェラトーニにしようと思ったのですが、権利関係での不安が大きく、一人目と同じフモフモさんシリーズを使用することにしました。フモフモさんを使用するにあたって、パペットと異なり胴体に穴が開いていないので非侵襲でボーンを通さずに動かしたい、そしてモータを仕込むと排熱がこもるのが怖い、ということで外側にモータを配置して外から動かすようにしました。これをやると正確な姿勢制御はできなくなるのですが、大まかに左右を向く程度の制御かつ自由度が少なめで要件を満たせるのであれば有効な手法だと気づきました。プラスチックや樹脂の胴体とも違ってぬいぐるみの肌は内側が熱がこもりやすいですし、そういった代替案を出すことには価値があると思いました。実際に展示を見てくれた方の中にモータを外だししたことに注目してよいアイデアだ！と言ってくださった方もいて、結構排熱問題とかぬいぐるみ操作における侵襲性問題は喫緊の課題なのかもしれないと感じました。
技術的な話
全体アーキテクチャ
今回は習字システム及びぬい動作システムとして2つのシステムを作成し、それを統合して動かすクライアントプログラムという構成になりました。
技術的な言葉を交えて説明すると、ChatGPTを使用した漢字生成とペンプロッターによる習字及びシンプルなぬいぐるみの身体動作を実施しました。基本的にはぬい動作システムと習字システムはサーバプログラムとして動作しており、クライアントシステムがそれらを順番に呼び出すことで一連の流れができるようになっています。
インタラクションのイメージはシーケンス図に書き起こして議論しました。イレギュラー対応を含めた詳細イメージや文言はフローチャート形式でもまとめていたのですが、基本的には以下の流れで進めています。とはいえ、シーケンス図だとシステム・アクター間のやり取りに注目されて内部的な処理が隠蔽されているので、実際何をしていたかは後述します。
システム間の接続及び備品の調達・管理の為にハードウェア間の接続を表す図の様も作っていました。習字システムやぬい動作システムはもう少し詳細な接続があるのですが、ひとまずこれらの要素があれば完結できるなという次第で記載していました。あまり厳密ではないですが登場人物と大まかな接続が分かることに価値があります。
ChatGPTによる漢字生成
ChatCPTによる漢字生成では、CNO(チーフ・ぬいぐるみ・オフィサー)の方がGPT4with Vison及びGPT3.5を併用して画像から漢字一文字を抜き出す処理を実装しました。まず最初に持ち物を撮影したら画像をGPT4with Visionに送り、その写真の説明文を生成させます。その後、説明文から特徴的な漢字一文字をGPT3.5に生成させて、習字システムに送信しました。GPT4及びGPT3.5の使い分けをした理由としては、一度に複数の命令を送るとGPTモデルの生成の精度が落ちる点と回答生成速度を気にしたところにあります。基本的には出力トークンに凡そ比例する形で実行時間がかかるので、GPT4で生成を待つのは現実的ではありません。
また、今回はモバイルWi-Fiルーターを使用してChatGPTに接続したのですが、デモ運用を考えると実行時間や可用性の問題でローカルでそれらを実施する案もありそうです。漢字生成についてはローカルLLMを走らせることができる他、実は画像の説明文はGPT4with Visionでなくとも今までやられてきた機械学習の手法でもそれなりの結果は出せると思います。
他にも、画像の説明文の生成の際にスマホの写真を見せると"写真"に注目されてしまったり持ち物を持つ手が注目されて"手"に注目されてしまう等の課題があったので、GPT3.5でその判断をさせる前に説明文の生成時点でうまくやる方が良いと考えて持ち物は茶色い紙の上に置く、プロンプトで茶色い紙の上にあるものを説明してくださいと指示する、（やったか覚えてないですが）写真の場合は写真の内容を説明させるみたいな工夫もしました。その他、漢字一文字の抽出にあたってFunctions Calling、JsonModeの様な機能も活用できるとは思ったのですがあくまでstringやparameter指定のみができてセマンティックな制御はLLMのみぞ知る部分だったので、返答からgrepして最初にヒットした漢字一文字だけを抽出するようなルールベースでの制御を入れていました。
習字システム
習字システムは一般的にペンプロッタと呼ばれるもので、モータで紙の上を自由にペンが動いて、ペンの上下によって線を引く/引かないを決定するものになります。試行錯誤段階では3つの方式を検討していました。名前はよくわからないので適当です。
まず、x-yペンプロッタは最も一般的な手法で精度も確保できます。外側にレールを配置して動きとしても単純になるので、これをステッピングモータで動かすことで安定した動作が期待できます（実は一般的な3Dプリンタもこの方法です）。しかし、今回ネックとなったのが可動域の外側に配置されるレールで、ぬいぐるみが書いてくれるのかと思いきや大仰なハードウェアが鎮座していたらイメージを棄損します。
そして、まず最初に作ったのが二つ目の極座標ペンプロッタで、最終的にもこの形になりました。レールが一本かつ伸びきった状態では可動域内にレールが収まる為、とても安定します。デメリットはいくつかあり、まず一番遠い箇所にレール伸ばすことを想定するとレールの長さが必要になります。例えば長さ5cmの正方形で原点の対角線上の頂点に点を打つ場合、5√2cmの長さが必要になります。これは仕方ないので、以下の様に原点位置をずらすことで回転角を少なく済ませることで影響を小さくしました。二つ目の問題はこの図でわかる通り、原点位置に点を打つのが難しい問題です。図の上の方にあるごちゃごちゃしたものがペン及びペンを上下させる仕組みなのですが、ハードウェアをコンパクトにしようと考えるとこれを原点の上で通過させるのが結構面倒になってしまい、結局ペンの周辺を極限までコンパクトにしたうえで原点から離しました。まぁぬいぐるみの腕が伸びるイメージなのでこれで問題ないという判断でした。
二つ目の問題は次のペンプロッタで顕著に出た問題ですが、原点から離れた位置ではペン先が沈み込む問題がありました。というのがx-yペンプロッタでは左右のレールでペンの高さが精密に制御できるのですが、コンパクトにまとめたこの仕組みではペン先を原点位置のみで支える為、レールを伸ばせば伸ばすほど沈み込みます。一応原点での支えの長さをある程度確保したり隙間を減らしたのですが、これに関しては金属製で隙間0.1mm以下のような精度で作らないと限界があります。今回はPLAフィラメントで部品を印刷したのでそこまで精度を求められず諦めたのですが、実際デモ中にペン先が浮いてしまう問題があり、難儀しました。コンパクトな機体を求める為にペン先のサーボのトルクが結構ギリギリで、可動域をあまり確保できていなかった為、ペンの上下が数ミリ程度、ペン先の自重による沈み込みが1mm程度でもペンが浮いてしまうようなオーダーとなっていました（本当は直動機構に変換すればこの辺りの問題は解消していたのですが、コンパクトに納められず断念しました、設計力…）。
三つ目の問題として、レールを伸ばすと分解能が落ちる問題がありました。まず、モータで制御できる値はレールの長さrと回転角Θです。x-yペンプロッタの場合は横のxと縦のyを動かすだけなのでどこに点を打っても均等な分解能なのですが、極座標ではそうはいきませんでした。レールが短い場合と長い場合での比較なのですが、左図のレールが長い場合に一定角Θ回転させると赤矢印の分だけ動きます。そして、右図のレールが短い場合は赤矢印が短いと思うのですが、回転角は同じです。これによって起こる問題として、単純に細かい字が書きづらいという問題も起こってくるのですが、モータを複数動かす場合は完全非同期ではない場合、ちょっとレールを伸ばして回転させて、ちょっとレールを伸ばして回転させて…のような動きの繰り返しになります。これを細かく繰り返すのですが、レールが長い場合にはこのちょっとの動きで大きく線が引かれてしまうのでヨレヨレになります。これに関してはステッピングモータで頑張れば現実的には影響を少なくできるのですが、ハードウェアの運搬での分解組み立てやメンテナンス、制御面もあり細かい角度調整に限界のあるサーボモータを使用したことやレールの長さを変える為のギアのクリアランスを大きめにしていたことなどが原因で、技術的には解消できずぬいぐるみの字の味として許容するに至りました。
三つ目の2自由度リンクペンプロッタは本当にシンプルにリンク機構となります。デメリットと呼ぶか悩んだ点として計算が少し面倒なのですが、座標の計算に逆運動学の計算をします。これを細かくやると計算が煩雑になるので微妙だったのですがとりあえず書いてみました。高校生ぶりにメネラウスの定理とか出てきたうひょー！とか思いつつ、図に起こしてPython及びArduino実装をやって、とりあえず動くようになりました。
ただやはり問題はペン先の沈み込みで、こちらの機構だと原点に2つモータを配置してそれが固定されているだけで、各リンクにも重みがあるのでかなり沈み込みます。ただこれをやるとかなり精度に影響も出そうと思い、その他設計面でも面倒な部分があったので断念…といった形になりました。
漢字を書くための制御
漢字を書くためには、与えられた漢字からペンプロッタの座標の配列に変換する必要があります。最初これを画像処理でやる案も考えたのですが、以前細線化処理の実装をした際に結構難しいと理解したことやその後の書き順への変換が難しいと感じて、まずサーベイ…ということで漢字のSVGファイルをまとめてくださっているKanjiVGというプロジェクトに出会い、これのデータを活用することとしました。
The Kanji Vector Graphics (KanjiVG) project - KanjiVG
今プライベートリポジトリで管理している習字システムのライセンスにはCC BY SAライセンスに則ってGitHubリポジトリにもライセンス記載していますが、一旦データのみ使用する形で実装しています。SVGファイルのファイル名が漢字のコードなんですね（今回の件で漢字コードに少し詳しくなりました…）
漢字のSVGがかなり面白かったので紹介します。例えば以下のファイルは漢字"零"(uf9be)の中身ですが、プリミティブないくつかの線の組み合わせをTree構造として持つことで構成しています。零は雨と令をtopとbottomに持ち、更に雨は一と｜とその他を持ち…といった次第です。見てもらうと分かる通り直線での表現で細かくは表現されていないので、ちょっと不思議なフォントになります。例えばしんにょうもカクカクになったり。因みに二つ隣のブースでx-yペンプロッタを展示されている方とお話したのですが、そちらではフォントデータからパスを抜き出したらしく、なるほどな～と思いました。そちらではフリーハンドで書いた線を書く機能も実装しており、かなり理想的な実装だと思いました。まぁ僕は思い付きでペンプロッタを作ることになったので、精進ですね。
因みに、結合テストの関係もあり簡易的なViewerを作成しました。基本的にはSVGの各直線の始点及び終点のセットを制御PCで計算して、それをArduinoと画像表示用のサーバにそれぞれ送信する流れで実装しました。Arduinoでは、直線を綺麗に書くために直線を細かい線分に分割しちょっとずつ書き進めるような処理だけ記載しています。
ぬい動作システム
ぬいぐるみの動作の為のハードウェアについては、よくあるパペットにモータを仕込む方式モータの排熱の問題とぬいぐるみに穴を開けたくない思想の問題を考慮して設計しました。とりあえず商品の写真から気合でモデルを錬成…しましたが、結局サイズ感が微妙に異なる問題やお腹がふっくらしていた等の課題があり実物を見て作り直しました。
ぬいぐるみを動かすにあたって、必要だったのは左右を振り向くことともう一人のぬいぐるみもしくはお客さんを見る為の上下の動きが必要でした（結局お客さんを見る動作は無くなったのですが、持ち物を見るかもう一人のぬいぐるみを見るかで上下の動きは必要でした）。自由度が少ない！と思い、シンプルに外側からモータで引っ張る形の構成にしました。ブースに来てくださった方がモータを外だしするアイデアは面白い！と芯を食った誉め言葉をくださったので分かる人には分かるもんだなぁと思いました。ただ、首3自由度とか精密な角度制御みたいなことをやろうと思うとぬいぐるみのふわふわした体ではそもそも難しかったり、外側が大仰になるのは操り人形の紐の先に人間がいるようなもので根本的な問題なので、やはりユースケースを選ぶものかなと思いました。逆にユースケースによっては友好なので是非ご参考にしていただければと思います。
その他の工夫・冗長化
まず、今回は習字をするにあたって、制御にはノートPCとArduinoとサーボドライバーであるPCA9685を使用しました。本来はラズパイなどで直にPCA9685に命令を送ってしまった方が良いのですが、以前からの学びで故障時の影響を小さくしたいという思想でArduinoと制御PCを分けることにしています。ラズパイはOSが乗っている分高価になりがちですが、これを焼いてしまったり破損した場合のリスクは大きいと感じています。ただ、Arduinoと制御PCでのシリアル通信が結構遅く遅延時間もばらばらなので、そういったケースを考慮するとシリアル通信抜きに送信できる必要があります。それを考えると制御PCとラズピコをEthernet等で有線接続してそこからPCA9685に接続かなぁとか考えてましたが、今回は拘束に習字しても逆に違和感が出るので一旦そのままとしました。（制御PC側でAckの受け取りでWaitしてるのが遅いと感じたので、Waitせず命令送り続けられるような方式を考えればよいかもしれません）
また、展示にあたっては冗長性が重要と考えました。電子工作あるあるとして疲労や電気的な事故による破損はつきものらしいですし、今回は僕の中では初めての技術系でのイベント出展だったので用意をしました。ハードウェア構成を見て、今回はトルクは小さいので3Dプリント部品が物理的に壊れる心配はないと見て一系統で心配な部品のみ密度高めに印刷するようにしました。と言っても力がかかると積層方向的に不安な部分を別パーツに分けてネジ留めにすることで折れることを避けたり、数ミリ厚くするなどのあがきはしました。結果的に残ったのが、Arduinoやサーボモータといった電気系の部品の予備と、制御PCや電源タップ等の持参忘れのリスクがある部品としました。CNOに制御PCは任せていたのですが、やはり万が一ということで僕もソースコードをもらったうえでクソデカゲーミングノートを持参していつでも差し替えられるようにはしていました。結果的に、2日間まるまる動き続けてくれて自分の設計に感謝…！という感じではあったのですが、僕のPCでは問題なく動作していたArduinoがCNOのPCでは認識されず、予備のものと差し替える必要があったので冗長構成にも感謝しました、結局ドライバーが入ってなかっただけだったのですが、後からそれを調べて判明したので、Arduino内での種類もそろえた方が良いな～とか最終的な結合テストが本番当日は危ないな～みたいな色んな気持ちになっていました。まぁ動いたのでヨシ！
お金の話
イベントに出るということは、お金がかかるものなので気になりますよね。同人誌を売って印刷費が100万円かかって売り上げが140万円になったので差額の40万円を東京大学で胃がんを研究している機関に寄付したみたいな話もありますし、実際にイベントに出展する場合どんなかんじなんだろう？とイメージできる参考程度の情報を載せてみます。
以前寿司にマイクロビキニを着せて本を売った時に収支報告を出したのですが、今回は展示物が技術的なものでハードウェア代もかかっているので、出していきます。因みにコミティアでは印刷費9000円程度を売り上げでペイしてポスター代・交通費・当日買った本・決起会及び打ち上げの寿司代で3~40000円程度マイナスになりました。決起会の寿司代が11000円だった時点でマイナスでした。
それでは、まず収入です。
以上です。展示を見せて書いた習字の紙を配っただけなので一円もいただいていませんね。
次に支出です。ハードウェア以外の経費としては、幕張メッセが千葉にある為、東京・神奈川からの交通費で4~5000円、ホテルも少し離れた場所で取って9000円、大阪でメンバーとの顔合わせも含めた打合せをした際に交通費で30000円、飲み会で5000円、その次の日に友人と食べた寿司6000円等結構マイナスになっています。当日の出展費用は1スペース2日間で20000円（但し負担額は参加者で割るので個人負担は少なめです）、飲み会で5000円、結構色んなブースで本を買ったりアクリルキーホルダーを買ったりして10000円以上使っていたことに気づいたり、まぁ人間すべからくイベントではお金を使いがちという面があるのでそういった支出もありました。ここまでで8万円くらい使っている気がします。
技術的には、元から所持しているハードウェアを流用したので実費かかっていないというか減価償却的にそこまでかかっていない部分が多いです。ただ、一旦元々の金額を出したうえで冗長構成を組むための予備部品の金額などで出していってみます。
サーボモーター（SG92R x6, MG996R x7）10000円くらい、Arduino x3購入当時の値段で4000円くらい、3Dプリントした本体が試行錯誤でかなり量を消費したので3~4kgで10000円くらい、その他サーボドライバー、USBケーブルやACアダプタなどで4~5000円くらいになります。その他には他メンバーの用意でWebカメラや三脚などがシステムとしてあり、他にも筆ペンや紙、朱肉等細かい備品がありました。大体30000円くらい使ってないですか…？
というわけで負担額11万円程度になった気がします。ただ金を払って人と無生物を笑顔にしただけのイベントだったのかもしれません。
終わりに
イベントへの出展は以前本で出したことがあったのですが、今回は技術面ではかなり不安も多く新鮮なことが多かったです。特に、本であれば現物と什器、ポスターやレジ系の備品等売る為の一般的な設備で一通り揃うのですが、機械系を動かすとなると備品だけでもメンテナンスや故障時の代替部品、電源系統などで大量になり、デモを動かす為の手順や事前準備も煩雑になる難しさがあると感じました。ただ、それに対して適切な技術やスケジュール・プロダクトの方向性の管理を行うか気合で何とかすれば解決できるというのは大きな学びでした。今後もこういうイベントに参加できたらと思うので
直近だと秋ごろ（9~11月の間？）で人形の教室展があるのと、12/6~8にデザフェスギャラリーで個展予定なので、今回の学びを活かして進めていきます！ありがとうございました。
