Brick Spine 2のＰＩＣコードを改良して、２つ以上の関節
を同時に動かせるようになったので、３点重心移動法で歩い
てみました。

http://www.geocities.co.jp/Technopolis/5834/index56.html

とってもロボットらしいカクカクした歩き方になってしまい
ました *_* 指令をもう少し早く送れると良いんですけど

> Brick Spine 2のＰＩＣコードを改良して、２つ以上の関節
> を同時に動かせるようになったので、３点重心移動法で歩い
> てみました。
>
> http://www.geocities.co.jp/Technopolis/5834/index56.html
>
> とってもロボットらしいカクカクした歩き方になってしまい
> ました *_* 指令をもう少し早く送れると良いんですけど

　Ｈｉｒｏｔａさん、先日はアドヴァイスありがとうございました。
作るまでには色々準備がありそうですが、まずは心の準備から。(^-^)

　８モーターあると４脚に２モーターずつ使えてイイ感じですね。
原理的に２モータ同時に指令を出すのは難しいと思うのですが、
どう解決しているのでしょう。　時分割とか、ラッチするとか…？？

　工作お疲れさまでした。またの 更新を楽しみにしてます！

> > とってもロボットらしいカクカクした歩き方になってしまい
> > ました *_* 指令をもう少し早く送れると良いんですけど

拝見しました。
抜き足、差し足、忍び足...て感じが悩ましいです。
特に、足をついた後、重心移動にカクッて感じが... (^^)

> 原理的に２モータ同時に指令を出すのは難しいと思うのですが、
> どう解決しているのでしょう。　時分割とか、ラッチするとか…？？

位置指定に16段階(4bit)、モーター指定に8チャンネル(3bit)だから、
残り1 bitを動作開始指令に使ったんですよね？

> 拝見しました。
> 抜き足、差し足、忍び足...て感じが悩ましいです。
> 特に、足をついた後、重心移動にカクッて感じが... (^^)
はは ^_^ もちょっとスムーズな動きを期待してたのですが。。。
１軸の指令に 0.1秒かかるので、全軸を一斉に移動させるところで、
８軸分 0.8秒 止まってしまいます 。

RCX Command を直接書いて送ることが出来る Brick Command
を使って 軸あたりの転送時間を 0.07秒に縮め、
歩き方のシーケンスも再検討しています。 もうちょっと
かっこよく歩いて欲しいですから。 （そのまえに真四角の
ボディをなんとかしたら？ と家内がゆってをります *_*）

Brick Commandはここで見つけました
http://www.geocities.com/Area51/Nebula/8488/lego.html

> 位置指定に16段階(4bit)、モーター指定に8チャンネル(3bit)だから、
> 残り1 bitを動作開始指令に使ったんですよね？
はい、ほぼその通りです。 １ビット使うのがもったいなかったので（せこい。）
モーター指定を ４bit （１６チャンネル）にして、１６チャンネル目の指令を
動作開始に使いました。 従って、RCX側はあと ７軸指令する余裕があります。
PICの I/O点数の制限で８軸になっているので、PICをもう一個足せば １５軸まで
いけます。 この拡張はやります。 （あー言っちゃった ^_^）

くるとんさん、コメント有り難うございます、はげみになります。

> １軸の指令に 0.1秒かかるので、全軸を一斉に移動させるところで、
> ８軸分 0.8秒 止まってしまいます 。

他のarticleで書かれた、動きをインテリジェンス化するのも、
一法ですが、動作中に次の動作指令を受け取れるようにする、
いわゆる"On the Fly"を実装するのはどうでしょう。

空チャンネルが、まだ、7chもあるそうですので、
「実行開始」（実装済み）
「動作完了まで待つ」
「無条件に0.1〜1.6秒待つ」（時間はポジションとして指定）
「即停止」
「バッファークリア」
などの、コマンド群をそこに割り当て、
未実行コマンド数を、センサー値としてフィードバックしてやる構想です。

ラジコンサーボには、Busy/Ready　Statusがないのが辛いですが、
消費電流を微分して、一定値以下になったことをもって、
判断すれば大体行けるんじゃないでしょうか？

RCXの方は、PICのコマンドバッファーを確認しながら、
オーバーフローしない限り、ドンドコ構わず、指令を書いていき、
各ステップ動作終了時に、次のステップの指令が転送し終わっていれば、
実効転送時間は０にできるという魂胆です。

PICに実装するのは結構大変そうですが、
インテリジェンス化より、汎用性、自由度は高いですね。

アドバイス有り難うございます。

> 他のarticleで書かれた、動きをインテリジェンス化するのも、
> 一法ですが、動作中に次の動作指令を受け取れるようにする、
> いわゆる"On the Fly"を実装するのはどうでしょう。
実は時間がかかっているのは指令の受信部なんです。 ＲＣＸの電圧を変更したときに
ＰＩＣが２回サンプリングして結果が同じなら採用という方法を取っているのですが
ＲＣＸの出力をある程度の時間保っておかないと、読み取りが安定しないのです。
割り込み処理を使うべきなのでしょうが、今までアセンブラレベルでの割り込み処理
プログラムを書いた事がなく、安直な方法を取ってしまっています。
（ＲＣサーボへＰＷＭを出力する際の ＯＮ幅の制御を正確にやらないと動作が
おかしくなるので、割り込みを使いくいとも思っています）

> 空チャンネルが、まだ、7chもあるそうですので、
これ！ これですよ。 そう言えば空いてた ^_^。 これと、下の Ｊｉｎさんの
コメントにある「ＥＥＰＲＯＭ − メモリに条件反射を記録」を組み合わせて −

今現在、軸番号１６の指令は無条件で動作開始なのですが、この時の
位置指令が無駄になっていますね。 で、１６個の動作を別の機能に割り振って、

例えば、
軸番号１６ 移動指令 ０ 移動開始
軸番号１６ 移動指令 １ 指令バッファの内容をメモリ １に書き出し
軸番号１６ 移動指令 ２ 指令バッファの内容をメモリ ２に書き出し
.....

軸番号１６ 移動指令 ５ メモリ１の内容を指令バッファに読み出し

のようにすれば、PIC16F84のＥＥＰＲＯＭ６４バイト÷8軸 ＝ ８パターンの
動作を ＲＣＸからあらかじめ送信しておいて、条件反射として利用する事
が出来ますね。（１軸あたり４ビットの指令なので、節約すれば１６パターン）

わはははは。 すごい ^_^

> インテリジェンス化より、汎用性、自由度は高いですね。
両立できそうです。

＊昨日はＶｅｒ２の基盤をはんだ付けしてナチュラルハイになってたところで
これを思い付いて 脳汁（エンドルフィンやら何やら）がでまくったのか目がさえて
しまってねらんなくなってしまいました ^_-

> 動作を ＲＣＸからあらかじめ送信しておいて、条件反射として利用する事
> が出来ますね。（１軸あたり４ビットの指令なので、節約すれば１６パターン）
>
> わはははは。 すごい ^_^

いやー、すごいすごい。
RCXから、ステップ動作をプリセットしてから、
実行できるようにするんですね。

> 実は時間がかかっているのは指令の受信部なんです。 ＲＣＸの電圧を変更したときに
> ＰＩＣが２回サンプリングして結果が同じなら採用という方法を取っているのですが
> ＲＣＸの出力をある程度の時間保っておかないと、読み取りが安定しないのです。

1ms単位の比較的安定した信号なのにちょっと不思議ですね。
割り込みまで使わなくても、Message Ball v2でやっている様に、
http://www.line.to/mac/MindStorms/mesball2/
TMR0をフラグ待ちで使い、0.1〜0.5msぐらいの間で、きちっと規制し、
かつ、これをRCXのPWM出力の立ちあがりエッジでリセットすると、
正確になるんじゃないでしょうか？

あるいは、TMR0をフリーランさせてしまい、
RCX PWMのエッジを検出したとき、カウンターを読み、
ポジ・ネガの差を取る方法が有効かもしれません。

> 1ms単位の比較的安定した信号なのにちょっと不思議ですね。
ざっとフローを書いて気が付きました。 こういう事だと思います。

ＲＣＸのＰＷＭ周期が８msec、ＲＣサーボのＰＷＭが1軸当た
り１−２ｍｓ、最悪の場合で ８軸分 １６msecかかります。
計24msec、２回読み込んで ＲＣＸの信号の変化
した瞬間の不安定なデータを捨てていますから、
これで ７２msec = 0.07sec 程度必要になります。

> かつ、これをRCXのPWM出力の立ちあがりエッジでリセットすると、
> 正確になるんじゃないでしょうか？
立ち上がりエッジを真面目に捕まえるプログラムを考え始め、
まず読み込みに８msec、最悪のケースで読み込み開始の待ち
時間 8msec、ＲＣサーボのＰＷＭは同じですから 16msecで、
この間エッジの検出ができないので、ＲＣＸの出力は 32msec
あれば良いことになり、約２倍の高速化です。
が、ＲＣＸの出力”８”にエッジが無い事に気が付いてしま
いました。。。

速度の問題は「条件反射」で解決する事にして、少しでも
ＲＣＸの出力を多く使えるように、 とりあえず現行の
ステータス式で読み込みを行おうと思います。
（安直な方にながれてをります。。。）

> ＲＣＸのＰＷＭ周期が８msec、ＲＣサーボのＰＷＭが1軸当た
> り１−２ｍｓ、最悪の場合で ８軸分 １６msecかかります。
> 計24msec、２回読み込んで ＲＣＸの信号の変化
> した瞬間の不安定なデータを捨てていますから、
> これで ７２msec = 0.07sec 程度必要になります。

あ、理屈に合っていたんですね。

でも、
すべてのサーボ出力をon;
count = 0;
do {
if (out1 < count) off1;
if (out2 < count) off2;
if (out3 < count) off3;
:
if (out8 < count) off8;
} while (++count < 2ms);

の形式で処理すると、サーボへの出力は2msで終わり、
残り、18msはRCXからの受信に専念できるんじゃないでしょうか？
countはtmr0のカウンターそのもので、
++countはハード的に行われますが...

> サーボへの出力は2msで終わり、
> 残り、18msはRCXからの受信に専念できるんじゃないでしょうか？

な、事言ったってこのループは時間的に厳しいんだぜ。
ジッターが出たら、位置決めがずれるやんけ、
と心配される貴兄に(^^;

実装例を披露いたしましょう。
4MHz 16f84でループは最短23usで回ります。
nopで31usに調整しましたが、分解能32 positionでも余裕なのです。

servo movf ch0,w
movwf cnt0
movf ch1,w
movwf cnt1
movf ch2,w
movwf cnt2
movf ch3,w
movwf cnt3
movf ch4,w
movwf cnt4
movf ch5,w
movwf cnt5
movf ch6,w
movwf cnt6
movf ch7,w
movwf cnt7

movlw 64
movwf olcnt
movlw 0xff
movwf outmask
movwf portb

outloop movf portb,w
andwf outmask
movwf portb
clrf outmask
decfsz cnt0,f
bsf outmask,0
decfsz cnt1,f
bsf outmask,1
decfsz cnt2,f
bsf outmask,2
decfsz cnt3,f
bsf outmask,3
decfsz cnt4,f
bsf outmask,4
decfsz cnt5,f
bsf outmask,5
decfsz cnt6,f
bsf outmask,6
decfsz cnt7,f
bsf outmask,7
nop
nop
nop
nop
nop
nop
nop
nop
decfsz olcnt,f
goto outloop
return

> な、事言ったってこのループは時間的に厳しいんだぜ。
> ジッターが出たら、位置決めがずれるやんけ、
> と心配される貴兄に(^^;

みぬかれてますねー ^_^; でもクロック数の検討と
ふらつきの幅は検討しました。 一番気になったのは
たしか分岐命令が分岐したときとしなかった時で
必要クロックが違う事だったのですが、それがあっても
いけそうだな− とも思いました。

で、まだ迷っている理由は − 「シンクロ無しでは
デバッグが厳しい」からです *_*

> 実装例を披露いたしましょう。
こっこれはー！！ ありがとうございますー。
実は、トロント大学でのデモに向けて少し時間的に厳
しくなっていますので、先に「動く物」にしてから拡張
させてください。 （基板の更新、条件反射、機体の
改造、タッチセンサ拡張、歩く以外の動作 を予定しています））
ＰＩＣのプログラムは毛のはえない素人なので、大改造
やって動かなくなるとお手上げなんです。 （ナサケナイ）

以下、ＰＩＣプログラムのディレクトリにしっかり
セーブさせていただきました。 ありがとうございます。
>
> servo movf ch0,w
> movwf cnt0
> movf ch1,w
> movwf cnt1


基板を工作中です。 これで動いたら、誰でも作れるように
なりますね。
-> http://www.geocities.co.jp/Technopolis/5834/index56.html

> みぬかれてますねー ^_^; でもクロック数の検討と
> ふらつきの幅は検討しました。 一番気になったのは
> たしか分岐命令が分岐したときとしなかった時で
> 必要クロックが違う事だったのですが、それがあっても
> いけそうだな− とも思いました。

普通のCPUの条件分岐命令は、status registerの各ビットがセットまたはリセットされている時、指定された番地にジャンプする機能をもっていますが、PIC12/16シリーズは、これに対しまったく違うアプローチをしています。

1. 指定したデータ番地の指定したビットがセットされている時。
2. 指定したデータ番地の指定したビットがリセットされている時。
3. 指定したデータ番地をデクリメントしたら0になった時。
次の命令が何であってもnopを実行し、条件がそろわないと次の命令を実行する。
という、3つの命令しかありません。

PICを理解する最重要点であり、逆に一般のCPUを使っている方が分かりにくいと思うのはここだと思っています。

どうしてこんなアプローチになったのか、ソフト屋的には意味不明かもしれませんが、ハード屋的には、大変明快かつ画期的な命令体系のReduceです。

一般のCPUと等価の処理をするためには、データ−番地にstatus registerを指定し、次の番地にgoto命令を書けば良いのですが、これではPICをカリカリに使う事はできません。

極論すれば、条件準備にstatus registerを使わず、かつ、条件分岐後に実行する命令を1つだけに、どうしたら追い込めるかが、カリカリチューンアップのポイントなのです。

もちろん常にカリカリに使う必要はなく、ここ一番ぶんぶんに回したいポイントに限定すれば良いのですが、プログラミングと言うより「パズル」的楽しみがあり、はまるとそこら中でやってしまい、「PICのアセンブラは理解しづらい」と、一般プログラマーに言われる事になります (^^;

> どうしてこんなアプローチになったのか、ソフト屋的には意味不明かもしれませんが、ハード屋的には、大変明快かつ画期的な命令体系のReduceです。

一部ハード関係者以外には余計意味不明なので補足しましょう(^^;

CPUの高速化にはpipe line化というテクニックが一般に使われます。
CPUは大雑把に言って、(1)命令をメモリーからもってきて、何をすべきか判断し、(2)その判断にもとずいて実際仕事をする、という動作を繰り返しています。
この作業をを分業化し、係りのものが2人で流れ作業をするのがpipe lineです。

普通の作業は、命令が並んでいるとおり順に実行されるので、この「ベルトコンベアー」はスムーズに流れるのですが、分岐命令は大変に都合が悪いです。
分かりますよね。折角係り(1)の者がした作業が無駄になるだけでなく、新たに別の場所から、係り(1)が命令を取り出し、作業終了するまで、係り(2)は、休憩に入ってしまいます。

これでは高速化の目論見が破綻するので、他のCPUでもいろいろ作戦を立ててます。
1. 分岐命令の次の命令を無条件に実行してしまう。
遅延分岐と言います。分岐の結果が反映されるのは次の次になるんです。
人間業で、最適化するのは相当難しいです。
2. どっちの分岐が起こるか予測し、それを取りこんでおく。
博打に出るわけですね。はは(^^;

これに対し、PICの戦術はpipe lineをnopにクリアーするだけ...
うー、なんてチープな解決。
私こういうの、好きですね (^o^)

おまけに普通のCPUは分岐先の指定が命令コードの中にあり、
また、分岐条件はCPU内のcondition registerなので、
データーメモリーのアクセスがありませんね。

データーメモリーとプログラムメモリーが別になっているハーバードアーキテクチャを取った、PICでは、データーメモリ／バスが、ひまになり、もったいない話です。
と言うわけで、データーをアクセスする構造の分岐命令にしたんですね。

> これに対し、PICの戦術はpipe lineをnopにクリアーするだけ...
あれはパイプライン処理だったんですか o_o
IntelなんかのでっかいＣＰＵ専用だと思ってました。

ＲＩＳＣチップうんぬんってＰＩＣのデータシートに
書いてあったのを「まーたまた、”減らした”じゃな
くて ”最初から少ない” じゃないの？」 なんて思っ
てたのですが、真面目に作ってあるんですね。

> > これに対し、PICの戦術はpipe lineをnopにクリアーするだけ...
> あれはパイプライン処理だったんですか o_o

PIC16F84のマニュアル10pageの
EXAMPLE 3-1: INSTRUCTION PIPELINE FLOW
図辺りを見ると明らかですが、2段pipe lineです。

> 真面目に作ってあるんですね。

でも、真面目かどうかはアヤシイですよ(^^;

fetch/execは、パイプラインでないCPUだって、
別のハードウエアーになっているわけで、
敢えてこれを2段パイプラインと呼ぶかどうかは、
分岐をどううまく処理して、
何事もなかったように処理をつずけさせるかだったりしませんか？
それをこんな裏技で避けちゃっているんじゃ(^^;

Jinです。

> 基板を工作中です。 これで動いたら、誰でも作れるように
> なりますね。
> -> http://www.geocities.co.jp/Technopolis/5834/index56.html

拝見させていただきました〜。 手作り基板いいですね〜。
こういうのを見ると、作りたくなります。

と同時に、エッチングして基板を作るのも挑戦したくなりますね〜。
基板が量産できれば、組み立てるのも簡単ですからね〜。

トロントでお目にかかるときが楽しみです。

> RCXから、ステップ動作をプリセットしてから、
> 実行できるようにするんですね。
そうです。 これなら汎用につかえますし。

> 1ms単位の比較的安定した信号なのにちょっと不思議ですね。
言われてみるとその通りです。 ”動けば良し”のつけですね。

> TMR0をフラグ待ちで使い、0.1〜0.5msぐらいの間で、きちっと規制し、
> かつ、これをRCXのPWM出力の立ちあがりエッジでリセットすると、
> 正確になるんじゃないでしょうか？
ちゃんと立ち上がりを待つべきでした。 真面目にプログラムします-。

というわけで久しぶりにフローチャートをかいております。

Jinです。 早速拝見させていただきました〜。
サーボモーターの音いいですね〜。 動きも RCXとの I/F を考えると
いい感じじゃないでしょうか

なんだか、ここまで来ると、RCXと言う制約も外してやりたくなりますね。
ただ、RCX CODEなどでプログラムできるというお手軽さなどはいいですよね。

> サーボモーターの音いいですね〜。
”しゅいいいん” ^_^

> ただ、RCX CODEなどでプログラムできるというお手軽さなどはいいですよね。

そうなんです。 PICのみにすると、プログラムの変更が大変ですし、センサー用の
Ｉ／Ｏも足りません。 どっちかというと、ＰＩＣのプログラムをインテリジェント化して、
「１歩け」、とか「回れ」というような形にすると、動きもスムーズに高速化できそう
す。 （条件反射の作りこみですね）

が、これをやると、ＰＩＣプログラムの改変無しには他の用途（ロボットハンドなんか）
に使いまわしが出来なくなるんで、 「んー どうしょっかなー」 です。

当面は、ＲＣＸから各軸移動指令で作りこんでいきます。 Ｔｏｒｏｎｔｏ Ｕのイベント
でデビューが目標です。

Jinです。
> どっちかというと、ＰＩＣのプログラムをインテリジェント化して、
> 「１歩け」、とか「回れ」というような形にすると、動きもスムーズに高速化できそう
> す。 （条件反射の作りこみですね）

やはり脊髄ユニットとして、将来的にはその線が楽しみですよね。

> が、これをやると、ＰＩＣプログラムの改変無しには他の用途（ロボットハンドなんか）
> に使いまわしが出来なくなるんで、 「んー どうしょっかなー」 です。

RCX側から、命令をあるプロトコルトで 脊髄ユニット に転送して
脊髄ユニット側はその命令を見ながらモーターを動かす感じにすると良いのでは。

MIT のクリケットの回路図が
http://fredm.www.media.mit.edu/people/fredm/projects/cricket/techtalk/logocore.html

にありますが、外付けの EEPROM などを付けて、そこに命令をダウンロードして
PIC側はそこに書かれた命令を読んで実行していくなんて、いいんじゃないで
しょうか？


> 当面は、ＲＣＸから各軸移動指令で作りこんでいきます。 Ｔｏｒｏｎｔｏ Ｕのイベント
> でデビューが目標です。

ですね〜。 自分も時間作って、脊髄ユニット作りたいです。 PICなどでも
C言語も使えるから、インタープリターなど作るのは難しくないと思います。

いや〜、なんだか、そっちの方にいきそうだな〜、今年は。 （＾＾）