SKY Crew Lab

RoboCup Junior(ロボカップジュニア)参加チーム、SKY Crew(スカイクルー)の技術ブログ。
技術の共有・伝達を目的に、ロボットに関するいろいろな情報やガイドを載せていきます。

2017年大会でRescue Line(レスキューライン) 世界3位、2018年大会でSoccer Lightweight(サッカーライトウェイト) 世界総合5位を獲りました!

カテゴリ:ソフトウェア > カメラ

日本大会の懇親会にて人気者のkossanの隣で爆睡していた、篠川です。

大会がひとまず一段落したので、またパラパラと記事を出していくつもりです。多分…

今回は私たちが日本大会で使った、全方位カメラでの相手ゴール周りの認識方法をものすごくざっくり説明します。

全方位ミラーを使う場合しか適応できない話が多くなりますが、ご容赦ください。

カメラの仕事は、相手ゴールの認識と、自陣ゴールの認識に大きく分けることができます。

この記事では前者についてです。

一応言っておくと、これはあくまで私たちが私たちのロボット向けに書いたプログラムの流れを、参考になるかもしれないと書き下しているだけのものです。

つまり、これは必ずしもベストとは限らないということです。

なので、ほかのチームにどれだけ当てはまるか、役に立つかは私もわかりませんし、もっといい方法も当然そのうち見つかるでしょう。

あくまで参考としてお読みください。

また、他にいいアイデアがあれば、ぜひコメントにお寄せください!

「この部分をもっと詳しく・よくわからない」といったご意見もどんどんお願いします。

内容

カメラが「相手ゴール周り」で認識するのは以下のことです。

  • 相手ゴールの方向
  • 相手ゴールの中でゴールキーパーがおらず空いている位置
  • 自機が前の角にいるか
  • ボールを蹴りだしてよいか

カメラは毎ループこれらを計算し、UART通信でメインマイコンに投げています。

大まかにこの順番に、どういうことをしているのかを説明していきます。

プログラムの書き方などはこの記事では扱いませんが、OpenMVに関してはIDEのメニューからFile→Examples以下のサンプルプログラムがとても参考になります。

そのまま貼り付けて使用するのはルール違反ですが、プログラムの書き方、ライブラリの使い方を理解する助けになると思います。

相手ゴールの方向

まずは相手ゴールの検知をするところから始まります。

全体的な方針として、角度を知りたいので、視野の中心、ミラーのてっぺんに当たる位置からぐるっと放射状に見ていきます。

close2

※画像左がロボットの正面

OpenMVで色を認識するといったら普通はimage.find_blobs(thresholds)を使うと思いますが、ここではそこまでする必要はありません

カメラをロボットに乗せた状態で、PCで視野を見ながらゴールのすぐ前→遠くまでだんだん離していくと、(当たり前ですが)ゴールが遠ざかっていくように見えますね。

close

far

ここで、下の写真の白い2円上をぐるっと見ていくと、その角度にゴールがあるなら、必ずその円上のどちらかの点がその色になっているはずです。

close with circles

far with circles

(手書きの雑な図ですみません)

ロボットが相手ゴールから背を向けるような向きになっている時はジャイロセンサーでまず正面(画像左)の向きに復帰する動きをさせるので、とりあえず前半分を回って確認していって、相手ゴールがあるかどうか調べていけばいいことになりますね。

ひとつ前のフレームとそこまでゴールの見える位置が変わることはないはずと考えると、毎ループで180度すべてを見回す必要もなく、直前にゴールがあった位置のすぐ近くを探索すれば、すぐにゴールが発見できます。

また、ある角度で黄色・青色のものを認識したとき、念のため+10度、ー10度の角度も確認し、干渉でないかどうか確認できます。周りに同じ色がなく孤立した小さなエリアはゴールではなく、ロボットのLED等の小さな部品が黄色・青色に見えているのだろうと判断できるからです。

というわけで、これによりゴールの左端の角度、右端の角度がわかりました。

相手ゴールキーパー回避

ゴールの位置が分かったところで、大抵はそこに相手ゴールキーパーがいます。

イナズマイレブンでもあるまいし、真ん中のゴールキーパーめがけてシュートしたり、ドリブルで突進していっても切ないので、ついでに相手ゴールキーパーも認識して、避けるように進ませたいところです。

というわけで、ゴールがある角度を7つくらいに分割して、それぞれの角度で「中心からどれだけ離れたところでゴールの色が出てくるか」ということを調べます。

中心から外側に向かって見ていって、最初に黄色・青色になるまでの距離を見るということです。

yellow

yellow enemy

さてここで、平均から明らかに外れて距離が遠いところがあります。上の写真で黄色く十字が打ってあるところです。

ここら辺を避けていくと、いい感じになりそうです。

というわけで、青の十字が一番長く並んでいる範囲に進めばよいですね。

補足すると、単に「平均より少しでも遠くに十字があれば、そこには相手!」とするのは良くないです。

コートの前側の角あたりにいてゴールの形が歪んでいたり、カメラの色認識に誤差が多少あったりすると、相手ロボット認識がいろんなところに出て荒ぶってしまうからです。

多少のマージンをつけましょう。

また、image.find_blobs(thresholds)はここらへんのところがごちゃごちゃにされています(よくわからん)。

相手ゴールキーパーがいるところもざっくりまとめて「ゴール」と認識されてしまったり、そもそも全方位に向いていないということで、この関数は結局一箇所も使わないことになりました。

ライブラリの関数はC言語で書かれてコンパイル済みになっており、Pythonで自力でループをまわして探して認識するより効率は良いはずなので、出来ればそちらを使いたいというのはあったのですが…

シンプルにゴールの位置を探すだけなら、きっとimage.find_blobsが一番楽なのでしょう。

ちなみに、去年の世界大会からは前向きにPSDセンサーを付けていて、正面の相手ロボットを認識してよけていくので、ドリブル時の敵よけはそちらにより頼るようになりました。

ただし、斜め前などの相手ロボットを避ける、相手ロボットの背丈が低い・肉抜きがすごくてあまり距離センサーが反応しない、もともと距離が遠いなどであれば、カメラの働きは大きいです。

コート前角検知

こちらは簡単なのでさらっと。

ゴールがめちゃくちゃ右・左に見えたら、それは自機がゴールに対して左・右にいるということです。

ゴールが真横近くにあるなら、自機がコートの前の方の角にいるとわかりますね。

相手ゴールの真横まで言ってボールを追いかけてもシュートにはつながらないし、角でアウトオブバウンズしたりゴールに引っ掛かったりすると、角は嫌なことづくしです。

というわけで、深追いせずに中立点の手前くらいまで後退し、アウトオブリーチやラックオブプログレスがかかるのを待つことにします。

ゴールの端っこが相手キーパーで隠されたりすると多少ずれてしまいますが、そこはあまり深く気にしないことにしました。

メインマイコンからジャイロセンサーの数値を送ってもらって、それを使って視界に映るゴールの角度を補正すると、割といい感じになります。

ボールを蹴りだしてよいか

ここら辺はキーパー検知と絡んできます。ロボットの正面と、左右数度を見渡して、ゴールがあり、相手ロボットがいなければ、キッカーを発動していいよ、となります。

メインマイコンは、ボールをキャッチした時、この情報をもとにキックするかを決めます。

これが「キッカーNG」という判定であれば、まだシュートせずに、相手ロボットの回避をがんばりつつドリブルしていくことになります。

その他の補足・小ネタ

カメラ(OpenMV)を使っているうちに気が付いた、本記事に関連するいくつかのことを、何かのために書いておきます。

FPS

PCにつないでカメラを走らせているときは、FPS(メインループが1秒で何周するか)を見ることができます。OpenMV IDEであれば右下にFPSというものが映っているはずです。

IDEに付属しているサンプルプログラムも、FPSを表示させるものがほとんどですね。

実は過去、後先考えずに相手ロボットの認識プログラムを書いていた時、気がつくとこれが5とか6になりました。つまりループごとに間隔が0.2秒くらい空いてしまうことであり、さすがに…という話になりました。

どうやって処理をショートカットして楽にするか、またどこの精度を落として手を抜けるか考えるのも大切そうです。

また、これもOpenMVの話ですが、PCにつないでFrame Bufferを表示させるだけで、通信でなかなかの時間がかかります。

IDE右上の「Disable」というボタンを押すと、Frame Buffer用の通信をしなくなるので、よりPCにつないでいないときに近いFPSを確認できます。

ただし「Disable」するとOpenMV IDE側でFPSを表示してくれなくなるので、サンプルプログラム通りにclock.fps()をprintしてみるのがよいと思います。

ちなみに現在の最新プログラムのFPSは30弱です。実はこれでも割と頑張った。

Stack overflow / Memory allocation error

OpenMVのメモリは実をいうとけっこう貧弱なようです。listやdictを大量生産していたとき、StackOverflowや"Cannot allocate memory"系のエラーが出て途方に暮れました。

気を付けましょう。

それから衝撃的なことに、静的変数を多く使用する、400行くらいになったプログラムをOpenMVに書き込み、実行させたとき、プログラムが長すぎてメモリに載りきらずに、エラーが出たり、ビジー状態になって手に負えなくなったりしました。

どうやらPCにつないで給電された際に、書き込んだプログラムをメモリに読み込み、さらにPCから「このプログラムを実行してくれ」と流し込んだことにより、400行プログラム2個分を読み込むことになっていたようです。

そこで、長めのプログラムが書き込まれた状態でPCと接続して、何かしらプログラムを走らせる時には、Hello Worldレベルの短いプログラムを一回だけ実行させてからだと、いったんメモリの中身がリセットされるのか、その直後長いプログラムをPCから実行してもエラーを吐かないことを発見しました。

Pythonプログラム中の半角スペースをTabで置き換えるのも地味に大きいです。

でもこれ1000行とか行ったら実行できなくなりそうだな…

通信

ほとんどの場合、メインマイコンに比べるとカメラのFPSはずっと低いです。通信でデータを投げるペースが全く違うので、メインマイコンでループ毎にカメラからの情報が来るまで待ち受けていると、それにメインマイコンの処理全体がものすごく足を引っ張られることになります。

メインマイコン側では「データが来るまで待つ」ではなく、「データが来ていたらなくなるまで受け取る」とするのがよさそうです。

干渉

相手ロボットが黄色や青の部品を積んでいたり、LEDが青色に見えたりすることがあります(私たちもあまりほかのチームのことを言えないところはあります)。

多少の小さなもので影響を受けないような仕組みにすることも大切です。なにかとびとびで小さく変な黄色・青色(・オレンジ色)のものを検知したら、ゴール(・ボール)と区別し、弾いてしまいましょう。

試合が始まる前に相手ロボットをしっかり見ておくのも大切です。後悔先に立たず。

まとめ

ここまで、実際にどうプログラムを書くのかという部分は全ておいておいて、「なにを行っているか」ということを書いてきました。

おそらくかなり雑でわかりにくいところもあると思うので、ご指摘、ご質問はどんどんお願いします。

また、かなりザーッと流れを書いたので、「この部分をもっと詳しく知りたい」というような意見は大歓迎です。

自陣ゴール周りの仕事やキーパーの動きについても、そのうち記事を書きたいと思っているので、よろしくお願いします。

篠川です。今回はカメラに関する記事ですが、まず実践的なカメラ導入の注意点を先に説明します。

ちなみにカメラはSKY CrewがRoboCupJunior Soccerに参加すると決めた時から「載せよう」と考えていた、ある種のアイデンティティです。

今までの大会でそれなりにいろいろなノウハウを積んできたので、これからもなんとかこういった記事は出していきたいです。(忙しかったりなんだり、ちょくちょく更新止まるけど許して)

なぜカメラ?

詳しくは約半年前の記事にも書きましたが、 簡単に言えば主に以下の理由からです。

  • 戦略の幅が増える
  • ほかのチームと差がつけられる

当たり前といえば当たり前ですが、ほかのチームと勝つためには、アイデアで差をつける必要があります。

別に特別なことをしなくても、お高い部品を積んで、アウトオブバウンズや故障をせず、きっちりボールを追うなどのことをこなしていれば、関東、日本と勝ち上がることは可能でしょう。

しかし、それだけでよいのでしょうか?

「いいモーターを積んだチームが勝つ」というようなつまらない競技にはしたくないですよね。

しかも、それで仮に日本大会を勝ち上がったとしても、上に行けば行くほどいい部品を積んだロボットは増えてきます。

つまり、(当たり前ですが)誰でもできることだけやっていても、勝てないのです。

どんなロボット競技でもそうですが、結局ものをいうのはアイデアだと私たちは信じています。

そんな方向性のSKY Crewにとって、「敵よけ」「FW・GK入れ替わり」はサッカー参入の時から目指していた夢であり、それらを実現しているのがカメラなのです。

積み方のバリエーション

「さあ、カメラを積もう!」となった時にまず考えるのが、普通に載せる全方位かですよね。

それぞれの特徴や利点などを説明していきます。

1. 普通に載せる(直置き)

  • 全方位ミラーを作るのが大変
  • 最初からいきなり全方位カメラをプログラムすることはリスクが大きい
  • ミラー・周辺部品はそれなりに重い

こういった理由から、Lightweightなら多くの場合は前向き、もしくは後ろ向きにカメラを取り付けることが多いでしょう。

ただし、Openではオレンジボールを認識するために、全方位カメラは必須です。

それからこの場合重要なのが、FW機には前向きGK機には後ろ向きに取り付けることです。(理由は後述)

メリット1. 簡単

簡単であるということは、設計の上で結構大切なポイントです。しっかり動作することを保証するには、やはり複雑にしすぎないことは大切ですよね。

それから、OpenMVの場合Pythonでプログラミングすることになります。

Pythonを使ったことがない場合はその分の学習コストも(そこまで高くはありませんが)必要ですし、バグのリスクもあります。

いきなり全方位を搭載するのはそれなりに大変です。ある程度の慣れ、練習はあってよいでしょう。

メリット2. GKが自陣ゴールとの位置関係を楽に計算できる

全方位ミラーを通して見ると、視界はゆがんでしまします。

しかし、直接カメラを後ろ向きに取り付けると、「ゴールから横に出すぎていないか」「前に出すぎていないか」といった判定がとても手軽にできてしまいます。

全方位でももちろん可能ですが、後方の視界を確保し、安定性を高めるという点で直置きは大変やりやすいです。

メリット3. ゴールがはっきりと、大きく見える

360°ではなく180°のみの視界であり、ミラーのゆがみなどの心配もないことから、カメラにとってはゴールがより大きく、きれいに見えることになります。

2. 全方位カメラ

カメラを真上に向けて、円錐またはドーム状のミラーを取り付けて360°見回せるようにしようというものです。

オープン機はオレンジボールを認識するため、必ず取り付けることになるでしょう。

ミラーの作り方や形状については別記事でゆくゆく解説します。

メリット1. 相手ゴールと自陣ゴールを同時に認識

これの何がうれしいかというと、マルチプルディフェンスを完全に防げるようになります。

割と知名度は低めかもしれませんが、最新ルール(日本語版)には このようなことが書かれています。ご存知でしたか?

マルチプルディフェンスが繰り返された場合、ロボットは故障として扱われます。単一の中断されていないチャンクの間に、3 回以上空いている中立点に移動させられたロボットは、故障したとみなされます。

注:ここでチャンクとは、何らかの理由(例えば、試合の前半が終わったとき、故障したとみなされたとき、またはアウトオブバウンズとなったとき)でロボットが 1 度フィールドから撤去されてから、次にフィールドから撤去されるまでを指します。

長いですが、要するにマルチプルディフェンスに対する罰則が明確に定められているのです。(しかも割と厳しめに)

ちなみにこれは2018年の世界大会になって追加されたルールです。ルール変更はちょくちょくありますから、気を付けましょう。

(逆に言うと、それまではマルチプルディフェンスがどこまで行ったら故障なのか、はっきり定められていませんでした。被害を受けたのが私たちで、2018日本大会の試合中かなり言い合いになってしまったことがあります。)

話を戻すと、このマルチ対策というのが割と難しいんです。距離センサーを後ろ向きに取り付ければ距離は測れますが、自陣ゴールよりも横にずれているときやGK(キーパー)がいるときに問題になります。

しかし、カメラがあれば全く問題が起きません。FWも相手ゴールと同時に自陣ゴールの距離・位置関係までわかるからです。

日本大会においてマルチで危なっかしい思いをしたことが、私たちが全方位にした大きな理由の一つです。

メリット2. 斜めを向いていても対象との位置関係が正確にわかる

このメリットは主にGKに発生します。

先ほど直置きのメリット2.で「自陣ゴールとの位置関係を計算できる」と書きましたが、(ジャイロセンサーを積んでいる限りあまり起きないことですが)何らかの理由でGKが斜めを向いてしまったときに問題が発生します。

ゴールが斜め向きに写るわけです。

これに正しく対処するのはそれなりに面倒です。

しかし、全方位であればミラーは円形ですから、いくら斜めを向いていようと関係ありません。

まあジャイロセンサーで正面を向いてから位置関係を計算すればよい話ですが。

(今回の記事とは関係ありませんが、ジャイロセンサーの記事もゆくゆく書く予定です)

メリット3. FW・GK入れ替えの夢

これを実現するためには、「FWになったら前のゴールを(メインで)見て、GKになったら後ろのゴールを見て」とするわけですから、全方位カメラは必要です。

割とこれは楽しかったですよ。

ちなみにここまで「FW機とGK機に分担する」前提で書いてきましたが、もちろん「両方FW」という戦略もなしではありません。

ただし、ボールの取り合いマルチプルディフェンス、相手のキッカーによるシュートマカオシュートなども考えると、やはりGKも作ったほうが安心ですね。

これも余談ですが、FWとGKの入れ替えは、マカオシュートを使うチームに対して特に有効でした。

マカオシュートを放った直後というのは、たいていスキが生じるものだからです。

最後に、それぞれのカメラに写る様子の写真を貼り付けておきます。

cam1

cam2

設計時に気を付けること

主なものを2つ取り上げます。

向き

カメラの視野は(多分どのカメラも)横長の長方形です。

直置きなら長いほうが水平になるように、全方位ならミラーをちょっと大きめにしてコートの縦の向きに長い辺が来るように置くことで、見える範囲を最大化できます。

視界を隠さない

特に全方位の時ですが、視界を遮るものをできるだけなくしましょう。

不透明なハンドルやフレームによって、カメラの後ろ斜め下が隠れてしまい、GKが自陣ゴールに近づいた時にゴールの下のほうが写らなくなってしまうことがあります。

これは距離を測るときに致命的になるので、注意してください。

試合中に気を付けること

こちらも2つ。

干渉

うっかり相手が青色LEDを使っていたり、見える範囲に黄色い部品をつけていたりすると、それをゴールと認識して突進していくことになってしまいます。

試合が始まる前にしっかりチェックして、干渉しないか時間をとって確かめてください。審判も待ってくれるはずです。

見つけたら指摘して、LEDを切ってもらったり、黒いペンで塗りつぶしてもらったりして対策してもらいましょう。

試合中に気づいた場合も、すぐに審判にコールできます。

ちなみに、白色LEDでも写り方によっては青と認識されることがあります。それはある程度までは認識プログラム側の責任ととられうるので、気をつけてください。

調整

ゴールの形や色合いは、たいていコートによって様々です。

しっかり調整しないと、FWがぐるぐるその場で回りだしたり、GKが自陣ゴールにぶつかりっぱなしになったりします。

各試合前には早めにコートに向かって、調整しましょう。


こんな感じでカメラを搭載したところで、今回の記事は以上です。

今回は余談多めでしたが、最後まで読んでくださりありがとうございます。

今度はプログラマの出番です。画像認識のやり方や全方位ミラーの設計・作成もただ今(本当に)執筆中で、日本大会までに出したいと思っているので、よろしくおねがいします。

こんにちは。ソフト担当の篠川です。私はサッカー部門について、特にカメラやジャイロについて書いていきます。

SKY Crewのサッカーロボットすべてに共通した特徴は、カメラの搭載です。 私もカメラ担当者として、ライトウェイトにおいて先進的なカメラの活用をしてきたとそれなりに自負しています。

しかしほかのチームを見ていると、カメラは(今普及しつつある?ものの)使っていないというチームもまだまだ多く、 積んでいてももっと有効活用できるのではないかと思うことがしばしばあります。

もしかしたら、カメラが今後のロボカップサッカー競技のレベル向上の大きなカギになるのではないでしょうか。

この「カメラ」カテゴリでは、さらなるカメラの普及と全体の技術向上を目指し、 全方位カメラの製作や処理の内容、カメラを利用した戦略などについて解説していく予定です(布教活動)。

今回はその第一弾として、カメラの導入をしない、または検討している、特にライトウェイトのチームに向けて、 カメラを導入する理由を説明します。

私たちのロボットは、最初に出場した関東ブロックの時からカメラを積んでいます。 ここでは、使っていてわかってきたメリット・デメリットについて(そしてなぜカメラが役に立つのか)説明していきましょう。

メリット

姿勢制御

フォワードロボットは基本的に、 常にゴールの中心を向くように動きます。 これにより、ボールを捕捉した後のドリブルが効率的になります。

キーパーロボットは、(全方位カメラを使った世界大会を除いて) カメラを後ろ向きに取り付けました。
これで自陣のゴールとの位置関係を計測し、ゴールからあまり遠ざからないように調節しました。

ここらへんのカメラを利用した戦略については、今後の記事をお待ちください。

正確なシュート

カメラを搭載していないロボットの動きを見ていると、ドリブルしてボールをコートの奥まで運ぶはいいものの、 ゴールの位置がわからないため、ゴール左右の外側にシュートしてしまって惜しくも入らない、ということがよくあるようです。

しかしカメラがあれば、先ほどの「姿勢制御」により、
どんな位置でボールを捕捉しても、スムーズにゴールへ向かいシュートすることができます。

距離センサーで壁との距離を測って横軸方向にどれくらいの位置にいるのか割り出すチームもいますが、 あれって隣に別のロボットがいたり、ロボットが少し斜めを向いていたりしてたら正しく出ないんじゃないでしょうか。

現在位置の大まかな特定

これに関しては、今年のルール改定でランドマーク(赤とか水色とか)がなくなり、少しやりづらくなりました。 しかし、ゴールまでの距離を3段階くらいで大まかに測ることで、 マルチプルディフェンスの回避ゴールキーパーの効率の良い動きが実現できます。

これらの恩恵は、実は結構大きかったです。

これに関しても、今後別の記事で解説する予定です。 ただし、世界大会のプレゼンテーションシートでもこの件について触れておりますので、 (英語ですが)そちらを見ればどのように位置情報を利用しているかがわかるかと思います。

プレゼンテーションシートPDF(32.4MB)

相手ロボットの回避

どういうことかといいますと、相手ゴールを部分的に隠している何かがあったらそこに相手ロボット(特にキーパー)がいるとわかるということです (これもプレゼンテーションシートに書いてあります)。

それがわかれば、それを避けてシュートすればいいですよね。

これはうまくいった時の効果が非常に大きいです。 するするっと相手キーパーをかわしてシュートする様子はちょっと感動モノですよ。

柔軟性

「こんな動きができるようにしたい!」というアイデアが浮かんだとき、カメラがあると非常に実現しやすいです。

例えば、日本大会のロボットはモーターが大きく、後の世界大会のときのようにラインセンサーを円形に配置することができませんでした。

センサーが不完全だったため、ラインの辺の部分であれば検知して内側に戻れるのですが、角にいるときに内側がどの方向かわからず外に出てしまうという事態が起こりました。

そこで私たちが取った戦略は、カメラでゴールとの位置関係を測ることでコートの角にいることを検知し、コートの角に行かないということです。

コートの角まで行ってボールを取りに行ったところで、ラックオブプログレスを取られたら意味がありませんから、 中立点の少し手前で待機して、相手より早くボールを捕捉しようという作戦でした。

何が言いたいかというと、カメラによって急な問題に対処しやすいということです。

「それくらいラインセンサーを設計する時点で見越しておけ」と言われれば、その通りですが…(^_^;)

Technical Challenge

ルール(こちらの24ページ) を見た方はわかるかと思いますが、「カメラがないとできない」というような課題が結構ありましたよね。

そこまで大きく勝敗にかかわるものではないかもしれませんが、一応メリットとして挙げておきます。

今後どうなるんでしょうね…

デメリット

調整が大変

もちろん、残念ながらデメリットもあります。その最たるものがこれでしょう。

実は、コートによってゴールの高さや光の当たり方による色の映り方が違うということが頻繁にあります。 ですので、各試合前にコートの色や形を設定する必要が出てきます。

ここでうっかりすると、最悪の場合オウンゴールもあり得ますから、焦らず慎重に行うことも大切です。

つまり、試合開始の10分くらい前からゴールに陣取っていろんな調整をすることになります。

もちろん会場の各コートの正確性や照明などによっても変わりますが、 ラインセンサーの調整などもしたい中、これはなかなか大変です。

ロボットは各チーム2台あるので、ソフト担当者が2人以上いれば、分担することでだいぶ楽にはなります。 ただしそうすれば片方はカメラにつきっきりだと思っていいでしょう。

時に相手ロボットと干渉する

これは例えば、相手ロボットの青色LEDが青ゴールに見えてしまい、 相手ロボットに向かってシュートしたり、敵避けをしなかったりするということです。

これも時に大問題になります。前もって何らかの対策を講じないと、決まるはずのゴールが全く決まらず、 相手キーパーにプッシングし続けることになってしまいます。

対処法はもちろん、試合前に干渉しないかチェックすることです。

人の目には青に見えないような白色LEDなどでも、カメラには青く映ることもありますから、 相手のラインセンサーやボール捕捉センサーが怪しいと思ったら、 前もって光をつけてもらって、干渉しないか確かめる必要があります。

ちなみに試合中でも干渉は主張できますが("Interference!")、 試合が始まる前に明らかにした方が仲も悪くなりませんし、世界大会ではTeam Spiritにも関わってきますので、 「わざと試合中に干渉を主張して相手を故障にさせよう」といった考えはおすすめしません

実際に干渉していたとしても、「これくらいのLEDだったらちゃんとゴールと見分けてほしい」と判断されることも結構ありますので、 きちっと前もって対策を講じましょう。

まああのカラフルなランドマークは廃止されましたので、その点では少し楽になったとはいえるでしょう。

視界を隠される

メリットのところで「姿勢制御」を書きましたが、一つ考えなくてはならないのは、
相手ロボットの背が高く、カメラの視界をふさがれるケースです。

対処法としてまず思いつくのはできるだけカメラの位置を高くすることですが、それでも完全ではありません。

そのため、結局はカメラだけではなくジャイロセンサーも同時に搭載することになるでしょう。
最初に参加した関東大会ではジャイロを搭載しておらず、オウンゴールを何度かしてしまいました。

ただし全方位カメラであれば、自陣ゴールが見えないという状況はあまりないと考えられるので、 ジャイロなしでも不可能ということはないかもしれません。それでもやはり積んでおくと安心です。

ジャイロに関しては、別の記事で詳しく書く予定です。

やや重い(?)

これはどうしようもありませんね。

具体的には、私たちの使用した「OpenMV Cam M7」の重さは16gです。これを重いと感じるか軽いと感じるかはあなた次第です。(笑)
一応Pixy(27g)よりは軽いのですね。

OpenMVとPixyの比較も後日詳しく書く予定です。
結論を先に言ってしまうと、可能ならばOpenMVの方をお使うのが良いでしょう。
私達が大会に参加しだしたときはそう考えたのですが、今年度Pixy2がリリースされ、状況が変わってきているようです。そちらもぜひ調べてみてください。

まとめ

カメラのメリットをまとめると:

  • 戦略の幅の広がり
  • 良い(まともな)シュート

一方、デメリットは:

  • 状況によって不安定

使ってみた私たちの感想としては、やはりあったほうが良いです。

不安定さというデメリットよりも、メリットの方を取ったわけです。

私たちSKY Crewは結構アイデア志向のチームなので、その意味でもかなりカメラとの試行錯誤は楽しいものでした。

その分不安定さの解決は頑張りました。きっちり前もって対策をして、スムーズにカメラの調整を行えるように努力する必要があります。

また、今までのロボットは重さの制約上キッカーを搭載することができませんでしたが、 キッカーを載せるならカメラの効果はとても大きいでしょう。

ロングシュートが相手キーパーを避けてスカーンを決まったら楽しそうですよね!

将来的にこのサッカー競技が発展して、レベルが上がっていけば、 どちらにせよオープンのようにいつかはカメラ必須のような状況になるのではないでしょうか。

先進的なサッカーをしたいと考えるのならば、 カメラは積むべきと言えるでしょう。

さて、今後は先程も申し上げたように、「カメラ」カテゴリで処理の内容や戦略について解説していきます。

それから、きっと近いうちに自分以外の暇なメンバーが世界大会の試合以外の評価について解説記事を書いてくれることでしょう(プレッシャー)。
ご期待ください。

ちなみに、今回ブログ全体のデザインを若干変更しました。

トップページもかっこいい感じにしたいと思います。

記事に関してもデザインに関しても、良くないところや改善点、どんな感想でも送っていただけると大変嬉しいです。

スマホの表示のカスタマイズが出来なすぎる
livedoorさん…

↑このページのトップヘ