レーダーチャートの更新周期は期待に反して十数秒に１回と残念な性能でした。高速化は別途取り組むとして、 せっかく出かけてきたので生垣との位置関係をいろいろ変えて測定してみました。
赤外線カメラの映像が露出オーバーになって、白くとんでいるエリアが多いので、思ったほどポイントクラウドデータが 取れませんでしたが、それっぽいレーダーチャートを取得することができました。
レーダーチャート
約４ｍ先の生垣を測れました
距離画像・赤外線画像・可視光カラー画像
レーダーチャートをとった位置と少し違いますが、大体こんな感じでした。
ポイントクラウドをスライスしてもまだデータが多いので、ポイントをタイルパターンに当てはめて データを間引いてから使うようにしました。
w7v2b1に実装した画面。
タイルのある場所がモノがあって進入不可のエリアです。
赤い点にD435が置いてあって、ピクチャーボックスは縦横３ｍくらいの
範囲で1回の測定分を描いています。（前回の記事の場所とだいたい同じ所から測定し、缶は無し）
実際に走らせてみてどの程度役に立つかはひとまず置いておいて、概ねイメージどおりのモノが出来
たかな〜と思いました。
もう少し作りこんだら、外で遊んでみようと考えています。
実験の様子
RealSense Viewerでの見え方（距離画像／赤外線カメラ画像）
RealSense Viewerでの見え方（カラーカメラ画像）
テキスチャーマッピング有のポイントクラウド画像
レーダーチャート(単位はｍ)
この形になれば、これまでｗ８用等に作ってきた、地図を作るプログラムなどへ繋げられます。
w7でもw8でも、超音波センサ等で周囲の距離を測っていた状態と比べて、データ取得にかかる時間が短いので、
ロボットを速く動かせそうだと期待が持てました。
RealSenseのファームウェアをアップデートしたらUSB2も使えるようになったので、すんなり載せることが 出来ました。
簡単なベースをプラ板で作って付けました。お試し用なので、パン・チルト機構無しの固定です
当面はいつも通り、ノートＰＣを片手に、ロボットとＰＣを有線接続して後ろをついて歩きながら実験してみるつもりです。
でも気が向いた時にノートＰＣをロボットに載せて走らせられるように、サスペンションのスプリングも強いもの
（黄色いコイルスプリング）に戻しました。（写真は作業中の様子で、１本戻したところ）
グラフのマス目は１ｍで、１０秒間隔で測定した点をつなぎました。
最初の測定値の座標を（Ｘ，Ｙ）＝（０，０）として描いてあります。
これを見ると、ウェイポイントの間隔を２０ｍ、位置計測を７ｍおき程度で走らせれば蛇行するのも当然だわなーと思いました。
ＥＲ０１の時に積んでいたeTrexHの時は、同じように１０個程度の衛星を補足した状態で、こんなに動かなかった
ような記憶があるので、これはなにか、ロボットの制御ソフト側で処理してから使った方が良いのだろうと思いました。
このモードは、マイコンから見てあるピンのHigh/Lowをチェックするだけで良いので、距離センサユニット側で測定に 要している時間に関わらず制御ループが回り、衝突防止目的のセンサーとして都合よいです。
GPSで予め登録しておいた経路に沿って走らせながら、衝突防止目的で機能するか？誤検出はどの程度か？など 様子を見たところ、１回あたり１００ｍ位のコースを２０回くらい走らせた範囲では誤検出も無く機能しました。
これまでに使った超音波距離センサユニットだと、ロボットの全体制御をするマイコンやＰＣのソフトで行なっていた 気温による音速の補正や、測定レンジオーバー、測定失敗時の処理などをユニット搭載のマイコン側がが処理 してくれる上、気温３０度で、ユニット搭載の温度センサの読みが４０度くらいの時も動作が安定していたので、 使いやすくて良いユニットだと思いました。
まず初めに、補正前の状態を見るため３６０度旋回しながらX,Y,Z軸に分けて記録をとりプロットしてみました。
測定サンプル
数回測定してみたところ、プロットはだいたい円形になっているので、円の中心をX=0,Y=0にオフセットしてからATAN2で角度を 求めるだけで、だいぶ良くなりそうな感じがしたので、その方向でやってみました。
この変更により、走行前のRCサーボの温度ドリフトの影響をキャンセルするための測定走行が省略可能になるとともに、 芝生の斜面を横切る時の様に車輪のスリップが大きい場合の旋回角度測定が正確になりました。
ちなみにこれ以前は、後車輪のエンコーダカウント値から旋回時の円周をどれだけ進んだか求め、そこから 旋回角度を求める方式をとっていました。
ここしばらくのテストでは、コーンの間隔がGPSの測定誤差（３ｍ程度）に比べて短いせいか、進行方向を計算するときの 誤差が大きくなり、蛇行する場合が多く、結局移動経路が長くなるため、ゆっくり正確に走る方向で作ったソフトの時に比べ タイム短縮につながらなかった感じでした。
走行経路プロットサンプル
これを見ると、とりあえず目標地点通過後、次の目標に切り替えた直後は高速モードではなく、精密モード
が良さそうだと思いました。
外で簡単にテストしてみた結果、レンジオーバーの時にセンサーから結果が返るまでの時間が、制御ループのサイクル時間 である２０msec以上にかかる点の考慮が無かったので失敗でした。この点に対策し、また試そうと思いました。
ネットで知ったVL53L0Xを買って付けてみました。(写真では超音波距離センサの上に付いています) 買ってから詳しくマニュアル類を読んで気が付いたのですが、 ER02の様に外で使う場合、車体の長さ程度しか測定レンジが無く、測定時間もおなじみの超音波距離センサや PSDセンサと比べて特に短いわけでもなく、消費電力も大差ないけれど、プログラムの準備が面倒という かんじで、メリットを感じませんでした。
ただ、太陽の影響がない屋内用の小さなロボットには、センサー自体が小さいのでPSDよりも良いかも？と思いました。
テストはmbedでSTM32用に公開されていたソースコード（メーカー提供APIベース）を使わせてもらいました。 ER02はLPC1768を使っているので、ソースの中のピンアサインや割り込み部分等を少し変えて使いました。
フィールドテスト＃２(2017/2/10)
フィールドテスト＃３(2017/2/19)
プロットを見て、どちらもキャリブレーションがいるな〜と思いました。
＃３でジャイロコンパスがそれなりに働くことを確認したので、＃４では旋回角度の測定にジャイロコンパスを使うモード を追加して動作確認しました。
登坂も下り坂も、例えば２ｋｍ／ｈと指定したら、だいたいその速度で走るか？といった速度制御の方は思った通りに 働きました。いっぽうジャイロコンパスのテストは動作がおかしかったので、あとでログを見ながら対策するという事にしました。
スナップ写真
まっすぐ走りながら＃３でプロットしたのと同じ測定をしてみたところ、まだゼロから外れた測定値になっていました。 後は、シリアル通信の割り込みでGPSからのテキストデータを拾っているため、マイコンのループが回る時間の つもりでジャイロの積分時に使っているデルタｔが実際と無視できないレベルで食い違っていることが考えられた ので、GPSテキスト受信に割り込み処理を使うことをやめ、GPSテキスト受信と、ジャイロの積分を同時にしない 様にすることとしました。
これまで使ってきたAtom N270のmini 9と比べると・・・というか比べられないくらい早くて使いやすくなりました。
まだER02と共に外に持ち出したのは１回ですが、左手にPCを持って操作しながらER02の後をついていく使い方で、タッチパネルで 操作できるのがなかなか良かったです。ただ日なたで使うには画面が少し暗いのが難点でした。
左が新PC、右が旧PCです。mini9と比べるとだいぶ大きく見えます。
新しいPCにはタブレットモードがあるので、タブレットモードで使う形にER02の画面を作ってみようかと思いました。
各種試行錯誤の跡が残り、最終的には使わなくなった部分が多いER01のプログラムから、有用だった部分を切り出して 作ったプログラムなので、初めての屋外テストですが、それらしくあらかじめ登録した緯度経度をトレースする動きが出来ました。
移動距離を測る、車輪に付けたホール素子のエンコーダーの信号を、W8のマイコン側のソフトをよく考えずに移植したままソフトウェアのポーリング で読んでいたのですが、速度2km/hですでに信号の取りこぼしが出てきたので、LPC1768のハードのカウンタタイマでパルスを数えるように変更しました。
カウンタタイマを使うにあたり、NXPのUM10360 LPC17xx User manual（Capter21のCAP2.0の説明）とmbed LPC1768の回路図を参照しました。 mbedの開発環境の中で使っていると、あまり見る必要が無いので、今回の件で、少しマニュアルに馴染んだ気がしました。
スナップ写真
だいたいOKだったので、当初の目的を目指して調整を進め、GPSユニットをはじめ、新しく積んだセンサー類で、どの程度 性能アップできるか、やっていこうと思います。
GPSモジュールの接続方法変更
ソフト的には、ＶＢのBackGroundWorkerで受ける方式から、、割り込み処理で常に
読み取ってある位置情報を、ＰＣからリクエストがあった時だけ送る方式に変更しました。
ER01では、搭載マイコンがH8/3664だったので、PCを載せずに自律動作することを考えていませんでしたが、 LPC1768は、使った感覚的に後期のPC9801程度の処理能力があるので、PC無しモードを作ることも検討中です。
開発環境変更
ただ、スタートメニューの表示にさえ待たされる感じの遅さなので、この際モバイルPCを新調しようかと検討中です。
マイコン＆センサー類の搭載
「シャーシにトレイを載せたまま」でも良いかな〜という気もしましたが、簡単なカバーを付けよう！ということで、別の工作の 残材のアルミアングルとプラダン（ポリプロピレンの段ボールの様な断面の板）で簡単なカバーを作りました。この先、センサーヘッド を載せるとしたら、若干補強したのち、この上に載せることになると思います。
プラダンは軽くて、加工が簡単で良かったのですが、逆に柔らかすぎて、手持ちの接着剤も無く、固定がちょっと手間でした。 具体的には３ｍｍのボルトで留め、その周囲は１ｍｍのプラ板をプラスチック用の両面テープで張り付けて補強しました。 （写真は補強板取り付け前）
これまた、以前アースローバー０１（ER01）に積んでいたeTrexHよりも性能的に良い感触でした。そこで、ロボットに積んで様子をみるため、以前 ER01として動かしていたCR-01シャーシを引っ張り出して、走らせられるように整備を始めました。
とりあえずは、ER01の初めの頃に、ベニア板にいろいろ括り付け、PCは手にもって５ｍのUSBケーブルでつないだロボットの後ろを歩く形で 動かしていた時と同じ構成にすることとしました。
ベニアの時は、持ちにくく、時々木の棘が手に刺さったりして、作るのは簡単なのですがいまいちだったので、今回は１００円ショップで買った、 A4サイズで半透明の書類用トレイを使うことにしました。
現在は机の上で邪魔にならないように、マイコン、電源、動作確認用のRCサーボなどを搭載済の状態のトレイを、CR-01シャーシから 下した状態でマイコン（ｍｂｅｄ LPC1768）のプログラムを作っているところです。
ER01のPC側プログラムから見て、以前と同じように見えるモードと、PCから独立してLPC1768で制御とGPSの情報を元にあらかじめ与えた コースを走るモードを作ろうと思っています。
他には、ER01の頃はバージョン１だったOpenCVもバージョン３になり機能も増えたようなので、GPSでしばらく遊んでから画像認識機能を 強化して走らせてみようかと思っています。