タランタセスの4週間のレース

みなさんこんにちは！ 私は、ラジコンタランタスレースの作成者の 1人です。



www.redbullsoapboxrace.ruは、Red Bull Soapbox Raceイベント専用のオンラインプロジェクトで、ミニチュアタランチュラレースです。



私たちのプロジェクトについての投稿が書かれており、これはプロジェクトについて話をしたいという誘いへの返答です。



このアイデアはキッチンでコーヒーを飲みながら生まれ、どのようにすべてが起こったのか、4週間でプロジェクトをどのように実行したのかを読み進めました。



私はプロジェクトのアイデアとアーキテクチャの著者であるDmitry Maximovの依頼で投稿を公開します。



実際、プロジェクトを立ち上げるまでにたった4週間しかありませんでしたが、驚くべきことに、6人のチームでこのタスクに対処しました。 私たちにとって、これは極端な条件でのチームワークに適した学校でした。

週1

建築

一見したところ、アーキテクチャは非常に単純です。







実装にはいくつかのオプションを検討しました。

1. インターネットを制御できる既製の車 。 このオプションはゴールドであることが判明したため、すぐに放棄されました。
2. 彼らはwww.jokerracer.comに連絡しましたが 、彼らはプロジェクトを作成するのに半年かかり、またそれを再び上げるには同じくらいかかり、そして私たちは3週間強しかなかったと言いました。 ちなみに、彼らはレースではなく、ただ乗りました。 そのため、「世界で最初」というタイトルを引き続き使用できます。
3. Aurdinoは、一方の端でusbポートに挿入され、もう一方の端でコンソールにしがみつき、無線信号をマシンに送信します。 しかし、Arduinoの下では、低レベル言語での開発が必要であり、すでに時間は尽きていました。
4. Phidg​​etsは、エンジンコントローラー、カメラ、あらゆる種類のセンサーを制御するための20以上の言語とライブラリの高レベルAPIを備えたプラットフォームです。

最後のオプションが完全に登場しました！



6 usbを搭載したLinuxのオンボードコンピューターがマシンにインストールされ、DCモーター（移動用のコレクターモーター）のマイクロコントローラーとサーボドライブ（前輪の回転を担当）のマイクロコントローラーが接続されます。



さらに、ラップタイムを修正するために磁気センサーがコンピューターに接続され、USBとカメラとwi-fiアダプターを介して接続されます。



すべて次のようになります。







唯一のマイナスのフィジェット-7台の車に7セット必要でしたが、完全なセットで購入できるのはカナダだけです。

車

当初からこのマシンを使用する予定でした。HCPRacingのMonster Truckです。 機械はプロフェッショナルであり、スペアパーツを簡単に見つけることができます。







コレクターは計画された負荷で3日ごとに交換する必要があるため、プロジェクトの開始前でも、ブラシレスモーターを搭載したマシンを推奨するGlavbotのスタッフと相談しました。 しかし、フィジェットはDCモーターでのみ動作するため、リスクを負う必要がありました。結局、正当化されることになりました。もちろん、モーターは変更する必要がありましたが、頻繁ではなく、重負荷のためではありませんでした。



マシンの速度は16 m / sで、レースルームの長さは15 mなので、速度を落とす方法を見つけなければなりませんでした。

1. 抵抗器を置くと、機械は消耗したバッテリーになりません。 通知。
2. 彼らはギアボックスを作ることを考えましたが、計画された負荷の下では毎日壊れる手動組み立てに成功していました。 通知。
3. そわそわAPIを見て、ああ、奇跡！ -速度を調整することが可能です。 これで停止しました。

バッテリー

機械に付属のバッテリーを使用すると、約15分間連続運転できます。 私たちは24時間ライドを行い、より多くの人が乗れるようにしたかったので、技術的な休憩を最小限に抑える必要がありました。



その結果、最大4時間充電できるバッテリーのオプションを選択しましたが、念のため、2時間ごとに交換します。







彼らはすべてのコンポーネントを決定したようで、すべてを手に入れ、プログラムとテストを行います。



UPD：約束どおり、プロジェクトに関する残りの情報を公開します！

週2：ビルド

先ほど書いたように、小道具は小道具サイトから直接カナダに注文しなければなりませんでした。 合計で約2か月間、ロシアの税関に確実に掛かる約30個のマイクロサーキットがあったため、2つの通関手続きでフィンランドを駆け抜けました。 そわそわによると、販売代理店は7月にロシアに登場しますが、それほど時間はありませんでした。



すべてが手元にあり、最初のプロトタイプを組み立てたとき、マシンの重量は3 kg（ケースを除く）になりました-マシンが腹に乗らないようにショックアブソーバーを強化する必要がありました。



最終的には次のようになりました。











Windowsの小道具に付属のプログラムを使用して、小道具をテストすることができ、いくつかの問題がすぐに検出されました。

カメラ

Fidgetカメラはひどい品質の画像を送信しました。これは常に320X240の解像度と毎秒10フレームでハングしました

最初は、これはそもそもが原因であるという仮定があったため、ビデオが直接送られるように、すぐにIPカメラを使用することにしました。 しかし、このオプションはマシンをさらに500グラム重くし、これは計画された負荷に耐えることができませんでした。



h.264でオートフォーカス、フルHD画像、ハードウェアビデオコーデックを備えた別のUVC互換カメラ（Logitech HD Pro Webcam C920）を試しましたが、結果はまさに素晴らしいものでした！ 確かに、h.264コーデックはフィジェットでサポートされていないため、使用できませんでした。 MJPEGで停止する必要がありました。



また、安価なLogitech HD Webcam C525（現在はトラックからのオンラインブロードキャスト）も試しましたが、ビデオが再びフリーズし始めました。



また、カメラの近くに配線がある場合、画質が大幅に低下するため、ケースをカメラから外さなかったことにも気付きました。ただし、審美的な観点からは、カメラがマシンの本体にある方が良いでしょう。



カメラとwi-fiアダプターの動作に影響を与える干渉のため、すべてのワイヤの長さを短くする必要がありました。

週3：プログラミング

到着は5分間続き、同時に5台の車が到着に参加できます。 5台のうち1台がpingに合格しない場合、2台の予備の車がアクティブになります。



レース間では、1人のユーザーから別のユーザーに制御を切り替えるために1分が割り当てられます。



2時間ごと-バッテリーを交換し、何か問題が発生した場合は修理するための30分間の技術的な休憩。



当初、最大の問題はビデオの遅延、またはむしろモスクワからのユーザーの遠隔性に関連する信号の遅延に起因すると考えられていました。 モスクワから200キロ以上離れた場所（レースが行われている場所）のユーザーは、間違いなくスキーの問題を経験します。 さらに、遅延があることすら理解していません。マシンの制御が不十分になっただけです。ユーザーは前に押し出され、マシンはわずか0.5秒後に移動しました。 前後の動きについては、これはそれほど大きな問題ではありませんが、順番については重要でした。 しかし、参加を制限することは不適切であると考え、次のように行動しました。



1）半径200キロメートルに住んでいた人は誰でも、近い将来にサインアップできます。

2）他の都市は、スケジュールの最後からサインアップできます



このオプションは遅延の問題を解決しませんでしたが、いずれにしても、最初に悪いレビューはありませんでした。



その後、近い将来、録音機能を中央地域全体に拡大しました。

映像

高品質のスケートには、遅延を最小限に抑えることが非常に重要だったため、メディアサーバーを介して車からビデオをブロードキャストするオプションは不要になりました。



ユーザーがJavaプラグインをインストールするためのオプションがありましたが、第一に、彼は非常に重く、第二に、誰もが自分でプラグインをインストールする可能性は低いです。 また、Flash要素を使用することを望んでいましたが、ビデオストリームを含むドメインにcrossdomain.xmlセキュリティファイルが存在する必要があり、httpd fidget WebサーバーでxmlファイルのMIMEタイプを構成することはできませんでした。



次のオプションを決定しました。

FF、Safari、Chromeでは、MPEGストリームをサポートできるブラウザー自体のツールを使用します。 他のブラウザの場合、画像を更新するJavaスクリプト。 その結果、ローカルネットワークでは、遅延は50ミリ秒でした（参考までに、マシンは0.5秒の遅延でほとんど制御不能になります）。

運営管理

タイプライターに接続したときに、DCコントローラーが接続されていないことが判明した場合がありました。 ユーザーは前後に移動できませんでした。 再接続してこの問題を修正しました。 したがって、カウントダウン中およびマシンが静止した後の最初の数秒の間、10秒後に最終的に運転を開始します。

サーバー

サーバーは、次のパラメーターを持つ通常のコンピューターです。

-Intel Core i3-2100プロセッサー

-マザーボードGIGABYTE GA-H61M-S2V-B3

-RAM DDR3 DIMM Hynix-4 GB



CPU負荷は、5台の車に乗る場合、10パーセント以下です。

インターネット

100 mbの専用チャネルを使用することを計画しました。 その結果、20 Mbpsのチャンネルで十分でした。 レースに5台の車が同時に参加するため、発信トラフィックは約7 Mbpsです。 通常、着信トラフィックは重要ではありません。



最初は、Trendnetのホームルーターを使用しようとしました。 ただし、3台のマシンを同時に接続している間、フリーズし始めました。 この状況は、シスコからLinksys e1200ルーターへの移行により修正されました。



定期的にwi-fi信号に干渉が発生し、マシンのpingが消えるか、非現実的に大きくなります。 これは2日ごとに発生し、5〜10分続きます。その後、すべてが安定します。 彼らは明確なパターンを明らかにすることができませんでした。 これが赤10月に含まれることはまだ興味深いですか？:)



制御の最大の問題は、要求が「前方/後方」になった瞬間に機械またはユーザーとの接続が定期的に失われることでした。この場合、機械はまだ前方にぶら下がり、障害物にぶつかってモーターを燃やしました。



Wi-Fi信号の送信の異なる周波数（5 GHz）に切り替えることを考えましたが、そのためには、5 GHzの周波数をサポートするルーターとWi-Fiアダプターに切り替えて、オンボードコンピューターに適切なドライバーをインストールする必要がありました。 Linuxがオンボードコンピューターにインストールされているという事実にもかかわらず、Phidg​​etsにはドライバーをインストールするための標準メカニズムがありません。 したがって、別の周波数に切り替えるという考えは放棄されました。

4週目：テストと起動

最初は、滑らかな上り坂と急な下り坂を備えた8桁のトラックが構築されました。







降下時には、磁石（通常、ナイフを研ぐため）が取り付けられ、磁気センサーが作動してラップタイムが記録されました。

速度調整

車の速度を一定にして、問題なくマシンが丘を登るような値に制限することを計画しました。 しかし、バッテリーの充電度への速度の依存に直面しました。 4ラップ後、マシンは速度を上げることなく上昇できなくなりました。つまり、バッテリーを交換するか、4ラップごとに速度を上げる必要があります。



プロセスを可能な限り自動化し、技術的な中断を減らすために、2番目のオプションを選択しました。 速度調整は、マシンの制御インターフェースで行われました。 ユーザーは、AZボタンを使用して速度を上げて丘を登ることができます。



プロジェクトが開始されたとき、登山はスキーの観点からはあまり面白くないことがわかりました-狭いため、クラッシュした場合は向きを変えるのが難しく、ほとんどのユーザーはそれにこだわっています。 登山は取り外され、ユーザーが運転できないように小さなステップで円形のトラックが作成されました。

モーター

リフトが軌道に乗っている間、機械が動かなかった場合、印加電圧のためにモーターが燃焼するため、モーターを交換する必要がありました。 ラップトップファンはエンジンの冷却に役立ちましたが、常にではありませんでした。



ある時点で、モスクワのモーターは終了しました:-)強い熱でコントローラーとモーターの間の接触を壊すヒューズを入れる必要がありました。 残念なことに、これは、レースの途中でユーザーが停止し、ヒューズが冷えて回復するのを待つという事実につながりました。 トラックが閉じられたため、このような問題はありません。

ファン

ファンは最も一般的なラップトップを使用しました：



アセンブリの最初のバージョンでは、ファンはバッテリーで直接駆動されて常に動作していました。 しかし、この場合、彼らはすぐに燃え尽き、さらにバッテリーを植えたので、ファンはコントローラーの別のポートに接続され、マシンが運転しているときにのみオンになりました。

本体

ケースは、上部と側面が金属板でできたバンパーで覆われた固体フォームでできていました。 その過程で、私たちの耳とヒレが飛んで、卵が巣から落ちましたが、体自体はそのままでした：











アップデート1 ：



多分ハブラー効果か何かかもしれませんが、今日では5台の車が同時に難航しました。 2台のルーターを設置しました-良くなりました。



更新2-ラップタイム追跡システムについて



このプロジェクトのもう1つの興味深い問題は、ラップタイムアカウンティングシステムの選択でした。 いくつかのオプションがありました。



ターンキーソリューションを使用します。 ラジコン車のオフライン競技では、多くのクラブがMy Lapsを追跡するプロフェッショナルなシステムを使用しています。 このシステムは、デコーダー、車に取り付けられたトランスポンダー、およびフィニッシュラインの交差点を固定するフレームで構成されています。 さらに、マシンが反対方向にフィニッシュラインを越える場合、デコーダーはこれを理解します。



ただし、My Lapsは非常に高価なソリューションです。 興味深い代替案が見つかりました。I-Lapsシステムは 、技術仕様ではMy Lapsよりも実際には劣っていませんが、価格は数倍安くなっています。



I-Lapsには独自の競争ソフトウェアがあります。 ただし、システムからデータをアップロードして各ラップの時間とレース終了時のベストラップ時間を表示する方法がなかったため、私たちの目的には適していませんでした。



また、 DCD timeRを見つけました-これは非常にエレガントなソリューションのようであり、価格の点で手頃な価格でした。 しかし、メーカーは、ウェブサイトにデータをアップロードするためのAPIを作成できないと述べました。 何と残念-このソリューションが本当に気に入りました。



私たちは、I-Lapsとの統合を自分で記述する必要があるという考えにほとんど慣れていましたが、アナログ磁気センサーをオンボードコンピューターに接続できることがわかりました。 磁場が増加すると、オンボードコンピューターに信号が送信されます。 磁場の発生源として、磁石を使用してツールを壁に取り付けました。 ゴルは、車がフィニッシュラインを逆方向に移動できるという事実にどのように対処したかについて質問しました。 これまでのところ、ステップの助けを借りて決定しました。 より興味深い解決策は、各マシンに2つの磁気センサーを配置することです。 次に、それらの操作のシーケンスにより、マシンがフィニッシュラインを横切った方向を判別できます。



乗りたい人は本当にたくさんいます。みんなが試せるように、私たちは乗り物のために夜の時間を開けなければなりませんでした。 もちろん、誰もが普通に運転できなかったのは残念ですが、これはほんの始まりです！