去年はご迷惑おかけして申し訳ありません。説明と現状報告をさせていただきます。

ゲーム開発者様向け情報#developer作成中

現状まとめ

センサーパネル5枚(20センサー、39ポジション分)中4枚の正常動作を確認。
どうも端のセンサーへの配線が断線していたらしく、両端のセンサーが反応しなかったが、片方は修理済み。
あと、自宅で動かすとノイズが殆どない。やはり部室はPCのノイズが激しいのか、鉄筋か何かの影響を受けているのか・・・。
通信は最低限(位置情報読み取り)のみ完成。
エラーテストを一部実装。コネクタの接触不良が分かってとっても便利。

残りの作業まとめ

CASシステムとは?

踏むと反応するセンサーを横に並べたゲーム用自作コントローラー。プレーヤーは上に乗って横に動くことで、画面上のキャラクターを操作できる。主犯はcap。
去年完成予定だったが、設計ミス実験不足その他もろもろによって失敗。本当にすみませんでした。
CASはCapacitor-Array Sensorから。性能・特性すべてがカスなので無理矢理カスと読む。
アルミホイルで作った電極を用いた静電容量センサーを最大32個用い、センサー部最大長は約8m。
倍密度検出技術(大げさ…)により、(センサー数)*2-1の最大63位置の細かさで位置検出が可能。
ただし、センサー部が長すぎるので数を減らして運用予定。

なんとなく資料公開
添付ファイルにアップ

名前募集

CASじゃ中途半端なので、なんか面白いorカッコいい名前募集中


進捗

現在進捗率95%(気分ベース)
電波祭までには間に合わせるつもりですが、予定が遅れていることは認めます・・・。

(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++による通信プログラムほぼ完成。ポケコン側プログラムの通信に問題判明。バッファにたまったデータの処理が変。 (10/12)バッファの問題解決。通信に問題なし。
(10/13)第3次ぐらい動作試験。パネル毎のゲインの調整は3枚でテストしたところ必要なし。
両足導通問題発覚(「新たな問題」参照)。
細かいバグを修正。
それ以外は正常。パネル3枚とも正常に反応。双方向通信も問題なし。
正確な読み取り速度は27回/秒と判明。まあ十分か。
ポケコンへのプログラム転送の問題の原因が判明。単なる非同期通信の設定ミス。

去年の失敗の原因

  1. CAS-ポケコン間のインターフェースの問題
    インターフェースLSIやCPUのZ80、ポケコンの仕様、信号線の駆動能力やタイミングなどをよく把握せずに、標準的な回路とは違う回路を作ってしまったため、データのやり取りがうまくいかなかった。かつ、制御線の配線忘れ?
  2. センサーのインピーダンスが小さく、センサー駆動回路のインピーダンスが大きい
    センサーを駆動するだけの電流を供給しきれていなかった。
  3. ノイズの問題

対策方法

  1. 標準回路の採用、バッファの追加
  2. 高出力のアンプの追加、低インピーダンスのパワーMOSFETスイッチの採用
  3. コンデンサの追加、閾値の微調整

現状・対策結果など

  1. インターフェースについては正常な動作を確認しました。
  2. ブレッドボード上にて、実際より小さなインピーダンスの状態(実際のセンサー群合計の1/2に相当)で、接続されたセンサー数が実際の1/4の規模でのセンサー1個の駆動と検出の実験に成功しました。
  3. コンデンサ追加でノイズがある程度除去できることを確認しました。ただし、周辺回路との兼ね合いでパラメータの調整がシビアなため、単安定マルチによる信号整形に任せました。すでに実験済み。

状況報告まとめ

  1. インターフェースの改良
    完了、テスト済み
  2. 電源構造の改良
    完了、負荷試験済み
  3. 発振回路の改良
    基板製作完了、調整中
  4. センサー選択用半導体スイッチのインピーダンスの低減
    完了、2.の実験時に実験完了
  5. 検出回路の改良
    基板完成、調整中
  6. 外装
    →未定(面倒なのでダンボールか何かで)
  7. センサーパネル増産(少なくともあと2枚、できれば3枚)
    →気合(実際は去年の余りをちょいちょい修正するだけ)
  8. 全体結線
    各基板間は配線完了、センサーパネルへのコネクタ搭載済み、パネル側のコネクタは未搭載
  9. ポケコン-PC間インターフェース改良(物理的強度の改良)
    →ガムテでケーブルを固定
  10. プログラム
    →去年のをそのまま利用。一部手直しが必要。これが面倒・・・。

新たな問題

  1. 検出部の調整がシビア・・・
    →発振周波数の向上(センサーのインピーダンス低減)と高出力化でカバー。必要に応じて、センサーに並列抵抗追加でセンサー毎のゲインを調整
  2. パネルによって閾値を変える必要がある(パネル特性がバラバラ)
    →抵抗を挟んで調整予定→(10/13追記)あんまりいらんかも
  3. 両足導通
    片足から交流信号がもう片足に伝わって誤作動する。
    →スリッパ底上げで対処
  4. MOSFETスイッチのゲートドライブ電圧がやたら高い(最大定格越え)
    トランスやコッククロフト型の倍電圧整流回路のレギュレーションの悪さを甘く見ていたようだ。無負荷時の電圧(ゲートに印加される電圧)は30V強、最大負荷でも25V程度・・・ACアダプタの表記は9V、ピーク値が12.7Vだから・・・ピーク値以上を維持してんな・・・
    倍電圧整流をやめるか、無駄にレギュレーターで対処。
    →倍電圧整流を廃止。必要なゲート電圧は確保できている模様。
  5. 回路がつぎはぎ
    ほっといてくれ

ゲーム開発者向け情報

CASを使ったゲームを開発する方に向けた情報。
CASとの通信方法とか

C++によるプログラミング

cas.hとcasdef.hを同一フォルダに入れて、cas.hをインクルードする。
その中のCRs232cクラスを利用。
ゲーム中のみ通信開始にして、通信中は定期的にデータを取得しないと、 バッファにデータがたまってしまうので注意
処理の流れとしては…

プログラム起動
 ①通信準備
↓
ゲームスタート画面とか
↓
ゲーム開始
 ②通信開始
↓
ゲーム中
 ③データ受信
↓
ゲーム終了(ステージ終了とか)
 ④通信停止
│
├→ゲームスタート画面とか
↓
プログラム終了
 ⑤CAS終了

①通信準備

プログラム初期化時とかにこれを実行。
portはcomポートの番号でint型。ポート番号は何らかの方法で切り替えられるようにしてもらえるとありがたい。
これを実行すると、comポートを初期化し、CASを待機モードから通常モードへ切り替える信号を送る。通信は停止される。

CRs232c r232;
int temp0;
temp0=r232.start_cas(port);
if(temp0!=0){
	//エラー処理(temp0を表示する)
}

②通信開始

ゲームがスタートしたら、これを実行して通信を開始。データが一方的に送られてくる。

int temp0;
temp0=r232.cas_on();
if(temp0!=0){
	//エラー処理(temp0を表示する)
}

③データ取得

位置情報がint tの下位6bit(bit0~5)に入る。下位6bitが0でセンサー上に何もなし。000001で左。
bit6,7にはステータスが入る。11が正常。01は異常。10は待機(テスト)。この時点で11以外なら異常だが、待機時のテストでないとエラーが分からないのでエラー処理は付けてない。

if( r232.GetLInt(t) ){
	//エラー処理
}

④通信停止

 通信を一旦停止するとき。  int temp0;  temp0=r232.cas_off();  if(temp0!=0){   //エラー処理(temp0を表示する)  }

⑤CAS終了

プログラム終了時に必ず実行。

int temp0;
temp0=r232.end_cas();
if(temp0!=0){
	//エラー処理(temp0を表示する)
}

トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS