(断りがない場合WLの話です)
「ルールが難しい」とか「運営が匙加減を知らない」とか普段言ってますが、今回は逆の路線から
「じゃあどういうロボットだったら対応できるのか」を真面目に考えてみます。
まずはロボットに対する要求仕様を定める必要がありますが、当然ルールがある競技なので
「ルールで定められている課題を攻略可能なロボット」
である必要がありますが、ルールも多いので果たしてどこから手をつければいいのやら...
ここで、ジャパンオープンの競技結果を見ていると結構なチームが時間を使い切るような競技をしていたことに注目して、まず初めに
「8分以内に競技を終了できるロボット」
という軸で考えてみます。
競技に必要な時間をざっくり見積もるため、ライントレースの長さや課題の数を数えていきます。
例えばジャパンオープンのラウンド3の競技レイアウトを見てみましょう。
指折り数えると、救助エリアを除いてスタートからゴールまで54タイルあることが分かります。
1タイルあたりの長さが30cmだとして、これを5分で走り抜けることを考えると、5.4cm/sで走行する必要があります。
ただこれは現実的ではなく、実際は様々な得点要素がライントレース上にあります。
例えば障害物であればこれを避ける時間が必要です。課題の攻略は基本的にロボットの動作速度に依存すると仮定して、「障害物のあるタイルは普通のライントレースタイルの2つ分の時間が余計にかかる」みたいな考え方をします。つまり障害物に進路上3回遭遇するラウンド3のレイアウトでは、
54+2×3 = 60
で60タイル分の長さがあるものと見積もります。これを換算タイル数とします
同様に他の課題について時間の重み付け係数を表のように設定すると、ラウンド1~3でそれぞれ表のような換算タイル数が計算できました。
各係数は採用するアルゴリズムによって上下すると思うので各自適当に変えてください。
求まった換算タイル数を元に、目標時間と安全率(進行停止等でのタイムロス)を入れて、必要走行速度を計算します。
表によると、換算タイル数が一番多いラウンド3では9cm/sでライントレースを行えば事足りるそうです。
あれ、意外と遅い
まぁ安全率が1.2と低い=ほぼ進行停止をしない前提なので、当然といえば当然でしょうか。
逆に言えばロボットの動作速度をここまで落としても、進行停止がなければ5分でライントレースが終わり残り3分を救助に充てられる、という計算になります。
とりあえずこの数値から、
①モーターと減速比、タイヤ径
②電源
あたりが見積れます。
おまけですが、この9cm/sという数値を元に、マイコンの処理速度を見積もってみます。
といっても私自身あまり込み入った部分はよく分からないので、これもざっくりとした見積もりです。
結論として、全く気にする必要はなさそうなので読む必要はあまりないです。
ラインを引くのに用いられているビニールテープはルール上1~2cmと定められていますが、実際には入手性の良い幅18mmのものが用いられていると思います。
このラインを9cm/sで横切ると0.2秒で通過することが分かります。
つまりロボットの制御周期は最低でも5Hzはないと、そもそもラインを見過ごしてしまう可能性があります。
余程変なシステムを組まない限りはこれを下回ることはないとは思いますが...
軽く調べたところ、ArduinoではanalogReadで100~200μsで読み取り可能です。
I2C通信ではビットレートを100kbpsの元、1回の通信として20bitだとやはり200μs程度です。
例えばこれらのセンサを合計20個つけると200μs × 20 = 4msとなります(250Hz)。
実際は諸々の影響(特にI2Cだとセンサ側の応答速度等)で読み取り速度は落ちるでしょうが、ライントレースの処理自体を50~100Hz程度でこなすぐらいなら余裕そうな感じです。
つまりこの辺りは全く問題にならないですね。
「ルールが難しい」とか「運営が匙加減を知らない」とか普段言ってますが、今回は逆の路線から
「じゃあどういうロボットだったら対応できるのか」を真面目に考えてみます。
まずはロボットに対する要求仕様を定める必要がありますが、当然ルールがある競技なので
「ルールで定められている課題を攻略可能なロボット」
である必要がありますが、ルールも多いので果たしてどこから手をつければいいのやら...
ここで、ジャパンオープンの競技結果を見ていると結構なチームが時間を使い切るような競技をしていたことに注目して、まず初めに
「8分以内に競技を終了できるロボット」
という軸で考えてみます。
競技に必要な時間をざっくり見積もるため、ライントレースの長さや課題の数を数えていきます。
例えばジャパンオープンのラウンド3の競技レイアウトを見てみましょう。
指折り数えると、救助エリアを除いてスタートからゴールまで54タイルあることが分かります。
1タイルあたりの長さが30cmだとして、これを5分で走り抜けることを考えると、5.4cm/sで走行する必要があります。
ただこれは現実的ではなく、実際は様々な得点要素がライントレース上にあります。
例えば障害物であればこれを避ける時間が必要です。課題の攻略は基本的にロボットの動作速度に依存すると仮定して、「障害物のあるタイルは普通のライントレースタイルの2つ分の時間が余計にかかる」みたいな考え方をします。つまり障害物に進路上3回遭遇するラウンド3のレイアウトでは、
54+2×3 = 60
で60タイル分の長さがあるものと見積もります。これを換算タイル数とします
同様に他の課題について時間の重み付け係数を表のように設定すると、ラウンド1~3でそれぞれ表のような換算タイル数が計算できました。
各係数は採用するアルゴリズムによって上下すると思うので各自適当に変えてください。
求まった換算タイル数を元に、目標時間と安全率(進行停止等でのタイムロス)を入れて、必要走行速度を計算します。
表によると、換算タイル数が一番多いラウンド3では9cm/sでライントレースを行えば事足りるそうです。
あれ、意外と遅い
まぁ安全率が1.2と低い=ほぼ進行停止をしない前提なので、当然といえば当然でしょうか。
逆に言えばロボットの動作速度をここまで落としても、進行停止がなければ5分でライントレースが終わり残り3分を救助に充てられる、という計算になります。
とりあえずこの数値から、
①モーターと減速比、タイヤ径
②電源
あたりが見積れます。
おまけですが、この9cm/sという数値を元に、マイコンの処理速度を見積もってみます。
といっても私自身あまり込み入った部分はよく分からないので、これもざっくりとした見積もりです。
結論として、全く気にする必要はなさそうなので読む必要はあまりないです。
ラインを引くのに用いられているビニールテープはルール上1~2cmと定められていますが、実際には入手性の良い幅18mmのものが用いられていると思います。
このラインを9cm/sで横切ると0.2秒で通過することが分かります。
つまりロボットの制御周期は最低でも5Hzはないと、そもそもラインを見過ごしてしまう可能性があります。
余程変なシステムを組まない限りはこれを下回ることはないとは思いますが...
軽く調べたところ、ArduinoではanalogReadで100~200μsで読み取り可能です。
I2C通信ではビットレートを100kbpsの元、1回の通信として20bitだとやはり200μs程度です。
例えばこれらのセンサを合計20個つけると200μs × 20 = 4msとなります(250Hz)。
実際は諸々の影響(特にI2Cだとセンサ側の応答速度等)で読み取り速度は落ちるでしょうが、ライントレースの処理自体を50~100Hz程度でこなすぐらいなら余裕そうな感じです。
つまりこの辺りは全く問題にならないですね。