発見！うれし〜

新サーボ制御ソフト・アナログサーボ接続テスト

アナログサーボにしてみたら
Pirkus-Rをつないでいる時は気づかなかったのですが、サーボが振り切るところがあることがわかりました。 MICRO-MGに繋ぎ変えているときに、じわっじわっとサーボ角度を動かしてくと、急にぎゅ〜んと振り切るところがあります。 うわ〜、なんでだろう、このサーボ、壊れてるのかな？

と、思って見てたら、ごめんなさい、サーボは壊れていませんでした。いつも幅の大きい方に振り切るんですね。 しかも安定して。再現性あり。というわけで、再びペン型オシロを引っ張りだしてきて（あまり当てにならんやつなので、 いつか、自分でロジアナ作ろうと思っているんですが）、信号をチェックしていたら、「2.7ms」のパルスが出ていました…。 すまん、ペン型オシロ、君は役に立っているぞ。

Pirkus-Rは、PWMのリミッタ−がついていて、それを超えると動作しないようになっているんですが、対してMICRO-MGはとっても素直。 なるほど。異常パルスが出た時に、Pirkus-Rでは、見た目、何も起こってないように見えたんですが、実はそういうことが起きていたわけですね。 ふむふむ。というわけで、これからは両方接続してテストすることにします。

それはそうと、なんで「2.7ms」がでてくるのかな？とコードを調べ始めると…この領域になってくると、 エミュレータじゃどうにもならないので、再現性の確認と、状態チェック。

なるほど。

	while( MM.GIP.SRV[MM.GIP.bSrvIoOpeIdx].CTL.bClk >= TV.TCNTV );
	

実は、こんなコードで信号オフのタイミングを待っているのですが、なんと、この処理、一周するのに4.8usもかかることがわかりました。 ということは…

1. 0xFFで信号オフしたい。
2. 最初に変数チェックしたら、0xFEぐらいだった。
3. 次に見たら、0x0Aだった…。

幸運なことに、タイマーＶには、もう１つコンスタントレジスタがついている（２つあります）。 そんなわけで、またまた一致フラグを使うことにしました。先割り込み時間も、ちょっと処理が増えたので、 10usから20usに出血大サービス（あまり増やすと、メインルーチンが動きません）して…お、いい感じですね。 というわけで、後は、ProBo信号解析処理とセンサ処理の組み込みをします。これが完了すれば…

タイマＶだけでサーボ制御とプロボ信号解析とセンサ平均化処理

の完成です。こっちの処理は、もともとの処理をちょっと改良するだけなので、割とすぐできそうです。 この調子なら、今週末には完成しそうです。 まずは、G-Tune2004FIIのSIPHA COREをAKI-H8/3694に換装してテストをしてみようと思っています。楽しみ〜。

新サーボ制御ソフト・だんだんいい感じ

大きめに震えるのは…
原因わかりました。オフ処理が１割り込み処理中のお尻のほうのタイミングの場合、オン分の遅れを入れ込むと、 はみ出す（実際には１バイト変数なので、前に戻る）ことがわかりました。うぐっ。初歩的ミス。 簡単に言えば、カウンタが0xFFでオフ予定だった信号に、「オンのズレ分の４カウント」を追加すると、0x03になってしまうのです。 あはは。浅はかでした。

というわけで、次のステップ（割り込み）にすればいいや〜、と思ったわけなのですが、そうすると、ケースによっては、 「オフタイミングを離す」という条件から外れることになります。どうしよう…。ならば！102.4usを１ステップとして…

• 最初に、サーボ信号オフタイミングが１ステップおきになるようにスケジュール。
• オンするタイミングが重なっている信号にオフセットを加える。
• これで必ず１ステップ以上、ずれることになる。めでたしめでたし。

という作戦で行くことにします。はっ、待てよ…。そうすると、４信号扱うということは、最大７ステップ広がることになります。 ということは、

「信号最小値の600us内に納まらない」

あらら、がっくり。…というわけで、しょうがないので３信号１組で扱うことにしました。これなら、最初の0msでスケジュール、 0.1024で最初の信号オン、0.3072msで次、0.5120msで最後、そして最初の信号オフ処理を0.6144msで開始することができるようになります。

ん？それってひょっとして…３信号用のスケジュールプログラムに変更してみました。あらら、あっという間に30usですよ。 今までの苦労って…。

そうだ、ここでこれを使うんだ！

○|￣|＿

新サーボ制御ソフト・なんとなく動き始めました。

と、きついきついとうなっていても何も面白くないので、負けじとプログラミングです。

大方いい感じ、でもちょっと問題あり。
というわけで、信号オンからオフまで、一通りのコードを書いてみました。まずはペン型オシロを繋いで信号チェック。 このペン型オシロで見ていると、どうも信号幅が広くなったり狭くなったりしているように見えるのですが、 ま、もともとそんなに解像度があるものではないので、気にしない、気にしない。 信号がだいたい出ているのがわかれば、ぐらいに使っています。

それっぽい信号が、それっぽい間隔で出ていることを確認したら、いよいよサーボ接続。軽く一発動作！ よしよし、快調快調…と思いながら、今度はゆっくり首振りするプログラムを入れてみる。 う〜ん、なんか、サーボがひっかかるような動きをするところがあります。また、時々、びくっとやや大きめに震えます。

サーボの動きが引っかかる
…と値を地道に１つずつ変化させて観察していたらわかりました。信号オフタイミングが割り込み直後だった場合に、 割り込み開始分だけ遅れることがわかりました。そりゃそうだ。 というわけで、カウンタがオーバーフローするうんus前に割り込みをかけるようにし（レジスタを使うとできます）、 タイミングを待つようにプログラムを変更です。

具体的には、もともとオーバーフローで割り込みをかけていたのを、10usだけ早くオーバーフローより早く割り込みがかかるようにしました。 タイマーＶには、コンスタントレジスタというのが２つついているのですが、ここに値を設定しておくと、 一致した時に割り込みがかかるようになります。それで、3usぐらいで割り込み処理に入って、 ちょっと準備すると10usでちょうどいいかな〜ということでして。これで、ぴくっというのは無くなりました。よしよし。

ロボコンマガジン No.40
amazon.co.jpで、ロボコンマガジン購入。 今回、miniSDメモリが欲しかったのでそれと一緒に（他のネットショップでもありますが、送料がただになる分、実は安かったので）購入。 ちょうど真中あたりを読んでいたらROBO-ONEとJ-Classを観戦した話がポツンとあって… 「外観からはとてもヒューマノイドとは思えないサイコロみたいなロボット」…やはり、これはG-Tuneのことでしょうか。 確かに、白と黒でサイコロに似ているかも…（ヒューマノイド型は意図的にはずしてますけど、はい）。

新サーボ制御ソフト・信号オンに必要な時間

昨日は眠ってしまいました…
う〜ん、深く眠れます…。昨日は、結局、夜デバッグもせず、朝も起きれず、ふか〜く、ふか〜く、眠ってしまいました。 とほほ。最近、血圧が低い（上が９０ぐらい）せいかな〜。前は９９とか１００とかあったんですが…。 でも、ROBO-ONEやっている人って、普段、血圧が低そうな人が多い気がする（試合中は別）。

という話はおいといて、楽しい！話。えまのんさんから救援物資到着。いや〜、まさしく救援物資です。 ありがとうございます。助かります〜。嫁さんは、このABSの固まりを見ると、いつも「白チョコみたい」と言い、 手にとって不思議そうに感触を確かめます。

次は信号オン
さてと、新サーボ制御ソフトのほうです。スケジューリングができるようになったら、今度は信号オン処理です。 試しに、まずは計測。コードはこんな感じです。ちょっとややこしいコードですが、構造体配列にインデックス変数を渡して、 それとORを取って、インデックス変数をインクリメント。

	*( MM.GIP.SRV[MM.GIP.bSrvIoOnIdx].CTL.pSrvIo->pbAddr )
	        |= MM.GIP.SRV[MM.GIP.bSrvIoOnIdx].CTL.pSrvIo->bOn;
	MM.GIP.bSrvIoOnIdx++;
	

これ、どれくらいかかると思います？うへ。約4usでした。うわ〜、ちょっといろいろやってみたのですが、 2usぐらいまでしか速くなりません。う、予想外…（って、最初にチェックすべきであった、う〜ん）。 信号オン処理なので、絶対に重なるタイミングあるしな〜。 アクセスしやすいようにI/Oを並べると自由度が減るしな〜、ということで…。

あきらめます。

でも、ただで全部をあきらめるわけではありません。「オンの遅れを見越して完了を遅らせる」のです。 そうすれば、ジッタは出ないはずです。しょうがないところはしょうがないとして、 今度はオフ側で吸収することにします。これから、信号オフの方のコードも書いてしまって、 一度動かしてみることにしようと思います。

新サーボ制御ソフト・信号計画部分高速化

ちょっと荒業でlongアテコミ
さてと、処理の分割（２回の割り込みに分ける）というのも早々に考えたのですが、ハタとバブルソート内の入れ替え処理が目に止まりました。 サーボ制御値だけ入れ替えると、どの信号がどれだかわからなくなってしまうので、一緒に、 「どの信号ですよ〜」という情報も入れ替えているのですが、ここは速くできそう。 移し変えたいデータのサイズを合計すると４バイトです。ということは…

long型で一気に入れ替え！
常識のある方はマネされない方が…。

ができます。さっそく構造体内のメンバーの順番を入れ替え、unionを使ってlongに当て込み、long型の変数で一気に入れ替えるようにしました。 いや〜、H8/TINYのアドレスが２バイトでよかった。昔、超有名なソフトウェアのソースコードで、こういうコードを見たことがあります。

むむむ、来ましたよ。一気に150usです。

100usで割り込むのはアキラメ
さらにもう一声、ということで、100usで管理するのはあきらめました。といっても、時間を延ばすのが目的ではないです。 今まで、人間がわかりやすいように、100us単位で割り込みをかけるようにしていて、当然、どの割り込みの何クロック目で、 という情報も100us単位だったわけなんですが、しょうがないので、コンピュータにとって得意なように、 102.4us単位にすることにしました。

要は…例えば、2048というデータが入ってきた場合、今まで、20と48という風に分けていたんですが、 このデータを作るためには「2048を100で割る」という処理が入ります。これをあきらめて、8と00にするようにしました （2048は、16進数で0x0800）。これで、「100で割る」という処理分だけ、高速化できることになります。

さて、結果の方は？おお、120usでいけますね〜。でもまだまだです。じゃあ、次は…

for文の比較部分
さてさて、もっと頑張らねば、ということで、今度は、"for"文に目をつけました。簡略化するとこんなソースコードがあります。

	for( a = 1; a < ( b-1 ); a++ ){
	...
	}
	

これ、ソートとかに良く使う文なんですが、確か…for文の条件判定のところで"b-1"のような、演算するコードを書くと、 毎回演算することを思い出しました。そりゃそうですよね。プログラムがそうなっているんですから。というわけで、これを

	signed char c;
	c= b-1;
	for( a = 1; a < c; a++ ){
	...
	}
	

お、なんか急に速くなったぞ。100usをきりそうです。対象となるデータは４つだけ。いっそのこと、 for文をやめたらどうなるかな？というわけで、４回単純に回るだけのfor文は全部やめて、ベタベタとプログラムを書いてみました。 結果は、なんと、80usです。お〜、やる気が出てきました。でも、プロポ信号解析処理も入れようと思うと、まだまだです。

さらにfor文削除
調子にのって、全部for文を削除してしまいました。とはいえ、時として、 ４つのサーボ制御信号を、時には３つのサーボ制御信号（１つは出力オフ）を、なんてことが必要なので、 可変にしておく必要があります。というわけで、全部、"switch"文にしていまいました。結果は…。

50us達成！

やった〜。このアイデアは成立しそうです。…ROM容量が少し心配になってきました…。

ここのところ毎日見てしまうページ
アップされてから、なぜかほとんど毎日見ているページがあります。 イカさんの「ロボワンへかけろ！」の「臨時日記・2005.06.11 今日の出来事」です。 ここを見ては「イカで〜す（かわいいアンブレラ風）てっくてっくてっくてっく、ひょ〜っ」と頭の中でやってます…。

新サーボ制御ソフト・まずは信号計画部分を…

100usって短いよ…
というわけで、新しいサーボ制御ソフトの構想ですが、「タイマＶを使ってサーボ制御信号を作る」、「プロポ信号解析処理も一緒にやる」、 「ついでにセンサー値の平均化もする」というのを実現しようと思います。 タイマＶは、タイマＷほど便利なタイマではないことから、いろいろ考え込んでしまいました。 充分な分解度を得ようと思うと結局は、８ビットが故、0.1024msまでしかカウントできません。
というわけで、ちょっと無茶苦茶っぽいですが、100us毎に割り込みをかけ、必要な処理をすることにします。 う〜んと悩んでいるうちに、ジッタフリーに近づくためのおもしろいアイデアを思いつきました。それは…

です。おお〜、これはすごい。今までの経験から、信号オンよりもオフの方が難しいです。 というのも、オンの方は、「うぉりゃぁ」とオンすればいいのですが、オフとなると…そもそも、いつオフするかなんてことは、 サーボ制御プログラムだけからみたら、実行して初めてわかるようなことなんで、それに加えて割り込みなどでタイミングを計った後、 いろいろチェックしてから「えいっ」とやるわけです。数マイクロ秒オーダーで考えると、 結構、ここを安定した時間でやるのは難しかったです（それをやろうとしたのが現行です）。 何しろ、単純なif分１ついれるだけで、１us近く使いますから。

とうわけで、信号オンする前に、「サーボ信号幅によるソート」をして「オフタイミングが近くなりすぎないようにオンタイミングを調整」、 そして「落ち着いて一個ずつ信号オフ」するようにしようと思います。 さらに、この隙間を縫えば、誤差50usぐらいで100us毎のインターバルな処理も可能になると思います。これでプロポ信号を読み取れます。

また、ずらす量ですが、割り込みを100usで入れようと思っていますので、これを基準としてシフトしようと思います。 例えば、1500usの信号を２つ出す場合は、「最初の割り込みで１つめオン、２回目の割り込みで２つめオン」とし、 1500usと1700usの信号を出す場合は、「最初の割り込みで２つともオン」とします。こうすると、オフのときに必要な間隔が開くはずです。

と、ここまでは、「新サーボプログラムを作ろう」と思ったときあたりから昨日ぐらいまでの話で、今日は、 プログラムがだいたい出来上がったということで、あれこれ試していました。 仕様としては、とりあえず、今のサーボ制御プログラムに習って、４つまで同時に制御することにしています。 また、「制御信号のオフタイミングを離す」ためには、ソートして再計画するのが簡単そうということで、ソートして、 100us単位でオフタイミングがずれるようにするようにしてみました。

…で速度計測してみたわけですが、いかんです。いきなり170usも処理がかかっています。 サーボ指示値をメモリからコピって、バブルソートをし、100usごとのステップ情報に分けるというコードを書いたのですが、 軽く目標値（50us）オーバーです。これでは、プロポ信号解析どころではありません。 １つの割り込みでさえオーバーしています。う〜ん。

新サーボ制御ソフト・現状のジッタ対策

SIPHA COREのジッタ対策
急に出張が入っちゃって、またまた一日空いてしまいました。いや〜、九州は遠かった…。

さて、前回、書きました「タイマＷによるサーボ制御」の最後に、「SIPHA COREでのジッタ対策」についてちょっと触れましたが、 今回は、そのお話です。

TSC16を動かしてみたことがある方はご存知かと思いますが、４つ１組にしたサーボ制御信号のうちのどれかが近づく、 もしくは同じ値になると、他の止まっている「ぷるっ」と震えます。 「 SISO-LAB不定期TOPIC Jun.2004」の2004.06.03に動画があります。 こんな感じでぷるっとなります。この時点で、ある程度の改良をしていますが、これをどうやったか？というところです。 ネタは既にSIPHA COREの解説のところでバラしてますが、もう少し詳しく説明します。
こうやってネタばらしをすると、次のアイデアが出てくるもんです。自虐かな？あはは。

割り込みの先取り（勝手語）
さてさて、前回の話で、４つ１組にしたサーボ信号をオフするタイミングで、信号幅の揺れがでるという話をしました。 じゃあ、どれくらいずれるか？というのを机上で考えてみると、こんなふうになります。

仮に、割り込みに入るのに3us、信号オフ処理が1us、抜けるのに3usかかるとします。 もし、４つとも同じタイミングでオフにしようとしたらどうなるでしょう？ なんと、最大、合計7usの処理が３つ（４つめの信号オフは、前に３回既に処理されていることになる）走っているわけですから、 合計21usの処理遅れが発生することになります。これだけ動くとサーボは約２度以上動いてしまいます。 逆にいうと、ロボットのホームポジションがこれにぶつからないようにしておけば、そんなに気になりません。 また、ホームポジション以外では、だいたいサーボは角度が常時変化させていますから、サーボによってはあまり目立たなかったりします。

しかしながら、サーボを高級化したり、動作を高速化させたりしていくと、それなりの精度が要求されてきます。 サーボの動きが良くなると、一瞬の「ガクッ」とした動きが不安定さにつながったりしてきます。そこで、「割り込みの先取り」を行います。

具体的には、信号オフ処理で割り込みに入った時に、もし、すぐ後に信号をオフする処理があれば、 最初の割り込みの中で時間が経過するのを待ちます。 そして、タイミングがきたら、その信号もオフしてしまい、新しい割り込みのフラグをクリアしてしまいます。 そうすると、後の割り込みは、最初の割り込み処理を抜けても発生しません（他のCPUではわかりませんが）。

まとめると、以下のようなことをしています。

1. まずはとにかく必要なサーボ信号をオンする。
2. オフタイミングも、４つのレジスタにセットしてしまう。
3. その後、ちょっと落ち着いて、オフにしていくプランを考える。
   具体的には、４つある割り込みのうち、これとこれは１つ割り込みで処理するとか、その時、 どれくらい待ちを入れるとか（後述）。
4. 0.6msぐらいからサーボ制御信号オフ処理を始める。
5. 割り込みがかかったら指定のI/Oをオフする。
   先に決めたプランに従って、他のやつも一緒に落とすならば、割り込みから抜けずに待ちに入る。
   一緒に落とす信号があった場合、時間が来たら、「ほんとだったら割り込みで処理するのにかかる時間（オーバヘッド）」 分だけさらに待ち、信号をオフする。
6. 一通り終わったら、次のサイクルへ行く。

この、「ほんとだったら割り込みで処理するのにかかる時間（オーバヘッド）」を待つ処理というのが苦労したところで、 これが無いと、これはこれでジッタになってしまいます。そんなわけで、それなりに複雑な処理になってしまいました。 特にこのプランを作る部分がややこしいです。ややこしくて苦労した割には「もう一声！」な結果になっています。

さらっとアイデアメモ的に書きましたが、コントローラソフト自作＋外部回路無し派の方は、チャレンジされてみるとなかなか楽しいですよ。

新サーボ制御ソフト…H8/3694のタイマ

H8/3694のタイマについて
開発日記をつける！といいながら、いきなり一日空いてしまいまいした…。 アイデアはもやもや〜っとあったので、ぼちぼちコードを書き始めています。 なんとなく、これだけ書くのは忍びないので、H8/3694についているタイマについて解説します。 H8/3694（H8/3664も同じ）には３つのタイマがあります。 他にもWDT（ウォッチドッグタイマ）とかあるんですが、このあたりは用途が特殊なのでおいときます。

• タイマＡ
  ８ビットタイマ（０から２５５までしか数えられない）です。時計的なプログラムを作るのに 便利なタイマで、AKI-H8/3694ですと、時計用のクロックを入力してカウントアップなんて のもできます。でも、ひたすらインクリメント（１ずつ加算）するタイマですので、他に 何に使えるか？というと、時間待ちぐらいにしか使っていないタイマです。
• タイマＶ
  同じく８ビットタイマです。タイマＡと違うのは、レジスタが２つついてまして、ここに 値をセットしておくと、一致チェックを自動的にしてカウンタクリアしたり、割り込みを 発生させたりすることができることです。そんなわけで、制御には使いやすそう。ただ、 インプットキャプチャ（入力されたパルスの幅を計測する）に関しては、ハードウェア マニュアルを何度読んでもよくわからない。なんとなくできないような気がする。 できても１chかな。
• タイマＷ
  なんと１６ビットタイマです。さらに、レジスタが４つついてまして、ここに値をセット しておくと、一致チェックとか割り込みとかできます。また、インプットキャプチャも リッチにできます。当然、１６ビットのレジスタです。H8/3694で、主役のタイマと 言えると思います。それだけに、人気が高い…。あれもやりたいこれもやりたい。 でも、タイマＷはひとつ…。

それぞれのタイマは、CPUクロックを分周して入力することができます。 例えば、H8/3664(16MHz）で、タイマＶとかタイマＷに1/8のクロックを入力すると、１入力が0.5us（1/16000000*8）となり、２カウントで１usになります。 この場合だと、タイマＶの場合は、128us、タイマＷでは32768us（32.768ms）でカウントアップできるようになります。

タイマＷによるサーボ制御
というわけで、1us程度の分解度を維持しながら2.5msをカウントしようとすると、 最低でも5000はカウントできないといけないので、SIPHA COREでは、 タイマＷを使ってサーボ制御信号を生成しています。アルゴリズムは以下のようなものです。

1. サーボ４つを１組として扱う。
2. 2.5msでカウントアップする値をタイマＷのカウンタにセット。
3. 先の４つのレジスタにサーボ制御信号をオフしたいカウント値をセット。
4. サーボ制御信号オン。
5. タイマＷスタート。
6. レジスタ比較による割り込みを発生
7. 割り込み処理の中で対応するサーボ制御信号をオフ
8. 次組みの処理へ…

と書くと、簡単そうです。実際、ここまでは簡単で、TSC16でもこの基本的なアルゴリズムを使用しています。 ところが、H8/3694は、割り込み処理に入るためには、約うんusかかります。ハードウェアマニュアルを読むと、「１５〜２７ステート」とあります。 たぶん、この「ステート」というのは、CPUクロックと同じだと思っているんですが、だとすると、0.75us〜1.35us（20MHz）ということになるのですが、 実際にはうんusかかっている気がします。きっといろいろ準備があるんでしょう。 細かいところはよくわからないのですが（Ｃを使っているからかもしれませんが）、 実際に測ってみるとこんな感じです。

というわけで、サーボ制御信号を１つだけオフするだけならば、かならずうんusかかるので、 それはそれで安定するのですが、これが、信号オフタイミングが近くなってくると話が変わってきます。 もし10usも処理がずれたら、サーボは１度以上動いてしまうわけなんですが、このロジックは、ある条件下において、 このズレが発生してしまうという難点があります（これについては次回）。

S03Tとかで普通に動かしているぐらいだと、あまり気にならないんですが、 だんだん動きの正確さを要求する度合いがあがってくると（高速動作させるとか、いいサーボを使うとか）、 気になってきます。そんなわけで、SIPHA COREでは、「信号オフタイミングが近かったら、 割り込みをまとめる」という処理をしています（これがまた苦労したんですが…）。

ＬＢＣ
宮田さんが公開されている、 ＬＢＣというすばらしいコントローラがあります。これに関しては、上記のような心配はまったく不要です。 タイマＷには、「レジスタにセットされた値と一致したら信号をオフする」という機能がついています。 この機能は、I/Oポート４つに対してしか使うことができないのですが、 外部にロジックＩＣを追加して切り替えることで、このハード制御信号を増やして制御しています。 よって、制御信号オフそのものは、H8/3694に内蔵されたハードウェア（タイマＷ）が行いますので、 ジッタ（信号幅のゆれ）が発生しません。しかも外付け回路に一工夫いれて、 完璧とも言える制御を実現されています。

でも、ソフトで完全に制御し、超小型制御基板でロボットに実装、これまた浪漫です。 とかいいながら、とどのつまり、G-Tuneにはとにかくスペースがありません。 ちょっとあってもこれまた中途半端な隙間でして…。次のSIPHA COREは、50×35mm以下の実装を目指します。 これでサーボの稼働範囲もばっちり確保！のつもりです。G-Tuneは、ROBO-ONEの中では小型な方ですから、 サーボや他の部品との体積比は、コントローラボードがかなり大きくなると思います。 そんなわけで、コントローラボードも小型を目指さないとね！なのです。

というわけで、実装サイズに問題がない場合、無理にソフトのみで制御する必要は無いと思います。 でも、こういうアプローチもおもしろいと思いませんか？（苦手なハンダ付けが少なくて済むし…）

今日のNOTE

• PSoC Express
  • 2005/06/15現在、Version 1.1がリリースされている。無料みたい。
  • なにやら画面で部品をペタペタするだけで、外部回路図まで生成してくれる開発環境のようである。
  • トランジスタ技術2005年7月号に、使い方紹介の記事あり。

VisiON NEXTA

襟が立ってマス
三月兎さんのところで、VisiON NEXTAの動画がアップされています。 VisiON NEXTAって、どうもりりしいイメージがあったんですが、理由がわかりました。 「襟」です。襟が立っています。なるほど。それでリーダーっぽい？わけですね。 そういえば、むか〜し、筋肉マン（オフィシャルサイトがあるのね…）を読んでて、 悪魔将軍の襟（プロテクターだと思うんだけど）が立っているのを見て、かっちょいいと思った記憶がよみがえってきました。 ということは、次のVisiONガールの服は、襟付き？結構、かっこいいかも。

肘の向き
このVisiON NEXTAもそうなんですが、肘の向きって、だいたいのロボットはロール方向（左右）がデフォルトですよね。 個人的には、ピッチ方向（前後）が自然だと思うんですが、いかがなもんでしょう？ 高校生の頃、マクロスというアニメのバルキリーが、デフォルトでピッチ方向で感激した記憶があります。 そんなわけでG-Tuneは、いつもピッチ方向につけています。 ただ、現状の部品で作ると、ロール軸にしたほうが、前から見たときに細く見えていいんですよね。悩ましいところです。 ちなみに、鉄人２８号は４５度で、現物が動いているのを見てすごく自然に感じました。やっぱ、真髄は４５度なんでしょうか。

今日のNOTE

• I2Cについて
  • シリアルEEPROMがI2Cの全てではない
    てっきりシリアルEEPROMの通信仕様がすべてかと思っていたら、そういうわけではない。デバイスアドレスとデータのやりとりが決まっており、データの一部をデバイス内のアドレスとしても使用するのがEEPROMアクセスのお約束事らしい。
  • I2Cバスフォーマット
    ｢スタート(1)」−「デバイスアドレス(7)」−「R/~W(1)」−「ACK(1)」−「データ(8)」−（「ACK(1)」）−「ストップ(1)」みたいな感じで構成されており、「書き込み」指定した時に次の２バイト分のデータをアドレスとするのがシリアルEEPROMの決め事らしい。 だから、読み出しアドレスを設定するのに、一度、書き込み操作をするのは、実用上、問題無いよう取り決められた（苦し紛れな）やり方？
  • CONTROL CODE
    シリアルEEPROMの「CONTROL CODE」（Microchip Technorogy Inc.の用語かも）が、MSB側から「1010」で始まるのも、EEPROM特有の取り決めなのかな？ この最初の４ビットは、少々特殊で、「0000」と「1111」は用途が決まっているとのこと。
  • 1M BitのシリアルEEPROMの内部アドレス
    1M Bitの場合、128kByteになるので、アドレスが２バイトでは足らなくなるせいか、デバイスアドレスの最終ビット（７ビット目）をアドレスの一部として使用している。これで内部アドレスが１７ビットで指定できるようになるので、128kByteアクセスができる。
  • フィリップス社（特許は2004年8月で失効）のI2Cバス仕様
    読んだら何かわかるかな？？？（＠＿＠）

新サーボ制御ソフト…開発始めました。

ジッタフリーとの限りなき戦い
さてさて、現在、新型G-Tuneの設計、PSoCの下調べをするかたわら、新しいサーボ制御プログラムを作成し始めました。なかなか難しいです。 そんなわけで、自分の尻叩きがてら、開発日記を書くことにします。

今までのも、なかなかいいプログラムだと思うのですが、ことの起こりは、PRS-3401をSIPHA COREに接続した時の話です。 アナログサーボではほとんど目立たなかったジッタが、結構、出ているではないですか…。これはイカンです。 今後、高速歩行とかにチャレンジしていこうというのに、こんなところでプルプルしていてはまずいです。 プログラムでは、確かに、場所によっては、一瞬0.5度ぐらいぶれであろうところがあるのですが、デジタルサーボでは、なんだか顕著。 これが謙虚だったらいいのに。

さらに、次はぜひともジャイロを接続して制御に使いたいです。一度マイコンに取り込み、それでいろいろできるようにしたいです。 ジャイロ解析に使えそうなモジュールは、H8/3694ではタイマＷだけです。 タイマＷは、H8/3694の中でも一番高機能なタイマーで、現行のサーボ制御にも使用しています。 ということで、いずれにせよ、ジャイロを搭載するところでサーボ制御ソフトはタイマＶへ移行させないといけなさそう、というわけです。

他のCPUに目をやると、なかなかいいのが無いんですよね〜。消費電力とかサイズをもう少しひろげれば選択肢はありますが、 電源電圧変動に強くて、そこそこ脚の数があって、そこそこメモリがあって、さらにそこそこサイズが小さいという（「そこそこ」ばっかり…）と、 H8/3687（ベステクのBTC065）と M16C/26（OAKS16-MINI）あたりになります。 なんとなくM16C/26だと、タイマ構成とかがいい感じなのですが、ちょっと基板が大きいのが難点…。 あれで幅が50mmだったらばっちりなんですけどね〜。 そういえば、BTC065って、H8/3694のBTC064と２００円しか違わないんですが、そんなもんなんでしょうか。

次のSIHPA SYSTEMの目標
さてさて、次にやりたいな〜と思っていることをまとめると、次期SIPHA COREの目標は、以下のようになります。

• サーボ…２１ch制御（うち１chはジャイロ出力用）ジッタは2us以下でほとんど目で見えないぐらい。
• 加速度センサ
• ProBo
• シリアルEEPROM
• 距離センサ…２ch
• ジャイロ…２ch制御（マイクロ秒単位での取り込みをして制御に反映）
• 電源電圧監視

これを全部直接続…(^_^;…チャレンジャーだな〜。あはは。これにLED出力つけたら、ホントに端子がもう無いです。

さて、この中での問題がジャイロです。ラジコン用のジャイロを使おうと思っているのですが、これはPWM取り込みです。 制御に使いたいため、それなりの細かさが必要になります。 分解度が0.1msだったら現行プログラムを改造すればできるのですが、やはりここは、サーボの間にジャイロを入れる仕組みと同じぐらいの精度で動かしたいです。 アイデアとしては、H8/3694のタイマＷを使って、ハード的にカウントしてやればいいや〜ってことになるんですが… タイマＷを計測処理に使ってしまうということは、サーボ制御を残ったタイマであるタイマーＶ（8BIT）で行うということになります。

このタイマＶ、以前から0.1msの割り込みやカウントに使っているのですが、実は機能がよくわからなかったりして…。 少なくとも２つのジャイロを計測するのは無理っぽいです。 そんなわけで、H8/3687にしようかな〜とかいろいろ悩んだんですが、サーボ制御とプロポ信号取り込み処理をうまいことやろうと思うと、 H8/3687にしても、それほど変更するメリットが無いかな〜というのと、せっかくAKI-H8/3694も買ったことだし、まずはこれでチャレンジしてみることにしました。

ちなみに、H8/3687は、タイマＺという、名前からして魅力的なタイマがついています。 ハードウェアマニュアルを読むと、タイマＷが２個分、という感じです。 PWMで信号が入ってくるものを処理するならば、非常にいい感じです。きっとさらにダブルになると、グレートタイマになるに違いないです。 そんなわけで、片方でサーボ制御信号、もう一方でPWM入力処理、なんてのも簡単にできそうです。 また、ROM、RAMともに大きくなっているので、これまたいい感じです。

しかし、しかし、やはり、H8TINY、今のプログラムをそのまま移植しただけでは、やっぱり同じような結果になると思いますし、AKI-H8/3694のもったいないおばけがでると困ります（ただでさえ、無駄にしているものが多いですし…）。 というわけで…タイマＶで動く「サーボ制御＆プロポ信号解析＆センサの平均化処理」プログラムを作ることにしました。

ま、まずはチャレンジチャレンジということで、はい。

サーボホーン、どれにしようかな…その２

ＪＲスーパーホーン
まずはスーパーホーンをつけてみました。おお、りりしい！というか、サーボと同じぐらいのサイズがあるような気がします。 はめた感触ですが、かっちりと問題無くはまります。

あたりまえと言えばあたりまえですね…。


そりゃそうだよね…


というわけで、採寸してみました。比較写真でも厚みがあるのがわかったと思うのですが、実際には2.4mmあります。 クリックで拡大します。ご参考までに、ということでよろしくです。

ＫＯローハイトホーン
続けて、ＫＯのローハイトです。は、はまりません。とはいえ、そこは樹脂、ぐりぐりやっていれば大丈夫です。 最後は、頭のネジを締めることで押し込みました。かっちり感はありますが、かなりきついです。

外してサーボホーン内側のセレーションを見ると、削れているのがわかると思います。というわけで、きっとアルミでは、はまらないと思います。

サーボホーン、どれにしようかな…その１

どどんとサーボホーン比較
え〜、PRS-3401につけるサーボホーン、どうしようかな〜といろいろ悩んでいるわけですが、消費者を代表して… いや、そんなたいそれたものではありませんが、安く購入できるということで、樹脂製のサーボホーンの比較をしてみました。

左から、「標準」、「ＪＲスーパーホーン」、「ＫＯローハイト」です。
「ＪＲスーパーホーン」はえまのんさんから頂いてしまいました。どうもありがとうございます。「ＫＯローハイト」は自腹購入です。

標準サーボホーンも、こうやって見てしまうと貧弱とはいえ、なんだか小ぶりな感じがスマートです。 フレームが面で当たるようにデザインすれば、それほど問題が無いのかな〜という気がします。触ると、少なくとも、MICRO-MGのよりは丈夫な感じがします。 スーパーホーン、厚みがあってしっかりしています。穴を追加してカットして使うベースにはいい感じです。 デザインが一番しっくり来るのはやっぱりＫＯローハイトでしょうか。寸法をチェックしてたら、ABSで手加工フレームだと、ＫＯの穴位置は苦しい気がしてきました。

高屈曲コード到着

すんごいですね〜
イカロスさん経由でなぐさんから分けていただいた高屈曲コードが到着しました。さっそく被服をはがして中を見る。 お〜、すげ〜。数えようと思ったのですが、気力負けしました…。まあ、たくさん、ということで。写真は、AWG22（0.3SQ）ですが、こんな感じです。イカロスさんところでも書いてありましたけど、これは、巻くのはさぞかし大変だったと思います。 （最近、ロボット王国で買った高屈曲ワイヤを一生懸命ほぐしていたので、よくわかります〜。）どうもありがとうございます。

H8/3664とH8/3694の違い

RES端子のプルアップ抵抗内臓
実はI2Cの機能を調べようと思って、データシートを眺めなおしてました。 IICがIIC2になっているのはすぐにわかったのですが、ついでに新しい違いを発見しました。リセット端子です。 H8/3694のリセット端子は、プルアップ抵抗（typ. 150kΩ）を内臓しているとの記述をハードウェアマニュアルで見つけました。 ということは、今まで、抵抗で5Vに吊ってスイッチをつけていたんですが、H8/3694では、スイッチをつけてGNDに落とせるようにするだけでよさそうです。

他には…PSoCのメモ書きでも書きましたが、あたりまえといえばあたりまえで、何で気づかなかったんだろう？というところで、 I2Cの通信速度が変わっています。クロック16MHzが20MHzに変わって、一緒に変わったようですね。

他にも少しずつ変わっている可能性があるので、時間がある時にまたゆっくりハードウェアマニュアルを読んでみようと思います。さっそくNoteに追加しておこう。

秋葉原でお買い物

めずらしく東京出張
久々の東京出張だったので、会議後に秋葉原まで足を伸ばしてお買い物しました。まずはオヤイデ電気でシリコン電線を購入。 よし、これで前から気になっていた、充放電器とバッテリ間の電線を太くできます。 次は千石電商で、APA302を購入。これは動的加速度センサで、動的な加速度だけを計測できるものです。 PSoCが届いたら接続してあれこれしてみようと思ってまして、わくわくです〜。 ついでに超音波マイクと超音波スピーカも購入してしまいました。これは、「初めてのPSoC」の最後に、ほとんど超音波マイクとスピーカだけで距離センサを作る章がありまして、ぜひとも試してみたいな〜と。

そして、最後は王国へ行きました。そしたら何やら取材をしている様子で、高橋さん（締め切り１号の）を店内で発見！というわけで、押さえていた新幹線の時間ギリギリまでみなさんとお話を楽しみながら購入したものは、 なぜかサーボマウントＡ、ローハイトサーボホーン、反対軸用サーボホーンなどなど（笑）。それに高屈曲ワイヤー。さて、試しにはめてみよう。 サーボマウントＡを買ったのは、ABS板を直交結合する時のパーツに使えるかな〜と思いまして。 M2とM3のネジを使わないといけないんですが、それでも精度あるので試しに、という感じです。

うぅ、ついつい、予定よりいろいろ買ってしまいました。

volatile忘れてた…

新サーボ制御ソフト開発してたんだけど…
は〜、わかってしまえばどうってことの無い話なんですが…「よし、新しいサーボ制御ソフト作るぞ」と、ソフトを書き始めたんですが、 まずは軽く雛型作ってテスト〜という段階で、「あれ？動かない」という事態発生。おかしい、少なくとも全然動かないことはなさそうなんだけどな〜と、悩むこと、人に言えないぐらい。

変数にvolatile宣言つけるのを忘れていました…。しかも最適化「-O2」です。ふわ〜。

説明しよう！volatileとは、コンパイラの最適化を抑止する機能で、この宣言を持った変数は最適化にも負けず、コンパイラが「こいつは無意味だ」と判断しても消されたりしないためのものであ〜る。割り込み処理等とmainな処理の両方からアクセスするようなグローバルな変数には必須な宣言なのだ〜。

最近、改造ばっかやってましたから、新規物のときの注意点、忘れてました。さ、気を取り直してデバッグデバッグぅ。

PSoC下調べ中（早く『取調べ中』になりたい…）

PSoC下調べの続き
現状、こんな感じです。せっかくなので、Noteというページを作って、 こういうメモ書きみたいなものはそっちに入れることにしました（いつかディスククラッシュした時のショック軽減のため…な〜んて）。

ぎざぎさを数える…の続き

サーボホーン、微妙に入らないとのこと
BBSの方で、KONDOのサーボホーン、PRS-3401には微妙に入らないとの情報がありました。う〜ん、残念。 そのかわり、他のJRサーボホーンが使えるとの情報も頂きました。 また、I-Beeさんから販売されているアルミサーボホーン（再入荷待ち？）にすれば問題無いんでしょうが、 それなりのお値段がしますんで、悩みどころです。実際、サーボって片持ちで使うわけではないので、ホーンそのものの強度はそれほど問題無いと思うんですが、 やっぱり、見慣れた丸いのがいいな〜とか、剛性感のあるものがいいな〜と思ってしまうのは、今までのサーボに見慣れてしまっているせいでしょうか。

今月もONOさんの「選り抜き」に入れてもらいました。ありがとうございます。 自分もよく使わせてもらってます。 ところで、「選り抜き」、TOPページの更新履歴以外のところからって、入り口ありましたっけ？ 未だに更新履歴のところからいつも行っているんですが…。
2005/06/04追記：わかりました。いずみかわさん、どうもありがとうございます。

ぎざぎざを数える

PRS-3401のセレーションを数えてみる。
PRS-3401の出力軸のセレーションを数えてみました。まともに数えると大変なんですが、ギアとかを数える時にやっている、楽チンなカウント方法を紹介します。

1. デジカメで真上から写真をとる（マクロモードでなるべく大きく）。
2. パソコンでペイントブラシなどでファイルを開く。
3. 画像に数えた情報を描きこみながら数える。

これだと、目が疲れてきたりとか、どこまで数えたかわからなくなったりしなくていいです。 で、PRS-3401を数えた結果は２３歯でした。なるほど。KONDOのサーボも２３歯なんですよね〜（テクニカルインフォメーションの中にPDF図面があります）。 ということは…。

夢が広がるPSoC

いや〜、PSoC、おもしろそうで、もうダメ！
既にPSoCミニ・ディヴェロップメント・キットをゲットされている、みすみロボット研究所さんのホームページを見させていただいていたら、 アナログ回路の取り込み、IIC通信等をやってみたいとのことが書かれていました。考えることは同じです…が、ハードPWM回路を使ってサーボドライブというところまでは考えていませんでした。 そういわれてみれば、PWMモジュールがあるわけですから、当然、サーボもドライブできますよね。 う〜ん、センサー取り込みばかり考えていたので、思いつきませんでした。16Bitカウンタを４つは配置できますから、少なくとも４つはサーボをハードPWMでドライブできます。 もし、出力端子もプログラムで切り替えることができるとしたら…ああ〜、夢が広がっていきます。んで、これをIICで芋づるにして、あんなことしてこんなことして…。

さて、ちょっと一息入れて…最初、この先もっとセンサーが増えてきたら、8PのPICとオペアンプでどうかな〜と思ったんです。 でも、回路組むと意外と大きくなりますし、なによりSISOは電子回路に弱いので、 電子回路面でコンパクト＆シンプルにできるのであれば、それに越したことは無いな〜と。 また、PSoCのチップって、\500〜\700ぐらいで安いです。能力的に考えてコストパフォーマンスもすごくいいような気がします。 もし28PINが大きすぎれば、8PINのCY8C27143が共立エレショップで購入できるようです （写真は28Pですが…本当はどっちなんでしょう？）。開発キットは対応しているのかな？

実のところ、今のH8/3694だけでも、サーボ20ch、加速度センサ、距離センサx2、ジャイロx2、ProBo対応まではいけると思っているのですが、 今後、もっといろいろ対応していかないとダメかなって思ってまして、次期のさらに次のG-Tuneあたりで搭載できたらいいな〜なんて思ってます。

やってみたいことは、各種センサを取りまとめてIIC通信化です。 H8TINY（H8/3687を除く）、I/O数が少ないので、いろいろ繋ぎたくても脚が足りなくなっちゃうというのと、 アナログを扱う以上は、オペアンプなどのアナログ回路は避けられない（特に安く使おうと思うと）のかな〜って思ってまして、 だったら、オペアンプなどを内臓して、しかも内部で組換え可能なマイコンであるPSoCならうってつけじゃないかな〜なんて予感がします。

IICは、芋ずるのように接続できますので拡張性も維持できますし、シリアルEEPROMを読み出すような感覚で扱えるスレーブのIICデバイスにできたら、 なんとか番地のメモリを読み出すと距離センサーの値が、別の番地を読み出すと加速度センサの値（しかも増幅された）が…なんてできそうです。 いや、プログラムも組めるわけですから、転倒判定もPSoCの方でやらせるのもいいかも…。ああ〜、また夢が広がっていってしまいます。 IICで体内ネットワークレベルまでやるとノイズの問題で難しいらしいですが（本当はどれくらいまでいいんだろう？）、隣のボードに繋ぐのは問題ないですし、 G-Tune程度のサイズなら簡単なノイズ対策程度で体内ネットワークもできるかもしれません。

というわけで、まだ開発キットは来ていませんが、なんだか我慢できなくなってきたので、PSoCデザイナーをダウンロードしてインストールしてみました。 本にもついているのですが、なんとなく開封するのがもったいなくて…。