« すごいぞスーパー・ありまろ | トップページ | 進捗 2006.09.09 »

2006.09.08

こんなことしてます

うう、みんな結構進んでるな。

私は長井用に制御系の改修中。

従来はこんな感じでした。(クリックで拡大)
Robo20060907_1操縦時の仕様は去年7月くらいから変わっていません。
通信は有線シリアルかWiportを使用した無線LANによるものとなっています。

自律デモ用は昨年秋の飛騨高山用に急遽こしらえたものです。 
miniSDに2分間の20ms毎の補間後モーションデータを格納しておき、PCからの通信と同じフォーマットで流すことでizCOREを騙します。

で、今作ってるのがこれ(クリックで拡大)。
Robo20060907_2_1izCORE部分は変わっていません。
従来の自律モードと同じように、miniSDを繋いだアドオンプロセッサを置き、補間後の各モーションデータをここに保管しておきます。こいつに外からコマンド(実際にはminiSDのアドレス(64KB単位))を送ってやればそのアドレスのモーションをizCOREに送ってやる手はずです。

これでかなり必要な通信が削減される(モーション再生中は通信が落ちていても再生し続ける)ので信頼性向上が図れるかと思いますが、その前段にさらに全力で通信をサポートするバッファ的プロセッサを置きました。

このプロセッサは基本的にはPCから受信した内容を下流にスルーするだけですが、通信が途絶えても2秒間は最後に正常受信したコマンドを下流に対して送ることを保証します。
通信断が2秒以上続くようなら下流には脱力コマンドを発行し、安全な形で待機させます。
もちろんその後通信が回復すればそのモーションを送ります。

これは今回、無線はZigBeeを使うつもりなのでその障害対策のためです。
(ヒロムロボにはWiportを置くスペースが無いのです...ま、Wiportも時々パケットが遅延したりするのでいずれはこんな感じにするつもりでしたが。)

これで、5個のAVRによるマルチプロセッサシステムとなります。 
なんかカッコいいぞ!

自律モードは基本的には飛騨高山とほとんど変わりませんが、前段に加速度センサをA/D変換で取り込んで転倒検知とそれに対する起き上がりモーションを発行するプロセッサを置いています。

飛騨高山でのAsso Di Fioriは実は自動起き上がりは出来ませんでした。
それでもなんとなく自動起き上がりっぽく見えていたのは、「走る」モーションの後は高確率で転ぶため、デモのシナリオとして「仕組まれた」ものでした。
走った後、逆にコケなければ突然のたうちまわります。

あと1週間ちょっとしかないや。
去年に比べて危機感が薄いような気がする。 

■宣伝協力■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
イコーぜ!長井!
いくぞタイガース & 走れ!ROBO-ONE弾丸吉日号 !
ROBO-ONE参加者じゃなくても観戦だけでもOK。
オジさんだって「青春」しようぜ! 合宿であの日の気分が満喫できます。 ゼヒ。
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

|

« すごいぞスーパー・ありまろ | トップページ | 進捗 2006.09.09 »

コメント

マルチプロセッサシステムかっこいいですねー
miniSDを使ったデータ格納は私もやりたいと思っています。
長井の宿でお時間があるときにでもとっかかりを教えてください。
SPI通信ができればよいのでしたっけ?

投稿: 人形つかい | 2006.09.08 12:27

人形つかいさんこんにちは。

SDはMMCの上位互換にあたるのでSPIでMMCのSPIモード用コマンドを投げればOKです。

私もこのあたり、1年くらい触ってないのですっかりブラックボックス状態になってます。
今回もこの部分はまったく触りませんでした。

当日、ソースとか印刷して持って行きますね。
その方が具体的で分かりやすいかと思います。
AVRのアセンブラですが、自分で分からなくなるのでコメントはバシバシ入れてますから流れは分かるかと思います。

投稿: いずみかわ | 2006.09.08 23:37

あ、私AVRのソースをみても多分何がなにやらでわからないと思います。(アセンブラはPICとZ80しか読めません)
ちょっと前にInterfaceかトラ技で特集があった(と思う)のですが、「結局何をどうすればつながるの?」状態でした。
次期メインCPUボードに選んだLinuxカードがメモリカードインターフェースを持っていないので、PICとminiSDを繋いでおいて、シリアル通信経由でデータを取り出せないかなぁ…と妄想しています。(今回は見送り)

私の手に余るようであれば、USBインターフェースが付いたLinuxボードに乗り換えようかと…

こんなレベルですので、いずみかわさんの説明についていけるかどうか微妙かも…

投稿: 人形つかい | 2006.09.09 00:24

いやいや、Z80が分かれば十分です。
Z80に比べればAVRは非常に分かりやすいですよ。 

それはさておき、人形つかいさんのまじかるコア、SPI使えますかね?
使えるのであれば話は簡単で、あとは決められたコマンドを投げてレスポンス待って、コマンド投げてレスポンス待って...というのの繰り返しになります。

実際にはコーディングの詳細より、
・初期化はこういう手順
・レスポンスの待ち方
・こういうコマンドを投げればこういうレスポンスが返ってくる
・データ読み出しの手順はこんな感じ
といったことが分かればそれで十分だと思います。

izCORE用のこのシステムでは4つくらいのコマンドしか使ってなかったと思います。

私が当時ハマったのは、このレスポンスってすぐには返ってこないんですよね。

ひたすらダミークロックを送ってポーリングしながら待つといった具合になります。
待ってる間に割り込みが入ってしまうとそのレスポンスを聞き漏らしたりすることもあるので、レスポンス待ちの間は割り込み禁止にしてたりします。
そこで困るのが、シビアなタイミング(例えばサーボパルス周期やパルス長計測)のためにタイマ割り込みをかけているような場合です。
RTOSの場合の処理がどうなっているのかは分かりませんが、AT90系AVR(今で言うとtiny級)で構成されるizCOREでは、他にもPCとの通信(それも結構な量)もしなければいけないこともあって、タイミング取りや余裕時間内での処理が難しそうだったので外出しにしてしまいました。
外部に出してしまえば、izCOREがサーボPWMを出力している間に次のレコードを読み出して、次のizCOREからの要求を待つということが出来ますので。

あと当時良く分からなかったのは用語かな。
R1レスポンス、R2レスポンス、R3レスポンスとかって、データシートには書かれてたり、各サイトのMMCコマンド解説なんかには書かれてたりするのですが、「何それ?」って感じで。

今のところ、このizCORE用のminiSDシステムにはFATのようなファイルシステムは実装していません。
AVRtinyクラスのプロセッサではSRAM(0~128バイト程度)が小さすぎて、512バイトのFAT情報を扱えないためです。

そのためデータは直接アドレスを指定して読み出しています。
例えば脱力は アドレス0x00010000、
歩行は0x00200000といった具合です。
実際のモーション指定は第2オクテットの指定で行うようにしています。
例えば歩行なら 0x20 とかいった具合で、上記アドレスからのデータが読み出されます。

簡単にいくなら「妄想」の通り、PIC等で組んで、外付けストレージ的にしちゃうのがよさそうですね。
アドレス指定でよければ、UARTで要求アドレスとサイズくらいを送って(簡単のためサイズは固定でもいいかも)そのレスポンスでデータをもらうようにするようなのは簡単に作れそうです。

ただし、アドレス直指定の場合はFATなどは使用しませんので、書き込む際にも指定アドレスに直書きします。
こちらの方は私はWin32APIでやっています。


最近では、CHANさんのページでMMCコマンドからFATまで一通りの解説とサンプルソース(こちらはCで)を公開してくださったので、参考になるかと思います。
http://elm-chan.org/docs/mmc/mmc.html

投稿: いずみかわ | 2006.09.09 01:30

CHANさんのページの紹介ありがとうございます。

今使っているL-CardはSPIを使えるのですが、次期コアのArmadillo-210はCPUのSPI信号が外に出ていないように思います。
(外部に出ているGPIOピンと共用になっていると良いのですが…)

ArmadilloにPIC16を繋ぐつもりでしたがSPI通信させるにはRAMが小さくてバッファリングが辛そうですね。
そろそろAVRかARM7に手を出さなくてはいけないのかも。

それでは長井で(というよりバスで)お会いするのを楽しみにしています。

投稿: 人形つかい | 2006.09.09 21:56

コメントを書く



(ウェブ上には掲載しません)




« すごいぞスーパー・ありまろ | トップページ | 進捗 2006.09.09 »