■１１月３日■
とうとう１１月に突入。結局、木曜日も金曜日も飲みに行ってたので作業どころか日誌の更新もできませんでした。いや、作業してないんだから開発日誌の更新は無いのか。。
今日はマリオギャラクシーをやりつつ、あい間に工作。とうとうアタマユニット（ほぼ）完成！ 本体に取り付けました。
今回の目玉は、これ！ 目玉じゃなくて「まぶた」！まぶたはバキュームフォームで作ってみました。
顔部分の拡大。
実はカメラは右目だけで、左目はダミー。左目のレンズの奥にLEDをしこもうかと思ってたけど、実験してみたらいまいちなのでどうしようかな。こないだまでは左目は別の形のライトにしようと思ったのだけど、まぶたをつけるデザインだと、やっぱりシンメトリーな方がいいかなと思ってちょいと主義を曲げてダミーにしてしまった。
目を閉じたところ。
今は外装がないので目を開けているとまぶたが眉毛みたいに見えるけど、外装をつけたら目を開けたときにはまぶたは外装の裏に隠れるようにする予定。 ガチャピンみたいになる感じ。タレ目じゃないけど。
もともとは、、レンズを超広角にするとつぶらな瞳になって、目玉が飛び出し気味。視野角が広いからそうなるんだけど、こけた時に真っ先に地面に激突するのがレンズになる恐れがある。で、こけそうになったら目をつぶってレンズを保護するってのはどうかなーと思ってつけてみた。でも、こけたら真っ先に壊れるのがまぶたじゃないかと思います。(^^ゞ保護になるかどうかははなはだ怪しい。
まぶたの開閉はミニサーボで行います。RPU-100は2チャンネルのPWMサーボインターフェースがついているのでそれのひとつを使う。ちなみに両目をひとつのサーボで動かしているのでウィンクはできません。
完成～って書いたけど、実は無理やり組み立ててるところがあって、まだ改良が必要。構造も入り組んでいて組み立てるのも一苦労。もうばらしたくない気分だけど最低もう一度ばらさなければならない。つらいなー。
明日は最後の工作と電源回路、そしてサーボを動作させようと思ってます。
■１１月４日■
瞬きのためのサーボのリンクに大苦戦。いま22時だけど、まだ電源の配線が未着手。ただし、アタマの取り付けは完全に完了。電源基板も胴体に取り付けられるようになりました。あとははんだ付け。
苦戦したまばたきリンクもちょっと不満が残る感じだけど、完成。ただただ瞬きを繰り返すムービーをどうぞ。↓
マイクロサーボは思ったより動作が遅い。まばたきパチパチする感じはでなさそう。レンズ保護のための機構だからまぁいいのか(^^ゞ
色々不満があるのだが、これ以上の改良は動作プログラムで動かしてみてからにしよう。きりがない。
しかし、頭部ユニット、こけたら一発で壊れそう。色々検討したのだが、着け外しが面倒な構造になってしまった。部品を増やしてでも着け外しを簡単にして、壊れそうな実験を行うときはストレス無く外すようにしないとイカンだろうなぁ。
ショック、、、 カメラ逆さまに取り付けてしまってる。。 うぅぅぅ、、もうばらすのやだ。。。
上側（画面だと下側）はまぶたでちょっと視界が塞がれている。設計だと完全にまぶたが開くのだがサーボのリンクの関係か、工作精度か、開ききらない。下が大丈夫そうなのでヨシとしたい。
■１１月５日■
電源配線完了。
←あと二つサーボつなぐ予定なのでちょっとでかいレギュレータ
アタマユニットのサーボはG-ROBOTと同じRS302CD。RS601CRとは電源電圧が違うので直接つなぐことは出来ない。RS601CR用の電源をレギュレータに入れて7.4Vに落としてやらなければならない。
簡単なレギュレータの回路なんだけど、久しぶりのはんだ付けで随分と手間取った。出来上がりも不出来なもんで全然満足していないんだけど、もういいや。はんだ付けは面白くない。
300系と600系では多分パケットが違うから「めんどくさいぞ」と思っていたのだが、アドレスマップがちょっと違うだけでプロトコルは同じ。調べたところ、601用に作ったサーボの管理ツールはほぼそのまま使える。
つないでみたらなんの問題もなく通信できてホッとした。IDの設定とボーレートの設定を行ったので601と同時接続できるようになった。同時接続の結果もテストプログラムレベルでは問題なし。
よく確認していないんだけど、メモリーマップも上位互換になってるのか？ 601の方が上位って思ってたのに601では実装されていないパラメータが実装済み。601もファームアップして欲しいな。
301/302にあって601に無いのは、反転・返信遅延時間・現在スピード・現在電圧
601にあって301/302に無いのは、加減速時間・LED・PID調整値
反転が欲しいなー。反転があったら、ちょっとだけプログラムが簡単になる。ま、ほんのちょっとだけど。いまはJointクラスってのを作って、そこで反転属性を設定しているので気にしなくていいようにはしている。 ・・・だから要らないか。
今日はもう遅いのでサーボにトルクを入れるのは明日。 サーボがすぐに動きそうなのでカメラの制御はすぐに出来そう。練習会までに形にできればいいのだが。
・・・・
さて、次はマニピュレータか外装か。 工作ばっかりやってるわけにも行かないからプログラムも進めないとロボットじゃなくて人形のままだ。次はプログラムに戻るとしようかな。カメラまで実装できたから自律で動くようにする最低条件は揃った。（バッテリー積んでないけど）
＃外装つけて来年の年賀状に載せたかったのだが、今年も無理っぽい(^_^;)
■１１月６日■
頭ユニットのサーボにトルクを入れてみました。サーボの初期値以外は601と共用できそうです。初期値を601と同じにしたらハンチングを起こして大変なことに。すんごいブルブルしてました。あと、トルク制御が601とは異なるみたい。同じように数値を変更してもトルクは変わらないように感じた。この辺りはもう少し確認が必要なようである。
前の頭をつけたときはイメージがスコープドッグっぽかったけど（顔がシンメトリーじゃなかったし、今見たら首が短いし）今度は何か？とりあえずキュリオには似てるな。顔だけは「ショートサーキット」のナンバー５に似てると言われた。ま、似てるってーか長方形に目をつけたらあの顔になるし。
頭にトルクも入ったことだし、適当に立たせて記念撮影。 ラムダのページの画像も新しい機体での画像に変更しました。
すこし頭部のサーボの制御方法について考えてみます。
頭部の３つのアクチュエータの動作はカメラの姿勢を制御するために動作させるのであって、手足のように先端座標、この場合はカメラの座標を目的の位置に移動させる、という必要はない。 なので、頭部ユニットの逆運動学計算は直行座標ではなく、カメラ姿勢の制御に用いられる。
姿勢は３つの角度であらわすことになるが、頭部ユニットはロール角（Z軸回転）とチルト角（X軸回転）しかないため、チルト角とロール角しか与える事ができない。パン角はその姿勢を取った時の結果として与えられる。もちろんこれは計算で求めることが可能。
頭ユニットの姿勢としては基本的にカメラ姿勢を指示する方針で行こう。ただ、チルト角＋ロール角では直感的ではないのでカメラ目線のベクトル方向を示す独立した二つの角度（ジョイスティックのX軸角度とY軸角度のような）を指示することにしよう。
ただ、頭部ユニットには首部分があり、チルト角アクチュエータは二つもある。更にロール軸とカメラの位置に関してはオフセットもある。そのため、与えた姿勢の他に制御すべきことが無いわけではない。
たとえば、寝転んでいる状態で前を見る時や、立っている時に真下を見る時など、二つのチルトを駆使しなければならない。
二つのチルトをどのように使い分けるかというのが一つの課題になる。簡単なのは膝のダブルサーボのように同時に動かすことで速度を稼ぐような方法。だがこれはうまくない。第一チルト（首の付け根の方）は前側には90度くらい回転できるが、後ろ側にはほとんど動作域がない。よってカメラが上を向く時には先に飽和してしまう。モノを目で追うような場合でも、第一チルトは荷重が大きいため、追従速度が落ちるはず。第二チルトを優先的に使い、動作域が足りない時には第一チルトを使うというケースと前出の特別な姿勢の特別な視野を得たい時に使うという２本立てで考えていこう。 ※首の根元のチルトを第一チルトとすることにしたので修正
そんなこんなで頭ユニットのサーボのコントロール方法についてもなにか指針が必要。
カメラの姿勢を制御する以外にも頭部のサーボを動かすことで表情が豊かになる。まぶたも合わせれば相当な表現力が備わったようにも思うのだが、そういうのはモーションで仕込まないとならないため、とりあえずは保留。「制御を積み重ねることで表情が出てきたら面白いのにな」というロマンチストな気持ちがあるのです。
■１１月７日■
頭制御用のクラスHeadを作成。
昨日の検討で、カメラの向いている方向で管理するように考えていたが、もっと詳細を考えると、カメラを向いている方向と第一チルトの角度で表現することとした。
首をかしげる軸（Y軸回転）を持っていないため、左右を向いた上で仰角がつくと、カメラは斜めを向く。カメラロール角と呼んでいるが、その値も管理する必要がある。受動的な値なので、いちいち計算しないで呼び出す際に計算すればよい。
サーボ部分がそのまま使えたのでコーディングは先ほど完了した。明日からデバッグ。
・・・・・・・・・・・・
頭ユニットの基本クラスの作成を進めつつ、自律のために何をすればいいのかを考えている。
・まずは立ち上がりができなければならないので、現状ではモーション再生が必要。
・次に歩行。これは前進、後退、カーブ、その場回転ができなければならない。パラメータ調整の機能はナシ。
・転倒については転倒感知して受け身姿勢、トルクを落として衝撃吸収をする。
・カメラについてはまずはCDTで色に反応するようにしよう。そして色のついた物体に視線をトラッキングさせる。 画像取得（および画像処理）プログラムと動作制御プログラムを共有メモリかなんかで通信させるようにする。ついでに音声合成も動かしてみようかな。
・あとは自律行動だが、まずは認知している物体に近づくというところから。徐々にお題を難しくしていこうと思う。早いとこ、色じゃなくモノを認知できるようにしたい。
自律プログラムを考えるとついつい思考の旅に出てしまう。早く取り組みたいのだが、まずは基本的な身体制御ができないと始まらなかったのだ。拙いのは承知のうえでとにかく自律にしていこうと思う。
■１１月８日■
色々手直し。
まぶたが完全に開ききらないことや、まぶたがちょっと歪んでいることや、カメラとか頭部ユニットサーボの配線ケーブルが長すぎることが気になっていたので一気に修正した。まぶたはほぼ完全に開くようになった。まぶたのゆがみもまぁ許せる範囲に収まった。だが、目を開くとき「カチッ」って音がするようになってしまった。気になる。
クラスHeadも完成。ベクトルを指示することでその方向に顔を向け、その時のカメラロールも計算できるようになった。進捗は、なかなか順調。 カメラで物体をトラッキングできるようになるのはもうちょっと先になりそうなので、PS2のジョイスティックで頭を動かせるようにしてみたが、プロトコルが手抜き（人間の操作での通信を前提としているので。。）なので、短い周期での連続コマンド受信だとうまくいかない。 まぁここはがんばるところじゃないので、もういいかな。
さて、頭部（カメラ）のメカ設計関連は完了したのでまたロール軸消失問題への対応に復帰だ。ここまできたら対策をインプリメントして姿勢ベースでのモーション再生にしてしまいたい。
で、早速そちらの方の話題だが、、J1=0でのIK変換で、後回しにしていた斜面への対応だが、法線ベクトルにすれば簡単に変換できることに気付いた（ってか気付くってレベルじゃーないのだが）のでこれも実装してしまおうと思う。多分、すぐできるはず。 カメラの視線方向とほぼ同じだから。。
・・・・・・・
先日、新しい頭をつけての撮影をしたが、わざと膝を曲げた姿勢でのポーズにしたのだが、ラムダは首が長くなってしまったのでなんだか短足になってしまった。足をできるだけ伸ばして撮影しなおし。
（今日撮影） （こないだ撮影）
見比べると目がちゃんと開くようになったのが判る。 トップページの画像も、この画像に差し替えようかな～。 手、作りたいな～。
■１１月１０日■
J1=0でのIK変換にて斜面を保存することができた。
斜面計算にて特殊な状況（90度の絶壁とか、オーバーハングな壁とか）はフォローしていないが、ロボットが立っている状態の斜面なら問題ないレベルにはなっているようだ。
J1=0でのIK変換っていうのは、ロール軸消失問題の回避策として、J2=-90度の状況でJ1が大きく変化することを避けるため、その近辺ではJ1=0を前提とした足姿勢を計算するIK変換のことで、足首座標と胴体の姿勢は保存するが、足先の向きはJ=0とするために自由にした計算のこと。
この時、ロボットが立っている面が斜面の場合は斜面も保存しなければならない。足先の向きが自由と言うことは足先の姿勢角度を保存するのではなく、足先が接する斜面を保存しなければならない。
当面、ラムダが斜面を歩行することや斜面に立つことさえ無い予定なので、当面は放置するはずだった。だが、寝転んで足を持ち上げるような場合を考えると、かならず平面に立つ前提の計算だと使えないことに気付いた。
さらには斜面を法線ベクトルで表せば簡単に変換できることに気付いたのでこの際、実装してしまおうということでやることにしたのだ。
実はオーバーハングの壁というのは寝転んで足の裏を上に向けているような状態を示していて、この状態をフォローできていないのならまだ実用には耐えないということ。ただ、チルト角（x軸回転角）についてはオーバーハングでもちゃんと計算できるので大抵は問題なし。問題となるのはパン（y軸回転角）が90度以上の時だけなのでロボットが真横に倒れた状態や足を左右に大開脚した場合が該当するのかな。
で、具体的には↓こんな感じです。斜面に立って足を動かしているのだが、斜面に合わせて足先を動かしているので胴体は動かないということです。
次はもっと難問の軌道生成。直角軌道にすればすぐできるんだけどな。。。
■１１月１１日■
今日こそはモーションを進めようと思ったんだけど、そしてほんのちょっぴり進めたんだけど、モーションはどうにも気が進まなくて結局放置。
来週の練習会にも参加したいなと思っているのだが、やはりろくに動かないままラムダを連れて行くことになりそう。
ただ、頭ができたからちょっとは見栄えはするかな～と、で、頭が出来たことでできることをやりたいなと思って、さっさとトラッキングのデモ的プログラムを作ってみることにした。
計画ではサーボを制御するプログラムと画像処理をするプログラムは別のプロセスにして、情報をプロセス間通信でやりとりするという感じで考えていた。
既に簡単な画像処理のプログラムは動いていたのでこれを改造すれば簡単にできるかと思って二つのプログラムを同時に動かせるようにしてみた。んが、動かない。
RPU-100のロボット関連デバイスはプログラム上でイニシャライズしてから使うのだが、二つのプログラムでそれぞれイニシャライズしなければ使えないのに、動作プログラムの方で（ビデオ関連を除く初期化モードにしても）デバイスがオープンされてしまって、画像処理の方ではデータが取得できないという事態に。
しばらく試行錯誤したが、らちが明かないのでこの件はスピーシーズに問い合わせることに。あそこって応答悪いからいつ返事来るかわからんのだが。
今度こそ諦めてモーションをやろうかとも思ったが、動作制御プログラム側で画像取得もやっちまおうと、それほど難しくないぞ、ということでやっぱりトラッキングに取り掛かった。
でも、今のところうまく行かない。やはり画像取得の時間と関節角度が正確にわからないとうまくいかなそうだ。アイボだとそれが可能なんだけどな。
今回は簡単に済ませたかったので夏ごろ実装したCDTを使ってのトラッキングなのだが、この場合、物体を認識しているわけではないので超広角レンズだとうまくない。周りの景色も全部見えてしまうので物体を特定できなくなってしまうのだ。 ということで、上の画像ではズーム状態にして画角は左右で80度くらいに狭めている。
ちょっとやってみた感想としては、やはり同じプロセス内で画像処理も行うというのは無理がありそう。大体にして16fpsくらいしか出ないキャプチャーなのに、25ms周期の割り込みルーチンが動いてると6fpsくらいしか取り込み出来てない。プロセスを分けたらどれくらい改善するのかってのも判らないが、これよりはましだろう。ちなみにアイボだと32ms周期だから31fpsくらい。
実は、もしかして別プロセスでデバイスを使えないっていう可能性もあるなと思っていて、そのときは取り込みだけは同じプログラムで行って、共有メモリにデータを書き込んで画像処理は別プロセスで行うということも考えていた。が、この取り込み周期を見るとその案ってないなぁと思う。
■１１月１３日■
昨日は飲みに行ってたので開発は休み。
実は昨日すでにスピーシーズから問い合わせの回答があったのだが、もうダメダメな返事でちょーブルーな気分です。担当に電話すると、「パソコンがこわれたのでデータがなくなった」とか、複数のプログラムでRPU-100のデバイスを同時に使う（RS485をあるプログラムが使い、他のプログラムで画像キャプチャーを行うという感じ）ことはできるかと聞いているのにその回答がないため、それについて聞くと、「多分できたとおもうんだけど、わからない。」というわけの判らない回答。
営業じゃわからないだろうからエンジニアに聞いてくれというと、「今の仕事が忙しくてとても相手にしてくれない。」とか。。 問い合わせする前からヘタレっぷりは想像がついていたのだが、（以前から問い合わせするたびにそんな感じだから）まったく役に立たない。そうそうにRPU-100とは縁を切りたいなと改めて思いました。
でも、11日の状況では先に進めないので、頼りにならない営業のセリフを頼りにもうひと踏んばりしてみることにしました。
RPU-100では専用デバイスを利用する前にspsInitializeDevice( )という関数を実行するのだが、二つのプログラムでそれぞれこれを実行すると後から実行した側で、
saa7113h:open: Device busy
と言われる。スピーシーズのエンジニアは双方でspsInitializeDevice( )を実行するのがおかしいのでは？とあてずっぽうで言ってたらしいが、これを実行しなければデバイス関連の関数を実行した途端にコアダンプする。spsInitializeDevice( )には引数があって、ビデオを使わない場合の設定というのがあるのだが、その引数はさっぱり働いている様子はなく、やはりデバイスビジーになる。 ＃これで判るようにスピーシーズはサポートする気がまったくなさそう。売りっぱなし。いままで対応してくれてたサーボのファーム修正は双葉電子だもんなぁ。(>_<)
まぁそういう感じでいろんなケースで試したがダメ。どうにもデバイス関連の仕組みがわからないので手の出しように困るのだが、/dev/にはsaa7113h0というデバイスファイルがあるくらいなのでそれほどおかしな処理はさせていないはず。すると、デバイスをオープンしてファイルディスクリプタをどこかのグローバルメモリに登録して、デバイス関連関数はそれらを参照することでファイルディスクリプタなどの引数を使わずにデバイスにアクセスできるって感じのしくみかなぁと想像してみる。ま、このあたりは詳しくないのであてずっぽうです。
すると、forkしてexecveしてる状態ではその辺りは継承されない感じなのでだめっぽい。ではexecveする前の子プロセスなら継承しているはずだから使えるはず。
で、試してみるとforkしただけの状態なら二つのプロセスからデバイスを使うことはできました。ということで、違うプログラムからそれぞれデバイスを利用するのは今のところ無理だが、違うプロセスから利用することは可能、という状態です。でも、、、これはあれだな、やだな。でっかいプログラムを書いて、それぞれ半分しか使わないわけだ。
デバイスを使う部分は1本のプログラムにまとめて、forkして二つに分割。RS485担当とsaa7113担当に分かれて、それぞれが更にforkして解析部や計算部のプログラムを起動。それらと通信してデータ処理をしたりサーボへの指示を受けたりするって仕組みになるのかな。めんどくさそうだけど、そうすればある程度は効率的にデバイスにアクセスできそう。
デバイス管理の仕組みが想像通りならばデバイス管理をしているメモリ内容をハックして同時動作する別のプログラム側に内容を移植するなどすれば動かせるようになるかもしれない。でも、その案は無いなぁ、解析する時間と労力がもったいない。
手段が見つかってよかったのか、思い通りにはいかないことがほぼ判明して悲しむべきなのか、複雑な気分。 多分よかったんだろうなぁ。
どなたか、オープンされたデバイスのファイルディスクリプタを調べる方法がありましたら教えていただけないでしょうか。探してみたけどわからない。。
■１１月１４日■
今日も出張の帰りに飲んできてしまいました。ビール→焼酎→ワイン コースでちょっと気持ち悪い。
帰ると、練習会用に買った無線LANアダプタ（IOデータのWN-G54/AM）が来てたので早速設定。 問題なくラムダとの接続も完了しました。
前回の練習会ではむかーしに買ったコレガの無線LANアダプタを持って行ったのだが、厳しい環境に耐えられなかったのか、接続直後に切断。使い物にならなかった。このアダプタではどうか？これ、11b/g用なんだけど、APにもなるし、有線-無線コンバータにもなるし、で、外出にはなかなかよさげなアダプタです。
これで、みんなの無線コントローラの嵐の中でも接続できれば言うことないのだが、、さて。
・・・・・・
出張の帰りは酔っ払ってたのだが、行きは酔っ払ってなかったので、ラムダのプログラム構成など考えていました。下の図が構成の概略図。
まず、デバイスアクセスプログラムを起動。これはRS485関連、キャプチャーデバイス関連のアクセスを行うプログラム。
これがforkして、片側はRS485アクセス、片側はキャプチャーデバイスアクセスを行う。二つは同じプログラムで、違うプロセス。
次に、それぞれがforkして、動作管理プログラムと画像処理プログラムにexecする。
ここまでで３つのプロセスに分離する。各プロセス間は共有メモリーで通信を行う。
音声認識や音声合成は画像処理プログラムから呼び出されるカタチになるかと思う。
画像処理で得られる情報とそれによる判断が一番比重が高いので、画像処理プログラムが事実上のメインプログラムになるだろう。ただ、RPU-100のキャプチャーは時間がかかるようなので、思考ルーチンは更に別プロセスにした方がよいかもしれない。そこんとこは今後の検討しだい。
現状のベタ書きプログラムから比べると随分と複雑な構成になってしまう。タイミングなどの問題も有りそうなので、早めにこの形にして開発を進めた方がよいのではなかろうか。
まずは雛形を作ってトラッキングアプリを動かしてみるところからだろうか。いや、その前に今のプログラムにCDTを積んで、forkしてプロセス間通信をさせてみるのが先か。
■１１月１５日■
昨日の続き、今のプログラムにCDTを積んでforkしてプロセス間通信をさせてみた。すぐにできて、プロセス間通信も正常に出来る。
ところが、同じプログラムを親子関係で動かすと、インターバルタイマーを使った割り込みハンドラーの動作に支障を来たすのだ。なんだか、キャプチャー担当のプロセスにCPUタイムを取られてしまう。どういうわけなんだろう？
割り込みハンドラーは25ms周期で、まぁウェイトも入れても10ms～15msくらいで終わる作業をしている。その中ではRS485を動かしているのでCPU自体は大した作業はしていないのだ。
はじめはキャプチャーコマンドがCPUタイムを奪ってしまうのかと思ったが、キャプチャーコマンドを外して、カラデータでCDT処理だけを回しても割り込みハンドラーの動作不全は変わらない。
次にforkした後、execveして、違うプログラムに変化させてキャプチャーコマンドとCDT処理をさせてみた。すると、わずかに動作不全が見られるものの、ほとんど割り込みハンドラーには支障がない。どういうことだ？
確かにexecveすると、正常にキャプチャーできなくなるので比較になるかどうかは怪しいのだが、CDT処理だけでおかしくなるforkだけタイプとはCPU処理は変わらないはず。
forkしただけで同じプログラムが動いていることが問題を生んでいるのか？教科書を読んでも、forkするとメモリー空間は別になると書いてるし、プロセスIDももちろん違う。割り込みハンドラーの設定はfork後に行っているので、キャプチャー担当側は割り込み動作は行っていないのに。
ちなみに以前スピーシーズからもらったサンプルプログラムは（当時はまともなエンジニアが対応してくれた）、インターバルタイマーは使っておらず、whileループで処理していた。時間管理は時計から時間を取得して管理していた。なので、マルチプロセスでの処理が前提。ただ、ビデオ取得は行っておらず、今の状況にはあんまり参考にならない。
CPUの負荷的には余裕があるはずなので、なんとか問題を打開したい。ふむー、デバイスの問題さえ片付けば簡単なはずなのだが。
■１１月１６日■
昨日の続きで検討を続ける。
ざっくり考えられる原因を当たってみたが全部ハズレ。
平行して調べていた、オープンしているデバイスのファイルディスクリプタを調べる方法を思いついたので試してみる。
ファイル情報を調べる手段として、fstat( ) という関数と stat( ) と言う関数がある。fstat( ) は引数にファイルディスクリプタを取り、stat( )は引数にパスを含むファイル名を取る。で、これを使い、/dev/saa7113h0というデバイスの情報を取得する。ファイルディスクリプタは正の整数なのだが、使用していない小さな数から使用していく。なので、小さな正の整数を順番に調べていけばわかるはず。stat,fstatで得られるファイル情報はstruct statという構造体に収められるのだが、その中のst_rdevという要素がデバイスIDを示す情報で、指定したファイルがデバイスファイルの場合はここに有効な情報が入るはずだ。
ファイルディスクリプタの0～2は標準入力、標準出力、標準エラー出力なので、3～10くらいを順番に調べる。すると、デバイスの初期化をした段階で3つのファイルがオープンされている。一番最初（つまりファイルディスクリプタ3）は標準的なファイルで、何かわからないがもしかしたら実行ファイルのことか？そして、次の二つがそれぞれRPU-100特有のデバイスで、saa7113と、br_devmap0というmmapデバイスらしい。
これで、オープンしている特殊デバイスのファイルディスクリプタを知ることができた。そして、起動したプロセスにてsaa7113h0デバイスをクローズし、forkしてexecveし、画像処理用プログラムを起動。そちらでも同じようにデバイスの初期化を行う。
成功。 これでやっと二つのプログラムでRS485関連処理とsaa7113関連処理（画像関連処理）を平行に動作させることができた。 これで、この件ではスピーシーズと連絡取らないで済む。
で、問題のインターバルタイマーの不全だが、別のプログラムで実行するようにしたら、だいぶ軽減した。更に、br_devmap0デバイスもクローズしたら、更に軽減した。この「br_devmap0」というのはなにをやるためのものかわからないのだが、恐らくはキャプチャーチップのメモリ空間をCPUのメモリ空間にマッピングするためのデバイスではなかろうかと思う。キャプチャーデバイスを使わないプロセスでは不要なのでクローズしても大丈夫なはず。大丈夫どころか、何か余計な仕事をしていたらしい。
最初、ざっくり考えられる原因での調査の時に、割り込みハンドラーに更に割り込みがかからないようにシグナル処理を追記したのだが、シグナル処理ってとても時間がかかるらしい。それを追記しただけで、動作がおかしくなってしまった。それを削除しないまま色々試していたため、デバイスのクローズができたのに動作が遅くてびっくりしてしまった。
ちなみに割り込みハンドラーの教科書的処理ではハンドラーの冒頭で割り込みが更にかからないようにシグナル処理を行うのが基本。それをやっていなかった今までのが手抜きだったのだが。。。。
随分動きはよくなったのだが、画像処理プロセス側のモニタータイプをCDTにすると、動作が不全になる。これはネットワーク処理が増えるのが原因らしい。バッファサイズを変更したりすれば状況が変わったりするのかな？
なんとかそれらしく動くようにはなってきたが、シグナル処理はそれほど軽い処理ではなく、他からの影響を受け易いらしい。（少なくともRPU-100は。それともPPCのNetBSDがかな？）スピーシーズのサンプルプログラムのような、やり方がRPU-100にとっては正しい形なのかもしれない。
明日中にCDTでのトラッキングが出来るようになりそうです。
･･･・・・・・・・・・・・・・・・・
上記の、カメラを動作させながら、サーボを動かすテスト中、不幸な事故がありました。
転倒したところにちょうどテーブルの足が。 不幸にも後頭部を強打し、首が折れてしまいました。チ～ン。
後頭部を強打 
首がくったり。。。
でも、うまい具合にヒューズが働いて、サーボは壊れませんでした。しかしメンテ性が悪い。これ直すのにはCPUユニットを外さなければならない。。。改良しなきゃなぁ。。
■１１月１７日■
本格的にトラッキングのデモ作成に取り掛かる。
画像処理側のプログラムはCDTテーブルエディタを流用（というか機能を追加する形で）するので、モニターアプリ側にも手を加える。画像モニターのONOFFボタンや、トラッキングするCDTチャンネルの指定など。
サーボ制御側のプログラムとは共有メモリで通信をする。
あれこれ考えながら作業したので、進捗は悪かったのだが、つまずくことも無く動き出した。でも、どうもハンチングが大きくて動きが収まらない。よく判らないが、オーバーシュートが大きいので計算上の目標物の位置角度を半分にしてみたら大体うまく行きだした。計算がどこかで間違えているのかも。
画像取得の反応速度が遅くて、ちょっとハテナなのだが、アイボよりは画角も大きく、目標物を見失いにくい。軽く歩かせてみたが、トラッキングははずれない。いいね。
だが、昨日日誌に書いた、ネットワーク通信がインターバルの邪魔をしているというのはどうも誤りのようだ。画像データの転送を止めて、CDT処理を行うともっとも動作不全が顕著になった。画像を取得した後のCDT処理ループに入ると割り込みハンドラーに処理が移りにくいようだ。これってマルチプロセスなのになにか考えなきゃならないのかなぁ？疑問。
デモ動作の動画です。↓
これは色が集中している方向を向いているだけで、知能程度で言えば虫程度。 「モノ」も認識していないのでそれ以上の思考も処理も出来ない。
最終的にはCDTではなく、物体の認識（物体であるかどうかは色集合で判断するのは同じなのだが、色の分布ではなく、集合で判断する）をして、それが「何か」を認識させるつもりなので動作予測なんかもさせることが出来る（可能性がある）。さらには超広角画像を使うつもりなので見失わないように目で追う必要も少なくなる。
なにはともあれ、マルチプロセス対応にしなきゃなぁ。
・・・・・・・・・・
画像処理プログラムのループに、適度に usleep(0) をばらまいたら随分とマシになりました。ボール見ながら普通に（ラムダレベルの安定度で、だけど (^_^;) ）歩ける。
これならボールに近づいていくこともできそうだ。次はそれかなー。頭ユニットの姿勢と画面上の重心（目的物の位置）から物体の方向を計算できるようにしないと。
インターバルタイマーによる定時割り込みでのシステムをスピーシーズ風の時間管理のシステムに作り直すのはちょっと大変。その上、効果がわからないので一気に切り替えるというのは無謀。テストプログラムを作ってみて、効果があるのなら切り替える方向で検討するって感じかな。
どっちにしてもループを持つプログラムにはプロセス切り替わりのタイミングを与えるような配慮が必要なのは変わらないだろう。
■１１月１８日■
関東組練習会行って来ました。
もちろんラムダは自由に歩けないので練習はできないんだけど、今回はトラッキングデモが出来たので見てもらえるネタがある。みんなに見てもらえてよかった。概ね好評。頭に３自由度もあったり、あちこち見れるってのはバトル系ロボットには有り得ないので新鮮だったかも。僕はアイボからロボットに入ってるのでこの形が自然でした。
画像処理プログラムにusleep()入れたりしたら、歩行はほぼ問題なしになってきたようだ。人形つかいさんにプロセス実行のプライオリティ調整のコマンドを教えてもらったからそれもちょっと試してみよう。うまく行けば、このまま次の作業に進めそうなのでありがたい。
さすがに練習会場ではプログラミングはできないので、トラッキングの調整なぞやってました。超広角にしてのトラッキングも結構使える。超広角で調整したトラッキングのパラメータをズームで使うとハンチング起こしてしまうってのが判った。この辺り、画像モードと連携させなきゃならないらしい。
耳寄り情報で吉田さんにホーザンの圧着工具を教えてもらいました。これはイイ。コネクタのコンタクトのはんだ付けをしなくて済むようになるかも。早速売ってるところを検索して注文しました。
あと、超高齢ロボットユーザー山田さんの差し入れ。膨大な数のドトールのワッフルたち。おいしゅうございました。ありがとうございました山田さん。下の画像はワッフルとバームクーヘンの一部です。
石川さんのSDレイズナーはロボビリヤード成功してました。
新たな目標として、自律でロボビリヤード完遂させるってのが出来た。番号読むのは難しいけど、色分けされたら結構できるかもしれない。ただ、リングアウトが問題だ。リングのふちを見分けないといけない。そのあたりが難問。
ゲームをやらせるのはいいんだけど、ルールをプログラムしなきゃならない。いつかは、ラムダにルールを言って聞かせて実行させるってのができるようにしたいな。ロボビリヤードでそれをやるのは難しそうだけど、パイロンを回って帰ってくるっていう位の競技だったらそれ（ルールを言って聞かせる）に挑戦したくなるんだよな～。
スケールばっちり。。。。 やっぱ外装いいなぁ。でも外装700gは重過ぎ。ラムダだと歩けなくなってしまう。
帰りはイガアさんにモーションの作り方の話や最近のロボ事情（3点防御ってのかな？）の話を聞きながら帰ってきました。極限まで突き詰めてモーション作ってるので色々ためになる話を聞きました。
次に練習会に参加するときにはまた進化させておきたいですね。とりあえずバッテリー積んで外装つけてって感じか？
■１１月１９日■
昨日の練習会で夕方ごろ見学に来た方がいらしたのですが、ラムダの写真を何枚か撮ってもらったりラムダの説明をしたりしました。
で、どうやらその方が「林ホビー工作研究室」の林さんだったようで、ラムダの画像を載せていただいてます。でもぉ～、「シグマ」になってますね。(^_^;) ギリシャ文字の「ラムダ」です、って言ったんですが。。。 シグマだと頭二つ作って４本足歩行にしないと。。。 でも、SDバレリーナよりはましかな。 林さんだとわかっていれば色々と教えてもらいたいことが有ったのですが～。
「思い立ったが吉日」にも登場させてもらいまして、ありがとうございます。 他のHPに載せていただいたのは初めてですね～。うれしいです。
「佐藤ロボット研究所」にも登場してる！B作さんありがとうございます。CDTってのは色を見てるだけなので、お腹のカタチは関係ありません。ご安心を。
・・・・・・・・・・・
ボールを目で追いかけさせても何も達成したわけではないのはもちろん。そろそろ目で見て歩き出させないといつまでたっても独り立ちしない。独り立ちするにも一人で立ち上がれないと始まらないので、まじめに起き上がり動作をどうやって構築するか考えねば（もう、モーション再生で立ち上がらせるつもりは失せてる）
考えているのは、基本的に姿勢をいくつかに分類して、現状の姿勢がどの分類に入るかを判断し、その姿勢から立ち上がりを行うということをさせようかと考えている。
例えば転びそうになって手を着いたとして、その姿勢から一度寝転んで立ち上がるのではなく、その姿勢から最短のモーションで立ち上がるようにする。
とりあえず、あまり難しく考えずそんなことをやらせてみようと思います。
寝転び状態 
座り状態
手を着いて立っている状態 
これでも立っている状態
手を着いて立っている状態②
白い灰になった状態．．．
問題は手を着いて立っている状態（亜立位）から立っている状態への移行モーションをどうやって生成させるか、デス。
■１１月２０日■
昨日、開発日誌をアップして風呂に入って、で、思うところあってまたPCに向かいました。
そして、「散財心理学実習講義200X」が更新されているのを見ました。なんと画像４カットも使って紹介してもらっています。ありがとうございます。<(_ _)> 散財さんに取り上げてもらって、なんだか、ひとつ目標を達成したような気分です。(^・^)
でも、石川さんが書いておられるようにあれってアイボがやってることなんです。そして、アイボの方がもっとがしがしとピンクボールについてくるんですね。まだまだだなぁって思っているのがホントのところだし、本当にやりたいことは色を認識することじゃなくてモノを認識すること。 たくさんの人に注目してもらって、「もっと精進せねば」と改めて思いました。 でも、アイボがボールを追いかけてるより、ラムダが（人型ロボットが）やってるとなんだかちょっと親近感があるような気がしました。なんていうか、人型であることで人に近づいてるってのは本当にあるんだなって思ったりもしました。
・・・・・・・・・・・・・・・・
昨日の続きで、、、独り立ちするには電源ケーブルも邪魔です。なのでバッテリー搭載を考えなきゃならない。
バッテリー乗っければいいだけなんだけど、ラムダの場合はバッテリー持続時間が活動時間というわけに行かない。
自律行動の結果である学習データがいちいち消えてしまっては学習のしようが無い。そこで、電源を切断することなくバッテリーを切り替える、または電源を切断することなく安定化電源供給に切り替える（またはその逆）ということができる必要がある。更には、バッテリーの過放電を防ぐため、ある程度の電圧の低下を感知して電源のシャットダウン（切り替えも含む）も出来なければならない。
つまり電源の二重化を実装しなきゃならないわけなんだけど、これが結構大変で、安定化電源の二重化ならばバランシングを行うということも考えられるが、バッテリーでは出力電圧の微調整ができないのでそれも無理。
電圧の違う（微妙に違う）バッテリーの出力を並列接続すると電圧が低い方のバッテリーに電流が流れ込んでしまうため、大電流が流れる事になりかねない。 それを防止するためにはダイオードオアを使うのが簡単だが、ダイオードでの電圧降下と発熱がイヤなのでその選択は無し。
採用を考えているのはFETでスイッチを構成し、マイコンで制御を行うという構成。先日の練習会で吉田さんの話を聞いてたときはふーん。。って感じだったんだけど、バッテリー乗せなきゃって考えた時に、「あれだな」と思いました。これだと明示的に切り替えられるし、ダイオードよりは電圧降下が少ない。
両方のFETをOFFにすれば電源スイッチオフも可能。注意点としては切り替え時に瞬断する危険があるのでスーパーキャパシターが必要か。
ただ、自分は電源回路をそのような構成で組んだことが無いのでチョンボると最悪ロード側につないだモノがすべて壊れてしまう大惨事も考えられる。よーく勉強しないと。。(-_-;)
「FETスイッチ」でググるとエアガンの世界に入っちゃうんですね。意外。そっちよりはモータードライブ回路の方が参考になります。モータードライブ回路から、高速スイッチングに関連する考慮が省けるかなぁってとこですね。
＃吉田さんが瞬断して不安定だって言っておられましたが、あれはハイサイドのスイッチ回路にNチャンネルFETを使ってるからではないでしょうか？ハイサイド回路にNチャンネルFETを使うとS－G電圧が不安定になるため、動作が不安定になるそうです。ハイサイドならPチャンネルを使うべきらしいです。
■１１月２１日■
どなたかのＨＰで301CRのCADデータをメーカーからもらったという話を読み、うちにももらえないか双葉電子にお願いしてみることにしました。
というのも、頭ユニットのサーボホーンの寸法がよくわからないのです。実測でCADデータを作っているのだが、作ってみると穴が合わない。仕方ないので穴を広げて取り付けているのだが、お陰で遊びが多く、あまりいい出来とは言えない。
もらったCADデータ。 問題のサーボホーンの穴位置は下3桁。キリのいい寸法にして欲しかったなー。もしかしてインチ？
・・・・・・・・・・
ラムダに自律でロボビリヤードをクリアさせるための基本機能を組み込んでいく。
今日は簡単にその場での方向変換を歩行ルーチンに書き加える。ラムダは直進・カーブ歩行はできるのだが、その場での旋回や横歩きはまだできないのだ。
コーディングはすぐに終わったのだが、どうもバグがある。1歩目が思うようにでないのだ。おかしいなぁ。
旋回歩行を試すうちにラムダを何度かこけさせたのだが、頭サーボのヒューズがビシビシとんでしまった。いま、ラムダの頭部分はあちらもこちらもぐらぐらです。でも、そのまんまで直してない。せっかく、CADデータがもらえたのできちんとした寸法の部品を作ってそれに取り替える時にネジも交換しましょう。
リミッターヒューズはちゃんと機能して、サーボが壊れないように働いているのだが、ちょっとプラネジ飛びすぎって感じだな。2本から3本に増やしてみようかな。
先日の練習会で教えてもらった圧着工具が届いたので早速圧着具合を試してみることに。
右の画像の左側が精密ペンチで曲げてはんだ付けしたもの、右が圧着工具でかしめたもの。
ストレインリリーフ部分がいまいちだが、かしめ部分はいい感じ。これではんだ付けしなくて済む。 かしめは専用工具でやらなきゃならないと思っていたのでうれしー。
それにしても、携帯でとった画像じゃこれが限界かな。昔に比べると綺麗になったなー。
・・・・・・・・・・
ラムダのその場での方向変換は無事バグが取れました。ラムダの歩行プログラムはテストプログラムが成長して今の形になったのだけれど、その名残の部分でおかしなことになってました。その辺りを整理して一応完成。
まだ、歩き始めの姿勢によっては一歩目が足ぶみになってしまったりするから手直しが必要だけど、これはもうなにがどうなっているかがわかっているから直すだけ。
当たり前かもしれないけど、前進・後退・その場旋回のそれぞれで安定した姿勢ってのが違う。理想的には姿勢に関係なく歩行できるべきなんだけど、ちょっと無理。
それぞれで安定している姿勢をチョイスして歩行モードにあわせてセットするようにしなければならない。モードが変わってから一歩目はその姿勢移行も行わなきゃならないわけだ。
次は～、何かな？立ち上がりをやりたいような気分ではあるのだが、歩行をセット化して色に向かって歩いていくってのをやってみるか？
アクションアイテムメニュー＜自律でのロボビリヤード完遂への道＞
■ その場旋回
□ 歩行セット化
□ こけた時の受け身
□ 立ち上がり
□ トラッキング歩行
□ 色いろいろ認識テーブル作成か、複色物体把握
□ 紙コップを持ち上げるとかはらうとかけるとか
□ どのコップがどこにあるか大体把握する頭脳
□ 適度なタイミングでまばたき
□ バッテリー搭載
ビリヤードやるのに「サラリーマン巡回問題」解けなきゃならないのか？と一瞬（ほんの一瞬ね）思ったが違うんだな。どの番号がどの座標にあるというのを覚えておけば最短距離の移動ができる。 あ、でも、直線の軌道だと倒しちゃいけないコップを倒してしまうから障害物回避も必要か。
□ 障害物回避（またはルート生成）
紙コップの番号の認識は、まずは色で。CDTは8チャンネルあるから8色まで色を見分けることが可能。だが、近い色（赤とピンクなど）は区別がつきにくい。そうすると３原色＋αくらいなのでその色の組み合わせで認識するのが簡単。 例えばロボカップのコーナーポストはそうなってる。
まばたきの動画
J1=0でのIK変換デモ
トラッキングデモ