開発日誌(29)
■１１月２２日■
１月のわんだほーが中止になったので、次に何をやるか迷い中でした。
自律でダッシュ2000リベンジ、といっても計算歩行が一応の成果が出たので、あとはパイロンの位置から歩行行動を決定するだけのこと。そこんとこはほとんど去年と変わらないのでがんばってやっても面白くない。（という性格なんで物事が完成しないんですが。。(^^ゞ ）
本当はそうじゃなくて、例えばイベントに出場するとその場での様々な外乱（アクシデント含む）が完成度を上げていくってことは重々承知しているのだけど、モチベーションが上がらないことはなはだしく、無理やり進めるとものすごい時間浪費になることは体験的に知っているので無理に仕上げにかかることは避けてます。
ということで迷った結果、意識エンジンの検討を開始することにしました。
関東ロボット練習会で自己紹介するとき、「自律を目指してます。」って言ってるけど、いまのところ目指してないですからね。(^^ゞ そっちでもちゃんと成果を上げないと。
自覚はもちろん有って、最近では「計算歩行やってます。」と言ってたり。(^_^;)
歩行の方で言えば、フィードフォワード系は一応の成果を見たけれど、フィードバック系がありません。 今のラムダってセンサーまったくついてない完全なオープンループコントロールなんですよ。(>_<) ジャイロとか加速度センサーじゃなくて足裏センサーをつけてフィードバックしなきゃとは思ってるのでそこはぼちぼちと進めたいと思ってます。チョロメテが積んでる３軸力覚センサーを積もうかと思ってたんだけど、JinSatoさんに「すぐこわれるよー」と言われてやめることにしたので違うセンサーを考えることにしてます。（1個5万円するから簡単に壊れられるとツライ）
あとは、シグマかな。 シグマは不整地走破をさせようと作ったのだけど、現在では脳みそを抜かれて抜け殻状態なので動かさなきゃね。 なんか知らないけど、シグマは人気あるみたいなので、ラムダロボット研究所の看板ロボットになっちゃってる感じがあって不思議な感じです。 みんなシグマのこと、ラムダって呼ぶし。(^_^;) 今は簡単な歩容で歩かせているけど、6本足をフルに使ったモシャモシャした歩き方をさせるのも良いかなぁと画策中。 田中さんとバトルもしてみたいし。
意識エンジンの検討としては、やはりまずは認知系を検討しようかと考えてます。
デジタル化（抽象化）された情報を入力して述語論理とかオートマトンとかを使うつもりはなくて、アフォーダンス理論を参考に進めたいと思ってます。 情報入力は主に画像ベース。音ベースも興味深いけど、センサーが難しそうなのでもうちょっと検討が進んでから考えます。
アフォーダンス理論ってのは、自然界を哲学化（抽象化っていうと違う気がするので）したようなもので、人が生きていくのに衣食住が必要なのだけど、町じゃなきゃ生きていけないわけじゃなくて無人島で生きて行くこともできるよな。 って感じの理論です。 ・・・多分。 「世界を受け入れる」とか「自分も世界の一部だ」とかそういう表現も合ってるかもしれません。 って書いたけどちゃんと勉強したわけじゃない聞きかじりの上、自分の考えが重畳していておかしな言い回しになっているかと思うのでご注意を。
でも、今日のところは計算歩行の改良をやろうかと思ってます。 ラムダの計算歩行はまだ不安定で、路面状態に大きく左右されます。グリップ歩行が身上の計算歩行なのにグリップがある床（足裏）だとうまく歩けません。 多分、（計算上の）フィードバックをかけていないYAW軸のモーメントが影響しているのだと当たりをつけていたのだけど、みんなのロボットの足裏を見ると中央にだけグリップを持たせているロボット（サアガとか）があるのを見て確信に変わってきています。
まずは足裏にかかるYAW軸モーメントの計算をして実際のところどうなっているのか調べてみましょう。
関節負荷算出のプログラムを使って、足裏に仮想YAW軸を設定して足首に加わるYAW軸回転の負荷を計算しました。
左足軸足スタートでの計算なので、まず右足が前に出る際に左足にモーメントがかかり、続いて軸足が変わって右足に反対方向の負荷がかかっている様子が計算できています。 立ち上がりでギザッとなっているのは両足支持期間の部分だと思います。 実はここはちょっとどうすべきか判らない部分で、目標ZMPは軸足に移っているのだけれど、両足支持で立っている期間です。重心は移動を開始しているので負荷は急激に増加しているのだけど、足を上げ始めてちょっと乱れが出るようです。
計算してはみたのだけど、負荷が大きな股関節のロール軸などと比べると二桁ほど小さな値です。この負荷のせいで、姿勢に問題が起こるほどではないように感じるのだが、どうなんだろうか。
とりあえずは実験。 上半身を負荷と反対方向の加速度が生まれるように振ることでキャンセルできるかどうか。
■１１月２３日■
ラムダ・マーキュリーのアタマを作ったり、ケーブル整線したりしていて、何ヶ所か穴を開けたり設計が間違えていたりしたので設計データにフィードバック。 忘れた頃に部品作り直したりしたら違うのができてきたら困るので。
せっかくCADを立ち上げたので、ラムダの腰ピッチ軸の構造を変更しました。 腰をしっかりさせようと思って長穴リンク構造を採用したのだけど、詰めが甘くて余計にガタガタになってしまった。サーボと直結に変更。 サーボ直結の場合、サーボの動作範囲を限定するように機械的なストッパーが必要。 腰ピッチでのけぞるとSEMB1200Aをつぶしにかかるので、一大事だ。サーボ一つダメにしてもSEMBを守るべきだよな。
あとは腕の軸構成を変更できるように部品を設計して用意しておこうかと。 今の腕は肘にYAW軸がないので前後に動かす時には肩ピッチだけの単純な動きしか出来ない。 とりあえず困らないけど、肘YAW軸も欲しいなと思う瞬間があるのでブラケットを作っておきます。
その他、シグマの補強と構造変更。 これが一番手間がかかったかも。 根元のブラケットが弱すぎて、いくつかへしゃげてしまったのを整形してだましだまし使ってます。 板厚を増やしてネジ止め位置を変更して剛性アップです。
意識エンジンへの取り組みだが、まずは情報入力もとの画像処理に取り組まねばならない。
今回取り組むのは空間認知。 まずはハフ変換とFFTという古典的な処理で景色を分析しようと考えています。 ホントはステレオグラフで空間の奥行き情報が得られれば簡単かもしれないなぁと思っていたが、RPU-100の画像入力は1ポート。 ステレヲグラフに取り組むには、まずはLINUXでUVCカメラを2チャンネル動かしてからと思っていたのだが、もやねさんのところに2チャンネル分の画像を1チャンネルに重畳する回路があるやーん(*^_^*) 以前、フレーム毎に左右のカメラを切り替えるって回路を探してみたけどみつからなかったので諦めていた。 ものすごく簡単な回路でできるんだなー、知らないってのは罪だな。 早速部品を注文して2チャンネル画像に挑戦してみることに。
ただ、外部同期が可能なカメラってことで、秋月で一つ15000円もするカメラを2つ使わねばならない。 その上でかくてロボットに乗りそうにない。 まぁ研究だから仕方ないか。
■１１月２４日■
上半身の動きを作るには、質点モデルによるZMP導出計算で、腕の質点をサポートするようにしなければならない。 今も計算はしているのだが、腕は動かさない前提で作ってあるので、固定値（現在のサーボ角度）を使っている。 なので、前にならえのままで歩行計算することはできるのだが、腕を動かしながらの歩行計算は未サポートなのだ。
腕の動きを歩行計算に加えるに当たって、やっておきたいのが、歩行モーション生成関数の統合。 いままでは直進、カーブ、旋回、サイドステップ と4種類の歩行に対してそれぞれ関数を用意していた。 腕の動きは別関数で作れば特にこちらには影響ないのだが、ずーっと整理したいなぁと思っていたのでこの際思い切って整理することにした。
結構面倒なプログラムになっているので統合してハマるといやなので、十分に解析して統合出来る部分と統合できない部分を切り分けて、場合によっては記述も整理してなんとかいい感じに統合できた。 なんで自分で作ったプログラムを解析せねばならんのかよくわからんが、書いて3日も経つと他人のプログラムという格言があるくらいだからきっと仕方ないのだろう。(^^ゞ
統合は成功。 一発で正常に動きました。 よかったー。
さて、次は腕の動きを記述してみよう。とりあえずは単純に歩調にあわせてぶんぶんと前後に振る感じで。 さっさとやらないと注文している部品たちが届いてしまうな。(^_^;)
■１１月２９日■
先週は、予定では金曜日だけが出張＆飲み会だったはずなのに、水曜日から金曜日まで飲んで帰るはめになったため進捗がほとんどなし。
土曜日は国際ロボット展にコスプレ観に行ってたのでやっぱり飲んでたし。(^_^;)
SHRBは、お祭度が高くて楽しいですね。 でも参加は無理だな。 コスプレしばりはちょっとなぁ、キャラにないし。
今日は、ロボット展の帰りにUMIEさんから受け取った切り抜いたアルミ板を折り曲げてシグマのメンテナンス。 足の付け根部分の関節を補修しました。 今度は簡単には曲がらないはず。 他にも今回のシグマ手入れのポイントとなる部品を作ったのだけど土曜日に間に合わなかったので郵送で受け取ることに。 でも、よかったかも。 その部品も今日加工したら腰がいっちゃってたかもしれない。 しっかりとストレッチしとかなきゃ。(>_<)
その後は画像に取り組むためにカメラの接続をしたり。 あぁしまったな。カメラ用のサーボブラケットを改良するべきだった。これだけじゃ勿体ないから何かと一緒に作らなきゃならないけど、いつになることか。
カメラは無事つながったので、画像処理について色々試してみたいと思います。 正直ノープランなので成果が出せるかどうかわからない。
ステレオカメラはもうちょっと寝かせてから取り組むことにしよう。 なんかネタが多過ぎる。
■１１月３０日■
気を緩めると浮かぶ構想は新足構造。 そこはネタにストックしておいておいおい検討することにして、今は画像処理からの認知エンジンの構想を進めねば。
アイディアとしてはアフォーダンスを取り入れるってことで、まずは画像から直線を抜き出して床や壁を抽出（というか感じるというか）するということをやってみたい。
まっすぐな道が目の前にあるとします。 すると、道の稜線はハの字に形づくられて、先に行くほど道の稜線は狭まっていきます。 これが道。 もし舗装道がなくても、例えば林の中にまっすぐな通り道があったとしたら、木の根の部分を通り道に倣って結んでいくとハの字の線が見えてくる。 これはもう道なわけです、、舗装道じゃなくても。
で、家の中を見渡すと稜線がいっぱいあって、線だらけになります。縦の線は基本的には壁を表して、斜めの線は奥行きを表します。斜めの線が対照的なハの字になるように進むと「まっすぐ」進んでいることになるし、すごーく斜めの線があったら自分は「ななめ」に向いていることになります。
ちなみにディズニーランドは奥行きを表現するために奥に進むほどに道が狭くなっているんだそうです。人の認知力を利用したアイディアです。
この認知方法だけだと、もし床にひし形模様のカーペットが敷いてあったらだめなんですけどね。それはもっと進化したら理解できるようになります。
取り込んだ画像データを離散的に解析して結果として扱うだけじゃ「認知」とは言えなくて、時間の流れや前後の依存関係を処理しなければならないのだが、そこに対するアイディアが思い浮かばない。 ううむ。。。
■１２月２日■
シグマの改良。
機構部の改良が終わりました。
左右の足の形が変わりました。 これは。。
ぢゃぢゃん！
手になります。
ただ、まだカニ味噌脳みそがないので動きません。Coronで計算で動かしてみようかと思ってます。ただの逆キネなら十分じゃないかなーと思ってるんですが。
この手の爪の先からBB弾が出ればかっこいいんですけどねー。
■１２月８日■
久しぶりの日誌更新。 だけど、書く事ありません。
実は先週末に、仕事のプチ打ち上げが有ったのですが、なんだか盛り上がって徹夜でカラオケになってしまい、土曜日の昼に目覚めると風邪ひいてました。 (ーー;)
土日は安静にしてたのですが、月曜日まで尾を引いて今日社会復帰です。
休みの間に注文していたCoronが届いて、予定ではそれまでにシグマの構造の手直し部分を終了して、インターフェイス回路を組むって手はずだったのにまったく手付かず。。
ところで大日本技研と浅草ギ研が交戦状態になってますけど、シグマは出番あるのかなー。 戦場がロボスポットになるのならシグマは（オール非KONDOなので）出番なしです。 でも、BB弾ばらまいても大丈夫な場所ってちょっと思い当たらないな。 ちなみにシグマは屋外でもOKですよん。
ってことで、銃座を構えるのはちょっと様子見かな。
■１２月１０日■
昨日はこの暮れ初の忘年会。 メンバーがほとんど先輩だったのだけど、なんだかしらないが、お前ゴルフ始めろ！って話で盛り上がってしまいました。 じゃぁ、ドライバーとアイアンとパターくれるんならはじめますよーん。 と言っておきましたが相手は酔っ払いなので覚えてないだろうなぁ。
ゴルフの練習する時間もゴルフコースに出る時間もお金もないですってば(>_<)
今週末はロボット忘年会。 練習会はどうすっかなーと悩んでおりましたが、ロボワンセミナーを聞きに行くことに。 もし、土曜日一日がんばればコロンでシグマを動かせるってなら動かして忘年会に持っていくところですが、全然無理なので。。 セミナーは、恐らくはソフトの説明に終始しそうな予感がしないでもないのですが、、、お勉強お勉強。
やっぱり一番人気は初代ラムダ。 静止画だとシグマは迫力なし。 ラムダマーキュリーに到っては見向きもされませんでした。（文科系女子アンケート）
目は大切ですねー。 もし見せたのが動画だと順位変わるのかな。 ダッシュ2000の時のラムダが一番人気だったらそれはそれで。。
■１２月１３日■
昨日はROBO-ONEセミナー＆ロボット忘年会。
セミナーは正直なところそれほど興味なかったのですが、著名なみなさんが参加されるようだし、お手伝いの練習もあるって話なので行ってみました。 あと、シミュレーション環境も考える必要があんだろうなということで、「Go Simulation! 」の説明を聞いてみようかとか。
MATLABでシムリンク使ってロボットの運動解析できる人ってなかなかいないだろうなー、敷居高すぎ。それを簡単に説明しすぎ(^。^) LabViewは、あれば便利な気はするけど、ロボットビルダーの人たちは、「まず作ってみる」みたいなとこが強いので基礎実験繰り返して、、 ってのは合わなさそう。 いや、ロボットに積むって話だったか。 自分的には「無い」けど、あるのかなー？？ そしてGo Simulation!は、あれでバトルが出来るってのは面白いですね。今使っているモーションデータをテキストファイルかなんかで書き込めるのかな？ 処理サイクルが5ms固定というふうに聞こえたけど、可変にしないと物理シミュレーションには使えないですね。 ODEとかOpen-HRPでやるのとそれほど差が無さそうな感じ。 モデルエディター分は得？ どちらにしても自分でインターフェイス（外乱に対応した処理をシミュレータ上のロボットに戻す処理）書く必要があるのでシミュレーションパラメータが自由な分オープンな方がいいかも。
結局、刺激になったのは同じくセミナーに来ていたJinSatoさんや網野さんと会話したことでした。 竹馬ロボット実機で作りたくなってきたな。 あ、OnPCの申し込みはとっくに終わってるのかー。
セミナー後に秋葉原に移動して忘年会待ち。 ロボスポで武器商人田中さんから武器を受けとりました。 シグマにつけなきゃな。 ぴしいさんと田中さんでセンサーのテストをやってましたけど、まだまだ開戦までは時間かかりそうですね。 準備期間がありそうでよかった。
エアガンを撃ってみる。 ほどなく分解改造されるので、製品のカタチのままで弾が出るのは今日限りかもしれない。 電池が手元になかったので６Vを外部供給。 タタタタタ となかなかの音量で弾も当たったら痛そうな勢いですね。 アルミホイルじゃなくても破れるんじゃないですかね。的の素材をもうちょっと厚いシートにしても大丈夫ではないでしょうか。 的は機体の全周から撃てなくてはならないので色々と配慮が必要そうで難しそうだ。 田中さん、原稿用には今の案を整理して出して、本番用にはもうちょっと悩みましょうよ。 うちでも方法考えてみます。 ・・ってダメですかね。
そうそう、今月号のロボコンマガジンが送られてきました。田中さんの記事のお陰で一冊いただきました。(*^_^*) 最近、読んでなかったけど結構色んな分野の記事が載ってて面白いですね。少しさかのぼって読んでみようかな。
やっとコロンの環境をインストールして電源を入れてみました。 先週は風邪引く予定じゃなくて、シグマをコロンで動かす予定だったので通販で買ったのに、、 昨日買っても一緒だったなぁ。(^_^;) CPUであるSTM32のリファレンスマニュアルが英語だから大変だなぁと思ってたけど、日本語版がちゃんとあるんですね。あぶないあぶない。 それにしても、コンパイルして、バイナリーファイルにして、転送するのにそれぞれ違うツール使うって、統合環境じゃないですよね。 ツールがコマンドラインで動かせないタイプなのかな。
USARTの割り込みも期待通りの割り込み起因がありそうで安心しました。（買う前に調べとけって話ですが(^^ゞ ） これならUSARTからサーボにデータを送りながら合間にIK計算するプログラムが書けそうです。
あと、今回はRS485を1チャンネルだけ用意して、そこから全てのサーボにコマンドを送るつもりなのですが、72MHzで動いているSTM32ならばUSARTとしては2Mbpsまで出せるらしい。RS601の最高速度1Mbpsでやってみるか！？ 待てよ、・・・RS301が460kbpsまでしか出せないのであった。 最大でも460kかぁ。
Coronのサンプルプログラムを元に、STM32の割り込み関連を勉強してました。 サンプルプログラムを見渡しても、メインルーチンはなんだかそっけないのばっかり。タイマーの設定やら割り込みの設定やらは全て関数化してしまっている様子。 タイマーの設定はサーボ関連の初期化ルーチンに書いてあるのでまだ判るけど、割り込みベクターの設定は、stm32f10x_it.c → stm32f10x_vector.c と、階層化されていて、stm32f10x_it.cで、共通的なハンドラーを定義していて、そこからアプリ関数（ここではサーボ信号生成関数）を呼び出している。 そしてstm32f10x_vector.cで共通的なハンドラーのアドレスをベクター領域にセッティングするようになってる。
で、サンプル毎にstm32f10x_***ってソースは用意されていてそれぞれ必要に応じて書き換わってるんですね。
これは、マイコン初心者にはとっつき難い書き方じゃないかなー。 初心者はサンプルプログラムを参考にプログラムするのが基本だから、用意されているサンプルベースの、メインループで処理できるレベルのプログラムしか作れないのではないかな。 サンプルプログラムから割り込みを使ったプログラムを勉強するにはソースを深く読み込んでいく必要があって、それは仕組みを知っている人ならまだしも仕組みをきちんと理解できていない初心者には難しい。 サンプルプログラムには初心者にもすぐに使えるものと、初心者にはちょっとわからなくても、いずれ必要になる手法を盛り込んだものが欲しいです。 そういう意味ではマクロをバリバリ使ってるサンプルが多いけどあれもどうしたものかと思うことが多い。 最初のサンプルプログラムはmain.c上でマクロ定義までしちゃうくらいの方がいいと思うんだがなぁ。
■１２月１７日■
STM32勉強中。
なかなか時間が取れなくて勉強が進みません。 でも、会社の昼休みに日本語リファレンスをダウンロードしようとして見つけたWikiがすごく参考になりそう。
「ARMマイコン」のところでSTM32をいじっている記録が出ています。 USARTをDMAで使うサンプルも載っているので心強い。 では今回はDMAで動かしてみようかと思います。 いままでDMAがついているマイコンは使ったことがないのでよくわかってなかったのだけど、割り込み頻度を減らすことができるのでCPUは更にペリフェラス処理から開放されるので今回の使い方に対してはとても嬉しいことです。
ところで、この東京理科大学木村研究室のWikiページに掲載されている標準ペリフェラルライブラリに比べてCoronについてきたライブラリは日付が古い。 1年くらい古いんだけど、、他のソースとの絡みもあるから差し替えしない方がよさそうだな。 なんだか新しいライブラリの方がちょっとだけ判りやすいような気がして。。。
先日、マイコン初心者にはとっつき難い云々書きましたが、
各ドライバは、ペリフェラルの全ての機能をカバーする関数からなる。ドライバーは、構造体、関数、パラメータ名を標準化する共通のAPIになるよう開発された(命名規則や考え方が統一されていると言うこと)。ドライバのソースコードは「Strict ANSI-C」で開発された(サンプルプロジェクトは緩い?ANSI-C)。これ(Strict ANSI-C?)は完全に文書化されており、MISRA-C 2004準拠している。「Strict ANSI-C」で書かれているため、ツールチェインに依存せず使用することができる。
らしい。 素直にこのライブラリを使っていくべきなのだろう。 あまりマイコンには詳しくないのだが、初心者向きでは無いのかなぁ。今度平野さんに聞いてみよう。
■１２月１９日■
先ほどやっとUARTが設定どおりに動き出した。
なぜかUSARTがうまくつながらない、という状況がずーっと続いてまして、色々調べていました。 パソコン側の設定をマイコンの設定の1.5倍の速度にすればつながることが判ったのだけど、なぜ1.5倍になってしまうのかわかりませんでした。
オシロで確認したらマイコン側が設定の1.5倍の速度を出していることが判明。
ボーレート発信器の設定は標準ライブラリの関数がやっているのですが、もうなんだかあちこちを参照していてなにやってるかわからん。 なので、リファレンスマニュアルから手計算で出した設定値を使って試してみるとちゃんと設定速度になることが判りました。
関数のバグを疑ったけど、手計算で算出した値と照合すると一致している。 ふむ。。 どうもシステムクロックとして設定されている値がおかしいらしい、 ということで追いかけていくとHSE（外部クロック）が8MHzと設定されているのを発見。 Coronの基板を見ると12MHzの発信機が乗っている。 ということでこの設定を12MHzに直してみると設定どおりの速度が出るようになりました。
ソースを見ると、システムクロックとしては内部クロック(HSI)を使うことも出来るらしく、そちらは8MHz固定らしい。 でも、外部クロックをシステムクロックとして使うか内部クロックを使うかは、SWSというフラグで決まるらしく、これはハードウェア設定（回路で決まる）らしい。 ということで、このHSEの設定が回路と一致していないとダメだってことでした。 Coronについているサンプルプログラムの設定は恐らく全部 外部クロックが8MHzになっていると思われるので修正しておいた方がいいですね。
USBを使って仮想COMポートで通信することも出来るみたいだけど、そっちのクロックは外部クロックを使ってないのかなー。
＃いま、サンプルプログラムのconfファイルを調べていて、USARTを使ったサンプルがあることを始めて知った。(ーー;) でも、自分で作ったのと差は無くて、やはり設定の1.5倍で動いてます。(^_^;)
さて、これでやっとRS485をつなぐことが出来そうだ。 ふぅ。
Coronの開発環境ですが、全体的に使いにくいです。
まず、USBでの書き込みですが、書き込みモードにするにはスイッチを押しながら電源を入れる必要があります。 スイッチを押しながらリセットスイッチを押しても書き込みモードにはなるのですが、ちょっと落とし穴があります。
まず、書き込みモードにしてプログラムを書き込み、 リセットを押すとRUNモードになってプログラムが動きます。 次にプログラムを修正するために書き込みモードにするとき、いちいちUSBコネクタを抜いて、スイッチを押しながらコネクタを挿すというのがイヤなので、リセットスイッチで書き込みモードに移ります。 そして、書き込みを実行すると、WindowsXPが一瞬ブルースクリーンになって落ちてしまいます。
実は書き込みモードでUSB接続すると、デバイスとして認識するのですが、ただつなぐだけだとデバイスとして認識してくれません。 問題は書き込みモードでUSB接続した後にRUNモードになった時、USBデバイスとして開放されないので、再度書き込みモードになった時に再接続しないのです。 そのため、不整合が起こるらしくパニックになってしまうようです。
これはデバイスマネージャーを使って認識しているデバイスを一度「無効」にし、続いて「有効」にすることでコネクタを抜き挿しせずとも再接続できます。（ほかにも方法あるかも） この手順を忘れると一気に地獄行きです。(>_<)
あと、HEXファイルをDFU形式に変換するツール。 これが挙動不審です。 変換対象をいちいち設定しないでも、前回の設定を保持しているにも関わらず、再度設定しないと最新のファイルを読み込んでくれません。 どういう目的があってこんな仕様になっているのか判らない。 プログラムを変更してもプログラムの挙動がまったく変わらないのでしばらく悩んでしまった。
プログラム修正 → 書き込み → 実行 → 修正 ・・・ の繰り返しになるのは必至なのにちょっと作業が煩雑すぎるなぁ。 USARTがうまく行かない時（この作業を繰り返すのはうまく行かない時だし） 気持ちが切れそうになりました。
■１２月２０日■
タイマー割り込み、DMAでUSART送信、USART送信終了で割り込み、 までできました。
これでサーボにシリアルでデータを送るための基本的な仕組みは作れるはず。 いままではフタバサーボのシリアルコマンドで、ロングパケットと呼ぶマルチキャストパケットを使っていたのだが、ショートパケットと呼ばれるシングルキャストパケットを使おうと考えている。
これは、ロングパケットの場合、パケットが長くなるためパケットエラーを起こしやすいのでデータ抜けが多いだろうということと、アクノリッジメッセージを使ってデータを取得しようという目論むから。 アクノリッジメッセージを扱うには1サイクル中にサーボ数×2くらいの割り込みが必要になるのでタイミング的に問題ないのかどうかわからないので要検討だけど。。。
送信終了割り込みは、インターフェイスがRS485なのでDIR信号の制御のために必要。 最後ここでちょっとつまずいた。 今日のうちに出来てよかったー。
さて、シングルパケットをだらだらとつなげて送信してちゃんとそれぞれのサーボが受け取ってくれるのか、 だめなら割り込み数が激増です。
1サーボへの角度情報送信で10byte、24サーボくらいあるから240byte 460800bpsで送れば約5msで送れる。アクノリッジを扱えば返しのパケットを待つのでその倍くらい。。。 115200bpsだとちょっとキビシイ構成です。
年内にサーボ動かせるかなぁ〜。
■１２月２６日■
どうやら年内にサーボ動かせそうにありません。 予定している帰省もできるかどうか。。 きびしー！
■１月３日■
あけましたおめでとうございます。 今年もよろしくお願いします。
年末から仕事がやっかいな事になったので帰省も危ぶまれていたけど、なんとか予定通りに帰省。 2日のUターンピークに一晩かけて戻ってきました。
仕事納めのぎりぎりまで仕事であたふたしていたせいもあって、休み中は完全に色んなスイッチ切れてました。 てーことでロボットの方は年末からまったく進展なし。
年も明けたしそろそろスイッチ入れなきゃなー。
■１月４日■
今日から仕事始め。 行きかえりの電車は空いている。 みんなまだ休みなんだなー、いいなー。
重い腰を上げてやっとCoronのUARTにRS485ドライバーをつなぐ。 CoronはLVCCなので、ほんとはレベルコンバータが要るのだが、そのままMAX485につないでみる。 受信側はRPU-100。 ただただ受信して受信データを画面に表示するプログラムを動かす。
9600bpsで動かしてもデータは化け化け。半分くらいはまともに受信できているようなので、通信レートは間違いないみたい。
これはやっぱりレベルコンバータが要るみたいなのだが、それよりもLVCCで動くRS485トランシーバーをつなぐべきなんだろうなぁと思って探してみると、あるにはあったのだが、SSOP16なのでピン間隔が0.635mm。
SSOP16のユニバーサル基板での配線はSEMB1200Aのインターフェイス回路でやってみたけど、もうやりたくないなぁ。どうやらSOPのレベルコンバータをつけた方がよさげです。 どうせCSIでコントローラをつなぐのにもレベルコンバータが必要なんだし、配線量は増えるけどはんだ付けの失敗確率は減るからきっとこっちの方がお得だろう。
でもその前にうまく通信できないのはレベルの問題なのかを確認する必要があります。 とりあえずはCoronからの送信のテストなので、トランジスタ一つでのレベルコンバータで確認してみることにします。
■１月５日■
テスト用のレベルコンバータ回路を製作。
LVCC→VCC はトランジスタで、 VCC→LVCC は抵抗の分圧で変換。
こいつをかませてCoronとRPU-100の通信テスト。 なんか結果が思わしくないなぁ。 文字化け具合が昨日と同じ。 レベルコンバーター入れた分だけ動作は安定しているが、文字化けの原因はRPU-100側の受信タイミングが合わないのが問題らしい。
RPU-100のRS485ドライバーってマスターっぽく作られている感じなので受信専用のモニター的な使い方には適していない感じはするのだが、、 もう少しまともに動いてもいいと思うんだけどなぁ。
やはりRPU-100からデータを送って、それに応答するカタチにしないとタイミング合わないのかも。
RPU-100とCoronで通信するのが目的じゃないので、サーボを動かすテストに進みましょう。
Coronでもたもたやってるうちにラムダ・マーキュリーのZMP軌範歩行の方の、改良のアイディアや試してみたい構造が色々と沸いてきた。 正直、そっちをやりたいなぁ。 こっちはあんまり面白くないし〜(ーー;)
■１月１１日■
非常に仕事がやばい状態なのだが、10日は時間が取れたので練習会に参加。
ラムダを持って行っても歩かせるくらいしかやることがないので、Coronの勉強をしに行くことに。 オシロは持っていけないのでLEDとかスイッチとかはんだゴテなどの工作機材も持って行きました。 まったく使わなかったけど。
ちなみに、Coronの方は、UART受信にてフラグ待ちループでパソコンからの文字入力を待ち、入力された文字に応じた送信文字列を送信する、というプログラムがやっとできたくらい。 strcpyがうまく動かなかったのですが、何か特別な流儀があるのでしょうか？？ もしかして、string系の関数は全滅なのかなぁ。
あとは多分DMAでのUART受信ができれば一通りの道具が揃うのではないかと思います。 DMAのUARTはちょっと使いにくく、受信エラーに対する対処を考えておかねばなりません。 具体的にはあらかじめセットしておいたデータ数が受信されたら受信完了の割り込みが上がるので、返事が無い場合はそのまんまになる。 なので、受信開始時にはタイムアウト監視用のタイマーもスタートさせ、受信が出来なかった時に備える必要がある。 後はノイズなどで想定データ数以上の受信があった場合に対応して、受信開始時には受信バッファを空にしておかねばならない。
時間的な処理の流れを絵にしてみた。
データを送信している間や受信している間も、処理はmainにあるので計算を実行することができる。 ま、これでCoronでシグマの足6本の逆キネ計算がリアルにできるかどうかはわからんですけどね。
練習会には田中さんもぴしいさんも来ていたので、多脚ロボを使ったサバゲの打ち合わせが有りました。
田中さんぴしいさんはREMOのカメラで操縦するってことなのでシグマもカメラを積んでやりたい。やっぱ戦車戦なら視界の悪さが重要ですからねー。
微弱電波トランスミッターでのモニターだとチャンネルが取れないとか違法とかで、合法で多チャンネルの通信が必要。 REMOはブルートゥースなので問題ないし、シグマはRPU-100が、、、、あれ？ RPU-100を積むならCoron要らないやん。 えぇとぉ〜。
平野さんの話によるとIPカメラってのがあって、監視用カメラでイーサや無線LANが使えるのがあるとの事なので調べてみた。
IPC-100ってのが安いようだが手に入りそうにない。 若松で叩き売りのIPカメラは5000円くらいだが、どちらも対応する無線LANカードが不明。 組み込み用のモジュール類は数万するので除外。 結局はプラネックスの安物のIPカメラがよさげだ。
CS-W04G最安値で8000円弱。 他のはリスクあるけどこれは多分動くだろう。プラネックスだと初期不良が心配かも(^_^;) ちょっと大きいけどシグマになら積めるはず。
もっといいのが有るなら教えてください。情報お待ちしてます。
RS485は半二重通信なので送信イネーブル信号を制御しなければなりません。 送信する間だけイネーブル信号をONにします。 信号をディスエーブルするのは「送信データをセットしたら、」ではなく、「送信データを送り終わったら、」なので、送信終了割り込みをかけてディスエーブルするようにします。 そうなっているかどうか、オシロで確認。
「send-a\r\n」というデータを送っています。「\r\n」はコンソールに表示したときに改行させるための制御コードです。
データ1バイトはスタートビットとストップビット合わせて10ビットです。 まずスタートビット0が出たあと、8ビット分のデータが送り出され、最後にストップビット1が出ます。「s」は16進数では73h、2進数では01110011です。UARTでは0ビット目(LSB)から送り出されるので「0110011101」で、｢s」一文字分です。
そして、上側の線が送信イネーブル信号でして、最後の0Ahを送り終えてストップビットが出た後にディスエーブル（ローレベル）になってます。
ここまではどうやらうまく行ってるみたいだ。 さて次はDMAでUART受信。 1バイトずつ受信してエコーバックを返すプログラムを作ってみることに。
DMAでUART受信はどうやらできた。 設定した文字数の受信を行うとメッセージを吐くようになりました。 ただし、フラグ監視している状態です。 DMA完了で割り込みを上げるようにしたいのだが、そこがまだうまく行かない。 もう少しだと思うのだがなぁ。 明日になると、またしばらく時間が取れないだろうから名残惜しいが、今日はこれで終了ですね。
■１月１７日■
依然として仕事が大変なことになってます。 恐らく今月いっぱいは大変なままだ〜。 昨日も出社してまして、未読メールを読んでいて気がついたのだが、まだ年が明けて2週間しか経ってないと。。 自分の中では確実に2ヶ月は経っている感覚。 なんなんだろうなぁ。 普段どれだけのほほんと過ごしてるんだよって感じです。
今日は仕事に行かなくて済んだので、UARTの受信をDMAで行って、受信完了で割り込みを上げるっていうのの続きをやっておりました。
どうにもこうにもうまく行かない。 割り込みコントローラの優先順位設定の設定がよくわからないのでここが怪しいと思ったのだが、ドキュメントが英語しかない。 どうもプライオリティグループというのと、プリエンプションプライオリティとサブプライオリティというのがあってどう使い分けするのかがよくわからん。
プライオリティグループというのは5グループあって、プリエンプションプライオリティとサブプライオリティの扱い数が異なるようなのだが、プリエンプションとサブの使い分けがわからん。どうせ順位が着くんだから1階層でいいんじゃないのかなー。 それ以上は追求してないのでわからず仕舞い。
結局優先度設定も問題ない様子。 フラグ待ちで動作させていて、一つおかしい動作をするところがあって、その追求に乗り出してみる。 DMA設定の初期設定での受信文字数と、一度受信してからの受信文字数を変えているのだが、初期設定の受信文字数は無視されるのだ。 おかしいな。 一度も送信していない状態で、送信完了の割り込みが上がっていることになる。 調べてみると、確かにプログラムを動かして一度も送信せずとも送信完了割り込みが発生している。 なんだろなこれは？ DMA受信の問題とは直接関係なさそうなので、追及はやめておく。
次に割り込みハンドラーの登録を追いかけてみると、 なんと、ヘッダーファイルで宣言している関数名と定義している関数名が違う！ なんだこれーやっと問題見つけたよ。やっぱりライブラリ新しくしないとだめじゃーん。 と思って修正したが結果は変わらず。 定義している関数名でベクターテーブルは設定されていたので実害なしです。 でもこれは正しておいた方がよいのでは？ ＞ テクノロード殿
最新のライブラリには色んなサンプルがついているので参考になるのがないかと探していると、割り込みコントローラのサンプルでDMAでUART受信で転送完了で割り込みっていうのがありました。 このサンプルと読み比べながら間違い探しをしてみたが、大きな違いは見つけられない。 各種宣言の順序をあわせてみたりしたがダメ。
細部にわたって記述を合わせて行ったら、とうとう転送完了での割り込みができるようになりました。 結局、キモになったのは、割り込みが発生して、次の受信の設定をする際にDMA設定をやり直すのですが、そのときに割り込み設定もしなくてはならないということらしい。 UART送信完了では割り込みイネーブルは初期設定だけでその後はずっと生きているのにDMAだとだめなんですね。 たぶん、DMAの再設定を必要としないサーキュラーモードなら初期設定が生きるのだろうけど、次回の受信文字数が変わる場合があるわけだからサーキュラーモードは使えない。
だとすると、一度は割り込みが発生するはずなのに、なぜ？ と考えると、、、さっきの送信完了割り込みのせいだ！ あれのせいで初期設定で行ったDMA割り込み設定が解除されてしまっていたのだ。 やれやれだぜ。
さて、今日はこの辺で。 明日の朝の会議の資料作らなきゃ。昨日、早く帰りたかったので仕事を持って帰っちゃったのでした。でも、昨日はまったくロボット開発はせずじまい。早く、といっても帰ったら9時。寝るまで撮りためテレビ番組見たりホゲぇ〜っとしておりました。
■１月２４日■
一週間ぶりの日誌更新。
更新のなかった一週間、ロボット開発は一切行っていないので日誌更新することもできませんでした。
今週は思い切って土日とも休むことに。 でも、土曜日は何をやっていても眠くて倒れそうになってしまうので諦めて一日脳みその休養。 ずーーーとテレビを見てました。テレビを見ていていつの間にか寝てしまうのって気持ちいいんですよね。 座りすぎて腰が痛くなってしまった。
今日は脳みそも回復したので、ロボット開発に着手。 UARTで操作するセンサーモジュールの動作確認をしたかったのだが、コンソールじゃ簡単にはできないコマンド体系なので、ついでにCoronでプログラムを作って確認することに。
Coronは、5本あるUARTのうち2本が使えるようになっているのだが、そのほかにUSBポートもバーチャルCOMポートとして使える。 UARTの出力はLVCCロジックレベルなので、普通のUSBシリアル変換ポートではつなげられない。 人によってはUSBのバーチャルCOMポートの方が便利な場合が多いだろう。
そう思い、お試しにUSBのバーチャルCOMポートを動かしてみたのだが、これまた書き込みモードとバーチャルCOMポートの行き来がわずらわしい。 書き込みモードから一度コネクタを抜いて、再度PCのUSBに接続しなければCOMポートとして認識しない。 更に、認識した状態でテラTERMの設定をしなければうまく接続できない。
便利かなーと思って試してみたUSBだが、これはイマイチかな。 普通のUARTの方がいいな。 さらにはUSBの設定って結構大変で、よく判らない関数がもれなくついてきてわずらわしい。
モジュールとの接続プログラムは、UART2をPCとの通信に、UART3をセンサーモジュールに接続することを前提にプログラムを作る。 センサーモジュールがうまく動かせるかどうかが判らないのでCoron側のプログラムデバッグもやりにくい。 そこで、UART3のRXとTXを接続し、折り返し状態にしてCoron側のデバッグを行ってからセンサーモジュールを動かす事にした。
センサーモジュールのUART仕様が8ビット奇数パリティ2ストップビット といういままでに扱ったことが無い設定だったのだが、パリティがある割りになぜか、30hというデータがB0ｈに化けてしまう。（パリティエラービットのチェックをやってないからそのまま通るわけなのだが） 30hの部分を2Fhにしても31hにしてもちゃんと送受信できるのに30hだとダメ。
オシロで確認すると、どうもB0hと送っているように見えるのだが、、、 おかしいなぁとSTM32のマクロを調べると、UARTの設定には、8ビットデータと9ビットデータという設定があって普通あるはずの7ビットデータという設定がない。 もしや、と思いリファレンスマニュアルを調べると8ビットデータ設定でパリティを有効にするとデータは7ビットになってしまうようだ。 この場合9ビットデータと設定しなければならないらしい。
パリティなんて使ったことないけど、パリティービットを合わせて8ビットデータという表現は合ってるのかな？ ちょっと違和感あるんだけどなぁ。 それにデータ長が7ビットになるならB0hって出るのは変だろう。（パリティービットを入れて表現するのか？）
それにしてもこの部分、折り返しでデバッグしてなかったら、オシロを持ってなかったら、動かない動かないって悩むばかりで問題に気付くのにどれくらいの時間がかかったかわからない（自分の経験不足も含めてだが。） マイコン工作するには、安物でもいいからオシロは用意しておいた方がいいですね。 いままで使わないでもなんとか動かせてきたけど、今回はオシロ大活躍です。
その後、センサーモジュールから取り出したセンサーデータを分析するのに、エクセルに取り込んでグラフ化しようとしたのだけど、16進数表記の文字列を10進数に変換する関数ってのがインストールされていない。 CDからアドインを入れようとしてもうまく入らない、入らない。。
ネットを徘徊すること2時間あまり、 結局諦めてPerlでスクリプト処理してしまった。 ものの数分で10進数に変換できてしまいました。最初からこうすればよかったな。 でも取り込んだ16進数データがおかしくて、やりたかったデータ確認はできませんでしたが。
結局、今日もサーボを動かすことは叶わず。 ま、でもセンサーモジュールを動かしたプログラムを使えばサーボを動かすプログラムは簡単にできるはずなので、今度時間が取れたときこそはサーボを動かせるはずです。
■２月１日■
とうとう週１の更新もできなくなってしまった。
この週末、臥せっておりましてロボット開発はとうとう出来ずです。 土曜日の早朝から吐き気で目が覚め、下痢、発熱と相成り、土日を安静に過ごす羽目になりました。仕事は相変らず落ち着かないので月曜日から活動できたのは幸いなのですが、ロボット的には最後の砦の土日も侵食された感じでがっくりです。
イガアさんの多脚ロボットがロポタルの動画にアップされてますね。 さすがイガアさん、機動力抜群っぽいですよ。やっぱ軽く作って機敏に動くと良いですねー、 考えると戦車戦だとウェイトってあるだけ損ですね。格闘と違うから。 重い分、装甲厚くして守備力を上げるようにしないとバランス取れないかも知れないですね。 格闘だとウェイト軽くしてもポイント稼ぐことが出来なかったのに対して、銃撃戦だとウェイト重くしてもいいことなし。 これは真逆な関係になってしまったかも。
■２月７日■
今日は事務所が全館停電のため仕事は休みです。
昨日も深夜帰宅で３時くらいまで起きていたけど、今朝は８時前には起きだしてロボット開発(*^_^*)
遅く帰った夜もちょっとだけプログラムを書いて寝たりしていたので、あとはボードをつないで動かしてみるだけ。
↑こーんな感じで、ケーブルにひっかかると机から雪崩落ちる感じの作業環境ですが、サーボは無事動き出しました。いまんとこレベル変換しないでもまともに動いてますね。（通信速度は460800bps)
サーボからのアクノリッジパケット処理などはまだ組み込んでいないのですが、当面は送信一本でシグマ動かすところまで進めるべきなのかなぁ。
無線コントローラとの通信用のSPIを動かすのが先かな。
ラムダの場合は、ロングパケットと呼ばれるマルチコマンドで一度に複数サーボのデータを送っていました。一応、サーボの動作同期を取るつもりでやっていたのですが、ロングパケットだと通信に失敗する場合も多いようで、万全と言うわけじゃありませんでした。
今回はショートパケットと呼ばれる一つのサーボへのコマンドを順に送っていく方式で実装しようと思います。これだと通信エラーを起こしても一つのサーボだけで済むので、全体の動作への影響が小さいのではないかなぁと思っています。 同期動作にしても、多脚ロボットの場合は同期はどうでもよさそうなので気にしないことにします。多分2足でも問題ないし。
ショートパケットにするので、アクノリッジパケットに現在の角度データを載せて来てもらって、角度フィードバックを受けたいなと思ってます。
調べると、フタバのプロトコルではアクノリッジパケット（リターンパケット）にレジスタ値を乗せてくる場合は、あらかじめグルーピングされたレジスタセットでしか取得できません。 現在角度が欲しい場合はそれに連なる18byteのデータがセットになっています。
角度だけを欲しい場合はレジスタと長さをセットにして、データ送信要求コマンドを送ることになりますので、動作コマンドとは別に角度取得用コマンドを送る必要があります。
上のオシロの画像は、上がトリガー用に送信イネーブル信号、下がサーボから帰ってきたリターンパケットを見ています。 左が、レジスタグループデータ18byteデータです。ヘッダーが付いているので、送られてくるデータは26byteです。 右はデータ取得コマンドの場合、 要求したデータは2byteだけど、送られてくるデータは10byteになってしまいます。
オシロの画面の１マスが200usなので、左の場合だと1.2ms、右の場合だと0.7msくらい。 右の場合は角度コマンドも送るので、角度コマンドだけで0.3msくらいなので、サーボ当たりマージン含めて、1.1msくらい。
左の場合だとセットになって送られてくるデータに、サーボ温度や、負荷などの情報も入ってくるのでお得ですね。
計画では20msインターバルで動かそうと思っていたのですが、RS485×１回線だと難しそうです。 ちなみにサーボの通信速度はRS300シリーズの上限が460800bpsなのでこれ以上の高速化は無理。 RS601は1Mbpsまでいけるんですけどねぇ。
RS485を2回線にするか、データ取得頻度を落とすか、なんですけどね。できれば頻度は落としたくないので、RS485×2回線の方向で検討してみます。
このCPUはUSARTを5本もっているのだけど、Coronで使えるUSARTは2本だけ。 1本はモニター用においておきたいので、他のUSART/UARTのピンアサインを調べてみると、UART4もUART5もSDIOに割り当てられちゃってるんですね。USART1のオルタネート側がモーターインターフェイスに割り当てられている。ピンヘッダに直接出てきているわけじゃないので意味ないか。 USART1はどこにも使われていないようなので引き出せれば使えるかも。
■２月１０日■
明日も出勤です。(T_T)
大日本技研の田中さんから多足でサバゲ参加表明者あてメールがきました。 14日の練習会でやるプレゼンの件です。
はぁぁ〜、そんなこんなで全然進んでないんですよね。 サバゲ開戦は春ごろってことなのでなんとか間に合わせねば。 初夏にはわんだほーだからそっちもあるんだよなぁ、ああ困った困った。
サバゲではカメラ視点で操縦するって事で、ネットワークカメラを買ってみた。 随分前にアマゾンで注文したけど、全然届かないので注文取り消して、アマゾンで出品しているショップに注文して買ったものです。(^_^;) 7980円でした。
これなら回線が被らなくて済むはず。IPアドレス分ければいいわけだし。 ただし、同じAPに複数台つないだ状態で、どの程度の動画が見れるのかは疑問だけど。
と、思って買ったのだが、、デカイ！寸法見てそのくらいならまぁいいかぁと思って買ったのだが実物見るとデカイです。 分解してみると、カメラ部分は別基板になっていてケーブルで接続していたので、カメラだけケーブルで引っ張り出して本体はロボット胴体に寝かせて取り付けられそう。ヨカッタ。
開けたついでに基板を眺めていました。カメラ基板は普通のボードカメラ（NTSCなど）かな？と思って載ってるチップを調べてみると、USB1.1だった。 USBも組み込みの内部ペリフェラルインターフェイスとして使われるんだな。1.1でもまぁ十分に高速だもんなぁなどと感心してました。
■２月１３日■
忙しかった仕事が半分終わった。 いままでは問題対策の検討だったので先が見えない作業だったが、これからは対策を折り込むという具体策なので随分と楽。 ちょっと時間も取れるようになるかも。
昨日、実験の待ち時間があったので本屋で物色していたら、トラ技別冊でdsPICの本があった。 ほほう、これがもやねさんが使っていたDSP内臓のPICかぁ、これならデジタル信号処理ラクラクってことかぁ。 と立ち読みすること数分で、買って変えることに。 当時の付録基板付きで、別売りの基板もいまだにマルツで売っているようです。そこまで揃えるかどうかは別としてデジタルフィルターの入門にはいいかも。 もやねさんのブログによると行列計算までDSPでできるらしいし、奥が深そうだ。
音を扱えるのなら、機械振動なぞ問題じゃないはずだから使い道ありそう。
明日の練習会はどうしようか、シグマは未だに脳無し状態だし、練習会に行くと開発進まないし、でもプレゼン大会もあるし、飲み会にも行きたいんだよなー。 参加表明人数が多すぎるので、とりあえず練習会はよしておいて、プレゼン大会はネット放送で見よう。（ネット放送やるのかな？） 時間があれば飲み会の頃行こうかな。 今後も時間取れないかもしれないので、開発優先で。
とかいいながら、今夜はレイトショーで「アバター」観に行ってきました。 リピーターが出るほどの人気だし、３Ｄだし、映画館で見といた方がよいかなと思っていたのだが、もうそろそろいつ終わってもおかしくない時期だし、、、 ということで急遽マイカルを予約。 一番後ろの席だったけど快適に見れました。 久しぶりに楽しめる映画だったなー。撮影のメイキング見て知ったけど、いまどきは表情もキャプチャーしてＣＧに反映するんですねー。すごい。
あ、そうだ。午前中はまだ練習会行くつもりだったので、ラムダ・マーキュリーの整備をしていました。 胴体ピッチ軸を長穴リンクにしていたのだけど、どうも失敗で、ガタを吸収するつもりが、ガタが大きくなってしまっていた。 長穴で減速するほどでもないからサーボダイレクトに切り替えました。 部品は随分前に切り出し済みだったんだけど、曲げ加工していなかったのを曲げて、タップ立てて、取り付けました。
長穴リンクは可逆域で使わなきゃだめですね。非可逆域で使ってたのが失敗の原因だったと思う。
■２月１４日■
今日は練習会だったが、行くのはやめてプログラミング。 あとオリンピック観戦。 上村選手４位入賞おめでとうございます。高速ターンを手に入れるのが一年早過ぎたんだろうな。他の選手が追随して追い抜いちゃったんじゃなかろうか。
インターバルタイマーからサーボを叩けるように作ったのだが、今回はリターンパケットをもらわない前提で、ショートパケットを連続で送り出すようにしてみた。 ２個のサーボでテストをして、出来たかな？ってところで５個に増やしたところ動作不具合が。 同時にON OFFはできるのに同時に動かそうとすると、３個しか動かない。 うむむ、、 短いON OFFコマンドは５個動くのにちょっと長い角度指定コマンドだと３個、 それも５個分のうしろの３個が動いて前の２個が動かない。 ふむむ、、 ならば、と角度と時間を指定していたところを角度だけにしてみると、、、５個動く。 つまり、ショートパケットをつないで送り出しても、サーボは全部受け取ってからコマンド解析するわけだ。 試しに１個のサーボに正規のコマンドに続けて無意味なヌルデータをつけて送ってみたところ、１２バイトの正規データに対して無効データを加えて５０バイトまでは正常に動作するが６０バイトになると動かない。
自分でパーサ作った時は前から処理するようにしたんだけどな。 全部受けてから処理する意味ってなんだろう？ 確か、以前に「チェックサムデータを受け取った時点で動き出す」と聞いた覚えがあるんだがなぁ。 まぁよい。 問題はサーボがどういう条件で受信を終了するのか？ 時間なのか、送信イネーブルが切れればよいのか。 時間だと面倒だな。
■２月１５日■
眠気とだるさが尋常じゃなかったので残業を切り上げて帰ってきました。 帰ると結構回復しちゃうんですね、これ。
昨日の続きでサーボ制御プログラム。 １サーボ毎に送信終了で送信イネーブルを落とすようにプログラムを修正。 これでだめならサーボ毎に時間を空けてみなければならない。 そうなるとタイマーも出動になるのでめんどくさいなー。
と、思っていたら送信イネーブルを一度落とすだけでいいみたい。 サーボ５個のテストは難なくクリア。 では、ということでシグマの全サーボをつないでみる。
今回は460800bpsで動かすので、ID設定とボーレート設定を変更。
やっと爪の先までサーボにトルクを入れることができました。 よかったよかった(^_^;)
まだ基板はテスト基板なんですけどね。
さて、基板製作にかかるとするか。 今回は、3本ずつじゃなくて2本ずつ動かすって歩容と、両手を上げた状態で4本足で歩く歩容を作りたい。 4本足は重心移動がいるのでちょっとだけ面倒。
■２月２１日■
パソコンのバックアップを取っている合間にミニ電動を改造。 不要部分を切り取ってシグマに搭載できるカタチにする。
シリンダーを動かすギアの逆転防止ノッチがあるんだけど、これを外しちゃうかどうかでちょっと迷う。 これ取っちゃうときっとジャムり易くなるんだろうなぁとか思いながらも削除。 だめなら別途逆転防止を考えるってことで。
まだカメラもマイコンもセンサーも載っていないのでもっともっとアタマがでかくなる予定。カメラは銃身の上に配置だな。左右にスイングする軸を設けるかどうか。 自由度イッパイつけても操作できないかもしれないしなぁ。 とりあえず砲台は回転できないようにします。 歩きながら横に撃てないか？と思ったが、シグマはどっちの方向にも歩けるから相対的には大丈夫なはず。 そこまでの実装ができるかどうかが問題か(^_^;)
銃身はもっと切り詰めたいなぁ、田中さんに聞くと威力が落ちるって話だけど、どんなもんだろう。 短くするのはいつでもできるからとりあえずこのままで。
こうなってくると、早く動かしてカメラ画像見ながら操縦してみたくなりますね。
そういや、昨日今日はお手伝いロボットの予選決勝なんですね。 観に行きたいけどなぁ、昨日の予選の方が本番っぽいからな。昨日は仕事だったので、どっちにしても観に行けなかったけどすっかり忘れてた。(>_<)
右に写ってるのがCoronです。大きさ対比用。
サーボ制御部のコーディングが出来たので、次は逆キネ。 逆キネのデバッグではロボット動かしたいのでマイコンやら電源やらRS485インターフェイスやらをシグマに組み込むために工作しなきゃならないな。
いつもはドロッパーで希望の電圧を作るんだけど、放熱板とかつけたくないし、素子の発熱が気になるし、なので、スイッチング電源を作ってみました。Coronは大した電流食わないけど、SEMB1200とかは大食いなので、３AのスイッチングレギュレータICをチョイス。 インダクターも３A以上流せるやつにしたらこんなにでかくなってしまった。 データシートによると固定電圧（５V）なら効率８０％らしい。 コロンは基板に３．３Ｖのレギュレータもってて、入力電圧は９Vくらいまで受け付ける。 SEMBも同じようなもの。いや、SEMBは5Vも作ってるから５Vじゃダメだったかな？
Coronには容量が大きすぎるので、この電源でミニ電動も動かしちゃおうってことで、出力電圧は６Vに調整しました。ちなみに出力電圧を調整すると効率は７５％に下がっちゃう。 最初、データシートどおりにフィードバック抵抗を計算したのに出力電圧が全然合わない。 フィードバック電圧もデータシートと違う値が出ているし。。 おっかしーなー、こんな簡単なので間違ってしまったのか？ と色々チェックしたが間違いは見つからない。 固定電圧に設定を変えるとちゃんと動くので素子は壊れていない様子。
ふと内部回路図を見るとデータシートにあるフィードバック電圧って素子内部の電圧に見える。 おかしいぞ？とデータシートを疑い始めて、内部回路図を参考にしてフィードバック抵抗値を計算してみると、ちゃんと思い通りの電圧が出始めました。 電流を流しても電圧は急変しないみたいだし、大丈夫だと思うのだが。。
ちなみに手元にある抵抗値の関係で、出力電圧は６．２Vになりました。 これでミニ電動動かすと５．８Vに垂下します。 テスターで見る限り問題なさそうだけどオシロでチェックしておいた方がいいかも。
１Aの素子も買っとこう。
■２月２２日■
とうとう仕事から早く帰ってこれたので、プログラミング。
今日は逆キネの組み込みを進めたのだが、以前のシグマのプログラムからそのまま流用。 軸の符号が逆なのでそこだけ修正。 今回のシグマは足と腕があって、関節間距離が違うので2種類の関数が必要。 変数にして共用することもできるが、計算量を減らすにはそれぞれ用の関数を用意した方がよい。 腕は左右対称だから厳密には3種類になっちゃうか？ さすがに腕の左右の差は切り替えて使うべきだな。
逆キネのデバッグするためにコンソールに変数の値を表示するのだが、やはりというかなんというかprintf族が使えないらしい。 デバッグに先立ってintとfloatの数値表示ができるように。 この辺は提供されていると、開発やりやすいんですが〜。 （もしかしてどっかに入ってるのかな？）
■２月２５日■
少し残業したのだが、まぁまだ宵の口だから今日はRS485変換部分のモジュールを作ろうと思って帰ってきたのだが、机に着いたのが１１時、レギュレータの選定してたら１２時になってしまった。 その上、このモジュール用にハープビッチのユニバーサル基板をいい感じの大きさに切り出していたのだが、熟慮の結果フルピッチのユニバーサル基板で作るべきだとの結論に達したため、今日の工作は打ち切り。
なんとなく何の達成感も得られないのはイヤなのでシグマ用に買っておいたXBeeの設定をしたり。
これで適当につないでいたので、気がつくと接続が切れてしまっていたモニター接続が無線でつながることに。
シグマのコントロールはいつものGロボのコントローラをつなぐつもりなのだが、残弾数表示や被弾状態のデータ通信用にXBeeが必要。 なんなら操縦もこれで出来るけど、GUIインターフェイス作らないとダメだからGロボコントローラつなぐ方が楽だろうな。
微々たる達成感を以って今日は寝ることに(^_^;)
昨日、上京してきた友人と科学未来館で月に２回行われている産総研のロボット研究室の見学ツアーに参加してきました。
２眼カメラでの3次元空間認識やマイクアレイによる音源認識のデモ、レーザーレンジセンサーを搭載した車輪型ロボットのデモなどを見てきました。
２眼カメラでの3次元空間認識は面白いですね。 やりたいと思っている空間認識とは関連性があるので参考になりました。 マイクアレイによる音源認識は、3方向から同時に発している音を聞き分けて、それぞれの音をほぼ完全に分離できていました。 あれは雑踏の中での音声認識に使えそう。 同じ方向からの声は聞き分けられないので万能ではないのだが、十分に実用になると思いました。 今みたいにマイクに口を近づけなければ音声を聞き取ってくれない状況は打開できそうです。 ただし、分離の原理が音速による到達時間の差を使っているため、マイク間距離にある程度の寸法が必要になるため、小型化は出来ないのが難点かな。
昨日は、そのあと秋葉原に買い物に行って、また台場に戻って大江戸温泉で夜を明かしました。 友人がロボット開発をやりたいって事で今回のイベントが勃発したのですが、研究系の話なので２足歩行ロボットとはちょっと離れた開発になりそうです。 画像認識系になりそうなので成果が出たら参考にしたいです。
シグマの方はRS485ボード、電源分配ボードが出来て、もうすぐバッテリーで動き出します。 あ、Coronへの電源供給のケーブルが出来てなかった。 せっかく秋葉原行ったのにコネクタ買い忘れたかも。
いつもは1枚のユニバーサルボードにインターフェイスとか電源回路を組んで実装するのだが、今回は機能別に小さなモジュールにしてケーブルでつなぐ方法にしようかと思ってます。 その方があとで流用が効くし、ロボットに収容する時も絶縁して、隙間に押し込むという感じでいいかなーと。
テストで動かすと逆キネ動作がおかしい。。 こないだ最後に修正したのが失敗だったか。 なかなか歩かないなぁ〜(>_<)