MUDAなことをしよう。MUDAなことをしよう。仮面ライダーゲーム任天堂3D造形3Dプリンタ型取りお知らせこのブログについてMenuSidebarPrevNextSearchTwitterYouTubeRSSFeedlyホーム>電子工作>Arduino【オーメダル&フルボトル連動】プログライズライターをつくる2020年1月3日あけましておめでとうございます。今年も宜しくお願い申し上げます。今回は2020年最初の作品、『プログライズライター』をご紹介します。『ライター(書き込み機)』の名の通りで、プログライズキーに対してデータの書き込みを行うマシン(の、玩具)です。書き込みを行うために、作成するプログライズキーと同じ生物をモチーフとするオーメダル又はフルボトルを使用するというのが、今回の作品のポイントです。『バッタ』のオーメダルを使用すると、書き込みによって『ライジングホッパー』として機能するプログライズキーとなり、『ウルフ』のフルボトルを使用すると、書き込みによって『シューティングウルフ』として機能するプログライズキーが出来上がります。『ライター』とは言っているものの、あくまで玩具ということで、実際に全ての音声データや発光色のデータを毎回ライターからプログライズキーに書き込んでいるわけではありません。詳細は後述しますが、ライターからプログライズキーに書き込んでいるデータは、『このプログライズキーをどのプログライズキーとして機能させるか』を示すID情報(整数値)のみです。(現時点で対応している)全てのプログライズキーの音声データや発光色のデータは、初めからプログライズキー側に全て格納されていて、ライターはどのプログライズキーにするかを選択しているだけ、ということになります。そのため、このプログライズキーは単体で何にでもなり得る『マルチプログライズキー』と言えるものになっているのですが、ただボタンをポチポチ押して切り替えても面白くないな、と思いましたので、共通する生物モチーフの多いオーメダルと連動させることをまず思いつきました。それだけだと対応できないプログライズキーがそこそこ存在しましたので(シューティングウルフ、スパーキングジラフ、ガトリングヘッジホッグなど)、それらをフォローするためにフルボトルにも対応させることにしました。FULLBOTTLE』の二種類を用意しました。言っても、この二つはラベルを貼り替えているだけで、実態としては一つしか作っていません。好きな方を選んで使用する形になります。ハードウェア解説まずはプログライズキー側の解説です。DXパンチングコングプログライズキーベースはDX版ならなんでも良かったのですが、基本黒で塗装するつもりだったので、ベース色がそれに近い灰色である『パンチングコング』をベースにしています。内側のシールは剥がしてしまい、外側の塗装はMr.カラーのうすめ液を染み込ませた布で拭き取りました。クリアパーツ上の塗装なので、うっかり除光液とかで塗装を溶かしてしまうと、クリアパーツまで白く変色してしまうので注意です。T102余談ですが、上記の塗装の剥がし方をを豆知識としてTwitterに投稿してみたところ、179件のいいねがついたので、「やってみたいけどやり方がわからない」という人が結構多かったのだなあという感じです。自分はガシャット改造のときにこのやり方を知りたかったのですが、なかなか見つけられなくて、結局いくつかのガシャットを犠牲にして自力でこのやり方に到達しました。お役に立ったようで何よりです。FULLBOTTLE』の二つのラベルですが、作成にあたり、ZXライドウォッチの際に昭和ライダーのデザインを引き受けてくださった方に再びご協力頂きました。こちらからイメージをお伝えしたものを実際にデザインとして起こしてもらい、それを見ながら、双方のアイデアを取り入れながら最終的に仕上げて頂きました。いつもご協力頂きありがとうございます。プログライズキーということで、”~ing”という名前のルールだけは最低限守った方が良いかとも思ったのですが、無理矢理そのフォーマットに押し込むとどの名前も何だかイマイチな感じで、また既に『アサルトウルフ』という例外も存在していることから、そこは拘らずに、最終的には素直に作品名を入れることで落ち着きました。上記の写真は試行錯誤の跡です。プログライズキー自体は一つしか作っていないため、この二つのラベルは必要に応じて貼り替えて使用する形になりますが、簡単に貼り替えられるように、スマホ画面の保護フィルムでよく使われている自己吸着シートを利用しています。100均で売っているもので充分です。プリンタで印刷したラベルをこのシートに貼ってからプログライズキーに貼り付けるようにすれば、しっかり張り付いてくれますし、剥がすときも綺麗に剥がすことができます。今回はやっていませんが、既存のプログライズキーのデザインのラベルを作れば、ベース色は黒になってしまいますが、完全にそのプログライズキーとして遊ぶことも可能になります。MEDALの場合は、オーメダルをそのままはめ込むことで、オーメダルが元になっている感(?)を出しています。メダルをそのままはめ込むのはちょっと厳しかったので、分解して絵柄のパーツのみをはめ込むようにしています。FULLBOTTLEの場合は、フルボトルをそのままはめ込むようなことはもちろんできません。したものかと思ってWeb上を色々探していたところで、フルボトルのデザインを正確にイラストに起こされている画像を発見しました。これを是非使わせてもらいたいと思って製作者の方を探したところ、ブラジルにお住まいのデザイナー、markolios様が作成されたものとわかりました。そこで、利用についてご相談したところご快諾頂き、今回使用させて頂きました。ご協力大変感謝致します。歯車がデザインされていることで、すごくビルド感が出て、とても気に入っています。オーメダルとフルボトルで重複する生物(ゴリラ、トラなど)については、どちらも対応しているのですが、シンボル部分で違いが出てくるので面白いです。続いて内部構造のお話です。いつもの、基本の具材のご紹介からです。最後のスピーカーですが、玩具に元々組み込まれているスピーカーと直径がほぼ一緒で、かつ、薄くて音が元々のものより良い(気がする)ので、最近多用しています。それから、今回特徴的な具材は以下の2つです。SIP-3)赤外線リモコンモジュール(IRM-3638N3)ホールセンサは『オーソライズ』ギミックのために今回使用してみました。試していませんが、リードスイッチでも代用できるかもしれません。いう部品の組み込みはガシャット、ライドウォッチとやってきましたが、ガシャットと同等、ライドウォッチと比べるとちょっと大変、という感じでした。スペース的にはかなり余裕がないです。ガシャット、ライドウォッチからもはや伝統の『二つ並んだベルト連動スイッチ』ですが、いつもここの認識スイッチをディテクタスイッチなどで自作して調整に苦労していたのですが、今回は「玩具の基板を破壊して、そこだけそのまま使う」という作戦に出ました。おかげでここは調整不要でラクに作業できました。今回はネオディケイド・ネオディエンドライドウォッチのときと同様、後からプログラムの修正や音声データの追加が発生するタイプだったので、SDカードのスロットやArduinoの書き込みコネクタにはアクセスしやすい形でまとめています。ついでに充電もここから行えるようにしています。このあたりだったり、あとホールセンサやLEDの位置がレイアウト上の制約になって、なかなか大変でした。今回の書き込み機能実現のポイントになっているのが、ここから顔を出している赤外線受信モジュールです。クウガライドウォッチ、ZXライドウォッチに続いて三回連続での採用です。それだけ、使いこなせるようになると工作の幅が広がる部品と言えます。プログライズキーライター側の赤外線LEDの点滅に乗って送られてくる整数値を受信すると、その値に応じて再生する音声やLEDの発光色を切り替えるようになっています。回路図としては、こんな感じになります。続いてライター側です。筐体は適当な大きさのケースを探してきて加工する、という手もありましたが、内部構造を考えると結局中は自作しないといけなかったので、オールプラ板&プラ棒で自作してみました。最後に黒く塗装しましたが、スプレー缶丸々一本使ってしまいました。黒いプラ板とかないのかしら。今回のプログライズキー側もそうでしたが、今までは既にある玩具の中にいかに部品を詰め込むかというところで頑張っていたので、当初「今回は好きなサイズで作れるからスペース余裕でラクだな~」とか思っていたのですが、そんな過去の自分をグーで殴ってやりたいぐらいに大変でした。プラ板工作が初めてということもありましたが、寸法計算するのはめんどくさいしキレイにカットするのも大変、いざ組み合わせてみると部品は干渉するし、ネジとナットは飛んでいくし想定より全然足りなくて何度も買い足すし、プラ板の切り屑がリビングまで付いてきてしまって奥様に何してんだと問われたりもするし、とにかく大変でした。P板カッターとピンバイスは大活躍でした。74112実際に筐体作成に使った部品も一応紹介しておきます。15mmを使っています。これらはホームセンターで大量に買い足しました。ヘビーに使わないのであれば全部接着剤で済ます、という手もあったのですが、今回は後々子供にも遊んでほしかったので、できるだけ頑丈に作るようにしました。全体的なデザインは、オーメダルとフルボトルを使うというところが、何となくコインでジュースを買うのに対応するような感じがしたので、一般的な自販機っぽい雰囲気になるようにしたいと思いました。その上で、自分が小さい頃にギリギリオモチャ屋さんで見た記憶のある、ファミコンディスクシステムのディスクライター的な雰囲気も出したいなと思って、こんな形になりました。複雑なデザインはそもそも作れない、というのもありますけれど。個人的に拘ったのは、このプログライズキーの挿入部の蓋です。内部構造を見えにくくするという効果はありますが、別になくても機能的には何も問題なく遊べます。先程のディスクシステム然り、自分が子供の頃にアホほど遊んでいたファミコン、スーファミ、64然り、何かしらカートリッジを差し込むものには蓋があった方が遊ぶときに絶対気持ち良い(?)と思ったので、プログライズキーの抜き差しに応じて自動で開閉する蓋を付けてみました。機構的な設計は苦手なので、重力と磁石を使うとかもっと上手い方法はあったのかもしれませんが、とりあえずバネを使って試行錯誤して何とかしました。続いて内部構造のお話です。使用した電子部品はこちらになります。LEDバーライター側はスペースの制約があまりなかったので、Groveシステムをベースにプロトを作ってしまって、それをそのまま筐体に突っ込んでしまうことにしました。LEDバーは機能の本質には全く関係なくて、ただ進捗っぽいものを表示して書き込んでいる感を出すためだけのものですが、やっぱりあって良かったと思います。赤外線LED(OSI5LA5113A)Groveシステムにも赤外線LEDはあるのですが、使い方がよくわからなかったので、使い慣れたものを使っています。MP3ボイスモジュールライター側の音声再生には、おなじみDFPlayerではなく、同じ会社が作っているMP3ボイスモジュールを今回初めて採用してみました。DFPlayerはモジュール単体は安いのですが、動かすのにマイクロSDカードが必要なので、意外とコストがかかります。再生する音声データがそこまで大きくない場合は、確実にオーバースペックです。こちらは音声データの容量は8MBとかなり控えめですが、効果音を少し鳴らしたいとかなら必要十分な容量ですので、SDカードを買い足さなくてよい分、コスト的にはお買い得です。サイズが意外と大きいので玩具への組み込みは意外と難しいかもしれないのと、あと開発環境によってはArduinoからプログラムで制御するときにちょっとハマるかもしれないので、意外と使いこなしが難しいかもしれません。プログラムについては、詳細は最後のソースコードの417~427行目のコメント文に記載していますが、曲の番号を指定してもその番号の曲が素直に再生されない、という現象が起こります。普通に使えている人もいるようなので、Mac特有の現象なのかもしれません。挿入したプログライズキーの固定のために、プログライズホルダーを丸々埋め込んでいます。これのあるなしで、プログライズキーの挿し心地と安定感が段違いです。DXプログライズホルダー&ラッシングチータープログライズキーさて、ライター側の肝になるのが、オーメダルとフルボトルの認識です。中古で買ったDXオースキャナーの基板を丸々そのまま突っ込んでいます。市販のRFIDリーダーの部品を買ってきて頑張る、という手もあったのかもしれませんが、それで確実にオーメダルをスキャンできる保証はありませんし、また電波を使用する関係上、それが日本の技適を通過したものかとかを気にするのも面倒だったので、玩具の基板をそのまま使うのが最も確実でラクかな、と思ってこうしました。オースキャナーの基板は、メイン制御部と思われる基板と、メダル(RFID)スキャン用の基板の二つに分かれていて、ちゃんと解析すればスキャン用基板だけを使うこともできるのだと思いますが、今回はそこまで頑張る必要もないかなと思いましたので、スキャン用基板がメイン基板に送っている信号をArduinoにも流して、その信号をArduinoで解読することにしました。詳しくはソフトウェア解説の方で説明します。フルボトルの方は、過去にトランスチームガン・カスタムという作品を作ったときに一度認識はやっていて、今回も認識用のスイッチとフルボトルの装填部分はトランスチームガンの部品をそのまま突っ込んでいます。トランスチームガン・カスタムの調子が悪くなっていたので、潔くトランスチームガン・カスタムを破壊して、部品をこちらに移植しました。回路図としては、こんな感じになります。ソフトウェア解説だいぶ長くなってしまいましたが、最後、ソフトウェアの解説です。ソースコードの全文は、プログライズキー側とライター側、まとめて本記事の最後に掲載しています。プログライズキー側です。ソフト的に特筆すべきことは特にないのですが、とりあえずとにもかくにもプログライズキーの状態遷移がわかっていないと何もプログラムが書けないので、まずは挙動解析からです。プログライズキーの状態は大きく「オーソライズ前」と「オーソライズ後」に分かれていて、それぞれの状態からスイッチの押し方によって、オーソライズ前だと武器用とフォースライザー用、オーソライズ後だとゼロワンドライバー用とショットライザー用に分岐していく形になります。細かいところですが、プログラムの組み方としては、ガシャットとライドウォッチのときは結構厳密にやっていて、「今のボタンの押され方の組み合わせから次のボタンの押され方に変わるとき、今どういう状態か」を網羅的に調べて処理を分岐させていたのですが、今回は厳密に調べるのが面倒だったので、「今の状態で、今のボタンの押され方から次にどういうボタンの押され方をするか」という形で、玩具的に必要そうな部分だけを調べて記述するようにしています。そのため、厳密には玩具と異なる挙動になるところもあるかもしれませんが、普通に遊ぶ分には特に問題なさそうだったので、これでOKとしています。あと、今回ちょっとハマったところとして、赤外線受信のところがあります。赤外線信号を「いつでも」受信できるようにしようと思うと、Arduinoのloop関数の中の処理を極力軽くしておかないと、Arduinoが赤外線信号の受信をチェックするインターバルが長くなってしまい、ライター側の赤外線LEDが発光してもそれをキャッチできなくなってしまいます。そのため、全体を「書き込み前」と「書き込み後」に分けて、「書き込み前」のときは赤外線信号を逃さずキャッチできるように極力looo処理を軽くして、メインの発光やら音声再生の処理は「書き込み後」にだけ行われるようにしています。「書き込み後」から「書き込み前」の状態に戻すために、特別に”Initialize(初期化)”という操作を加えています。上部のボタンを5秒程長押しすると「書き込み前」の状態に戻って、再び赤外線信号を受信してプログライズキーの書き込みができるようになります。このイニシャライズの発動条件は結構悩んで、最初はライターにキーを差し込んだときにドライバー連動ボタンが同時に押されるなどして、書き込む前に自動的にイニシャライズが走るようにしようかと思ったのですが、それだとフォースライザーで遊ぶときに勝手にイニシャライズが走ってしまったりしたので、誤作動しないように長押し5秒という条件で発動するようにしました。続いて、プログライズキーライター側です。こちらのメインは、「どうやってオーメダルをArduinoに認識させるか」というところです。先に述べたとおり、オースキャナーの基板は、メイン制御用とメダルスキャン用の2つに分かれています。ABLENと記載されています。前2つは電源関連で良いとして、あとの3つからArduinoでどう情報を引き出すかです。スキャン用の基板の方を見てみると水晶振動子の部品が付いているので、「スキャン用基板はメイン基板からはABLEN経由で指示を受けて、メダルを読み取ったらCLOCK信号にDATAを同期させる形でメイン基板に信号を送っているのでは」と推測しました。何枚かのメダルをスキャンさせたときのCLOCKとDATAの01の変化を観察してみると、完全に理解したわけではありませんが、少なくともメダルを1枚読み込んだときには01の変化に以下のような法則性があることがわかりました。今回は複数メダルを認識させてコンボ発動とかまではする必要はなかったので、ここまでの理解でプログラムを組んでみました。続いてフルボトルの方の認識ですが、こちらは先に述べたとおり、以前にトランスチームガン・カスタムという作品を作ったときに、一度プログラムは作成しています。トランスチームガン・カスタムで遊んでみると、フルボトルを全然認識してくれなくなっており、どうやらスイッチ部分の経年劣化に対して非常に弱い認識プログラムになっていたことがわかりました。いうわけで、認識ピンの認識アルゴリズムを全面的に見直して、一から組み直しました。結果、誤認識することはまだそこそこありますが、前よりはちゃんと認識してくれるようになりました。詳細は省略しますが、簡単に言うと「認識ピンのあるときは0と1の値がバタつくが、認識ピンのないときは0しか現れない」という、ある種当たり前の前提に則ってプログラムを書くようにしています。基本はZXライドウォッチのときとほぼ変わっていませんので、詳しくはそちらをご参照ください。フルボトルを認識して得られたID(整数値)を送っているだけです。念のため補足しておくと、書き込みの効果音が流れている間中ずっと赤外線信号を送り続けているわけではなく、実際に信号を送っているのは音楽が終わった直後の最後の一瞬だけです。LEDバーが示している進捗状況も、「それっぽさ」を出すためだけの、完全なフェイクです。オモチャということで。まとめということで、『プログライズキーライター』のご紹介でした。今回は「プログライズキーを作り出す工程」を作品化したので、「何かすごいプログライズキーそのもの」を期待されていた方は、申し訳ありません。新しいプログライズキーを創り出そうと思うと、必然的に音声データを作成しないといけなくなるのですが、自分はデータの編集は出来ても、ゼロから音声を作り出すことはできません。その制約の中で最大限楽しく遊べるものを目指した結果、今回はこういう形になりました。実際、長男も楽しそうに遊んでくれているので、まー良かったかなと思っています。ちなみに、今回は作り込んでいませんが、レジェンドライダーのメダルやボトルを使ってプログライズキーを生成できるように機能拡張するのも面白いかもしれません。オフィシャルにレジェンドライダープログライズキーも発表されたことですし。他にも、セルメダルを使ってゼツメライズキーを作ったり、というのもアリだと思います。今回、なかなか汎用性のある仕組みを作れたかな、と思っています。いうわけで、今年もこんな感じで適当に間を空けつつ続けられれば良いなあと思いますので、引き続き宜しくお願い致します。DXザイアサウザンドライバーソースコード最後に参考としてソースコードの全文を掲載しておきます。プログライズキー側です。ボタン操作による状態遷移管理。}}続いてプログライズライター側です。この定義だと再生曲数は255に限定されるので注意。容量的にそこまで使うことはほぼないと思われる。16MHzのArduinoなら10、8MHzのArduinoなら5ぐらい。1回のループでおよそ26μsになるようにIR_SHORT_DURATION_MICRO_SECを設定。この段階では、何もしない。日中は仕事があり、何度コメントを頂いてもすぐに返事できるものではありません。ご了承頂けますと幸いです。部品に変更はありません。使っているうちに、「SDカードへのMP3ファイルの追加・削除を何度も繰り返していると、どうもディレイが大きくなってくるようだ」ということが体感的にわかってきました。ネオディケイド・ネオディエンドライドウォッチを作っているときにそれが顕著に現れてきました。理由は不明ですが、以後はディレイを感じるようになったら、一度SDカードを上書きフォーマットして真っさらにしてから、改めてMP3ファイルの全コピーを行うようにしています。これで極端に大きなディレイが発生することはなくなった気がしますが、それでも多少のディレイは依然として発生するようなので、完全な対応方法は今も不明です。少なくとも自分の環境ではこれで多少マシになりますが、他の人の環境でも同様に適用できるかどうは不明ですので、ご了承ください。PMコメントの仕組みをわかっておらず、反映がなされていないと思い込んでいました。何度もコメントしてしまい申し訳ありません。返答を急かすつもりではありませんでした。返信ありがとうございます。いつも楽しく見させていただいています。SDカードにもキャッシュデータ的なものがあるのですかね。カードに対するアクションが内部に積もっているのかもしれません。素人なのでよくわかりませんが。何はともあれおかげさまで疑問が解決しました。この度はご返答ありがとうございました。参考にさせていただきます。様こちらこそ、コメントの仕組みがわかりにくいUIとなっており、申し訳ありませんでした。今回の件を受け、試験的にですがコメント受付の条件を緩めてみました。今は、即時反映になっていると思います。これでもしスパムや誹謗中傷が増えてしまうことがあれば、また元に戻すかもしれません。自分がMac環境だからかもしれませんが、SDカード上でファイルを削除しても、それが「SDカード上のゴミ箱」に入っているように見えます。それがなぜ影響してしまうのかはよくわかりませんが、それも含めて消そうと思うと、今のところ上書きフォーマットぐらいしか手が思いつきません。あと、使うモジュールを変えるという手もあるかと思います。DFPlayerの代わりに、今回プログライズライター側で初めて使用したMP3ボイスモジュールを使うとか。こちらは、容量が小さかったり、また開発環境によっては変な挙動を示すこともありますが、ディレイという点では今のところ体感ではあまり感じていません。今後、使用を重ねれば色々出てくる可能性もありますが。PM返信ありがとうございます。僕もわからないことだらけなので、やっぱり色々試してみようと思います。ありがとうございました。コメントをキャンセルメールアドレスが公開されることはありません。hidaka_hirojiAmazonほしいものリストこちら自身の工作用に使いたいものがメインですが、必ずしも工作に使うわけではないのでご了承ください。MUDAなことをしよう。