プラットフォーム
昨年、私たちは賞金100万ルーブルの飛行ロボットコンテストを発表しました 。 タスクは簡単に思えます-離陸し、障害物を迂回して着陸マーカーに座ります。 障害物とマーカーはタスクからタスクに移動します。 ロボットは、地上からのコマンドなしで飛行します（より正確には、「開始」と「緊急シャットダウン」の2つだけを受け入れます）。
競争の開始時に、情報技術部門のエンジニアとプログラマのチームは、ドローンの開発に関与したことはありませんでした。 しかし、私たちはロボットを購入し、全員と平等に競争に参加することにしました。 より正確には、対等な立場ではありません-条件に応じて賞品を獲得したり、賞品を受け取ることはできません。つまり、分類を超えています。
2012年の夏、ベルギーのオンラインストアから荷物が届いたときに初めてロボットを受け取りました。 ところで、私たちは幸運でした-ロボットはたった3週間しか持ちませんでした。 一部のチームは、プラットフォームに時間どおりに到着する時間がなかったため、競争から撤退しました。
それは準備の最初と最後の運でした。 この瞬間から、数ヶ月のレーキの話が始まりました。
最初はすべてがシンプルに見えた
ポリゴンレイアウト
したがって、最初のタスクは、ある時点で離陸してホバリングすることです。 つまり、ロボットが落下したり、飛び上がったり洗ったりしないようにする必要があります。 2番目は、実際には、壁に衝突しないように迷路を通る旅です。 3番目は認識です。 これらのタスクはすべて、何らかの方法で個別に解決できます。 また、センサーからのデータのフィルタリングなどの補助タスクの束（たとえば、一貫性のない照明条件や床の敷物のさまざまなテクスチャによる）。
同時に、高レベルのロボットアルゴリズムが私たちにとって最も重要であるため、多数の既製のライブラリとプラットフォームを使用することが許可されました。たとえば、ゼロからパターン認識を記述したり、宇宙でマルチロータープラットフォームを安定させるシステムを記述したりすることはできませんでした。
そのため、パッケージを開いた瞬間から、cなR＆Dが始まりました 。 チームにはクアドロコプターの管理に豊富な経験を持つ人がいますが、それらを管理するためのソフトウェアを作成した人はいませんでした。 そのため、すべてをゼロから完全に理解し始めました。 たくさんの本や記事を読む必要がありました。 10年前に大学で教えられたことを思い出して、飛行の物理を理解します。
私が最初に購入したプラットフォームはかなり「愚か」であると言わざるを得ません。つまり、たとえば、水平方向に自分自身を安定させる方法がわかりません。 ほとんどのアルゴリズムを自分で作成しました。 今、私たちはすでに障害物を吊るし、動かし、飛び回る方法を知っています。 しかし、私たちはゆっくりと正確に、約30センチメートル/秒で飛行します。 最短時間でタスクを完了したロボットが競争に勝つため、私たちはこれに取り組んでいます。したがって、他の参加者への模範にならなければなりません。
驚くべきことに、最も簡単な部分は、障害物を避け、ロボットの飛行経路をプロットする数学でした。 少なくともこれまでのところ、それは私たちに思われます。
センサーについて
宇宙空間でのオリエンテーションでは、GPS信号の使用を許可しましたが、ドローンは限られた空間で、またはGPS信号がなくても使用できるという事実から進んでいます。 したがって、ロボットには他のセンサーがあります。 幸いなことに、私たちはロシア最大のIT企業の代表として、それを購入する余裕があります。
私たち自身が導入したもう1つの制限は、すべての計算能力がロボット自体にあるということです（競合の条件に従って、プラットフォーム自体ではなく、自律型計算ユニットを使用できます）。 Intel NUSを使用しました。重量はわずか200グラムです。
Intel NUC
当社のレーザー距離計 （より正確にはLIDAR）は、パスポートに応じて30メートルを超えます。 つまり、ロボットがトレーニンググラウンドの開始点にある場合、遠方の壁が「見える」可能性があります。 これにより、現在の場所を正確に把握できます。 理論的に。 実際には、パスポートのデータは壁からのビームの完全な反射の状態でほとんど書き込まれているため、ライダーはわずか10メートルに当たります。 現実には、コーティングには「盲点」が存在します。 したがって、ポリゴンの「ボックス」全体が常に表示されるという事実を伴う初期計画は現在は機能せず、現在の速度を何らかの方法で測定する必要があります。 たとえば、オプティカルフローの原理によると、つまり、床を見下ろすセンサーを使用します（マウスのように）。
下と上からのロボットの外観は、開発の途中です。
そして、これがベルギーのオンラインマイクロコプターストアのウェブサイト上のプラットフォームです。
新しいセンサーを追加するのは大変な作業です。 まず、ファームウェアを監視する必要があります。 次に、フィールドテストを実施する必要がありますが、これは多くの場合、構造的な不具合で終わります。 回復するまでに数日かかる場合があります。 たとえば、ロボットで下向きの超音波ソナーをテストしたところ、定位置でのホバリングの原因となるアルゴリズムが失敗し、飛行中の飛行機の代わりにたくさんの曲がった鉄が得られました。 なんで？ ソナーは「耳が聞こえない」場合や、許容できない遅延を伴うデータを返す場合があるためです。 オフィスではうまく機能するが、アスファルトや他の舗装などではうまく機能しないソナーがいます。
6つのソナーに行きました。 オフィスでの保持決定を初めてテストしたとき。 それから彼らは外に出て、通りのソナーが地球を見ないことに気づきました。 その後、オプティカルフローセンサーをねじ込み始めました。ソナーもあります。 ですから、古いソナーを捨てなければなりません。
または、ここに着陸します。 ロボットがゲート（障害物）を飛行すると、カメラからの画像が着陸マーカーの検索のために分析され始めます。 マーカーが写真の中にあるとすぐに、幾何学的な問題を解決し、着陸のためにロボットの座標を与える必要があります。 そして、さらにテスト：センサーのエラーが干渉する場所、数学を誤って考慮する場所、ハードウェアに障害が発生する場所など。
テスト
アルゴリズムをテストするには、ガゼボシミュレーターを使用します。このシミュレーターでは、ヘリコプターとセンサーのかなり正確なモデルを作成し、ポリゴンモデルを再作成しました。 実際のテストについては、最初に部屋で約10 x 10メートル飛行しました。 これを行うには、すべてを正確かつ正確に行う必要がありました。なぜなら、そのような小さなスペースの飛行ロボットは多くのことを行うことができるからです。 そこで彼は10センチメートルの精度で位置を保持しました。
その後、CROC本社の駐車場の屋根に競技場のコピーを作成し、「戦闘」状態でロボットのテストを開始しました。
迷路をすばやく通過する方法を学べば、バッテリーを容量の少ない軽量なバッテリーと交換することでロボットを容易にすることができます。 これにより、設計が容易になります-重量は2.3キログラムになり、これが快適な管理の限界です。
鉄について
プラットフォームは、Mikrokoper quadro XLです。 初期ハードウェア図は次のとおりです。
スキームは最終的に当初の計画から変更されました。 たとえば、実際には、飛行構造自体（モーター上）に1つのバッテリーがあり、センサーと計算機に電力を供給する1つのバッテリーがあると想定しました。 現在では、1つのバッテリーにまとめられています。 さらに、私が言ったように、ソナーモデルが変更されました。 むしろ、ソナーの代わりに、すでにソナーが含まれている別のボード、Px4flowがありました。 私たちは彼女について楽観的です。 おそらく、加速度計が回路に追加されるでしょう。
最初のスキームでは、ARMプロセッサに基づくコンピューターを計画しました。 しかし、その後、Framework ROS（Robot Operating System）に基づくソフトウェアアーキテクチャに決めました。 このフレームワークには、オペレーティングシステムに対するかなり厳しい要件があり、LinuxベースのUbuntuシステムの特定のバージョンでのみ特定の機能を保証します。 また、すべてのARMコンピューターにこのシステムがクラウドレスでインストールされているわけではありません。 NUCはより重く、より多くの食べ物を食べますが、すべてうまくいきます。 それは多くの時間を節約しました。 一部のチームも試してみました。
ソフトウェアアーキテクチャ自体は次のとおりです。
埋立
多くの問題は、ロボットのテストの主なピークが冬に落ちたという事実にありました。 しかし、雪の吹きだまりに着陸するためのオープンプラットフォームでの私たちにとっては、最も望ましい状況ではありません。 フィルムを包むことさえ。
テストサイトを構築したとき、壁はフィルム付きの合板（ラミネートのようなもの）で作られていて、すべてがスムーズに進みました。 しかし、塗装が完了すると、素材の反射率の低下によりセンサーの精度が急激に低下しました。
数日前、ベルギーから2台目のロボットがやってきました。 最初に何かが起こった場合、競争のための予備としてそれを必要とします。
映像
テスト飛行中に発生するすべての動画を撮影し、YouTubeにアップロードします。
ここでは、強風でロボットをテストする方法を見ることができます。
これは私たちが小さな部屋に飛んだときの古いビデオです。
そして、ここにシミュレータからの小さなスケッチがあります-制限速度テスト：
これも興味深いかもしれません：
他のチーム
最初のチームは、配信の問題のために非常に最初から落ち始めました。 次の重要な脱落は4月から5月にかけてで、チームがモデルを粗末に扱いました。 すでに成果があり、問題を解決する方法が理解されていて、書かれたコードが2千行ある場合、非常に残念です。 彼らはそれをすべて捨てることがどれほど哀れかを書きました。
標準のAR.Droneで飛行するチームがあります。 AR.Droneにはソナーと2台のカメラがあります。正面向きのHDと、垂直方向に見える低解像度カメラです。 つまり、原則として、必要に応じてすべてを実行できますが、タスクはアルゴリズム的にかなり複雑になります。 もちろん、ロボットの鼻を着陸マーカーに置き、その真下のマーカーを見つける問題を解決できます。 しかし、干渉する価値があり、すべてが失敗します。
既製のプラットフォームを使用しない人がいます。 彼らはいくつかのスキーム自体を汚染した可能性があります。
プログラミングにはほど遠いチームがありますが、航空機のモデリングで20年の経験があり、ソビエト連邦の時代からこれを行ってきました。 彼らは開発者を自分自身に連れて行き、試してみます。
私たちは他のチームを支援しようとします：私たちはまだハードウェアへのアクセスが良好です。
現在、私たちのテストサイトでは、競争の一環としてテスト飛行が既に完了しており、戦闘に参加しなかったUAV開発者がやってくる可能性があります。 現在、モスクワとその地域の住民の間で、最後のコントロールポイント（最終日-7月21日）内を飛行しています。 参加する場合は、robots @ croc.ruに連絡してください。合格します。 レコーディングを急いで行うことをお勧めします。木曜日から日曜日まではすでに動揺しています。