PlaceEngineはGPSを補えるか？

GPS単体測位の位置精度は「仕様通り」に精度が出て５～１５ｍ程度で、時間が経過するにつれて衛星の位置が変わるので計測している自分の位置もどんどん動いていきます。安いGPSアンテナを使っているとしょうがないのかなぁと思いつつ、PlaceEngineみたいな位置情報サービスを使ったらGPSの位置計測結果のばらつきを補えないかなぁ、と思いました。

その、PlaceEngineというのは、無線LANのアクセスポイントから送信される電波の信号強度を使って自分がいる位置を計測してしまおうというシロモノ。詳しいことはリンク先を見ていただくとして、最近は公衆無線LANのサービスやFON、家庭用の無線LANが普及してきたので、結構いろいろなところで使えるんじゃないかと目論んだわけです。

しかし、リスクもいくつか思いつきました。例えばこんなリスク。

• 無線LAN(Wi-Fi)のアクセスポイントが無い場所では使えない。当たり前ですが。
• PlaceEngineサーバに登録されていないアクセスポイントは計測に使えない。
• 位置の精度は５～１００ｍ程度らしい。

では、つくばチャレンジが開催されるエキスポセンター付近でどれくらい無線LANのアクセスポイントがあるでしょうか。これは現地に行って、コース上で実測してみないと何とも言えませんが、このblogにまとめられている公衆無線LANアクセスポイントからたどってみると、TXのつくば駅は無線LANサービスを行っており、今年のコースの折り返し地点付近ではオークラフロンティアホテルつくばでHOT SPOTサービスが、FONマップを見るとエキスポセンター付近でFONを使っている人がちらほら。コースに沿った場所ではつくば市中央図書館でフレッツ・スポットのサービスが提供されているようなので、こんな感じで結構使えるんじゃないかと予想しています。ただし、無線LANの電波はあまり遠くに飛ばないのでコース上の特定の場所でしか使えないかもしれません。

そうなんですけど、ちょっと裏技的なアイデアとしては、今年のつくばチャレンジの事務局テントに無線LANアクセスポイントの箱が山積みになっているのを見かけたので、きっとつくばチャレンジの中継ストリーミング放送かなにかで無線LANのアクセスポイントを用意していたのではないかと。これに乗じてしまえば・・・というアイデアは試走会では使えないのでリスキーですね。

PlaceEngineサーバに登録されていないアクセスポイントについては、PlaceEngineクライアントを使って位置情報を取得した後「位置を教える」でPlaceEngineサーバに情報を送ればOKなので、そんなに問題無いと思います。

位置精度も、PlaceEngineクライアントを自分のノートPCにインストールして試してみたら、最初に出た位置は200m以上ずれていましたが、「位置を教える」で位置情報を修正したら2回目以降は教えた場所を指すようになったのでいい感じです。こういうやり方でコース上の位置情報をPlaceEngineサーバに多数教え込んでおけば、GPSと違って時間変化しない情報なので、位置情報のばらつきを抑え込めるんじゃないかと期待しています。ただし、これは無線LANのアクセスポイントが見つかれば、の話です。先ほどアパートの玄関からノートPC片手に表に出て位置計測を試してみたら無線LANのアクセスポイントが見つからず、位置計測できませんでした。なので、つくばチャレンジのコース上でアクセスポイントが見つかるかどうかは、現地で計測してみないとわかりません。

PlaceEngine APIを使ってローカルマシン上でプログラムからPlaceEngineを使えるようなので、ロボットの自己位置計測に使えるかどうか試してみる価値はあるんじゃないかと思います。

いろいろ気づいたこと

今年のつくばチャレンジが終わったので完全OFFモードに入りたいところですが、その前に今年度の反省と参加レポート作成を片付けようと思い、いろいろまとめ始めました。で、その参加レポートには書かないような雑多なことを覚書としてここに書いておこうと思います。

■ 出走までの待ち時間について

今回はトライアルで係員に呼ばれてから出走するまでの待ち時間が３０分くらいありました。前のチームが出発してから３分後に次のチームが出発していて、１０チームくらいが待っていたということで３０分です。このまっている間、ノートPCの電源を入れっぱなしにしているのでバッテリがどんどん減っていきます。コントローラとしてロボット上にノートPCを載せているロボットはバッテリ残量がすごく気になると思いますし、私も気になりました。出走を待つチームの数は５チームくらいで十分なのではないでしょうか。

■ 電源の確保について

参加チーム数が５０チームもあると事務局側で屋外用電源を確保できないということで、試走会の段階から各チームで電源をなんとかすることになっており、うちのチームは自動車用の鉛蓄電池とDC-ACインバータを使ってノートPC用のAC電源を確保しました。使用した鉛蓄電池は近所のホームセンターで買ってきた 38B19L（28Ah)で、バイク用のバッテリより容量が大きくて安かったからという理由で選んだのですが、結果的にはもうちょっと容量が大きいものを選んだ方が良かったようです。朝９時からA4サイズノートPC１台、VAIO C1Xを１台つないで、午後３時くらいには電源供給を継続できないレベルにまで電圧が下がってしまいました。ロボメカショップ店長の岩崎さんによると、自動車用のバッテリはセルモータを回す際にガツンと電流が流れるように設計されているため、今回のような用途にはボートなどに使われるディープサイクルバッテリの方が適している、とのこと。他チームは発電機を持ち込んでいるところが多かったようです。

■ エキスポセンター敷地内の導線について

ここでいう導線というのは人の通り道のことです。今回はエキスポセンターの敷地に入ってすぐの場所に本部テントが設営され、その奥のゲートを通ってバックヤードに行けるようになっていました。しかし、バックヤードに行くには通れるルートがそこしかないので、エキスポんセンターの敷地外からバックヤードに行こうとすると常に本部テント前を通るという導線設計になっていました。いや、導線なんて考えていなかったからそうなったのでしょう。（私はプランターや柵を飛び越えて出入りしていましたが。）

■ ロボットの外装について

ほとんどのチームが雨対策も兼ねて外装をしっかり作っていたので驚きました。特に、クジラ、パンダ、ウサギなど、キャラクター性のある外装は非常に重要ですね。ネギを振らせるチームが無かったのは残念。

長くなったのでこの辺でやめます。

つくばチャレンジ2008 結果

今年も、と言ってしまうと何ですが、我がチームはトライアルを突破できずにつくばチャレンジを終えました。

とりあえず、うちのチームがどうだったかなんて関係なく、全体的な結果を知りたいという方のためにこちらから。

■ トライアル結果　
http://picasaweb.google.co.jp/t.tomiyama.1976/200811#5271444966253515346

■ 本走行結果
http://picasaweb.google.co.jp/t.tomiyama.1976/200811#5271451260459546690

ここのblogは写真のサイズが 1MBを超えるとアップロードできないので、写真はPicasaのほうで見てください。

見ていただいてわかるとおり、20日（木）のトライアルでは登録５０チーム、出場４７チームのうち２２チームが１００ｍを走りきって21日の本走行に進みました。トライアルのチャンスは2回あるのですが、結果を見てみると17チームが1回目でクリアしており、2回目でクリアしたチームが5チームにとどまりました。一番早く１００ｍを走ったのは北陽電機・産総研ジョイントチームで1分46秒、一番遅かったのは宇都宮大尾崎研究室で8分1秒。平均は計算していませんが、大体３～５分くらいのチームが多かったようです。

21日の本走行は、完走できたのはヤマハチームのみという厳しい結果でした。ただし、公式記録としては完走でないものの、金沢工業高専チームのLove itは止まることなく、コースアウトすることなくゴールまで戻ってきました。Love itは折り返し地点を少し手前で折り返してしまったため走行距離の記録が４５０ｍになっています。しかし、３台のロボットとすれ違う際に自律的に衝突を回避してゴールまで戻ってきたのですから、技術的には立派に完走したといってもよいのではないかと思います。そんな金沢工業高専チームにはバンダイナムコホールディングスの社長、高須武男さんからバンダイナムコ賞が贈られました。（ヤマハチームには、つくば市長賞が贈られました。）

うちはと言いますと、ロボットNo.03の「移動ロボット開発日記」チームなのですが、1回目はエキスポセンターの門を出られず、門と売店の間にロボットが入って行ったため走行を中止しました。2回目は出走直前になって電源系のトラブルにより走行ができなくなり、棄権しました。したがって、結果は１０ｍ。その電源系のトラブルというのは、Top-URG用に14.4Vから12Vを作っている三端子レギュレータの足が破断してしまい、電力を供給できなくなっていたというもの。写真で指さしている部分がそれです。

1回目のトライアルが失敗したのはウェイポイントの置き方なのか障害物回避なのか、分析はこれから進めますが、かなり本質的な問題点によるものだと考えています。それに対して2回目のトライアルができなかったところは完全に設計ミスによるもので、以前からそこがちょっとまずいことはわかっていたのに手直しをしなかった。そしてそこが大切な時に壊れたという、なるべくしてなった結果でした。

油田先生の話ではまた来年もコースを少し変えてつくばチャレンジを開催するようですから、少なくとも完走するまではつくばチャレンジに挑戦し続けようと思います。

さ～て、プロジェクトのまとめと参加レポートでも書くか！

これから出発します

つくばチャレンジの本番がちかいせいなのか、blogのアクセス解析を見るとこのblogに「つくばチャレンジ」というキーワードで検索エンジンから飛んでくる方が多いようです。

今日は水曜日なので定時退社してきました。これからつくばチャレンジ事務局に提出する書類をそろえて、荷物を積み込んで、つくば市に向けて出発します。

残念ながらうちのチームは明日のトライアル参加が私ひとりになってしまうので、安全管理責任者を出してもらえるよう事務局側にお願いしてあります。平日２日間をつかうのは、社会人にとって参加しずらいです。この辺りは来年なんとかしてもらえたら嬉しいです。

結果は帰ってきてから報告します。

試走会、安全対策、そして運の悪い日

１６日の日曜日は、つくばチャレンジ本番前の最後の日曜日なので、しっかり試走をしてこようと試走会に参加しました。

朝７：００くらいにマヒソンさんを迎えに行ったら、コンビニの駐車場で車をバックさせようとしたところゴツン！と、やってしまいました。運転席から後ろを見ても見えない場所にコンクリートがあって、後ろのバンパーが少し割れてしまいました

１０時ちょっとくらいにエキスポセンターに着いて受け受けを済ませました。雨が降っていたので参加チーム数は少ないかと思いきや、けっこうみんな雨対策をして試走会に臨んでいます。かな～り、急ごしらえの雨対策から、外装デザインの凝った雨対策まで、チームによっていろいろです。

うちのチームは一番最初に車検をやって、ハード的に小さいしちゃんと安全対策してあるからなのか特に何も言われなかったのですが、他のチームは安全性に関して厳しくチェックを受けていたようです。私が見かけたところでは、緊急停止スイッチを無線でやろうとしているチームがあって、「それは本質安全になっていない」と指摘されていました。

本質安全、っていわれても学生さんだと何の事だか分からないかもしれませんが。ここを読んでいる学生さんのためにちょっと書いておくと、フェールセーフとフールプルーフを考えて設計しなさいってことです。

まずフェールセーフですが、「故障するときは安全側に倒れる」という考え方です。先ほどの無線で緊急停止スイッチを入れるという考えを例に挙げると、何か緊急停止しなければいけない状況になったときに無線の混信などがあって信号が届かなかったらロボットを止めることができません。言い換えると、無線の機能が使えなくなったときに安全に止めることができないので、このやり方は駄目。同様に、障害物検知センサを使って緊急停止します、というのもダメ。プログラムにはバグがあるものとして考える必要があります。一番妥当なのは、駆動系の電源を切るためのスイッチを押しやすいところに設けておくことです。

続いてフールプルーフは、「不注意な扱い方をしても怪我や事故になりにくい」という考え方です。例えばロボットにとがった部分や発熱する部分、チェーンなどが外に出ている場合、うっかり誰かが触ってしまったりすると怪我をする虞があります。なので、とがった部分はやすりがけして丸めたり、スポンジやゴムで覆ったりするなど、人が危険な部分に間違って触れることのないように安全対策をしておく必要があります。

こういう安全対策のポイントを事務局側でチェック項目として挙げてしまうと、参加者が「コンテストのレギュレーション」ととらえてそこしか安全対策してこなくなってしまう恐れがあるということで、なかなか扱いが難しい問題になっているようです。

で、ですね、肝心のうちのチームの試走は、モニタ用に使っているマヒソンさんのノートPCのハードディスクが壊れてしまい、な～～～～～んにもできずに終わってしまいました。せいぜい、コースを歩いてGPSの座標データ収集をしてきたくらい。まずいな～、すごくまずい。

宿の手配

つくばチャレンジ本番まであと１週間を切り、大会参加に向けたロボット以外の準備も進めておくべき時期になりました。そして忘れちゃいけないのが、宿の手配です。参加者用メーリングリストで事務局から流された情報によると、11/20（木）のトライアルは受付が朝の8:30から、搬入は8:00からということで、三島からつくばまでざっくり３時間かかることを考えると前日入りしておくのがbetter。　そういうわけで、宿を手配しました。

宿は去年と同じ、筑波研修センター。松見公園のすぐそばで、エキスポセンターからは直線距離で１ｋｍくらいの場所にあります。

大きな地図で見る

建物はちょっと古めですが、１泊 \3,600-なので、学生さんにはちょうどいいんじゃないかと思います。

冷たい雨の中でテスト走行

日曜日はお昼ごろまで曇っていたのが、お昼過ぎからぽつぽつと雨が降り出して、午後は本格的に雨になりました。そして、そんな雨の中でもうちのロボットはしっかりテスト走行しました。さみーってばよ！

いままで会社の体育館や事業所の敷地内を使ってプログラムの修正やテスト走行をしていたのですが、先々週、警備員のおっちゃんに「休みの日に厚生施設を使うときはちゃんと許可取らなきゃだめだよ」って注意されまして、しゃーないので総務部に行って日曜日の体育館和室と午後のグラウンドを予約しました。初めはいろいろ聞かれましたが、つくば市で開催されるロボットコンテストに参加します、と話したところ総務部長は「セグウェイみたいの？　俺も乗せてよ。」と大分理解を示して下さって、これで堂々とテスト走行できるようになりました。いや、ここに書くと誰が見てるかわからないからアレだよな、ってこともあるのですが。

テスト走行を何度かやってみた結果ですが、まず建物が近くにないオープンスペースならかなり位置計測の精度が高くとれます。ちなみに、カルマンフィルタ入ってます。センサはGPS以外に、デジタルコンパス、ジャイロ、ロータリーエンコーダを使っています。しかし、建物に近づくとGPSの位置精度が悪くなり、建物に挟まれた場所を走行すると無残なことになります。GPSの位置情報が大きく狂うためカルマンフィルタでは吸収できず、何度もコースアウトしました。

GPSに関して言うと、way point の設定方法にも難点があります。今はGoogle Earth上で航空写真を見ながらway pointを作っているのですが、このGoogle Earthの航空写真でとらえた座標がロボットの走行に使えるだけの精度をもっているという保証がなく、また、GPSの単体測位では同じ場所にいても時間と共に位置の計測結果が大きく（２～５ｍ程度）動いてしまって、正確な位置を得にくいという問題があります。この位置情報がずれる問題は、走行中にも目に見えるレベル（数十秒のうちに２～３ｍくらい）で発生することがわかりました。

それから、防水性は私が予想していたよりはるかによくできていました。小雨じゃなくて、傘をささなきゃずぶ濡れになる雨の中、アスファルト上の浅い水たまりを突っ切って走れましたし、内部には水が全く入ってきませんでした。試走会で見かける他チームのロボットはほとんどのチームが雨が降ることなど考えていないように見えるので、11/20のトライアルで雨が降ったら走れるロボットは５台くらいになってしまうのでは？

そんなこんなで問題が色々ありますが、ナビゲーション部をマヒソンさんに任せてしまった私には大してできることも無く、カルマンフィルタの勉強をしたり、大会参加の手続きをしたりしてます。

カルマンフィルタ入門 (０)

今年のつくばチャレンジ用に開発中のロボットにはすでにマヒソンさんがカルマンフィルタを組んでくれているのですが、私自身がカルマンフィルタをよく理解していないので、これを機会に勉強することにしました。

教科書としては

• 先日の日記でも紹介したこれ
• 確率ロボティクスの本の第2章、第3章、第7章
• ロボット工学セミナー第47回　ロボットの環境把握と自己位置推定　のテキスト

が手元にあるので、あと統計学や線形代数などで何か必要になったら大学時代に使った教科書を引っ張り出して何とかする予定です。確率ロボティクスの本は、Amazonで購入可能ですが、ロボット工学セミナーのテキストは参加者じゃないと手に入らないかもしれません。

確率ロボティクスの「はじめに」を読んでみたところ、カルマンフィルタを理解するため道筋は「ベイズの定理」、「ベイズフィルタ」、「カルマンフィルタと拡張カルマンフィルタ」になりそうな感じです。

今日は手始めに「確率」の基礎概念から始めました。このblogで数式を展開する気はないので、キーワードだけ書いていきます。

今日のキーワード：条件付き確率、独立性、ベイズの定理（ベイズ則）、条件付きベイズ則、分散、共分散行列、正規分布（ガウス分布）、

勉強しながらその学問分野特有の表記がいくつか出てきたので、やっぱり大学時代に使った教科書を引っ張り出す必要がありました。

カルマンフィルタ

今日は久しぶりにお昼からマヒソンさんと一緒にロボットの動作確認をしました。やった内容は、カルマンフィルタの実装が正しくできているかどうかの確認です。そのカルマンフィルタというのがなんなのかという話はおいておいて、それを使ってロボットの位置計測の精度を向上させようという狙いです。自律移動ロボットの分野ではカルマンフィルタが非常によくつかわれていて、かなり効果があるそうです。私もむか～しちょっとだけやってみようかなと思って、結局よくわからなかったので諦めた思い出があります。

なんでそんなものが必要かというと、

• GPSから得られる位置情報だけでは、
• (1) 絶対的な精度が２～１５ｍくらいしか得られない
• (2) 高い建物に近づくと建物から反射される電波によって位置情報が大きくずれる
• (3) 街路樹程度は問題ないが、人工衛星からの電波が遮られる場所では位置情報をえられない
• ジャイロや地磁気センサ、オドメトリもそれぞれ固有の誤差要因を持っている

という理由があるからです。

で、今日はマヒソンさんがソースコードを直している間に、ここの「カルマンフィルタの入門書といえばこれ」というドキュメントを読みながら、カルマンフィルタってなに？てのを勉強しました。加えて、今回うちのロボットに実装されたカルマンフィルタがどういうモデルなのか、どういう仕組みでどういう効果があるのかというのもマヒソンさんに説明してもらい、カルマンフィルタのコンセプトが大体わかったような気がします。気がするだけですが。

ちなみに、Wikipediaのカルマンフィルタの項にある説明はわかりにくいと思います。行列とか統計の予備知識がないと、式の展開を見ただけで「む～～～り～～～～」となること必至。興味があったら、上記のリンク先に富んでみて、５秒であきらめて帰ってきてください。

AC100V電源を確保する

気がつけばもう１０月も終わりです。仕事は、今週はたまたま飛び込みで「納期は今週中」なんてのもありましたが、それほど忙しいわけでもなく、ぼちぼちやってます。

で、さっき気づいたんですが、ここ２週間くらいロボット関連のことを何も書いてませんでした。意図的に書いてなかったわけじゃなくて、２週間前のつくばチャレンジ試走会のあとちょっと風邪をひいて調子が悪かったとか、マヒソンさんにプログラムを任せっきりにしてしまっていて私の方は何も進捗がないから書くこともなかったとか、そういうわけでロボット関連の日記を書いていなかっただけ。今日は思い出したのでちょっとだけ書きます。

前回の試走会での反省ですが、AC100Vの電源を自前で用意していかなかったのが非常にまずかった。これは、メーリングリスト等で大会事務局側で電源を用意できない旨の連絡がすでにまわっていたのに用意していかなかったので、現地でデータ収集やプログラムの修正をしている間にノートPCのバッテリが空になってしまい、作業を続けられなくなったというもの。幸い、兄に作業場所と電源を提供してもらえたおかげで何とかロボットを走らせてデータ収集できました。

そこで。近所のホームセンターでDC/ACインバータを買ってきたので、今週末の試走会には自動車用の鉛蓄電池と、DC/ACインバータを持って行って、ノートPC用の電源やロボット用バッテリの充電に使う予定です。

IEEE 754形式のfloatをCCS PCMのfloatに変換する

掲題の件、何が悪かったか判明しました。簡単に言うと、「シフト演算子とビット演算子の優先順位を私が間違えていたことにより、仮数部が正しく変換されていなかった」というのが原因でした。

参考までに、その変換を行う関数のソースコードをUpしておきます。

/**

    CCS-PCMのfloatフォーマットに変換する。
   
    @note CCS-PCMのfloatフォーマットが一般的なIEEE 754とフォーマットが異なるので
    この変換関数を作成した。
*/
float convertToCCSFloat(unsigned char d[4])
{
    // IEEE Std 754-1985 float format (big endian)
    //
    // 31............24...23............16...15.............8...7..............0
    // S E E E  E E E E   E F F F  F F F F   F F F F  F F F F   F F F F  F F F F
    //
    // where
    //     E : 8bit exponent with bias of 7F
    //    S : Sign bit
    //    F : 23bit Mantisa
    // Number = (-1)^S * 1.F * 2^(E-127)   
   
   
    // CCS-PCM float format
    // (Reference: CCS-PCM C Compiler Reference Manual, Common Questions and Answers)
    //
    // 31............24...23............16...15.............8...7..............0
    // E E E E  E E E E   S F F F  F F F F   F F F F  F F F F   F F F F  F F F F
    //
    // where
    //     E : 8bit exponent with bias of 7F
    //    S : Sign bit
    //    F : 23bit Mantisa
    // Number = (-1) ^S * 1.F * 2^(E-127)

    float number = 0;
    unsigned char *ptr;

    ptr = (unsigned char *)(&number);

    *(ptr + 0) = ((0x7F & d[0]) << 1) | ((0x80 & d[1]) >> 7);
    *(ptr + 1) = (0x80 & d[0]) | (0x7F & d[1]);
    *(ptr + 2) = d[2];
    *(ptr + 3) = d[3];

#if 0
//    printf(" data = %02X%02X%02X%02X \r\n", d[0], d[1], d[2], d[3]);
//    printf(" conv = %02X%02X%02X%02X \r\n", *(ptr), *(ptr+1), *(ptr+2), *(ptr+3));
    printf(" number = %f \r\n", number);
#endif   

    return number;
}

バグがあったのは、上記のコードの
    *(ptr + 0) = ((0x7F & d[0]) << 1) | ((0x80 & d[1]) >> 7);  // 正しい
の部分です。これを
    *(ptr + 0) = ((0x7F & d[0]) << 1) | (0x80 & d[1] >> 7);　　// これじゃ駄目
こう書いていました。下の書き方では、>> が先に評価されてしまうため、0x08 & d[1] >> 7 は常に０になってまう、というのが不具合の原因でした。

ジャイロも付いたよ

10/10（金）は年休を入れて自主的に体育の日にしました。でも、運動しないで、先週秋葉原の千石で買ってきたジャイロ（司21)をロボットに載せる作業を進めました。ジャイロの出力はSH2のADコンバータから読み取って、ADコンバータの値をそのままPCに送ることにしました。どれくらい零点電圧がドリフトするかまだ計測していないのですが、動かしてみた感じではかなりドリフトが小さそうです。

とりあえず付けてみたかったから付けたというだけで、どう使うかは未定。

久しぶりの秋葉原

日曜日は久しぶりに秋葉原まで部品の買い出しに行ってきました。この日はつくばチャレンジの試走会で参加申し込みをしていたのですが、先週の日曜日の段階で自律走行できていなかったため「自律走行できないまま車で３時間もかけてつくばまで行く意味あるの？」って感じで試走会参加を見送りました。

秋葉原では私の巡回コース（ツクモロボット王国、千石、秋月）をさらっと流して、駅の反対側にあるスーパーラジコンにも足を延ばして、ストックが底をついた部品やモータドライバIC、E-Savage用の黒スプリング（スーパーハード）などを仕入れてきました。で。今までロボットに非常停止スイッチが付いていなかったので、いわゆる「キノコスイッチ」を秋葉原で探したのですが、これを置いているお店がなかなか見つからず苦労しました。最終的には、JR秋葉原駅の電気街口を広場側に出て中央通りに辿り着く間にある田中無線電機（パーツ店）でお目当てのものが見つかりました。値段は\1,491-でした。

ついでに書いておくと、今回私がロボットの台車に使っているHPI E-Savageはタイヤの直径が13.5cmくらいあって結構大きいのですが、スーパーラジコンには直径が16cmくらいあるさらに大きなタイヤがありました。エンジンカー用なのだと思いますが、屋外用ロボットのタイヤに使うにはいいんじゃないでしょうか。

そんなわけで。今日の写真は「いかにも」なキノコスイッチをつけたロボットの姿です。

屋外でマニュアル走行

来週日曜日の試走会に向けて、土日はマヒソンさんと一緒に会社の体育館とグラウンドを使って走行テストを行いました。

モータのトルクが細くなってしまう件については、PWM信号の周期を 2kHzに落とすことで暫定対策しました。こうした理由はいくつかあって、一つ目はPololu社のウェブサイトにあるフォーラムでこんなスレッドを見つけたからです。二つ目の理由は同じフォーラムの他のスレッドで5kHzで使っているという書き込みを見たからで、三つ目の理由は先日の日記にもあるとおりモータドライバの出力が2kHz程度に間引きされているっぽかったから。間引きされる原因として何らかの保護回路が働いているのであろうと推測しているのですがこれはあくまで推測にすぎず証拠はありません。とりあえず暫定対策で「まあまあ」なトルクが出ているので当面はこれで進めて、どうしてもだめならモータドライバをもっと単純なものに交換することを考えています。

で、土日の走行テストでマニュアル操縦による屋外走行ができるようになり、ログ取り程度のことはできるようになりました。走行時に収集したGPSデータをGoogle Earthで表示させるとキレイに航空写真と一致します。位置の精度がかな～りいい感じで、見た感じでは誤差は１ｍ以下っぽいです。ただし、建物の間を通り抜けるコースは位置情報が狂いやすい傾向があるようです。

ウェイポイントを巡回する自律走行も試したのですが、これはうまくいかず、持ち帰りになりました。水曜日の午後５時以降に再度走行テストを行う予定です。

余談ですが、私が担当している部分はメカ、回路、ファームでマヒソンさんがノートPC上で動くAI部を担当。こうなった理由は単純で、メカ、回路、ファームの開発に必要な資材や開発環境が私の手元にそろっていて、AI部は最低PC１台で開発ができるから。ナビゲーションに必要なウェイポイントの作成方法や障害物回避方法など、私はかなり複雑な方法を考えていましたがマヒソンさんのアイデアでもっと単純な方法を取ることにしました。開発のボリュームが大きいので私ひとりでは全然開発が進まなかったんじゃないかと思います。彼の知識と経験もさることながら、情熱に引っ張ってもらっているところが大きいような気がします。

配線が焼き切れていた

今日も昨日の続きで、モータのトルクが細くなってしまう問題の原因調査を進めました。

まずはモータをロックさせた時に電源電圧がどうなっているか。これ、前からちょっと気づいていましたが、今日改めて測ってみたら、モータを回さない状態でCPUのGNDとモータ駆動用電源のVccがすごくノイズまみれになっていました。CPUのGNDとモータ駆動用電源のGNDも同じ状態です。モータドライバの回路図を見るとモータ駆動用電源のGNDと信号線のGNDはつながっているはずなのですが、こんなにノイズだらけだと何かおかしい。これ、つながって無いんじゃね？　と思ってモータドライバの回路基板を確認してみたら、目視で見つけました。これがその写真。

ちょっと分かりずらいと思いますが、写真の下側に写っている線がモータ駆動用の電流が流れる線で、右側のピンヘッダが信号線です。そして信号線の一番下側が信号線のGND。これがモータ駆動用電源のGNDとつながっているはずなのが、＋の上あたりの変色した部分で基板上のパターンが焼き切れてしまっています。ということで、つながっていませんでした。

でも。ラッピングワイヤでこれをつないでノイズはなくなりましたがモータドライバの出力波形が2kHz程度に間引かれる現象はあいかわらず。さてこまった。

モータドライバが間引きをしている？

昨日の続きで、モータのトルクが十分出ていない件の調査を進めています。今日は有力な手掛かりになりそうな証拠物件を集めました。

走行中に車輪をロックさせると妙にヒ～～ンという音がするので、制御の周波数が変わっているのではないかという疑いを持っていました。そこで、今日はCPUからモータドライバ(Pololu MD01B)に対して送られるPWM信号と、モータドライバのDCモータに対する出力電圧の波形とを比較してみました。

　 　 　 　

下段の水色がCPUが作っているPWM信号で、上段のオレンジがモータドライバの出力波形です。PWMの周波数は10KHzにしてあります。一番左の図はバッテリ電圧14.4V（実際は15Vちょっとでてるかも）で車輪を無負荷状態にして計測した場合。PWM信号とモータドライバの出力がきれいに同期しているのが見て取れます。ごく普通ですね。

続いて左から二番目は先ほどの状態から車輪を手でおさえてロックさせた状態です。これを見ると下段のPWM信号のHighになっている時間が多くなっていますが、これは走行速度制御でPI制御をかけているからで、これは設計通りで問題なし。問題は上段のモータドライバの出力波形で、これがPWM信号と同期していないことがわかります。この状態で時間軸をもう少し延ばして表示したのが左から三番目の図で、これをみるとモータドライバの出力波形が500us周期（周波数でいえば2kHz程度に減っていることがわかります。

３番目の図と同様のことをバッテリ１本（＝7.2V)でやったときの波形が４番目の図で、これもモータドライバの出力が間引かれているっぽい感じ。なのですが、ちょっと解せない現象があります。というのは、先ほどの１～４枚目の図はバッテリからモータドライバの間に電源用のスイッチを挿んでいるのですが、このスイッチを通さずバッテリをモータドライバに直結すると、５番目の図のように車輪をロックさせてもPWM信号とモータドライバの出力波形が同期したままなのです。

考察。

1. モータドライバがもっている何らかの保護回路により、何らかの条件でモータドライバの出力が間引かれてしまうのではないか？
2. モータドライバにバッテリを直結するとモータドライバの出力が間引かれていない、ということは、電源スイッチになんらかの問題があるのではないか？
3. まだ確認していないが、モータドライバの出力波形が間引かれている状態のとき、電源の電圧はどうなっているか？　もしかして、電源スイッチが大きな電流を流すことができずに、モータドライバに供給される電源電圧がふらついたりしていないか？

そういうわけで、今週末までに電源電圧の変動を確認する予定。

屋外初走行！ しかしモータのトルクが出ないのはなぜだろう？

9/21(日）に会社の体育館とその周辺を使って、初の走行試験をしました。問題はいろいろ出ましたが、とりあえず屋外で初走行に成功しました。

問題というのは、小さなものではロータリーエンコーダの値を取得するコマンドを出すとファームが返すレスポンスのCRCがおかしいとか、ステアリング制御に使っているRCサーボのトルクが弱いとか。大きいものでは、部品を全部台車に載せた状態で走行させようとするとモータがヒ～～～ンとかいって全然走らないことです。

このモータのトルクが不足する問題について、今日はいろいろやってみてわかってきたことをメモしておきます。前提条件は、バッテリ電圧が14.4V、バッテリの容量が3300mAh。周期10kHzでPWM制御をしています。最初に気付いたことは、モータドライバが全然熱くなっていないということ。そこでモータドライバのCS端子（出力電流1Aあたり0.13V出力）をオスロスコープで見てみると、モータをロックさせたときファーム側でPI制御がかかってPWMのデューティが90％近くまでいくのですが、このときCS端子の電圧は200mVに満たないくらいしか出力していません。モータの出力電流でいえば1.5A程度しか流れていない計算です。バッテリの容量は3300mAhでニッケル水素電池なので、1C放電しても3.3Aは流せるはずなのにその半分も流せていない。これはバッテリを安定化電源（最大電流32A)に変えて13.5Vを与えても傾向はいっしょなので、バッテリの性能による問題ではなさそうです。

でも思い出してみると、先日バッテリ１本（7.2V)でやったときは座布団を乗り越えられていたので、試しに安定化電源で電圧を7V程度に落としてやったところ、手でロックさせるとトルクリミッタが働くくらい大きなトルクでタイヤが回りました。このときの出力電流は4A程度。同様に、バッテリ１本でやってみたら、フローリングの床上を問題なく走れて、私の足の甲くらい乗り越えられる程度の走りっぷりでした。

バッテリ電圧が14.4Vだとトルクが出なくて、7.2Vだとトルクが出るというのがどういう理由なのかよくわかりません。

モータが止まってしまう問題再び

平日は完全にロボット開発を止めて睡眠時間を確保したところ、なんとか不調期を抜けたような気がします。そうはいっても、調子がいいと思って土日に頑張り過ぎると、体力を回復しないまま月曜日になって仕事が始まってしまうので、リズムは崩さないようにロボット開発を進めたいところ。

さて、先日の日記にあるとおり、ロボットに載せるべき部品はほぼ全て載せてバッテリ電圧も7.2Vから14.4Vになったので、明日の屋外走行試験に向けてDCモータ制御用PWM信号のデューティ比と走行速度の関係を計算し直して、「全部載せ」の状態で狙った走行速度で走行できるか試してみました。しかし。走りません。

経緯を書いておきます。まず、モータを選定する際にロボットの全備重量を6.0kg、最大走行速度を4km/s、ギア比を15.6対1、電源電圧 14.4Vと仮定してマクソンのRE35 90W(273753)を選びました。モータ選定プログラムによると、このDCモータで4km/hの走行速度で動かすには13V必要ということで、これでつくばチャレンジのレギュレーションどおり、試走や実験でも4km/hを超えない設計になっています。

問題のモータが止まってしまう件については、7/6の日記で書いたサーマルシャットダウンを疑いましたが、今回はヒートシンクが全然熱くなっていないのでこれは違いそう。PWM信号の波形などはまだ見ていません。モータドライバについているCS端子（電流を見る）やDIAG端子などもプログラム中では見ていないので、波形を見た後でこのあたりをプログラムに組み込もうかな。

やはり、問題が発生したときはきちんと原因と発生プロセスを理解して解決策をとっておかないと、後でかならず同じ問題が発生しますね。

少しだけやる気が戻ってきた

疲れがたまっていたのかここしばらくやる気が出ませんでしたが、この３連休で少しだけやる気が戻ってきつつあります。やる気が戻って最初にやったことは、部屋の掃除でした。続いて洗濯。

やる気が戻ってきたところで、つくばチャレンジ準備の方も少し進めました。主に配線周りを作って、GPSアンテナ以外はすべて積み込んでケーブルがつながりました。配線はかなり汚いですが、こうなっています、というのが今日の写真。

　 　 　 　

左から１枚目の写真はGPSアンテナ以外必要なものを全部載せてこんな感じです、という全景で、体重計で重さを量ってみたら7.4kgありました。モータを選定する際には全備重量6kgで計算していたので、7.4kgは大分重量オーバーです。重すぎて後輪のサスペンションが沈んでいます。

積んでいる物の中で一番重いのはノートPCで、1.1kgあります。そのノートPCは、写真の２枚目、３枚目のように載っています。去年秋葉で買った中古のVAIO (C1)で、元はWindows 98が動いていたようですが、今はコンソールモードのみのLinuxが載っています。このVAIOにはUSBポートが１個しかないので、PCカード型のUSBハブを使って口数＋４個しています。

ノートPCを除けると、４枚目の写真にあるように足まわりを制御しているSH2とモータドライバが顔を出します。ここに載っているSH2はSH7149で、今やらせていることからするとオーバースペックですが、今更CPUを変えるのは時間の無駄なのでこのままオーバースペックを押し通します。SH2の左手に見えるのは電源スイッチで、大きいスイッチがDCモータ駆動用、小さいスイッチがその他の電源のスイッチになっています。Top-URGを動かすために必要な12Vはこの電源基板上のレギュレータ LM338Tで作っています。レギュレータとモータドライバがそこそこ発熱するので、この熱を逃がすために冷却ファンをつけました。

５枚目の写真がバッテリで、バッテリは番号をつけて管理しています。バッテリは7.2Vのニッケル水素電池を走行用に２本、制御用に２本、合わせて４本積んでいます。だから重い。

まだギア周りを囲っていないので、次の週末には屋外でテスト走行できるよう、明日はギア周りの囲いを優先して作る予定です。

泥よけの板をつけてみた

今日は年休を取る予定でいたのに、木曜日中に片付かなかったジョブが１件、金曜日の午前中に打ち合わせを入れてしまったこともあって、まんまと２１：４５まで仕事をして帰ってきました。先週末から仕事も帰宅後のロボット作りもハイペースで来ているのでかなり疲れ気味。

それはそれとして。明後日は今年のつくばチャレンジの第２回試走会があるので、屋外を走行できるようロボットに泥よけの板をつけてみました。といっても、ギアやモータ周りはハウジングしていないので、砂埃等の対策はまだできていません。今日の成果はこの写真。

この黒い板は3mm厚の低発泡塩ビ板（Forex)で近所のホームセンターで調達しました。発泡塩ビ板は120℃くらいになると曲げ加工ができるそうで、私はライターの火で炙ってアルミ板をガイドにして発泡塩ビ板を狙った形状に曲げ加工しました。材質的には自己消火性なのでモータの熱にさらされても発火するおそれはありませんが、塑性変形を始める温度が比較的低いので、モータの近くで使うのはまずかったかなぁと少し気にしています。（大丈夫だとは思いますが。）

熱といえば、モータドライバがかなり発熱するので、台車の上に載っているツールボックスに４ｃｍ角の冷却用ファンをつける予定です。明日はツールボックスに部品を据え付けます。

すべての部品を台車に載せよう

昨晩で走行速度制御を実装し終えたので、今日はプログラムから離れて部品を全部台車に乗せるための工作をしてみました。写真を見てもわかるとおり、大越さんのデザインをパクッたとしか言いようがない(；´Д`A ```

最初は半透明な工具箱に部品を入れたらLEDが光ってるのが見えていいかなと思ったのですが、なんかいまいち。そこでほとんど同じサイズの藍色の工具箱を使ってみました。（ココログの調子が悪くて２枚目以降の写真がUploadできません。）　とりあえずいい感じで工具箱が台車に乗りました。

よくある話

今日あった「よくある話」を２つほど紹介します。

まずは会社の実験室で。半年以上前に書いたプログラムに不具合が見つかって、「ココだ！」という不具合発生場所を探り当てて修正したつもりだったのですが、直したはずなのにプログラムの動きがなんかおかしい。よく見たらケーブルが抜けていたという落ちでした

続いて、会社から帰ってきてロボットの速度制御のプログラムを実装している間の話。速度制御をきっちり入れてあげたら、数日前はばっちり座布団を乗り越えられたのに、今日は座布団を乗り越えられません。あれ、計算をどこか間違えたのか？　と思ったら、単にバッテリがへばっていたという落ちでした。

こういう当たり前すぎるアホなミスって、結構見逃すんですよね～。

ロータリーエンコーダの値も取れている

日曜日に接続テストをするのに走行速度制御が間に合わなかったのですが、その原因がわかりました。ロータリーエンコーダの値がなぜ取れなかったのか。理由は、エンコーダの出力が入ってくる端子を入力端子に設定し忘れていたから。モータテスト用のプログラムを作った時にはちゃんと動いていたのでハード的に問題がないことは分かっていました。きっと、あと１時間もあれば速度制御の実装ができると思いますが、これを書いている今はすでに午前１時２５分。プログラム書いてたら寝る時間が無くなり、明日の仕事に影響が出るのでもう寝ます。

９月に入って急に仕事が忙しくなってきて、ロボットを作っている時間的余裕がありません。８月中さぼり過ぎたかな～。特許提案、マニュアル作成、バグ修正、技術調査、報告書作成など、いかにも期末っぽい仕事の溜まり方です。今週末につくば市で開かれる第２回の試走会に参加するのは厳しいかも。

接続テストは上々

日曜日は今回のロボットに乗せるすべてのコンポーネントをつなぎ合わせて接続テストをしました。コンポーネントは、Linuxを載せたNote PC(VAIO)、レーザーレンジファインダ(Top-URG)、デジタルコンパスモジュール、台車となるラジコンバギー、台車を制御するマイコンボード(SH2)です。ナビゲーションを担当するノートPCにすべてのコンポーネントがUSBやUSB-232C変換ケーブル経由でつながります。だから、もうケーブルのジャングル状態。

とりあえず全部つないで通信はできてる、データはちゃんととれる、モータやステアリングは動く、というところでこの日の接続テストを終了しました。左の写真から見てもわかるように、このままじゃ屋外を走れないので、接続図を書いて、バッテリをどうするか、どの部品をどこに配置するかなどを検討して、この日の打ち合わせを終了しました。

打ち合わせ後、近所の模型屋さんでサスペンション用の固めのスプリングやバッテリコネクタを、ホームセンターですべてのコンポーネントを台車に積みこむための材料を調達して、それで力尽きました。なにせ、金曜日の夜から半徹状態でプログラムの修正をしていたので、もう気力も体力も目いっぱいでした。

そうそう、このところ忙しくてブログに書きそびれていたのですが、新しく届いたマクソンのモータを台車に載せて動作実験をしてみたところ、すごくあっさり座布団を乗り越えました。速度の制御は比例制御のみ。お金を使って解決できる問題はお金で解決することで開発時間を短縮するという戦略は正しかったようです。ただし、ロボットの全備重量を6kgとして計算するとバッテリ電圧が 7.2Vでは走行速度が50cm/s程度しか出ないので、時速 4km (=111cm/s）を得るには 14.4V のバッテリが必要です。

V2Xeのheadingデータが飛んでしまう

ようやくデジタルコンパスモジュールV2Xeをコントロールできるようになったのですが、それでもまだ未解決の問題があります。それは、コンパスモジュールをゆっくり動かしても特定の方位で heading データの値が不連続に変化することです。

具体的には、
Xc = -.126, Yc =  .603, head = 129.0, m =  .616, t = 40.5, d = 1, sts = 0
Xc = -.158, Yc =  .619, head = 255.6, m =  .639, t = 37.1, d = 1, sts = 0
こんな感じで、コンパスモジュールをゆっくり動かしているにもかかわらず heading の値が不連続になってしまっています。ちなみに、Xc, Yc はキャリブレーション済みの磁気センサの値で、このXc, Ycを使ってV2Xe内部でコンパスの向きを計算しています。

きゃりぶレーションが下手なのか、電源ケーブルのせいなのか、はたまた私の部屋に変な磁界があるのか。疑ってみましたがどれも白っぽい。そんな中でPNI社のV2Xe サポートページで次のような記述を見かけました。

• Heading Angle = θ
• θ  = arctan (Y/X)

で、先ほどのheadingデータが不連続なときのXc, Yc の値は不連続ではなさそうなので、-π～πまでを出力範囲にするために atan2 を使えば連続した headingデータを求められるのではないか、と。いうことで、Excelで計算してみた結果は次の通り。

Xc    　　Yc    　　head(rad)    　　head(deg)
-------------------------------------------
-0.126    0.603    1.776787663    101.8024342
-0.158    0.619    1.820710409    104.3190222

なんだかよさそうです。

そこでPIC上でこの計算をしてやろうと思ったのですがCCS-PCMにはatan2関数がありません。じゃあ自分で作ったろかと思ってやり始めたのですが、atan関数を使おうとするとメモリが足りず、多項式を使ったやり方では計算に時間がかかり過ぎるということで、PIC側でatan2計算するのをあきらめました。　コンパスデータを受け取るPC側で計算すればいいかな。

Maxonからモータが届いた

7/6の日記で書いた座布団が乗り越えられない件。ロボットの全備重量を最大6kg、走行速度を4km/hと仮定してトルクを見積もってみると、障害物を乗り越えられるだけのトルクがなさそうだという結論になりました。そこでギア比を大きくすることを検討していたのですが、適度なギア比のギアやギアヘッドが見つからず、Maxonモータに手を出してしまいました。φ35mm、グラファイトブラシ、90Wのモータで、ギアヘッドなしでなんとか6kgの負荷を乗せて4km/hで走れるだろうという計算です。

で、お盆休み直前に注文したモータが昨日(8/27)届いて、今日はモータを台車に据え付ける板の設計をしました。購入したのは、型番で言うと273753です。安定化電源や電池でモータ単体を回してみた感想ですが、すごく静かでスムーズに回ります。驚いたことに、単4乾電池1本でモータが回り始めるのです！　RS-550モータじゃあピクリともしないのに。　低速域での速度制御でもかなり期待できそうです。

コンパスモジュールがとりあえずできた

お盆休み前からずっとかかりっぱなしだったコンパスモジュール。昨晩ようやくプログラムを書きあげて、簡単なテストをして、すごく簡単な取扱説明書を書いて、（つくばチャレンジ参加を手伝ってくれている）マヒソンさんにリリースできました。まだハード的に問題があるっちゃあるのですが、致命的ではないし、走行中にトラブルを引き起こすものでもないので放置します。

デジタルコンパスモジュールにV2Xeを使用し、PIC16F876Aを使用して、CSS-PCMでプログラムを書きました。V2XeとのSPI通信ができるようになるまでかなり長い時間を要しましたが、とりあえず動くようになってホッとしています。

今週末は会社のグラウンドを使って走行実験をしたいので、それに間に合うよういろいろ仕込みをする予定。来週末の第2回目の試走会になんとか間に合わせたいと思っています。

V2XeとPICとCCS-PCMで一苦労

お盆休み前からずっとデジタルコンパスモジュールと格闘中ですが、今日はだいぶ進歩がありました。昨日、今年のつくばチャレンジ参加を手伝ってくれているマヒソンさんからV2Xeを使ったサンプルソースコード（PIC18用、HI-TECH C使用）をもらい、今日はV2Xeのモジュール情報とバージョン情報を読み出すところまで成功しています。

わかったことをメモしておくと、そのもらったソースコードでは、起動時にV2Xeの内部バッファをクリアするためにSYNC端子をLow -> High -> Low するとき、待ち時間として 200ms 程度置いていました。私は 20ms 程度もおけば十分だろうと思っていたのですが一桁違った。　待ち時間を 200ms にしてからは、SPIの同期クロックSCLKを1.25MHz (=20MHz/16) に設定して通信できています。

さら気づいたことがあります。V2Xeが返すデータのfloatのフォーマットは IEEE Std 754-1985.に従っているのですが、CCS-PCM の float はフォーマットが違います。コンパイラのリファレンスマニュアルの Common Questions and Answers を見てわかりました。 これが違うのに気づかず、heading情報を読み出しても temperature情報を読み出してもな～んかおかしいので、すごく困っていました。どこまで変なコンパイラ何だ、CCS-PCMは！

HI-TECH Cもインストールしてちょっとだけ試してみたのですが、Vistaにインストールした場合は作業中に１００％の確率でMPLABごとプログラムが落ちるのでNG。XPにインストールしたほうでは printf の可変引数あたりでコンパイルエラーがでて解決に時間がかかりそうだったので断念しました。とりあえず今回は時間が無いので我慢してCCS-PCMを使いますが、後で時間を作ってHI-TECH Cを使えるようにしておきたいと思っています。