MUDAなことをしよう。MUDAなことをしよう。前回のハザードトリガーに引き続き、今回もビルド関連の工作です。トランスチームガンをベースに、『ぼくのかんがえたベストマッチ』を実現するオモチャを作ってみました。正確に言うと、任意のフルボトルを組み合わせることで、元々存在しているベストマッチ以外の組み合わせを、新たなベストマッチとして定義することができます。わかりやすい例でいうと、『魔法使い』x『ライオン』で、『仮面ライダービースト』!とかですね。フルボトルの組み合わせも、別に二つの組み合わせに限定する必要もないだろうということで、とりあえず三連ベストマッチまで定義できるようにしてみました。「こういうベストマッチもありかと思うけど、それにうまく合うようなフルボトルが東都にも北都にも西都にもレジェンド関連にも存在しない!」という事態にも対応できるように、自分で新たなフルボトルを定義する仕組みも用意しておきました。これにより、ベストマッチの組み合わせはアイデア次第でほぼ無限大に用意できることになりました。工作のアイデアとしては昨年(2017年)11月頃、特撮玩具好きの部屋のクレーンの丈様によるビルドドライバーの音声解析結果を見たときに思いついていました。その頃はフルボトル専用発光台座の制作で大忙しだったのと、丁度その制作がひと段落した頃にハザードトリガーが発売されて、そちらの工作を優先した結果、ようやく今(2018年4月)になって完成させることができました。このアイデアの特性上、ある程度フルボトルが出揃ってからでないと面白くないなあとは思っていたので、結果としてはベストな時期に作成することができたと思います。こちらが改造を施したトランスチームガンです。一応、トランスチームガン・カスタムと名付けてみました。してみると外見はほとんど変わっていません。銃口を見ると、奥の方にフルカラーLEDが仕込んであるのがわかります。フルカラーシリアルLEDテープ(17cm)そして見た目に一番変わっているのは、実はこの後部分です。本来ならスチームブレードが接続されるべきところに、インタフェースが二つ追加されています。左側が制御基板へのプログラム書き込み用のUSB-シリアル変換アダプタを接続するための口になっています。ガシャット制作のときは基板もMP3プレイヤーも完全に中に閉じ込める形にしていたのですが、今回は作品としての性質上、後からプログラムの書き換えやMP3音声ファイルの追加が頻発することがわかっていたので、それぞれアクセスしやすいように内部レイアウトに気を遣ってみました。このあたりの考え方については、以前私がマリオガシャットを作成した際に、私のやり方を取り入れつつも独自にオリジナルガシャットを作り上げられたのり軍曹様のやり方を参考にさせて頂いています。中をもう少し詳しく見てみます。基本的には元々のトランスチームの部品をそのまま流用していますが、スピーカーはあまりに音質が悪かったので、以下のスピーカーの中身を取り出して置き換えました(さすがにケースごとはちょっと入りませんでした)。16MHz)を埋め込んでいます。16MHzMP3プレイヤーはここに入っています。miniを使用しています。並行輸入品それから、フルボトルのイジェクトボタンのところは本来電気的なスイッチは入っていないのですが、ここに一つスイッチを埋め込んでいます。中身についてサラッと見ましたが、今回の工作では、ハード側の方で語ることはあまりありません。今回の肝になるのはソフト(プログラム)側、具体的には『どうやってフルボトルの個別認識機能を実現するか?』に尽きます。要するに、例えばラビットフルボトルは「1」、タンクフルボトルは「2」であるとプログラムで認識することさえできれば、あとはプログラム上で「1と2はベストマッチだよ」という定義を書いてあげれば良い、ということになります。各フルボトルにはそれぞれ固有のナンバーが割り振られていて、それは認識ピンの下に明記されています。ラビットなら「001」、タンクなら「002」といった具合です。認識ピンの配列とこれらの固有ナンバーの関係についてはクレーンの丈様がこちらで解説してくださっていますが、計算に必要な情報をまとめると以下のようになります。わかってしまえば単純ですが、自分は二進数と思い込んでしまっていたせいで、最初は結構混乱してしまいました。二進数ではなく三進数であることに気づくのがポイントです。「ピンの並びがわかれば固有ナンバーの計算はできる」というところまで来ました。あとは、「ピンの並びをプログラムでどう認識するか」です。これはトランスチームガンの認識ピン読み取り部分の部品を取り出してきたものです。6本の線が出ている内、真ん中の2本は白色LEDの制御用の線です。mini)のGPIOにINPUT_PULLUP指定で接続すると、各読み取りスイッチは押されていないときに1、押されているときに0を出力するようになります。これを踏まえて、フルボトルが装填されると0と1がどのように変化していくかを考えてみます。基本的な考え方は以下のようになります。A列先行型の場合は、A列が読み取り開始の合図を出す役目を持つピンだと考えるとわかりやすいです。C列先行型の場合は、当然ですがC列がその役目になります。この考え方は素直でわかりやすいので、私も最初はこの考え方で認識ロジックを書いてみたのですが、いつもビルドドライバーで遊んでいるときのようにボトルを素早く装填してしまうと、うまく認識できないという現象が発生してしまいました。調べてみたところ、ボトルを素早く装填してしまうと、どうも先述の「読み取り開始の合図を出すピン」を読み飛ばしてしまうことがあるようだということがわかりました。いうことで、少し考え方を変えてみました。「途中にある読み取り開始の合図を出すピン」は読み飛ばすことは多いものの、「一番最初の読み取り開始の合図を出すピン」と「読み取り終了」の数字の並び(111)を読み飛ばすことはあまりないようでしたので、「読み取り終了」をベースにピン配列を認識する方法に変えてみました。これで、認識不良や誤認識はだいぶ減らすことができた気がします(←発生しない、ということはないです)。あとは、上記のロジックをプログラムとしてコーディングして、それに肉付けしていく形でプログラムを完成させていきます。この記事の最後にソースコードの全文を載せていますので、興味のある方はご覧ください。ここまでくれば、オリジナルのフルボトルとベストマッチを定義することはそんなに難しくありません。作成したソースコードの中から、関連するところだけを抜き出して説明します。未定義};ソースコードの中では、こんな感じでフルボトルについての情報を定義しています。IDトリガー押下時変身音声IDトリガー長押し時必殺技音声IDの情報を自分で好きなように与えることで、フルボトルごとの挙動を自由に定義することができます。フルボトルIDの122番目以降は元々ビルドドライバーでも利用が想定されていない領域なので、この部分を使えば、元々用意されたフルボトルは全て認識可能な上に、自分で新たなフルボトルを追加してあげることが可能です。私の場合は122番目に新たに『ゲンム』のフルボトルを定義しています。続いて、オリジナルベストマッチの作り方です。こちらも、上記のオリジナルフルボトル追加の手順と似たようなものです。カメラ)};こんな感じで、ベストマッチIDベストマッチになるフルボトルのID1ベストマッチになるフルボトルのID2ベストマッチ判定時音声ID変身待機音声ID変身音声ID必殺技音声IDを指定してやればOKです。一応、ビルドドライバー組み込みで49個程度(?)ベストマッチが存在するようなので、50番目以降のIDを使えば、新しいベストマッチの追加ということになります。最後に、三連ベストマッチの定義は以下のようになります。コブラ)};各項目の内容は、二連ベストマッチのときとほぼ同様です。あとは、それぞれ自分が定義した音声IDに対応するMP3音声ファイルを用意する必要があります。自分の場合は、基本的に玩具の音声をiPhoneのボイスメモで録音して、それをPCのiTunes上でMP3に変換するようにしていますが、どうにも手に入らない音声については、YouTube上で音声素材を公開されている方にお願いして、音声を使用させて頂きました。ご快諾頂いた冬樹因幡様に、この場を借りてお礼申し上げます。ありがとうございました。いうわけで、随分長くなってしまいましたが、以上がこのトランスチームガン・カスタムの仕組みです。今回はガシャットのときと違って見た目はほとんど変わっていないので、ある程度中身のことをちゃんと明らかにしておかないと、動画を公開しても「音声合成w」みたいな扱いを受けてしまいそうな気がしましたので、ポイントだけはちょっと詳しめに説明してみました。現時点で実装済みの、私が自分で定義したオリジナルのベストマッチは以下になります。「カード」が重要過ぎますね。続いて三連ベストマッチです。オーズがほとんどですね。ラトラータについては、ライオンの代わりにトラにしても良いと思いますし、サゴーゾについてはゴリラの代わりにサイを使っても良いと思います。ブラカワニについてはなんと三匹ともフルボトルで揃っている(コブラ、タートル、クロコダイル)のですが、これにメダルを加えると四連ベストマッチにしなくてはいけないので、今回はやめておきました(やろうと思えばできます)。以上、ベストマッチをカスタマイズ可能にした『トランスチームガン・カスタム』のご紹介でした。三連ベストマッチ機能それでも見た目の派手さはないし、また音声再生のディレイのせいで全体的に動作がもっさりした感じにはなってしまっていますが、フルボトルを使った遊びの幅をだいぶ広げるものにはなっただろうと思います。「コレとコレはベストマッチだろう」「いやいやコッチとアッチの方がベストマッチだろう」という、各自の思い思いのアイデアを実現することができますので、『さぁ、実験を始めようか。』がキャッチコピーのビルドにふさわしいオモチャにできたのではないかなあと思います。『仮面ライダー』という枠を超えても良いのであれば、こういうことを考えても良いわけです。ワンピースというようなことまでやってしまったって良いのです。これはもう本当に、自由です。ベストマッチを考えてみて、楽しんでもらえればと思います。DXトランスチームガン以下、「自分でも作ってみたい」という方向けに、回路図とソースコードを載せておきます。ご興味のある方は、ご参照ください。10のSDカードを使用していても)というところが改善すべき点として残っていますので、「ここはこうすればもっと良くなるよ」というアイデアがあれば、是非教えてください。今までの自分の工作にないポイントとしては、DFPlayerのBUSYピンを使用していることです。このピンの状態を監視することで、「今再生している音声が終了するまで待つ」というような処理が可能になりました。ソースコードあんまり綺麗じゃないと思いますが、ご了承ください。同業者(?)の方に褒められるとまた一段と嬉しいです(笑)。そもそもの動機としては、丈様の解析結果があってこそのものです。私は既にあるモノを組み合わせての応用はそこそこ得意な方だと思うのですが、基礎的なところをきちんとやりきるのが苦手なので、あの解析結果は本当にすごいと思います。ありがとうございます。ゲンムのところはゲームの誤字じゃなくて、本当にゲンムなんですよー。新たにゲンムのフルボトルを定義しているのでゲンムなのです。YouTubeの方の動画の5:20あたりから登場します。゚ポーンDFPlayerのBUSYピンで再生監視は知ってたんですけど音声が短すぎて上手く信号拾えなかったのでdelayだけで処理したんですよね。それだとどうしても大量の音声を綺麗に繋げられなくて妥協していたんですが。・・いや参考にさせていただきます。PMかっぱ次郎様DFPlayerのBUSYピン、確かに癖がありますねー。BUSYピン監視でループ待ちをしても、再生命令直後にBUSYピンを見にいくと「まだ再生してなからBUSYじゃないよ」となってループ待ちをスルーしてしまうという。この問題を回避するために、wait_for_sound_stopとかwait_for_sound_stop_with_lightingの冒頭でdelay(500)とかdelay(1000)を入れているんですが、やっぱりdelay(1000)とかにしとかないと、ループ待ちをスルーすることがありますね。今回の工作で一番悔しいところは、DFPlayerの反応が鈍過ぎて、フルボトルの認識後の音声再生とかトリガー押した後の銃撃音が遅れて聞こえてくるというところです。Class10のSDカードを使ってもダメでした。DFPlayerはMP3が簡単に扱えるだけでも十分にありがたいモジュールなのですが、もう少し値が張ってもよいので、応答速度の早いMP3モジュールが欲しいなあと思う次第です。