PSoCセンサの動作確認。

先日製作したPSoCセンサのデータ受信側をコツコツ製作。回路は単純ですぐに用意できたが、問題はソフトウェア実装の通信処理。PSoCマイコンでセンサ基板から毎秒3000回、1.5Mbpsで1バイトずつ6回に分けて送信されるバイナリデータを受信すること、各種エラーのチェック (エラーフラグ、データ整合性) を手抜きせず行うことが、通信の要求仕様。

とりあえずC言語で受信割り込み処理を書いてみたが、あっさり玉砕。リストファイルでコンパイル後のアセンブラソースを見ると無駄な処理が多すぎで話にならないので、アセンブラで受信割り込み処理を書き直して再トライすると、今度は問題なし。送信側から毎回1ずつインクリメントするダミーデータを流してデータ抜け確認をしても問題なかったので一安心。ただし受信処理に処理能力の大半を喰われているため、他に同時にこなせる処理は限定されそうだ。デバッグ用に用意している液晶表示プログラムを使うと、データ抜けが発生。

動画も撮ってみた。Lが黒→灰の位置、Rが灰→黒の位置の生データ値で、センサとコースを20mm離した条件で動かしている。(実使用時は10mm前後を考えている) 理想は色が変わる位置をジャストで取得したいところだが、現状のセットアップでは左右とも狭くなる方向になっている。ハーフラインやクロスラインの認識も問題なし。直線番長ロボットでも作らない限りは確実に認識できるはず。
今後の細かい調整はプリント基板作成後とするが、PGAのゲインやコンパレータの閾値、LEDの点灯時間などはすべて実行時に変更可能であるので、悪さをしない範囲での自動調整にもトライしてみたい。

＃雑談１
個人的にアセンブラに手を出したのはSEVENの製作以来だが、やはり限られた能力を最大限に活かすにはアセンブラしかないと思ってしまった。PSoCは8ビットマイコンの中でも処理能力は貧弱な部類なので、アセンブラを使わないとソフトウェア依存の高速処理はすぐに限界を迎えてしまう。(なるべくソフトウェアに頼らずハードウェアでコトを済ませることが PSoCの価値を引き出すポイントでもある)　いきなりアセンブラで全体を構築することは容易ではないし開発効率も上がらないが、「このロジック、このアルゴリズムで最適」「処理速度面で置き換える意味がある」と判断できれば、積極的にアセンブラで置き換えてしまうべきかもしれない。

PSoC の開発環境である PSoC Designerは、ユーザがピックアップした機能 (PWM,ADC,...)の全てに対応するAPI を動的に生成する。このAPIを用いることでC言語やアセンブラから機能を手軽に使えるというのがこの開発環境のウリであるが、APIはアセンブラ記述であり、一見便利な機能ほど多くのソフトウェア処理で構築されていることがAPI実装を読むことで分かる。ADC機能を構成する処理の一部もソフトウェアになっていて、全体の処理が追いつかなくなるとADCの変換精度がおかしく‥など他のマイコンでは考えにくい事象も生じる。PSoC独自の機能が不要であれば、AVRやPICを使う方が楽で確実。

この手のマイコンでは、AVRが今一番情報もツールも揃っていて使いやすいと思う。各種データシートも日本語化されているし、このサイトのようなとても参考になる技術情報もある。このサイトの”AVR専用ライブラリ(for ASM projects)”のアセンブラ実装を見ると「これで出来るの!?」「なるほどな」と感心しきり。平方根の実装もスマート。ムリヤリC言語で置き換えた実装を作ってみると、アセンブラの利点がよく分かる (本来C言語でこんな実装はしない)。 H8もC言語では簡単にできない処理が一発でできる命令が沢山あるので、マイコンカーでもこの先ソフトウェアの複雑化、制御の高度化が進んでリソース面で追い込まれていくと、アセンブラによる実装を行う人が増えるのかもしれない。(第一回大会などは皆アセンブラ？)

＃雑談２
個人的なこれまでのSANYOの技術的な評価はバッテリー等を含めてかなり高かったが、昨年買った Xacti HD1A は‥これは全く人に薦めることができない。高速性は評価できるものの、室内撮影など暗所でのドットノイズが盛大な画質にはガッカリ。購入検討中の方は、この春に出るという次期モデルの評判を聞いてからでも遅くはないはず。上の動画は目立たないようにフィルタをかけたものの、ボケの無い鮮明な画像にすることは不可能‥(泣)

PSoC バイナリ受信の備忘録。

PSoCマイコンを使用しない人には役に立たない情報ではあるが、個人的な備忘録として PSoCでバイナリデータを受信する際の対応方法を書き残しておく。内容としてはこちらのブログに近い内容であるので、補足的な位置付けとなるだろうか。

PSoCの統合開発環境において、Device Editorで RX8 (またはUART) を使用した際、

• デフォルト設定
• "Enable interrupt generation control" が有効で、モジュールパラメータの "Interrupt API" を Enable した状態

のいずれかで Generate Application を実行すると、受信割り込みのためのコードが自動的に生成される。しかし、この受信割り込み処理は通信を介したコマンド＆パラメータの受信処理、つまり文字列受信のアプリケーションに適合するように作られており、バイナリ受信を想定していない。先に挙げたブログでは「バイナリーの受信割り込みができない」と記載されているが、より正確には「バイナリ受信用としては都合の悪い処理が、自動生成されたアセンブラコードに含まれている」というところだろうか。いずれにせよ、これは”仕様”であるし、この”仕様”を変えたい場合には自ら手を入れるしかない。

先のブログでは C言語による受信割り込みの実装を試みているので、先ずこの線で考えてみる。自動生成されたアセンブラコード rx8int.asm (ブロック名が"RX8"の場合) を見ると、 "IF (RX8_RXBUF_ENABLE)" として割り込み処理の実体やそこで使う変数の宣言が括られている。つまり、Device Editor 上で "RxCmdBuffer" を  Enable/Disable のいずれにするかで、標準の割り込み処理を使用するか否かを選択できることになる。一方で、rx8int.asm 内には、"Insert your custom code below this banner" という統合環境下の割り込み設定ではお馴染みの記述があり、指定された範囲に任意コードを記述すれば良いことが分かる。Cの関数にジャンプするなら "ljmp _isr_rx_interrupt" と書いて、Cソース側で"#pragma imterrupt isr_rx_interrupt" と後に続く "void isr_rx_interrupt()" 関数を用意すれば良い。
以上をまとめると、

1. 受信割り込みルーチンの生成を有効にする
2. "RxCmdBuffer" を Disable する
3. Generate Application を実行する
4. rx8...int.asm 側の "Insert your custom code..." に ljmp文を書く
5. Cソース側に #pragma interrupt ... 文と割り込み処理関数を用意する

の 5ステップで、C言語による受信割り込みの実装を書く準備が整うことになる。先のブログでは 4 の部分を boot.asm の内容変更で行う方法が紹介されているが、boot.asm に書いた内容は Generate Application を実行するたびに初期化されてしまう (変更箇所が無効になる) ため、他の割り込み処理と同様に ...int.asm 内の指定部分に ljmp を書くアプローチの方がスマートだろう。

上記の方法で C言語による割り込みの実装を書く場合、APIとして RX8_bReadRxStatus() と RX8_bReadRxData() の 2つを利用することになる。先のブログでは受信バッファレジスタの値を直接ユーザバッファにコピーするだけの例が示されているが、用途によってはこれだけでは色々と足りない部分が出ると思う。標準生成されるアセンブラコードによる割り込み処理を見てみると、

• 受信完了 (8ビット揃っているか否か)の確認処理
• 受信エラー(パリティ/オーバーラン/フレーミング)の確認・フラグ記録処理
• フレーミングエラー発生の場合の受信復帰処理(コントロールレジスタの RX8_RX_ENABLE ビットを一度クリアしてから再セット)
• 受信バッファ (Device Editorでサイズ指定) のオーバーラン確認処理

といった処理が、"文字列受信"のための処理(行末コードの認識etc) 以外に組み込まれている。受信バッファは別として前の3項目は必須ではないかと思われるが、これらを全てC言語で処理していては時間的に間に合わないというケースも考えられる。

ここまでの情報を統合すると、C言語ではなくアセンブラによる実装も難しくないことが分かる。元々、自動生成のコードに「バイナリ受信用としては都合の悪い処理」が入っているだけで、それらを取り除けば上記のエラー処理と受信バッファへの格納処理をそのまま使うこともできる。名前が"RX8" のとき、rx8int.asm 内の「都合の悪い」処理は

   tst  [RX8_fStatus],RX8_RX_BUF_CMDTERM
   jnz  .RESTORE_IDX_PP
　　‥中略‥
   jc   .RESTORE_IDX_PP
　ENDIF

の区間と、

   RAM_SETPAGE_IDX >RX8_aRxBuffer
   RAM_CHANGE_PAGE_MODE FLAG_PGMODE_10b
   mov  [X + RX8_aRxBuffer],00h
   RAM_CHANGE_PAGE_MODE FLAG_PGMODE_00b

の区間だろうか。
前者の区間でコマンド終端の認識や特定コード以降の無視などを実行していて、後者の区間では受信バッファが埋まった際に末端データをナルにして、後の文字処理に支障が出ないようにしている。これらをゴッソリ取り除くだけでバイナリ受信の支障はなくなり、かつ受信データ配列 RX8_aRxBuffer[] や受信カウンタ変数  RX8_bRxCnt、ステータス変数 RX8_fStatus  などの変更をアセンブラに任せることができ、残りの処理を C言語で行うとしてもエラー確認、ヘッダ確認、データ長確認、チェックコード確認などに抑えることができる。アセンブラの最後の受信バッファ更新部を変更して、リングバッファを組んでも良いだろう。
以上をまとめると、

1. 受信割り込みルーチンの生成を有効にする
2. "RxCmdBuffer" を Enable する
3. Generate Application を実行する
4. rx8int.asm から上記の”不要コード”を削除し、必要ならば小改造を加える
5. 4の内容に応じて、C言語側の実装を書く

という 5ステップで、自動生成されるアセンブラコードを利用してソフトを組むことができる。ただし 4 での変更は、再度 Generate Application をすると消えてしまう点に注意。確認は行っていないが、2を Disable として、"Insert your custom code..."の箇所に"不要コード"を削除したアセンブラコードをコピーしてしまえば、より良い方法になるものと思われる。5の内容については色々と考えられるが、

• 受信割り込みとして C言語の関数へ ljmp せず、main関数で以下をポーリング処理

1. 受信エラーあり or 受信バッファの先頭が規定のヘッダ値ではない → CmdReset
2. 1を通過したら、受信バイト数 RX8_BrxCnt が受信データ長以上となるまで何もしない
3. 2を満たしたら、受信データ全体についてチェックコード(チェックサム/CRC)で確認
4. 3を満たしたら、受信データを利用
5. CmdReset

という単純なパターンで済む場合は、"不要コード"を除いただけのアセンブラコードでも対応できる。いずれにせよアセンブラを用いる以上、無駄な処理を減らせるという利点を享受すべくアセンブラの割り込み関数から #pragmaなC言語の関数に ljmp する形にはしないことが重要だろう。

最後に余談だが、PSoC用のCコンパイラ (IMAGECRAFT製) はコンパイル前に "定数の畳み込み" の最適化をしてくれないことに今更ながら気付いた。

>　#define HOGE    (1+1)
>　...
>　nData = nData + 1 + HOGE;

と書くと今時のコンパイラは畳み込みの最適化で nDataに 3 を足すマシンコードを生成するものだが、このコンパイラは愚直に 1ずつ 3回足すコードを生成してくれる。「定数は計算を敢えて残して分かりやすく‥(実行時には畳み込まれているから関係ないし)」と考えていると無駄処理に足を取られる格好になるので、このコンパイラを用いる場合は要注意です。

PSoCセンサの試作評価。

マイコンカー競技を睨んだリニアイメージセンサ基板の試作を進めている。車体側の親基板にあると想定したPSoCマイコンに、センサ側の子基板にあるPSoCが”黒→灰の遷移位置”と”灰→黒の遷移位置”を通信で伝えることの成立性評価が目的。プリント基板を起こす前の部品定数検討・最適化、新しい信号処理ロジックの成立性評価、高速シリアル通信の成立性評価、外乱評価と対策検討が課題。
今日までの作業で、親基板は6V出力のACアダプタをレギュレートした電源のみ (採用予定の面実装リニアReg.を立てて使用、ドロップ電圧 0.4V) を設けて、子基板の製作と評価を実施。まず写真の状態で、新しい信号処理ロジックの成立を確認。そこからオシロスコープで波形を確認しつつフィルタの定数変更等を行い、より安定して位置を検出できる条件を決定していった。

今日は位置を約 3kHz の頻度で連続測定でき、測定データを親基板にRS485で出力できること、測定と通信のタイミングが設計どおり動作していることまでを確認したところで作業終了。明日以降で親基板に受信回路と受信データ処理を実装し、センサシステムとしての完成を目指す。H8とのインターフェイスは車庫入れロボット同様にパラレルI/Fとして、H8からはBUSY(更新中)でなければいつでも最新の位置データを取得できるようにする予定。

センサの電荷蓄積タイミングと同期したLED点灯も成立性があることを確認。蓄積時に点灯、読出し時に消灯することで、常時点灯に対し点灯時間はほぼ半減で省エネになるだろう。Dutyを変えて点灯時間を変えれば電荷量も制御できるので、基板を何センチか持ち上げていくと検出位置の左右が詰まってくる(中点は変わらないためトレースは可能) 動作を抑える対策にも応用できそうだ。

マイコンカーの世界ではFETのゲート制御にCPLDを用いる等の事例はあっても、基本的にはH8だけで全てを済ませるアプローチが普通であると思う。そして、H8だけでもその能力を使い切れば、十分に速いロボットが作れることが毎年のように大会で証明されている。一つで済ませることができれば、シンプル、小型、軽量、低コストと良いこと尽くめ。

しかしマイコンカーの世界を抜けて、実際のクルマの世界を見てみると、クルマの中はマイコンとそれが収まるECU(電子制御ユニット) が急増して大変なことになっている。本来、クルマでもECUが1個なら、人や荷物を収めるスペースを大きく取れるし、ECUやハーネスも減って軽量化できて低燃費にもなる。これが出来ない理由としては、

1. クルマの中ではセンサやアクチュエータがその目的を果たすための位置に置かれているが、その位置が”分散”しているため、これらにつながるECUもその近くに置かれてきた
2. 簡単な機能を担うECU同士は次第に一体化されているが、複雑な機能を担うECUを統合することは、マイコンの処理能力面、ソフト構築面、ハードウェア実装面で困難であり、なかなか統合できなかった

というような事柄があり、新機能が増える→ECUが増える→ECU間を結ぶハーネスも通信も増える、という構図が繰り返されてきた。最新のレクサス車では高速な制御用ネットワークだけで 8系統もあり、それらを”中継”するための ECUが3個もある。全体としての動作を簡単には説明できないだろうし、管理も大変、どこまでもECUを増やすというアプローチは限りなく破綻寸前という段階にある。

このような現実は何処の会社でも基本的には同じであり、いつか解決しなければならない課題であるため、近年では様々な”標準化団体”を介して”基盤技術”を共同で構築することで、最小限のリソースで課題を解決しようとしている。機能毎のECUは機能部分が”アプリ”として抽出され、それが共通規格のOSとECUの上で複数同時動作、ECU間は高速通信で結ばれる・・・丁度現在のPCのような世界となり、対決の土俵は”どのような新機能アプリを作るか”というソフトウェア主体となっていくが、ECUが1つになったりはせず、”解決したい問題をどのように機能分割して、それぞれどのECUで処理するか”という課題は残り、そのセンスは従来以上に問われる。

前置きがとても長くなったが、自分のマイコンカー活動ではこの”機能分割”の領域を、勉強のために敢えて導入するようにしている。機能は物理的に分割されると、その間のインターフェイスをどうするか、通信をどのように構築・実装するか、全体の時間成立性は・・・という新たな課題が発生し、全て一つで行う場合よりも問題が難しくなる。通信を含めて本業と重複するとことがあり、取り組むことに自己投資としての意義も感じられるため、今後もチャレンジ要素として維持していきたいと考えている。

”全て一つ”は”全て一人”でも同じだろうか。自分の最初の頃のロボット活動では「とにかく個別部品以外は全て自分で作らなければ、得るものが少ない」と考えていたが、その後にこのアプローチでは身に付かない領域があると気が付いた。一言では「分かる」の問題 と表せることだが、自分以外の設計者・製作者に”分かる”よう、望みのモノを手にすることが出来るようにに”専門外”の図面や説明を書いたり確認を取ったりすることも、ロボットに関わる中で学べる大事な要素の一つだと思う。

最速ロボットのレポートを見る。

J's Factory さんで、”大会には出場しない最速ロボットMCR2007仕様”が公開されていた。島津さんの公開レポートといえる内容、掲載に感謝。

神様の歴史を振り返る(?) ということで、以前に掲載されている 2003年仕様のページとざっくりと見比べて比較すると、変わっていない要素は使用モータ、ホイール、走行ギア比、バッテリ本数、液晶の搭載くらいだろうか。AWD化(四輪独立制御？)、ホイールベース拡大、タイヤ径アップ、サーボ減速構成の変更、プリント基板化、レギュレーション変化とスピード増に対応するセンサ追加‥目に付く個性は残しつつ、フルモデルチェンジで正常進化したという印象を受けた。

掲載されている画像を保存すると、実は大きな画像でびっくり。縮小表示されていたようだ。機構の造りが大いに参考になるので、まずこの視点で見ていく。サーボモータや前輪モータを支持する板は厚く頑丈そうで、シャシーとの接合基部は後方から伸びる金属製のロッドで強化されている。前後方向から見た構造も、前後とも□断面になるように結合されていて車軸付近でのロール剛性が高そうな感じ。ギアも操舵ギアの最終減速が真鍮製、駆動ギアも厚く、しっかりしている。以前の薄い駆動ギアは秋葉の千石電商でも売っており、「確か島津さんも使っていたし、これでも問題ないのかな」と思いつつも購入は見送っていたが、ご本人の説明によるとすぐに欠けてしまうものとのこと‥今後の散財可能性が一つ減りました。高強度で簡単に曲がらないシャフトが欲しいのは全参加者に共通かもしれない。しかし細かく見れば見るほど速いロボットになるほど生じる様々な問題 (各部の強度・剛性とそのバランス、コースアウト時のダメージ低減etc) にどう対処するか‥と考えて改良を重ねていった結果の構造・パーツになっていると捉えることができるし、自宅加工のノウハウも沢山含まれていると思われる。ナゼナゼ解析も兼ねて、6台目の3Dモデルとして模倣してみたい。

新しいセンサ群の構成と狙いも書かれており、こちらも参考になる。スタートバー検出用の”ベストテクノロジーの800mm光センサ”(KU381とこれは別物？自分も以前 KU381 を買おうとして見つからず、これを買いました) が浜松ホトニクスの変調センサと干渉するという件、これは未検証だったので先行情報として参考になった。消費電流の変動問題への対処も含めて、スタート専用とするならば島津さんのように電源を落としてしまう方向で検討したい。プレセンサは参加者の中で島津さんのようなセンサアーム取付け式のセンサと、シャシー取付け式の光学センサの二通りがあり、それぞれ一長一短があって迷うところ。検出の確実性はセンサアーム取付け式が上だと思うが、サーボ駆動に余裕が無ければ延長＆重量増加はダブルパンチで制御性に効いてくる。効果そのものは確実な減速とジャンプ量抑制に加えて、荷重移動による曲がりやすさの向上もあると考えられ、今年是非導入したい要素。 (導入の意味がある速さも追求したい)

最後の”感想”、個人的には今大会でも「重量はどうあるべきか」がはっきりと見えなかった。レーシングカーとしての常識では軽いに越したことはなく、JMCRでも直線加速では確実に優位に立てるはず。しかし問題は安定性で、”タイヤとコースのグリップ/適合性”と”制御難易度”の２つの点で、軽量路線は茨の道だと思う。後者は軽くなるほどにセンシングすべき要素、制御すべき対象、制御の精度と速さが増大してくるという点で実車と同じはずで改善の余地もまだあるはずだが、前者はタイヤ表面素材が事実上単一化されていることもあり、差別化の方向を出すことが難しい。接地面を横長に取る方向が良いとまでは感じても、タイヤ固さなどは重量(接地荷重)毎に固定的な条件に落ち着いていく気がしている。個人的にはまだ思い切った軽量化路線に走る段階ではないはず。基本が把握できていなければ軽量化により問題の原因分析がより難しくなり、軽量化で強度が落ちれば修復作業にも追われるはず。多少重くても確実に走るロボットを構築した後で軽量化を考えたい。

一周年。

気付けば今日で、このブログを開始してからちょうど一年。成果物まとめサイトも同じ日に立ち上げたため、こちらも満一年。Webでの情報発信に関してあまりマメとは言えない自分がブログなんて継続できるのか？と思っていましたが、内容は薄いもののなんとか一周年を迎えることができました。やはり継続的に見て頂いている皆様、同じように情報発信をされている方々のおかげで継続できたのだと思います。ありがとうございます。

次の一年では成果物まとめサイトについても、新規マイコンカーロボットの追加を含めてもう少し更新していくつもりです。こちらのアクセス状況を確認すると、検索サイトから様々なキーワードで個々のページへ直接たどり着いている方が多いのですが、「昇圧ICを探して来たのに、 ICの型番すら書いてない」という様な状況もあるようなので、随時補足や小修正を入れたりしています。ブログ側を含めて検索数の多いキーワード (昇圧関連、モータ駆動回路関連、アッカーマンステア関連etc) について、まとめサイトでもう少し踏み込んで解説することも考えてみます。

いろいろ。

昨夜はいつもより早く寝て、今日は朝5時半から名古屋に出張。帰りも遅くなるだろうな、と思っていたら思いのほか早く仕事が終わり、先日行こうとしていたアキバの店の午後7時閉店時間に何とか間に合った。目的の品を入手完了。日常の移動はクルマに頼りきりであるため、最近の出張の際は運動も兼ねて積極的に歩くようにしており、今日は10km以上歩いたはず‥良く眠れそう。

MCR公式サイトの全国大会レポートも読んでみた。このレポートは何方が書いているのだろう‥毎年”ただの報告レポート”に終わらせない文章力が垣間見える。”スネークロード”区間はこれまでの大会では無かったというのも意外。防衛大さんの「車体の形状がコースに合っていない」という内容も、詳細が気になった。優勝者の中村先生のコメントも印象に残る。確かに予選は確実に通過できるプラン、決勝トーナメントは確実に完走できる前提の下の高速走行プラン、これがきっちりと実践されて結果も出たという格好に見えたし、一番喜べる形の優勝であると思う。この成功が生徒への”一か八か”に頼らない指導にもつながるのだろう。「これだ」という”根拠のある自信”を貫くことができれば、結果がどうであれ、それを運ではない自身の実力としてしっかりと受け止めることができるはず。

TMCC様の新アップロード動画も確認開始。以前にアップロードされていた動画は「インターレースが解除されていないままプログレッシブ形式のエンコードをしたのかな？」という感じがしたが、今回の全体動画はいつも通り見やすくなっている。隠れ後輪駆動フアンとして気になっていたのは、TMCC会長様ととくながさんのロボットの走り。会長様はたこつぼカーブで如何にも後輪駆動っぽいオーバーステア挙動が出てしまい惜しくもコースアウト、とくながさんは予想以上の速さで予選コースを完走し、後輪駆動ロボットとして予選トップのタイム、しかしマシントラブル‥次回作が非常に楽しみ、自分にとって良い刺激にもなった。

ロボットランサーのルールは未だ公開されていないが、将来の参加を睨んだ"取材"計画を一歩進めた。土日でしっかり見ておこうということで、会場近くの宿も確保。ロボット分析用として昨年末に購入したMPEGカメラ も持ち込む‥640x480の解像度で60fpsのプログレッシブ記録ができる代物。マイコンカーのクランク/レーンチェンジ走行分析よりも先に、ランサーの走行分析に使うことになりそうだ。このくらいのモノでなければきちんと撮れないレベルの走り・動きかもしれないが、今年は”連覇”か”連覇阻止”かの構図もあるはずで、今から楽しみ。特に後者の動きが気になる、マイコンカー競技にも姿無し‥

大会動画を頂く。その２

TMCC様が砺波工業高校のWebサイトにて、追加の全国大会動画を公開されています。ありがとうございます。今回の動画はJMCR2007の予選および決勝とのこと、さっそくダウンロード開始。前回同様、あとで内容を分析してみます。

TMCC会長様のブログでは、阿佐美先生のロボット写真を発見。先日公式サイトの写真を整理した後で先生のロボットを探そうとして見つからず、分類を間違えたかな、とファイル検索をかけても見つからず‥元々サイト上に無いと分かりましたが、本日見ることができました。全日本ロボット相撲大会の動画では色々と噂の聞こえる、地に噛み付く”低速ロボット”に果敢に立ち向かう先生のロボットが‥優勢で一本取った後に Li-Poバッテリが音を上げてしまい三位を逃したのが残念ですが、これでバッテリ以外には大きな損傷が無かったとのこと、回路等の完成度もかなり高い模様。ラジコン部門の三位対決では”低速ロボット”に三豊さんが急所を見つけて高速アタック＆撃退成功！これはスカッとしました。次回はこういうシーンが自立でも見られるのかも。

同じく会長様のブログで、一部のディジタルセンサなロボットの車線変更走行の解説。つくづく車線変更の映像を良く見ていないことが判明‥気付いていなかった自分。会長様の解説どおり、ハーフラインを抜けた後にセンサ基板のトレース中心が変化。ディジタル式はこれが出来ることも有利、と車庫入れロボットの紹介の際には書いたけれども、実際にマイコンカー競技での適用例を目にすると、これは是非自分のセンサでも実現してみたいと思った‥良い動きです。

雑記。

本当に雑記、独り言です。

夜10時、出張より帰宅。仕事が早く終わったらアキバで買い忘れのギヤを買いたかったが、遅くなりすぎて閉店済みでアウト。来週末までの出張はあと三回、この期間のどこかで買いたい。

ロボットランサーのルールブックはいつ公開されるのだろう。昨年のルールブックを見ても的の突き方の可・不可が今ひとつ分からない。検索すると過去に「ヘンな突き方だ」と無効になった人も居るらしい‥動画を見ても速すぎて良く分からない、第一人者の”正道”がどうなのか直接見た方が良さそうだ。3月11日、中央大学理工学部キャンパス‥φ（。。)

神様がつぶやきを更新、新たな参加者レポートを募集されている。自分の後がとくながさん一人だけ‥こんなに少ないものとは思わなかった。参加者の皆様、是非‥しかし個人的に一番見たいのは、神様ロボットのレポートだったりする。ロボットの構成も未だじっくりと見たことが無い‥謎が多い。

他の方のブログを見ていると早くも新作があったりして、自分も新型ロボットを作りたい衝動に駆られる。しかし今年は昨年以上に、機構もちゃんと検討・検証を重ねて作らねば。車検に通らない、一番肝心な軸の支持剛性が無い‥これでは全然ダメ。四駆と後輪駆動、２パターンの設計を用意して比較したい。基本的な要素で迷いそうなのはホイールベース長、これも年々拡大傾向にあるのではなかろうか。ホイールベースは短い方が最低車高と重心を下げられるしクランク等で小回りも効いて良いのかなと思っていたが、全国大会にあったような細かい蛇行コースなどでは、(センサアームとの長さ比が同じなら)長いホイールベースのロボットより不利そうな感じ。真面目に蛇行してしまう。これで車体も軽かったら‥防衛大さんがヨー慣性を意図的に大きくしているのも分かる気がする。

改めて優勝者・中村先生の走りを見る。コース上でとても大きく見えるロボットだが、見かけによらず俊敏。決勝トーナメントのタイムを見ても僅かな右肩下がりだけ、安定している。勝負の場で、誰とも駆け引きをせず、運に頼らず、自身が安定して完走できると判断した設定を貫いたように見えるところが自分好みであり、模範としたいところ。

全国大会ロボットの写真を見る。

動画に続いて、JMCR公式サイトの写真集で公開された全国大会2007参加ロボットの画像を分析。まずは情報の整理ということで HTMLソースを秀丸エディタの高度な置換機能で整理して掲載情報をリスト化し、Excel で参加者一覧としてまとめ上げた。続いて全ての画像ファイルをツールでダウンロードし、参加者一覧の情報を用いたリネーム用バッチファイルでファイル名を <部門>_<所属名>_<氏名>_<ロボット名>_<ゼッケン番号>.jpg の形式に一括変更。これで画像ビュワーを用いても写真が見やすくなった。全体傾向の分析を開始。

(上記から"氏名"を除いたファイル名に変換するバッチファイルを以下に公開します。全ての画像ファイルがあるフォルダに置いてから実行してください)
バッチファイルのダウンロード

シャシー材料
全体的にCFRP素材を導入したロボットが増えている。アルミ素材でも A2017, A2024, A7075のジュラルミン系が増えているらしい。適切なサイズ、十分な強度・ねじれ剛性を維持した上での軽量化が今後更に進むのだろうか。

操舵系
センターピボット式が多いので、こちらから。操舵モータの横置きにチャレンジされている方も居られるが、RCサーボ使用を含めて縦置きパターンがほとんどで、防衛大さん系列を除いてはモータ出力軸が下に出る形式が多数派。防衛大・滝田教授の操舵系モータが増えている。タイヤとセンサアームが独立駆動になったのだろうか‥気になる。

Maxonモータ等で俺サーボ化している方の"モータ径"は全体に増大傾向だろうか。センサアームの長大化、S字やレーンチェンジでの高速走行への対応からモータへの要求トルクが増していると思われるが、特にアナログ式センサのロボットでは振り遅れ(位相遅れ)が致命的になるため、高トルクモータの必要性が高いはず。一般114さんや大沢野さんはダブルモータ。

モータのギアヘッド出力軸を最終段とするか、更にもう一段落とすかは、各車で対応が割れている。TMCC様は前者から後者へシフトする構想があるようだ。神様を含めて後者の速いロボットが多いことで、この形式の優位性が見えてきた感じ。

アッカーマンなどの非センターピボット式も調査。教科書的なアッカーマン式、junさんに代表される擬似アッカーマン式、パラレルリンク式、4WS形式、何処かで見たようなタイヤ付き多足式(?)と形式は多様。一般013さんは左右にRCサーボがあるが、どうなっているのだろう。一般092さんが4WS、前後操舵が独立か否かは不明だが、センサアームは独立駆動らしい。一般073さん等は擬似アッカーマン。一般104さんはベースが1/18のRCカーだろうか、デザイン賞。一般117さん等、タミヤF103の部品を使用？というロボットもちらほら。

全体を (1)RCサーボ・ピボット式、(2)俺サーボ・ピボット式、(3)非ピボット式、(4)その他(非4輪)、とざっくり分類すると、(1)が46.8パーセント、(2)が37.6パーセント、(3)が10.1パーセント、(4)が5.5パーセントとなった。キットカーと同様の構成が最も多いが、俺サーボ・ピボット式が多数派となる年も近いのではなかろうか。

駆動系
非ピボット式では擬似アッカーマン式の数台を除いては後輪駆動ロボットが多いが、ピボット式では全体的に四輪駆動形式が多く、特に俺サーボ化のグループで顕著。一般の部でも指定モータの使用者は多いが、非指定モータはMaxonのコアレスが多く、RE+ギアヘッド または RE-max+自前減速の構成が多い。防衛大さんの3台はPortescapのコアレスモータ?。

ライントレースセンサ
RCサーボ・ピボット式のグループでは、圧倒的にキット・ディジタル式が多い。自作ディジタル式の人との比は9対1程。見てすぐにアナログか？と思えたロボットは僅か1台だが、見た目では分からないものが若干あると思われる。(しかしRCサーボでの成立は厳‥実態はケースとギアだけ利用の俺サーボかも)

俺サーボ・ピボット式のグループでは、アナログ式を取り入れていると思われるロボットが多数派で、全体の65パーセント程度。15パーセントがキット・ディジタル式、残り20パーセントが自作ディジタル式と分析。非ピボット式のグループでは、キット・ディジタル式が7割近く、カメラ式1台を除いた残りがアナログ式。一般069とくながさんのように、前後方向に2列のアナログセンサを設けている(と思われる)ロボットも複数台見受けられた。

全体としてはディジタル式が多数派で、上位進出者に占めるディジタル式の比率も高いと感じる。アナログ式は何らかの"想定外"があると、ガラスの床が抜けてしまうような脆さがあり、あらゆる条件に対応できる仕上がりとするためには、ディジタル式以上に多くの実験(コース素材・外乱環境の違いetc)が必要であるはず。島津さんのようなアナログ神様となる道は険しい‥。

一般の部動画を分析。

TMCC様ご提供の動画、一般の部とアトラクションを分析していた。まずは全て640ｘ480のAVIファイルに変換し、1レース単位で分割。続いてトーナメント結果を参照し、勝ち上がっている方の走りで、タイムのより早い走行をピックアップ。中村さんは決勝トーナメントよりもアトラクションの2走行が早いため、こちらも全てピックアップ。最後に各人の走行における

(1) イン側 右レーンチェンジ通過後 90度左に曲がった地点～アウト側ゴール
(2) アウト側左レーンチェンジ通過後 左カーブが始まる地点～イン側ゴール

の2つの局面に着目し、頭を揃えて動画を切り出した。(1)は"Ω対決"、(2)は"蛇対決"と勝手に命名。結果として"Ω"と"蛇"を1セットとする動画が、中村さん×３(最終走行をPick)、藤坂さん×１、河野さん×１、杉谷さん×１、島津さん×１だけ出来上がった。2動画を同時にスロー再生できるプレーヤを用意し、誰が何処で速いのかを見る準備が整った。

＃その後この方法の時間ズレに気付いたので、4人の動画を1ファイルに編成しました。こんな状態です：

"Ω対決"で一番速いのは、島津さん。２番目に速い河野さんは前半の連続Ωで最も拮抗しておりほぼ互角、しかし最後の”登り～カーブ～下り～クランク”の区間で、しまさんが伸びている。３番目が中村さん・杉谷さんで、連続Ωから少しずつ差が開く。５番手の藤坂さんはさらに遅れている。

"蛇対決"で一番速いのは、またまた島津さん。２番目は河野さん、中村さんで拮抗、4番目は杉谷さん。島津さんは下り→登り→左90Rの後の区間(クランク×３、ヘアピン)で他者を引き離しているようだ。

カーブ走行でトップレベル、クランクを含めた込み入った局面で他者を引き離し、今回挙げていないゲート近くの直線加速やレーンチェンジでも速い‥島津プロの走りは驚愕のレベル。やはりマイコンカーの神様‥もし一般参加者であったなら”マイコンカー界のランス・アームストロング”な成績を残しているだろう。

しまさんロボットに高く聳える金字塔‥ではなくサーボモータが気になる人は自分だけではないようだ。一見して高重心‥しかし結果として速いことに違いはなく、JMCR用ロボットとしてのトータルバランスが優れていることも間違いない。あの位置には何か副次的効果が?とすら思えてしまう。しまさんやTARO君のロボット(やはり速い)は自分としても模倣しやすい構造に見える。今年は後輪駆動を考えていたが、マクソンギアヘッド＋最終減速ギアのピボット式ステア、長いセンサアーム、比較的ワイドなタイヤ、指定モータAWDという特徴をセットで取り入れる方向に軌道修正を検討。メカニカル構成では過度に凝り過ぎずに速いロボットを模倣、違いはセンサなど電装系とプログラムで出したい‥ここで崩壊する可能性も大いにあるが。

公式サイトの方でも良い仕事が。早くも全国大会出場ロボットの写真集がアップロードされています。今年は全国でもクリックで写真拡大、例年より良く見えます！ありがとうございます。

大会動画を頂く。その１

TMCC様の拠点、砺波工業高校のWebサイトにて、早くも全国大会の動画が公開されていました。ありがたい。動画は高校の部ベスト８、一般の部ベスト８、そしてアトラクションの３種類。早速ダウンロードして、トーナメント表を見ながら確認してみます。

大会結果を見る。

マイコンカーの公式サイトに、先日の全国大会の結果が掲載されていた。TMCC様など参加者の方々が既に伝えた情報に加え、予選の完走者と完走タイムも公開されている。

昨日、一般の部結果の速報を見て「いつもと違う」と思ったのが常勝・香川勢の不在だが、予選結果を見ると二位に 0.5秒以上差を付けての一位、しかも大会ベストタイム。一発勝負であるからこれでも設定を落としているのだろうが、速い。決勝トーナメントで設定を上げたときに波乱があったと思われるが、詳細は参加者の方のレポートに期待。このベストタイムの上を行くタイムを出した島津さんは、さすがプロ。神様の走行も見てみたい。高校生の部を含めた全体を見て感じたのが、九州勢の台頭。速さを見せていた昨年よりも更にレベルが上がった感じです。関東勢の一員、見習いの身として頑張らねば。

北海道放送のサイトでは、1分30秒ほどの動画が公開されていた。早速ダウンロードして見てみたが、流石に全国大会、皆さん速いです。junさんの左レーンチェンジ走行も動きが速過ぎて良く見えないため、AVIに変換してコマ送り‥センターラインが切れた途端ビシッと舵を切り、右タイヤがコース右一杯の所を狙って抜ける無駄の無いライン取り、流石ですね。

初仕事。

初仕事が終了、今年も一年頑張ろう。本業が成ってこその個人活動。

MCR全国大会の結果が気になる。某所の情報によれば今年も一般の部で色々と波乱があったらしく、1位が球磨工業の中村さん、2位が三洋メディコムソフトウェアの藤坂さん、3位が junさんであるらしい。公式サイトの結果発表が待たれる。公式レポートと大会参加者の結果報告も楽しみだ。

藤坂さんのサイト も連日チェックしていたが、周囲が壁の狭い部屋に、最悪条件?と言いたくなるような厳しいコースを敷いて走行を重ねていることに驚いていた。MCX-03 のようにRCサーボを載せてタミヤのプラ素材を多用したシンプルロボットであったはずだが、これで2位ならば素晴らしい。とかく複雑化の方向に走りがちな自分も、原点に立ち返って考え直した方が良いのかも‥と思えてきた。(全国大会では南関東地区大会に出場の「さめさめふぁいやー」でしょうね。勘違いでした)

以前に挙げた丸さんの記事 に「ソフトウェアエンジニアリング系の人にはロボット好きが多いと感じている」という話があったが、マイコンカーの世界でもアルゴリズムのバグ探しや問題の発生する条件探しに能力が発揮され、練度の高いソフトウェアに仕上げることが出来ていると思われる。実機＆複数条件によるソフト検証の必要性も改めて感じた。やはりマイコンカーはラリー競技であって、サーキット競技のように特定コースにピッタリ合わせ込む調整方法は、一発のタイムは出ても”抜け穴”を見落としてしまう危うい方法なのだろうか。少々の外乱や条件変化に影響を受け難い”ロバストなロボット”を如何にシンプルな構成で作り上げるか‥このロボット開発の方向性も面白そうだ。

電流検出によるフィードバックを用いたサーボ制御も、色々と詳細を詰めるとハードを複雑化しなければ中途半端な出来に終わる(メリットが薄い・無い)可能性が見えてきた。複雑化しても対象は競技ロボット、規模が大きくなって重くなったり良い位置に載せられなくなると、やはりメリットが無くなる。モータにエンコーダを直結し、累積の回転角度だけではなくモータ回転速度も得て逆起電力分の電圧を求め、これとバッテリ電圧から駆動電圧、これと抵抗値から駆動電流、と算出していくアプローチの方が、厳密ではなくとも全体として良いかもしれない。

マイコンカー電装系の検討。

JMCR全国大会へ参加する方々は北海道に向かう時機と思われるが、自分の正月連休は明日で終わり、作業を進める。今年は昨年の反省を活かして機構の検討よりも先に電装系から検討。以下のような基本方針(備忘録)を考えた上で、使用部品や回路構成の詳細をまとめている。

1.電源系
　□バッテリ
　　・KR-1100AAU電池8本を使用(試走/比較用にはIntellect 2000)
　□5V電源
　　・スイッチングReg.+LDO型リニアReg.で構成 (消費電流増加に対応)
　　・ICの最低動作電圧、リニアReg.電源リプル除去のf特を確認
　　・逆流防止ダイオード、電源変動抑制インダクタ、低インピーダンスコンデンサの導入
　□電源電圧監視
　　・バッテリ端子電圧(MUST)

2.センサ系
　□ラインセンサ
　　・マイコンとのI/Fをディジタル化
　　・非重力式のコース接地圧確保
　□マーカセンサ
　　・光変調型のセンサを使用
　□スタートゲートセンサ
　　・光学式センサ、ボディ取り付けで使用
　□坂道センサ
　　・センサ～コースの距離検出をベース
　　・登り/下りの始めと終わりを共に検出できること
　□操舵角センサ
　　・導電性プラスチック型ポテンショメータを使用、5kΩ以下
　　・配置位置に応じてバッファを入れる
　□車体速センサ
　　・100(400)PPR以上のロータリエンコーダを使用
　　・エンコーダ車輪を小型化しない
　　・設計上のロボット最高速とマイコンの最小入力パルス幅を考慮
　　・回転以外の自由度は上下のみで可、接圧維持を考慮
　□トルクセンサ
　　・電流センス式、正逆の電流を検出可能(オフセット出力)
　　・小型軽量化を考慮、ホール素子式よりシャント抵抗式
　□ヨーレートセンサ
　　・高レート対応可能でドリフト低減可能な振動ジャイロを導入

3.走行モータ系
　□使用モータ
　　・コアレスモータを使用(Maxon A-max or RE-max)
　　・停動トルク、回転数-トルク勾配を重視
　□モータ駆動
　　・2象限動作,端子間ショート,フリーが可能な構成
　　・インダクタンス調整/適切なスイッチング速度(リセット対策)
　　・トルク検出WANT

4.操舵モータ系
　□使用モータ
　　・コアレスモータを使用(Maxon RE-max or RE)
　　・十分なトルク余裕度、適度な慣性モーメントを重視
　□モータ駆動
　　・4象限動作が可能な構成
　　・インダクタンス調整/適切なスイッチング速度(リセット対策)
　　・トルク検出MUST

5.デバッグI/F
　□オンタイム解析
　　・内部状態表示(LED/ブザー)の導入
　　・着脱可能な開発用テレメトリ(無線)I/Fの導入
　□オフタイム解析
　　・EEPROM/NVRAMによるブラックボックス解析
　　・記録が高速なデバイスを検討
　□オンタイム調整
　　・走行モード、走行スピード設定用のスイッチ導入
　□オフタイム調整
　　・各種パラメータのEEPROM/NVRAMへの記録・コマンド通信I/Fの導入

6.その他
　□ESD/ノイズ対策
　　・電源ラインの低インピーダンス化
　　・ボディGNDと回路GNDの接続管理、ボディGNDのコース接地
　　・ガード配線の導入
　　・入力保護回路(過電圧保護/ノイズ吸収)の導入
　　・重要ラインの絶縁(擬似)を検討
　　・高インピーダンスのラインを引き回さない、必要に応じインピーダンス変換
　　・モータへのコンデンサ接続、モータケースGND処理、基板側モータノイズ対策の検討

坂道センサなど「最初の段階で必要になるか？」という要素もあるが、後から載せようにも載せられないという状況を避けるべく、最初から導入を前提としている。モータ類は候補を幾つか絞り込んでいるが、後輪駆動/AWDの最終決定は今回の全国大会の結果を見てから行うことにする。

リセット対策と静電気を含めたノイズ対策は、今回の最重要課題。コアレスモータは電気時定数が低いため、単体で PWM駆動周波数を下げて使うと低Dutyでも大電流が流れ込む。これでソフト対策も効かないリセット問題にはまる人が多いのかもしれないが、個人的に今回問題と捉えていることは電源ノイズとモータノイズ、そして静電気など外部からのノイズによる誤動作やリセット。ノイズ発生そのものを低減する対策を導入し、実際にノイズが入った場合に誤動作やデバイス故障を防ぐための対策も検討する。対策内容によっては通常動作時の特性に悪影響を与えるものもあり、バランス取りが必要になる。時間的に追い込まれると特にこの辺の作業ができなくなるが、今からならば実験する余裕もある。毎日コツコツ。

元日のご挨拶。

明けまして、おめでとうございます。
本年も宜しくお願いいたします。
MCR全国大会への参加者の皆様、最後の追い込み頑張ってください。