去年はご迷惑おかけして申し訳ありません。説明と現状報告をさせていただきます。
ゲーム開発者様向け情報#developer作成中
CASシステムとは? †
踏むと反応するセンサーを横に並べたゲーム用自作コントローラー。プレーヤーは上に乗って横に動くことで、画面上のキャラクターを操作できる。主犯はcap。
去年完成予定だったが、設計ミス実験不足その他もろもろによって失敗。本当にすみませんでした。
CASはCapacitor-Array Sensorから。性能・特性すべてがカスなので無理矢理カスと読む。
アルミホイルで作った電極を用いた静電容量センサーを最大32個用い、センサー部最大長は約8m。
倍密度検出技術(大げさ…)により、(センサー数)*2-1の最大63位置の細かさで位置検出が可能。
ただし、センサー部が長すぎるので数を減らして運用予定。
なんとなく資料公開
添付ファイルにアップ
- ブロック図.png…CASの回路の仕組み。こんなの見るやつおらんだろうが。
- センサー構造.png…たぶん去年より分かりやすいセンサーパネルの構造図。
詳しい仕組みの解説ができたらアップする予定。
名前募集 †
CASじゃ中途半端なので、なんか面白いorカッコいい名前募集中
進捗 †
現在進捗率89%(気分ベース)
電波祭までには間に合わせるつもりですが、予定が遅れていることは認めます・・・。
細かいバグ取りに時間を奪われ、また、パネル増産も考えて進捗率を修正。
パネル増産しなければ+2%ぐらい。
(8/21)祝!本番用基板およびセンサーパネル仮配線にて、テスト成功!
(8/22)センサーパネル7枚中3枚を仮配線から本配線へ移行。出力コネクタ実装。センサーへの交流給電部、仮配線から本配線へ移行。シールド化。なかなか進まん・・・。
(8/26)再テストにより停滞していましたが、本日夕方から再開。制御プログラム更新中。
(9/10)中間報告。個人的に色々とあって更新停滞してましたが、生きてます。制御プログラムは恐らく正常に動作できるレベル(タイミングの問題は実機が完成しないと試験できない)。ハードには変更なし。
もう山場は越えているので更新ペースは落ちます。
(9/17)制御プログラムの出力系のデバッグ・テスト終了。出力系(スイッチ制御)に問題なし。
現状での位置読み取り速度(位置情報が送信される回数/秒)は約10回/秒と判明。遅いな・・・。やっぱCからアセンブリ化が必要か・・・。
(9/18~19)中間報告。制御プログラムにシステムバステスト機能を搭載。模擬エラーテスト。82C55 8bit x3パラレルインターフェース部の電力供給ルートを仮から本配線へ変更。および増強。ゲートドライブ電源の降圧改造中。
(9/19最終)なぜかポケコンへのプログラム転送が固まることが…。CASプログラムによる通信は問題なし。制御プログラムに手動制御コマンドを搭載。通信速度を4800bpsに引き上げてテスト。読み取り速度が20回/秒に向上。
(9/22)RS-232C通信のクラスをネットから拝借してテスト。しかし、バグだらけで使い物にならず・・・。
(10/3)全体接続テスト結果。
センサーパネル3枚中2枚は動作を確認。
3枚目はうまくいかず。ゲイン調整が必要な模様。もしくは配線が長いためにノイズを受けている。
PC→ポケコンの通信が不能。自宅での確認では動作。原因不明。
回路に軽度なバグを発見。正論理であるべきところを負論理にしていた。
(10/8あたり)C++での通信をテスト中
(10/11)C++による通信プログラムほぼ完成。ポケコン側プログラムの通信に問題判明。バッファにたまったデータの処理が変。
去年の失敗の原因 †
- CAS-ポケコン間のインターフェースの問題
インターフェースLSIやCPUのZ80、ポケコンの仕様、信号線の駆動能力やタイミングなどをよく把握せずに、標準的な回路とは違う回路を作ってしまったため、データのやり取りがうまくいかなかった。かつ、制御線の配線忘れ?
- センサーのインピーダンスが小さく、センサー駆動回路のインピーダンスが大きい
センサーを駆動するだけの電流を供給しきれていなかった。
- ノイズの問題
対策方法 †
- 標準回路の採用、バッファの追加
- 高出力のアンプの追加、低インピーダンスのパワーMOSFETスイッチの採用
- コンデンサの追加、閾値の微調整
現状・対策結果など †
- インターフェースについては正常な動作を確認しました。
- ブレッドボード上にて、実際より小さなインピーダンスの状態(実際のセンサー群合計の1/2に相当)で、接続されたセンサー数が実際の1/4の規模でのセンサー1個の駆動と検出の実験に成功しました。
- コンデンサ追加でノイズがある程度除去できることを確認しました。ただし、周辺回路との兼ね合いでパラメータの調整がシビアなため、単安定マルチによる信号整形に任せました。すでに実験済み。
状況報告まとめ †
- インターフェースの改良
→完了、テスト済み
- 電源構造の改良
→完了、負荷試験済み
- 発振回路の改良
→基板製作完了、調整中
- センサー選択用半導体スイッチのインピーダンスの低減
→完了、2.の実験時に実験完了
- 検出回路の改良
→基板完成、調整中
- 外装
→未定(面倒なのでダンボールか何かで)
- センサーパネル増産(少なくともあと2枚、できれば3枚)
→気合(実際は去年の余りをちょいちょい修正するだけ)
- 全体結線
→各基板間は配線完了、センサーパネルへのコネクタ搭載済み、パネル側のコネクタは未搭載
- ポケコン-PC間インターフェース改良(物理的強度の改良)
→ガムテでケーブルを固定
- プログラム
→去年のをそのまま利用。一部手直しが必要。これが面倒・・・。
新たな問題 †
- 検出部の調整がシビア・・・
→発振周波数の向上(センサーのインピーダンス低減)と高出力化でカバー。必要に応じて、センサーに並列抵抗追加でセンサー毎のゲインを調整
- MOSFETスイッチのゲートドライブ電圧がやたら高い(最大定格越え)
トランスやコッククロフト型の倍電圧整流回路のレギュレーションの悪さを甘く見ていたようだ。無負荷時の電圧(ゲートに印加される電圧)は30V強、最大負荷でも25V程度・・・ACアダプタの表記は9V、ピーク値が12.7Vだから・・・ピーク値以上を維持してんな・・・
倍電圧整流をやめるか、無駄にレギュレーターで対処。
→倍電圧整流を廃止。必要なゲート電圧は確保できている模様。
- パネルによって閾値を変える必要がある(パネル特性がバラバラ)
→抵抗を挟んで調整予定
- 回路がつぎはぎ
ほっといてくれ
ゲーム開発者向け情報 †
CASを使ったゲームを開発する方に向けた情報。
ハードウエアの知識が必要になるので、そのまま使えるプログラム例をアップ予定。でもいつになるかは分からん。
内容変更中。まだ未完成。
- 通信方式
- RS-232C
詳細変更↓
4800bps
全二重通信(いつでも送受信可能)
ハードウエアフロー制御(CTS/RTS,CS/RSフロー制御とも)
パリティはeven
スタート/ストップビットは1bit
断線等を考えるとソフトウエアフロー[Xon/Xoff]がいいんだけど、通信速度が下がりそうなんで…
- データ構造
- CASから送信されるデータ
- 8bitのデータが一定間隔で勝手に送信される
下位6bitで位置を示す。上位2bitはステータス。
MSB上位← SSXX XXXX →LSB下位
XX XXXX:位置情報、0で検出なし、000001が左端、111111が右端
SS:ステータス。11で正常。01はエラー。10はスタンバイモード。00は未使用。
バッファが空であるのと見分けがつかない場合があるので、全ビット0のときは無視すること。
- CASへ送信する制御コード
- 通常、何も送信しなくていい。
特定のコードを送ると、スキャンが停止され、制御コードを受け取る体制となる。
手動によるマトリクススイッチON/OFFや、リセット命令などを実装。
命令表は作成中。
- その他
- 通信開始時にはRS-232Cバッファのフラッシュを推奨。
常にバッファの最終データを読まないと、過去のデータを読む可能性がある。
データの読み取り速度が20回/秒を下回るときは、バッファが空になるまで読み取る等で最後のデータを取り出す必要がある。もしくは、RTSをOFFにして送信を止める(RTSの制御はHSPだとできんっぽい)。
ポケコン側は割り込みではなくポーリング処理で通信している(割り込み処理する余裕は色んな意味でない)。
- プログラムについて深く突っ込む
- WinAPIを使う場合、フロー制御の設定がいろいろあるらしい。ソフトフローについては1種だが、ハードフローはCTS,RTS,DTR,DSRの4つ信号線を使う組み合わせができてしまうらしく、さらに1つ1つに制御方法が3種ぐらいあって・・・。
調査中。
かなり設定は流動的なんで、仕様が変わったらごめん。