2010年1月17日日曜日

CapybaraG.S.

去年の作った機体2つが、WMMCのHPの作品紹介に追加してもらったので、こっちでもう少し詳細な作品紹介を書いてみようと思います。
今回は、つくばチャレンジ2009に出場した機体、"CapybaraG.S."について。

まずは、簡単なスペックを紹介します。
  •  統括PC
    • Core2 Quad Q8400S
    • Windows Server 2003
    • RAM 4GB
    • SSD 30GB
    • 電源 Pb 12V 9000mAh
  • 駆動制御プロセッサ
    • SH7125 48MHz
    • RAM 8KB
    • Flash 256KB
    • 電源 NiMH 6Cell 7.4V 3300mAh
  • 推進
    • DCモータ x2
    • 電源 NiMH 6Cell 7.4V 3300mAh
  • 操舵
    • サーボモータ
    • 電源 NiMH 6Cell 7.4V 3300mAh
  •  センサ
    • ロータリエンコーダ
    • GPS
    • LIDAR
    • 地磁気
  • 台車
    • Tamiyaスーパークラッドバスター改造
  • 重量
    • 約20kg
  • 稼働時間
    • 約1時間
スペックを眺めつつ、解説をしていきます。

まず、ハード構成としましてはPCを統括、つまり障害物・自己位置推定および経路計画に用い、リアルタイム性が特に重要視されるごく局所的な速度制御および操舵処理を制御プロセッサであるSH7125が行います。
制御プロセッサを介して繋がるのは、推進用DCモータ、サーボモータ(さらにサーボコントローラであるAVRを挟む)、ロータリエンコーダです。このあたりのユニットは、実はモータドライバ以外は大学ロボコン2008で使ったものの使いまわしで、部室にあったものを有難く使わせてもらいました。ソフトは、以前使って知っていたので非常に組みやすかったです。
ロータリエンコーダの信号は、制御プロセッサで処理された後、PCからのコマンドに応じる形式で送信されます。
PCに直接繋がるのは、LIDAR、GPS、地磁気センサです。
稼動時間の1時間は、PC電源がなくなるまでの時間です。

次に、ソフトウエア構成についてです。
基本的にすべて.NET Framework3.0上で動作するように設計しました。
ソフトウエアアーキテクチャは、階層モデルを用いてデバイスを抽象化し、経路計画等の上位アプリケーションや、各種フィルタアルゴリズムなどがデバイスが変わった場合でも実装の変更を行わなくても済むように設計しました。
階層は3層に分かれており、各層はかならずI/Fを挟んで呼び出します。
シミュレータも簡単に作れるはずです。(作らなかったのですが……)

最後に重要モジュールに使われた(使う予定だった)アルゴリズムを簡単に説明
(抽象化されてるので、センサとかは変更されても大丈夫ですが、今回の構成で実際に使われたものを書きます)
  • 自己位置推定: 地磁気とエンコーダを用いたオドメトリ(EKF使用?)の後、パターンマッチ結果とのPFによる合わせこみ。ただし、地磁気M/WとPFの実装が間に合わず、実際はエンコーダのオドメトリのみ。
  • 障害物検出: LIDARからの情報を変換
  • 経路計画: ウェイポイント方式。位置推定の精度が悪いので緊急で付け加えて、一部区間は植木とのPID制御(位置)。
  • 障害物回避: 障害物が退くまで待機 & 動かない場合はいない方に進行

さて、反省を書きます。

まずは、全然大会に間に合いませんでした。最後のアルゴリズム説明の曖昧さから分かるように、使うアルゴリズムすら明確に決まっていない惨状です。この辺は、プロジェクトの初期において決めるべきだったかもしれません。
結局本腰を入れた期間が短く、実質的作業時間がほとんどなかったのと、ハードを大幅増強した時期の遅さ、それに伴うM/W製作に大きく時間をとられたことが問題です。

次に、台車の性能です。
プロジェクト立ち上げ時から懸念していたのですが、この台車はあまり適切ではありませんでした。何が最もいけなかったかというと、重量が大きすぎてステアリングの利きが悪くなった点です。リモートですらまともに操作できない操舵性……。傾斜次第では、最大にステアを切っても曲がらない、そもそもサーボの応答が遅いなどなど。なぜ変えなかったかというと、台車に愛着を持っている人がいたのと、終盤では時間とお金がなかったためです。これは今年、可及的速やかに対処します。

最後に天候対策。
トライアル前日の雨で回路が故障したのですが、そもそも屋外ロボットの大会なので、十分に考えておくべきことでした。事実、ほかのチームはしっかり対策がなされておりました。

というわけで、まとめます。
全体を通して、見通しが甘かったというのが事実です。これは言い訳できません。シンポジウムでほかの人の話を聞いていて、見通しの甘さを痛感しました。今年は、初期に大会までのロードマップと、アルゴリズムなどが迷走しないようにテーマを定めて製作にかかろうと思います。
各種センサやM/Wは前年で大体整備できたので、若干ソフトウエア設計を変更した後、各種モジュールの実装には比較的はやい段階で入れそうです。今年の物理的変更点は、恐らくIMUの追加と台車の変更くらいです。
懸念すべきは、研究室配属で場合によっては時間がとれなくなってしまうところ。まだまだ技術がない学生にとって、作業時間が削られてしまうのは致命的です。
しかし、仮にそういった事態になってもめげず、今年は完走を目指したいと思います。

3 件のコメント:

  1. 少々気になるのですが、センサーにGPSや地磁気センサーを用いているようですが、回路を組む際どのような事に注意されましたか?似たような回路を作りたいため教えていただきたいです。

    返信削除
  2. GPSはUSB接続のモジュールになっているので、回路そのものは特に考えていません。
    地磁気も結局はモジュールだったのですが、一般的にセンサ回路を組む場合は、モータなどの大電流回路など、ノイズ源の近くに置かなかったり、ノイズ軽減のために配線パターンを大きくとるようにしたりしています。あと、ディジタル化するまでの配線を極力短く、ですね。
    特に磁場に影響されるため、配置が大きな問題になります。回路が良くても配置が悪いと機体フレームの金属やモータなどに影響されるので、チップの配置だけでなく回路自体を最終的にどこに配置するべきかも考える必要がありました。

    返信削除
  3. やはり、配置に問題が出てくるようですか…。
    回路はやはりできるだけコンパクトに作ると意識はしてますが、やはりデジアナ混在回路となると心配ですね。
    GPSはUSB接続でしたか。
    自分も見習って、是非良いロボットを作れる様になりたいですね。

    返信削除