低コスト検査ロボットの設計と開発
1。はじめに
我が国のインフラは老朽化し、急速に悪化しています。現在、私たちの橋、廃棄物タンク、パイプライン、および原子炉の状態を徹底的に検査するメカニズムはありません。これらの構造物の多くは設計寿命に達しており、劣化がないか検査する必要があります。陸上でのこのような状況のように、腐食の兆候がないか、米海軍の船や石油タンカーの船体や甲板を検査する必要もあります。背の高い橋や廃棄物タンクなどの多くの古い構造物は、さまざまな理由で調査や検査が難しいことがよくあります。最も一般的な理由は、検査プロセスが人体に危険であるか、構造にアクセスできないセクションがあることです。もう1つの一般的な理由は、現在のプローブ技術ではそのような構造を正確に検査するには不十分な場合があることです。したがって、手動検査は、頻度が低く、面倒で、費用がかかり、危険であり、エラーが発生しやすいものです。この問題は、よくできた検査ロボットに絶好の機会を提供します。
検査ロボットは通常、電気および機械エンジニアの資金が豊富な大規模なチームによって設計および開発されています。 Packbot 510（http://endeavorrobotics.com/products）などの商用ロボットは、100,000ドル以上かかる可能性があります。個々の科学博覧会プロジェクトの制約を考えると、ここでの範囲は、検査ロボットの安価なプロトタイプを設計、開発、およびテストすることです。 このプロジェクトの目的は、検査対象の表面に取り付けたままで済む、小型、軽量、安価な検査ロボットのプロトタイプを開発することです。 プロジェクトは、次のタスクで構成されています。文献と既存のデザインのレビュー。要件の仕様;ロボットの設計;初期プロトタイプの開発とテスト。工学力学計算; Pythonを使用してロボットをプログラミングする。 2番目のプロトタイプの開発とテスト。最終的なプロトタイプの開発とテスト。
ロボットを物理的に構築する前に、3DモデリングソフトウェアSketchUpを使用して、ロボットを視覚化し、設計を改良しました。ロボットは、ロボットを制御するためのRaspberry Pi 3モジュールなど、市販のコンポーネントから構築されました。繰り返しのテストにより、設計は繰り返し改善されました。 Pythonコードは、ロボットをプログラムするためにゼロから作成されました。設計が進化するにつれて、ハードウェアとソフトウェアの両方を同時に変更する必要がありました。プロトタイプは、ワシントンリバープロテクションソリューションズとパシフィックノースウェスト国立研究所のエンジニアリング専門家、およびワシントン州のシニアデザインクラスにデモンストレーションされました。
大学、トリシティーズ。専門家からのフィードバック、工学力学の計算、およびテストの結果に基づいて、3番目のプロトタイプが作成およびプログラムされました。結果として得られるロボットは、適度な速度で壁を登ることができ、ナビゲーションと検査に役立つ複数のカメラを備えています。このプロジェクトで製造されたロボットは、この目的のために特別に作成されたソフトウェアを使用したユニークなデザインを表しています。このプロトタイプは、検査機能を強化するために必要に応じて新しいセンサーを追加できるという点で、柔軟なプラットフォームとして機能します。
2。文献レビュー
プロジェクトの作業を開始する前に、既存のソリューションを評価するために文献レビューを実行しました。現在利用可能なプローブは、固定式と可動式の2つのタイプに分類できます。
固定プローブは、構造を検査するために最も広く使用されているツールです。それらは、構造の特定のセクションに関する非常に詳細な情報を提供し、それを継続的に監視できます。ただし、ある場所に配置すると、観測範囲が制限されます。機動性がないため、大きな構造物の監視には適していません。もう1つのカテゴリは、ロボットに取り付けられたプローブで構成されています。これらは、プローブを自由に動かすことができるため、より高度な機能を提供します。現在市場に出回っているほとんどのロボットは、特定のタスクまたは種類の検査に非常に特化しています。一部のロボットは、水、高地、または湿地の半固体地形の横断に特化している場合がありますが、これらのロボットはいずれも構造検査には役立ちません。
水生検査ロボットAQUA 1 良い例です。 AQUAは高度に専門化された高価な検査ロボットです。それは水域のベッドの上を這い回り、その領域の3次元（3D）スキャンを行います。カメラ、センサースキャン、およびアルゴリズムを使用して、指定された水中の経路をたどることができます。検査ロボットであるにもかかわらず、鉄の表面に登る能力がないため、構造検査には役に立たない。
もう1つの例は、AETOS 2 です。 空中ドローン。 AETOSドローンは、測量、景観マッピング、緊急対応に使用されるクワッドコプターです。ロボット自体は、高出力カメラを吊り下げるリモートパイロットクワッドコプターです。カメラは、構造物や風景の詳細な画像やビデオをキャプチャして記録することができます。 AETOSドローンは用途が広く、橋などの露出した構造物を空中から検査することもできます。ドローンの欠点は、検査の途中で風がドローンを移動させる可能性があるため、詳細な構造検査には理想的ではないことです。ドローンは、墜落の危険性があるため、密閉された構造物内でも使用できません。 AETOSドローンは頻繁に充電する必要があり、長時間空中にいることはできません。また、高価で、損傷を受けやすく、クラッシュからの回復が困難です。
現在利用可能なロボットの中には、強力なセンサー、複数のカメラ、および壁登り機能を搭載しているものがあります。このようなロボットは非常に高価であり、検査を実行するために大量に配備することはできません。これらのロボットに関連する損傷のリスクと交換費用も非常に高くなります。 2017年3月の時点で、日本の福島第一原子力発電所で損傷した原子炉を検査するために使用されたほとんどすべてのロボットが故障しているため、損傷は非常に現実的な考慮事項です。高価なロボットの例はMagneBike 3 。 MagneBikeはかなり新しいロボットで、まだ商業的には販売されていませんが、現在テストと民間開発が行われています。 MagneBikeは、2つの車輪がフリージョイントで本体に接続されているロボット自転車です。このジョイントにより、ロボットは輪郭に関係なく、あらゆる鉄の表面を自由に移動できます。各ホイールには、側面に2つのレバーが取り付けられており、補助輪に似ています。各レバーの長さは、各ホイールの半径よりわずかに長くなっています。レバーは、ホイールが接続されている磁気面からホイールのリンクを解除するために使用され、内角をスムーズに移動できるようにします。 MagneBikeは、高解像度カメラをサポートするように設定でき、3Dマッピングセンサーをサポートします。これにより、周囲の3Dモデルを作成できます。ロボットはケーブルを介して制御および給電され、簡単に取り出せるようにつながれたデバイスです。ただし、MagneBikeの欠点は、壊れた場合に交換するのが非常に困難であり、使用する部品が手に入るものである場合は非常に高価になることです。
同様の磁気ホイールロボットは、米国海軍のマルチセグメント磁気ロボット 4 （MSMR）。 MSMRは、船体検査用に設計された海軍ロボットです。 MSMRは地上の構造検査用に設計されていませんが、構造の検査に簡単に適合させることができます。また、船体の検査と産業構造の検査は、異なる作業ではありません。 MSMRは3セグメントのロボットであり、各セグメントは電子機器を含む金属製の箱であり、側面に2つの車輪が取り付けられています。セグメントは、フレキシブルコネクタまたはジョイントコネクタで接続されています。
各ホイールは独立して動作でき、すべてのホイールが連携して動作する場合、ロボットは3D障害物を簡単にスケーリングできます。車輪は磁化されており、ロボットを支えることができます。ロボットの欠点は、テザーがないため、バッテリーのみで電力が供給されることです。これは、ロボットの制御を大幅に困難にし、ロボットの検査寿命を制限するため、不利です。 MSMRも現在リリースされておらず、海軍のみが使用しています。ロボットはおそらく当面の間そのように残るでしょう。
検査ロボットのもう1つの例は、全方向性ウォールクライミングロボット 5 です。 。マイクロボットは、重量がわずか7.2グラムの小さな円形ロボットです。直径26mm、高さ16.4mmです。ボットは現在テストの最終段階にあり、まだ市販されていません。ロボットは、360°回転機能を備えた3つの磁気ホイール付きマイクロモーターをサポートしています。ホイールを使用すると、ほとんどの鉄の表面を簡単に通過できます。 Microbotは、単一のマイクロカメラをサポートするように設定できます。カメラは簡単な画像やビデオをコントローラーに送り返すことができます。ロボットもつながれています。保護のために絶縁できる銅線でコントローラーに接続されています。ロボットは安価でグループで使用できますが、1台のカメラしかサポートできず、テザーは弱いです。また、拡張の余地がなく、センサーをサポートできません。
吸盤またはプロペラによって生成された負圧を使用して表面に取り付けるロボット設計があります。吸盤は、磁気ホイールに比べて可動性が制限されており、複数のカメラとセンサーを備えた大型ロボットには適していません。また、機械的摩耗により吸引力が時間とともに低下します。負圧システムには、かなりの電力と一定の電力が必要です。電源が切れると、ロボットは表面から外れます。これまでに試した設計にはそれぞれ長所と短所がありますが、検査の問題を完全に解決したものはありません。文献レビューにより、私は風景を調査し、以前に何が試みられたかを学び、自分のデザインを思いつくことができました。
1。要件の仕様
検査ロボットはいくつかの制約を満たす必要があります。ロボットの最初の制約はサイズです。検査ロボットは理想的には小型です。ロボットが検査するスペースのいくつかは、幅と高さが1フィート未満です。このプロジェクトでは、サイズは25x25x25cmに制限されています。サイズが小さいほど、橋梁などの複雑な環境でのロボットの機動性と汎用性が向上します。サイズが小さいことの利点は、ロボットの消費電力が少なく、操作が簡単なことです。ロボットもつながれている必要があります。テザーロボットは、ワイヤレスロボットよりも多くのデータをより速く、より確実に送信できます。
ロボットの制御者は、ロボットが無線信号の範囲を離れることを心配する必要がなく、事故や故障の場合にロボットを簡単に引き抜くことができます。さらに、検査ロボットは、徹底的な検査とナビゲーションのために複数のカメラをサポートする必要があります。ロボットからコントローラーまでのライブカメラ映像は、ロボットが検査している構造物を正確に通過し、コントローラーに差し迫った危険を警告するために必要です。ロボットが満たす必要のあるもう1つの制約は、鉄の表面に登ることができる必要があるということです。この制約を満たす最も簡単な方法は、ロボットに磁気ホイールまたは磁気ボディを持たせて、ロボットが鉄の表面を簡単にスケーリングできるようにすることです。これは、軟鋼、低合金鋼、鉄などの強磁性材料がそのような構造の構築における主要な材料であるためです。最後に、ロボットは安価である必要があり、できれば200ドル未満のコストである必要があります。安価なロボットは交換が簡単で、古い構造物を検査する場合、ロボットが損傷しても驚くことではありません。安価なロボットは、より多くのロボットを購入してタスクに使用できることも意味します。これにより、検査の効率が大幅に向上します。
4。ロボットの設計と開発
4.1。プロトタイプ1：LEGO EV3
上記の制約を満たすロボットを設計するために、私はLEGOEV3コントロールモジュールと他のLEGOパーツを使用してプロトタイピングを開始しました。 LEGOを使って構築するのは簡単で、ロボットを作成するのはかなり簡単なので、私はもともとプロトタイピングのためにLEGOを使い始めました。 EV3モジュールは、LEGOロボットを制御するプログラム可能なロボットコアであり、すでに自宅で利用可能でした。レゴのピースを使用すると、4つのモーターとホイールが取り付けられた頑丈なロボットボディを簡単に作成できました。 EV3を使い始めたとき、私は自分のロボットのためにフラットでコンパクトなデザインを作ろうとしました。レゴのピースを組み合わせる方法が原因で、私の3番目の を取り付けるときに、そのアイデアは失敗し始めました。 および4 th モーター。モーターを制御モジュールに取り付けることができませんでした。次に、モジュールをロボットの他の部分の上に吊り下げ、モーターをメインフレームからアーチ状にした角度のある設計に移行しました。コントローラーの下にすっぽり収まるメインサポートフレームを設計した後、モーターサポートを設計することができました。サポートは、メインフレームから突き出てモーターに取り付けられた下向きに傾斜したアームでした。テスト中の構造的破損を防ぐために、モーターはサポートの端に完全に固定されました。モーターとそのサポートをさらに安定させるために、各モーターを最も近いモーターに固定コネクターでリンクしました。また、コネクタは、モーターを相互にリンクして2次フレームワークを作成するのに役立つため、1つのモーターが他のモーターよりもはるかに高速になるのを防ぎました。
レゴロボットの構造設計と製作を終えた後、車輪の設計に移りました。ホイールについては、4つの標準サイズのEV3ホイールから始めました。各ホイールの半径は17mm、幅は17mmでした。各ホイールには、中空のゴム製タイヤが付属しています。磁気運動用のホイールを構成するために、私はタイヤを取り外すことから始めました。タイヤを外した後、むき出しのプラスチックホイールだけが残った。プラスチックには妖精の深いくぼみがあり、それは一貫してホイールの大部分を覆っていました。くぼみがあるため、ホイールに磁石を直接取り付けることができませんでした。 LEGOロボットに使用した磁石は、K＆J Magnetics 6 のD51-N52ディスクでした。 。 D51-N52磁石は、直径5/16インチ（8 mm）、厚さ1/16インチのネオジム-鉄-ホウ素（NdFeB）ディスク磁石です。
（1.6mm）。それらの磁石を使用することを選択したのは、それらの磁石をホイールに巻き付けて磁気バンドを作成できるほど小さいためです。各D51-N52は、鋼板に直接貼り付けた場合、2.05ポンド（9.1ニュートン）の引張力を持ちます。 4つの車輪が磁石で包まれている場合、図1に示すように、磁気はLEGOロボットを支えるのに十分すぎるほどです。
ロボットの車輪に磁石を取り付ける方法をテストしました。私はもともと、紙をホイールに巻き付けて、その紙に磁石を超接着してみました。紙が弱すぎて磁石にしっかりした表面を提供できなかったため、そのアイデアは機能しませんでした。
磁石が凝集してホイールから離れないようにするのに十分な強度。次に、ホイールの穴を粘土やプレイドーで埋めて、その上に磁石を取り付けてみました。どちらの材料も瞬間接着剤に付着しないため、このアイデアも失敗しました。どちらのアイデアも機能しなかった後、2つのアイデアのハイブリッドが機能するかどうかを実験してみました。ホイールのくぼみを折りたたんで圧縮した紙片で埋めました。次に、ストリップを所定の位置に接着しました。
その後、折りたたまれて鉄の細い糸で補強された紙をホイールに巻き付けました。強化紙は、磁石を瞬間接着剤で接着するのに十分な頑丈でありながら柔軟性のある表面でした。四輪すべてに磁石を取り付けた後、タイヤを使わずに各輪をガムテープで包みました。私がタイヤを使わないことを選んだ理由は、タイヤがその厚さのために磁石の引っ張り力をあまり下げないのに対し、ダクトテープは牽引力を提供しながら引っ張り力を大幅に減らすことはないからです。ホイールを包んだ後、LEGOアクスルを各ホイールに通し、それを使用して各ホイールをモーターに取り付けました。
ホイールの取り付けは、私の最初のプロトタイプの開発の終わりを示しました。プロトタイプをスチールドアに押し付けてテストしました。ロボットは滑ることなくドアにしっかりとくっつくことができました。ロボットはいくつかの設計上の制約を満たすことができませんでした。25x25x25cmより大きく、200ドル以上の費用がかかり、つながれておらず、バッテリーが必要で、カメラをサポートしていませんでした。
ただし、この最初のプロトタイプは重要な目的を達成しました。私の最初のプロトタイプの真の目的は、磁石を使ってロボットを鉄の表面に効率的に取り付ける方法を理解し、検査の問題を解決するためのロボットとホイールを設計する方法を理解するのに役立つことでした。
4.22番目のプロトタイプの材料とコンポーネントの選択
LEGOを使用して最初のプロトタイプロボットを構築した後、コンポーネントを選択し、構築を開始する前に、コンピューター上で次のプロトタイプを設計および視覚化することにしました。まず、将来のプロトタイプのコアとしてRaspberryPiを使用することにしました。私がRaspberryPiを選んだ理由は、Piが非常に軽量でコンパクトであるにもかかわらず、かなり強力な回路基板であるためです。 Piは、USBおよびイーサネット機能を備えたまま、モーターコントロールボードに接続できます。さらに、Piは非常に安価なコンピューターであり、無料のOSパッケージが付属しています。図2は、Raspberry Pi3の写真です。
次に、L298Nモーター制御ボードを使用してモーターを制御することにしました。 L298Nは、2つのDCモーターを制御できる非常にシンプルなモーターコントローラーです。モーターコントローラーは、最大35Vの電圧を処理できると記載されています。使用したいモーターのほとんどは6V〜12 Vの範囲であったため、L298Nは私にとって理想的でした。ボード自体は非常に小さく、RaspberryPiの3分の1のサイズです。このシンプルさにより、複数のL298Nを低コストで簡単に購入できます。また、Raspberry Piを使用した最初のプロトタイプでは、1台のカメラから始めることにしました。私が使用することを選択したカメラは、Raspberry PiNoIRカメラです。
このNoIRカメラは、暗視用に設計されたPi互換カメラです。橋のような建造物は照らされているかもしれませんが、戦車の内部はおそらく暗くなります。そこで、標準のPiカメラの代わりにPiNoIRカメラを選びました。また、NoIRカメラを選択したのは、Raspberry Pi用に構築されており、他のどのカメラよりも使いやすいからです。
私のモーターには、標準の6 VDCプラスチックArduinoモーターを選択しました。 Arduinoモーターであるにもかかわらず、これらのモーターを選択しました。これは、ドライバーボードがその電圧制限内で任意のDCモーターを実行できることを知っていたためです。以下で説明するように、必要なモータートルクを推定するために、工学力学の計算を行いました。プラスチック製のモーターは非常に使いやすく、配線も簡単で、安価でもあります。モーターの1つが壊れた場合、新しいモーターと交換するのは簡単です。モーターには、ロボットを支えて動かすのに十分な大きさでありながら、簡単に制御できるほど小さいプラスチック製の車輪も付いています。 2つの駆動モーターに加えて、別のモーターを使用して、ロボットの下にそれを支えることができるレバー機構を作成したいと思いました。このメカニズムは、ロボットのフロントエンドを地面から持ち上げて、鉄の表面によりよく付着できるようにするために使用されます。私は、ロボットを単純なプラスチック製のロボットシャーシに取り付け、金属ストリップを使用して、シャーシ自体に収容できない部品用の高架プラットフォームを形成することを計画しました。私はL298Nに4-AAバッテリーパックまたは2つの2-AAバッテリーパックで電力を供給することにしました。 Raspberry Piは、コンセントに伸びるUSBケーブルから電力を受け取るように設計されています。ロボットは、USBケーブルを使用して接続された有線のXbox360コントローラーによって制御されます。ロボットの動きを制御するのに理想的な方向パッドを備えているため、Xboxコントローラーを使用することにしました。また、カメラコントロールなど、ロボットのコード内のさまざまなタスクに割り当てることができる追加のボタンもあります。磁石については、D51-N52磁石を使用してホイールの周りに磁気バンドを作成することが、最初のプロトタイプで磁気ホイールを作成するための実行可能な方法であることが証明されたため、引き続き使用することにしました。
4.3 2番目のプロトタイプのコンピューター支援設計（CAD）
材料とコンポーネントを決定した後、2番目の を作成するために使用します プロトタイプでは、プロトタイプのCAD図面の作成に移りました。これにより、指定したパーツが到着したら、簡単に作成できるようになりました。 CAD図面を作成するために、SketchUpというソフトウェアを使用しました。このソフトウェアは無料で、自分で習得しやすく、使いやすいためです。 2番目の を作成するために使用する予定のパーツのオンラインおよび物理的な測定値（パーツが到着したら）を使用する プロトタイプロボットでは、図3に示すように、ロボットプロトタイプのリアルな3D CAD図面を作成することができました。次に、最適なネジの位置を考慮して、プロトタイプをさらに改良しました。デザイン機能の追加と細部の改良を数回繰り返した後、ロボットの満足のいく3Dモデルを取得することができました。これは、実際の部品を使用してコンピューターモデルの物理的なコピーを作成するだけでよいため、プロジェクトのハードウェア部分を簡素化するのに役立ちました。
4.4プロトタイプ2a：既製のシャーシ
プロトタイプ2aの構築
すべての部品が到着し、CAD図面が完成した後、ロボットの構築は簡単な作業でした。ロボットを組み立てるとき、私はラズベリーパイを取り付けるための穴を開けることから始めました。プラスチックシャーシにドリルで穴を開けるポイントをプロットするために、Piをシャーシの後端の上に押し下げ、細い鉛筆を使用して、シャーシの各ネジ穴の下の領域に印を付けました。次に、Piのネジ穴より少し大きいドリルビットを選択して、各穴にドリルで穴を開けました。次に、ドライバーボードを収容するために、シャーシの前面に同様にドリルで穴を開けました。ドライバーボードとRaspberryPiを取り付けるために、＃4-40のボルトとナットを使用しました。両方のボードを取り付けた後、付属のネジを使用して後輪と
を取り付けました。シャーシに事前に穴を開けるためのモーター。シャーシ、モーター、および後輪はナット、ボルト、および説明書と一緒に付属していたため、両方のコンポーネントをシャーシに簡単に取り付けることができました。
このプロトタイプでは、頑丈な両面テープを使用して、ロボットの下側の両方の駆動モーターの間に直接3番目のモーターを取り付けました。次に、4本のアイスキャンディースティックを取り、2本セットで縦に接着しました。その結果、私は2本の非常に厚いアイスキャンディースティックを手に入れました。次に、アイスキャンデースティックを半分にカットし、各半分のアイスキャンデースティックの端にモーターアクスルの端をスケッチしました。次に、ドリルを使用して、モーターの車軸を収容する新しいスティックのそれぞれに穴を開けました。その結果、私は4本の太くて半分の長さの穴あきアイスキャンディースティックを手に入れました。次に、最適な2本のスティックを選び、中央のモーターの車軸の両端に取り付けました。アイスキャンデーの棒をホットグルーで固定しました。この電動装置の目的は、モーターが作動すると、ロボットをその上にある表面から押し出すリフターとして機能することでした。この装置は、ロボットが鉄の表面から自分自身を切り離すことができるように設計されました。また、ロボットが主な磁気ホイールを地面から持ち上げて、別の表面から鉄の壁に取り付けることができるようにします。これは、このプロジェクトのいくつかのユニークなデザイン機能の1つです。磁気ホイールの設計は、もう1つの革新的な機能です。
3つ目のモーターを取り付けた後、穴あき金属ハンガーテープを使用して、ドライバーボードとRaspberryPiの上にブリッジのような構造を作成しました。ハンガーテープは、追加の部品を取り付けることができる二次面として機能しました。穴が開いているため、シャーシに金属製のハンガーテープを取り付けるための穴を開け、残りのボルトとナットで固定するのは簡単でした。ロボット前面のハンガーテープブリッジの上に、2つ目のドライバーボードを取り付けて3つ目のモーターを制御しました。これは、各ボードが2つのモーターしか制御できないためです。両面テープでドライバーボードを取り付けることができました。より多くの両面テープで、メインドライバーボードに電力を供給するために、リアメタルハンガーの上部に4-AAバッテリーホルダーを取り付けることができました。また、ロボットの前面に2本の2-AAバッテリーホルダーを取り付けて、2番目のドライバーボードに電力を供給しました。
Raspberry Pi NoIRカメラを金属製ハンガーテープブリッジの前面に熱接着して、この2番目のプロトタイプを完成させました。ロボットを組み立てた後、残ったのは車輪を磁化することだけでした。ホイールからタイヤを外し、各ホイールに両面テープを貼りました。プラスチック製のホイールとモーターを図4に示します。各ホイールのリムの周りに小さな円形のD51-N52磁石を円形に貼り付けたため、各ホイールに2つのリングがありました。すべての磁石を追加した後、磁石を保護するために両方のホイールをダクトテープの単層で覆いました。後輪を磁化するために、私は車輪の周りのリングに磁石を熱接着し、次にそれらをダクトテープで包みました。ダクトテープを使用した理由は、引っ張り力を大幅に低下させない程度に薄いが、磁石を保護するのに十分な強度があるためです。
配線プロトタイプ2a
ロボットのすべてのコンポーネントを取り付けた後、それらを一緒に配線し始めました。 Raspberry Piの電源は、側面のマイクロUSBポートから供給されました。次に、バッテリーパックをそれぞれのドライバーボードに配線しました。モーターは、モーターに付属のワイヤーを使用してドライバーボードにも接続されていました。ワイヤーをモーターの電源リードにはんだ付けし、ネジでドライバーボードに接続しました。次に、PiのGPIOピンをドライバーボードに配線しました。 GPIOピンは、RaspberryPiの汎用入力/出力ピンです。一部のピンはアースと電源に使用されますが、一部のピンはワイヤを介して信号を送信するために使用できます。 GPIO 2と6を一方のドライバーボードに配線し、4と9をもう一方のドライバーボードに配線しました。これらのピンは5Vピンであり、ドライバーボードを介したモーターの移動と制御を可能にするために使用されました。次に、ピン11、12、13、および15を最初のドライバーボードに配線し、ピン16、および18を他のドライバーボードに配線しました。これらのピンは、実際のモーター制御信号を送信するために使用されました。各モーター
制御には2つのピンが必要であり、ロボットは3つのモーターを使用したため、ドライバーボードには、ボードごとに5Vとアースに加えて、モーター制御に6つの接続信号GPIOピンが必要でした。必要なGPIOピンを接続した後、Piとラップトップの間にイーサネットケーブルを接続しました。これにより、ラップトップはRaspberry Piとリモートデスクトップ接続できるようになり、モニター、キーボード、マウスが不要になります。また、USB経由で電源付きハブをPiに接続しました。ハブはXboxコントローラーに接続されていたので、Xboxコントローラーを介してロボットを制御できました。
プログラミングプロトタイプ2a
私の2番目の nd のデザインで最も難しい部分 プロトタイプはコードでした。私の最初のプロトタイプでは、それは単なるハードウェアモデルでした。コードは実行されませんでした。私の理由は、私の最初の st プロトタイプ、試してみてください。4つのモーターすべてをコードと同時に動かすことができませんでした。最初のプロトタイプも、主に磁気ホイールの概念をテストし、将来のプロトタイプの理想的な設計を考え出すのに役立つように作成されました。 Raspberry Piでは、Pythonを使用してコーディングしました。これは、PythonがRaspberryPiの唯一の言語であることがわかったためです。ただし、コードを開始する前でも、ラップトップとリモートデスクトップ互換になるようにロボットを設定する必要がありました。
Piをセットアップするには、モニター、キーボード、およびマウスをRaspberryPiに一時的に接続する必要がありました。その後、Piを起動し、イーサネット経由で静的IPを設定しました。シンプルで簡単なアドレスだったので、192.168.1.10を選びました。 IPを設定するには、編集する必要がありました
私のPiの/ect/dhcpcd.conf。 dhpcd.confファイルは、PiのIPおよびネットワーク接続を制御します。静的IPを設定するには、ファイルの先頭に行を追加する必要がありました：
インターフェイスeth0
static ip_address =192.168.1.10 static routers =192.168.1.1
Piの静的IPを設定した後、Linuxパッケージtightvncserverをインストールしました。 Tightvncserverは、VNC（仮想ネットワーク接続）サーバーをRaspberryPiにセットアップできるようにするパッケージです。リモートデスクトップ接続は、VNCサーバーを介して実行されます。 VNCサーバーをセットアップした後、
を介してRaspberryPiへのリモートデスクトップ接続を作成することができました。ラップトップ。 Piにアクセスできることを確認した後、モニター、キーボード、およびマウスを切断しました。次に、ロボットのコーディングを開始しました。
まず、どのGPIOピンが自分のPiのどのモーターに対応しているかを調べる方法が必要でした。各GPIOピンがアクティブになると、単一のモーターが一定の速度で前方または後方に回転します。したがって、各モーターには、2つの対応するGPIOピン、前進モーションコントローラーと後退モーションコントローラーがあります。各GPIOピンが何に対応しているかを調べるために、各GPIOピンを個別にテストするプログラムを作成しました。これにより、どのGPIOピンが何を実行したかを書き留めることができます。プログラムへのコメントを通じて観察結果を記録しました：
時間インポートスリープからRPi.GPIOをGPIOとしてインポート
GPIO.setmode（GPIO.BOARD）
GPIO.setup（12、GPIO.OUT）#Left Backward GPIO.setup（11、GPIO.OUT）#Left Forward GPIO.setup（13、GPIO.OUT）#Right Forward GPIO.setup（15、GPIO.OUT）＃右後方GPIO.setup（16、GPIO.OUT）#Lifter Out GPIO.setup（18、GPIO.OUT）#Lifter In
GPIO.output（12、GPIO.HIGH）
sleep（2）GPIO.output（12、GPIO.LOW）
sleep（1）
GPIO.output（11、GPIO.HIGH）
sleep（2）GPIO.output（11、GPIO.LOW）
sleep（1）
GPIO.output（13、GPIO.HIGH）
sleep（2）GPIO.output（13、GPIO.LOW）
sleep（1）
GPIO.output（15、GPIO.HIGH）
sleep（2）GPIO.output（15、GPIO.LOW）
sleep（1）
GPIO.output（16、GPIO.HIGH）
sleep（0.5）GPIO.output（16、GPIO.LOW）
sleep（1）
GPIO.output（18、GPIO.HIGH）
sleep（0.5）GPIO.output（18、GPIO.LOW）
sleep（1）
次に、RaspberryPiがXboxコントローラーから送信された信号を受信して理解できるようにするソフトウェアまたはコードが必要でした。 Xboxdrvは、Linux用のXboxコントローラードライバーです。私はそれをインストールし、それを使用してPiをXboxコントローラーに接続しようとしました。通常、プロンプトでコマンド「sudo xboxdrv」を実行すると、接続されているXboxコントローラーの入力がコマンドプロンプトウィンドウに表示されます。ただし、私のXboxコントローラーはMicrosoft製ではなかったため、xboxdrvでは通常はサポートされていませんでした。コマンドを実行して問題を修正しました：
sudo xboxdrv –device-by-id 1bad：f02e –type xbox360 –detach-kernel-driver –mimic-xpad
xboxdrvの使用方法と、コードを使用して通常の関数を変更する方法を調査した後、このコマンドを作成することができました。このコマンドで、1bad：f02eであるデバイスIDを使用して、接続されているコントローラーをXboxコントローラーとして識別しました。 This command allowed me to view the inputs from the controller in the command prompt. I needed a way to access the input values from a
Python program, so that I would be able to use the values to control my robot. After some searching online, I found a Python program that received and displayed Xbox controller input values on Github 7 。 The code was by martinohanlon. I downloaded the code onto my Raspberry Pi and started working on modifying it to control the motors on the robot based on the values it received. The problem I faced was that the code was so long and complex, that I was unable to tell where the input value from the Xbox controller was read. To solve that problem, I went through the program and I made a series of print statements that printed the variables of the program as it ran. Through the process of observing the values as buttons were pressed, and deleting print statements, I was able to find the main event system in the program at line 265:
#run until the controller is stopped while(self.running):
#react to the pygame events that come from the xbox controller for event in pygame.event.get():
#thumb sticks, trigger buttons
if event.type ==JOYAXISMOTION:#is this axis on our xbox controller
if event.axis in self.AXISCONTROLMAP:#is this a y axis
yAxis =True if (event.axis ==self.PyGameAxis.LTHUMBY or event.axis ==self.PyGameAxis.RTHUMBY) else False
#update the control value self.updateControlValue(self.AXISCONTROLMAP[event.axis],
self._sortOutAxisValue(event.value, yAxis)) #is this axis a trigger
if event.axis in self.TRIGGERCONTROLMAP:#update the control value
self.updateControlValue(self.TRIGGERCONTROLMAP[event.axis], self._sortOutTriggerValue(event.value))
#d pad
elif event.type ==JOYHATMOTION:#update control value
self.updateControlValue(self.XboxControls.DPAD, event.value)
#button pressed and unpressed
elif event.type ==JOYBUTTONUP or event.type ==JOYBUTTONDOWN:#is this button on our xbox controller
if event.button in self.BUTTONCONTROLMAP:#update control value
self.updateControlValue(self.BUTTONCONTROLMAP[event.button], self._sortOutButtonValue(event.type))
Within the main event system, I searched for the component that handled the directional pad (d- pad) on the Xbox controller, as I was planning on using it to control the motors on the robot.
After finding the directional pad control component, I added some statements to the end that sent signals through the GPIO pins to the motors whenever a certain direction was pressed on the D- Pad:
#d pad
elif event.type ==JOYHATMOTION:#update control value
self.updateControlValue(self.XboxControls.DPAD, event.value) if event.value ==(0,1):#Forward
GPIO.output(11,GPIO.HIGH) #Left Forward GPIO.output(13,GPIO.HIGH) #Right Forward
elif event.value ==(0,-1):#Backward GPIO.output(12,GPIO.HIGH) #Left Backward GPIO.output(15,GPIO.HIGH) #Right Backward
elif event.value ==(1,0):#Right GPIO.output(11,GPIO.HIGH) #Left Forward
GPIO.output(15,GPIO.HIGH) #Right Backward elif event.value ==(0,1):#Left
GPIO.output(12,GPIO.HIGH) #Left Backward GPIO.output(13,GPIO.HIGH) #Right Forward
GPIO.output(12,GPIO.LOW) GPIO.output(11,GPIO.LOW) GPIO.output(13,GPIO.LOW) GPIO.output(15,GPIO.LOW)
After successfully configuring the motors, my next challenge was to code the Raspberry NoIR camera. The Pi camera came with a Python camera package. Coding it so that pictures were taken or videos were recorded every time certain buttons on the Xbox controller were pressed was fairly easy.
#button pressed and unpressed
elif event.type ==JOYBUTTONUP or event.type ==JOYBUTTONDOWN:#is this button on our xbox controller
if event.button in self.BUTTONCONTROLMAP:#update control value
self.updateControlValue(self.BUTTONCONTROLMAP[event.button], self._sortOutButtonValue(event.type))
if event.button ==0 and event.type ==10:camera.capture(‘image’ + imgNum + ‘.jpg’) imgNum =imgNum + 1
if event.button ==1 and event.type ==10:if isRec ==False:
camera.start_recording(‘video’ + recNum + ‘.h264’) isRec =True
else:
camera.stop_recording() isRec =False
if event.button ==1 and event.type ==10:if isPrev ==False:
camera.start_preview() isPrev ==True
else:
camera.stop_preview() isPrev ==False
For this portion of the code, I did have to make variables to serve as counters every time a picture or video was taken, so that they would be numbered. I also had to make Boolean variables that determined whether a video was being taken, to prevent the robot from trying to take another video while one was already recording. After coding the camera, I was finished with programming the robot.
Testing Prototype 2a
The first thing I recorded was the mass of the robot. Using a standard kitchen scale, I recorded the mass of the robot to be 0.66 kg. While not being especially light, prototype 2a was significantly lighter than prototype 1, which had a mass of 0.92 kg without cameras. Prototype 2a was also measured to be 15 cm long x 18 cm wide x 12 cm tall. Prototype 2a could meet the size constraint, which was another improvement over prototype 1. Prototype 2a could stick to ferrous surfaces. While the motor of prototype 1 could not overcome the magnetic pull force and move the robot, prototype 2 could move the robot downward or sideways but not upward when attached to a vertical steel wall. The 3 rd motor on the robot that was planned for lifting of off surfaces was also unable to function because of a lack of torque. Prototype 2a had only mounted 1 camera, and thus failed the multiple camera requirement. However, prototype 2a was an improvement over prototype 1. Prototype 2a only cost about $120 to build compared to prototype 1, which cost more than $400 even without cameras.
4.5 Engineering Mechanics Calculations
I calculated force and torque using equations from the literature as shown below.
Force and Torque Equations
Figure 5 shows a sketch of the robot climbing an inclined plane and the forces present.
| For a robot at rest in the plane: | m*(N1 + N2) =Mgsinq | (1) |
| Perpendicular to the plane: | N1 + N2 =F(M1) + F(M2) + Mgcosq | (2) |
| For a vertical wall q =p/2. | N1 + N2 =F(M1) + F(M2); m*(N1 + N2) ≥ Mg | (3) |
| The required magnetic force is | F(M1) + F(M2) ≥ Mg/m | (4) |
With two motors, the torque needed from each is t ≥ MgR/2 (5)
Force Calculation for Magnet Placement
The paper by Wang and Kimura (IEEE 2014) shows that the friction coefficient for tape covered wheel on metal m =0.45. The mass of my robot prototype 2a is M =0.655 kg. The acceleration of gravity g =9.81 m/s 2 。 From equation (4), the required magnetic force =14.5 Newton. The pull force of the N52 magnet away from a steel surface has been tested and reported by the manufacturer KJ Magnetics. It is shown for different distances in Figure 6. The thickness of the duct tape I used is 0.01”. At a distance of 0.01”, the pull force is 1.26 lb per magnet according to the data plotted in Figure 6. In SI units, this pull force per magnet =5.6 Newton. To get a magnetic force of at least 14.5 Newtons calculated from equation (4), we need at least 3 magnets in contact at all times (one per wheel). The m value of 0.45 is only an estimate. If it is lower (say 0.25), the required magnetic force is higher, about 26.1 Newton.
Thus, for safety, we need 2 rows of magnets per wheel.
Torque Calculation for Motor Selection
Torque is important, because it is the rotational force (force multiplied by radial distance) that the motor must generate to move the robot. From equation (6), we know that the torque must be greater than MgR/2 for each of the front wheel motors. For prototype 2a, this works to torque being more than 0.08 Newton meter per motor. The plastic encased motors I used in the prototype 2a (Figure 4) were rated by the manufacturer as 0.1 Newton meter each. In my tests, prototype #2a could stay attached to a vertical surface and climb down. However, it struggled to climb up the vertical wall. The torque was barely enough to fight gravity. The results of this test of prototype #2a show that the force and torque calculations were correct. The lesson I learned from building and testing prototype 2a is that the robot should be lighter or a motor with greater torque should be used. The use of CAD and mechanics calculations made the design and development process systematic and logical. Figure 7 shows the underside of prototype 2a. The three motors and the popsicle sticks can be clearly seen.
4.6 Prototype 2b:Pre-Made Chassis
After developing and testing Prototype 2a, I realized that there were multiple changes I could make to it to make it fit the constraints better, without constructing an entirely new bot. So instead of starting from scratch, I decided to make a series of modifications and upgrades to Prototype 2a, resulting in the creation of Prototype 2b.
Building Prototype 2b
The first change I made to prototype 2a was that I removed all the motors. The motors did not work as expected for climbing up a vertical wall because of lack of torque; so, all of them had to be replaced or removed. I replaced the drive motors with two new larger motors, and I simply removed the third motor without replacement. The new motors were Uxcell 12V high torque gearbox motors. They were chosen, because their torque rating was much higher than that of the motors they replaced, but these new motors were heavier. I fastened both motors to the underside of the robot, where the previous motors had been using strips of double sided tape for preliminary testing. The new motors had a mass almost 100 g more than that of the old motors and so adding both new motors added almost 200 g to the mass of the robot.
I removed the driver board that controlled the third motor, because there was no longer a third motor on the robot, so there was only a need for a single driver board. Next, I removed all of the battery packs on the robot. Battery packs add unnecessary mass to a robot, and only limit its inspection life. Additionally, using batteries increases chances of motor failure when the robot is in deployment, because batteries might run out of battery power in the middle of a run, resulting in the need for an emergency retrieval. I then moved the remaining driver board onto the metal hanger above the Raspberry Pi, where the 4-AA battery pack had been previously. This allowed me to remove the metal hanger at the front of the robot because it was not being used. I also removed two posts with magnetic disks at the rear of the robot that were included in Prototype 2a to increase the stability of the rear. I found out through testing that the posts were not needed.
At this stage, I encountered a major problem. My wheels were no longer compatible with my motors because the new motors had a different shaft compared to the old motors. I tried drilling and cutting the wheel wells to make the wheels fit the motors, but neither solution worked. After some research on what items fit a D shaped motor shaft, I found out that oven knobs often fit D shafts. After buying some oven knobs, I tested them to see if they attach to the motors. After finding out the oven knobs were compatible with the new motors, I sawed the top off the oven knobs, resulting in flat disks that fit onto the new motors. I then drilled out the wheel well on the wheels, after which I superglued the disks to the wheels. By supergluing the disks to the wheels, I made it so that they would be able to attach to the motor. After attaching the wheels and motors, I set up the cameras. I hot glued the Pi NoIR camera to the back of the robot and made it face backwards for my rear-view camera. I then took a wide-angle, fish-eye camera, and hot glued it to the front of my robot facing forwards for my main camera. I then double sided taped and hot glued an endoscopic inspection camera to the front rim of the chassis facing downwards. The use of oven knobs to connect wheels to the new motor shaft is an innovative solution developed in this project.
Wiring Prototype 2b
After modifying prototype 2a, there were many components to re-wire. I had to re-solder a wire to the power leads of the motors and connect it to the remaining driver board. I then removed all of the wires connected to GPIO 4, 9, 16, or 18, as they were no longer in use. I also decided to use a 12 V power cable to power the driver board instead of a battery pack. To do so, I cut the output end of the power cable off, so that all that remained was the adapter and a length of wire. I then separated the two strands of power wire, one being positive and the other being negative, and stripped the wires so that both wires were exposed at the end. After twisting and tightening the exposed wire, I connected the positive wire to the ground slot on the driver board, and the negative wire into the voltage slot on the driver board. I left the NoIR camera connected to the Pi, but I connected both the other cameras to my laptop so that my laptop directly received feeds directly from the cameras instead of getting them through the Pi, with the exception of the NoIR camera. To finish, I swapped the Xbox Controller with a Super Nintendo Entertainment System (SNES ) controller. An SNES controller is a much lighter and simpler controller than an Xbox controller and unlike the Xbox controller which requires a powered hub for power, an SNES controller can be powered by the Raspberry Pi. The two controllers are shown side by side for comparison in Figure 8.
Programming Prototype 2b
Since the Raspberry Pi had already been completely set up with the previous prototype, I was able to dive straight into programming. While no new code was needed to test the motors, since the previous motor test program worked, a new controller code became necessary because I changed the controller and was no longer using an Xbox controller. Because of the simpler nature of the SNES controller, there was no driver similar to xboxdrv for the SNES controller.
The Pi is capable of interpreting the input from the SNES controller by default. After doing some research and looking into how to interact with an SNES controller through Python, I wrote the following controller program from scratch:
import pygame
import RPi.GPIO as GPIO GPIO.setmode(GPIO.BOARD)
GPIO.setup(12,GPIO.OUT) #Left Backward GPIO.setup(11,GPIO.OUT) #Left Forward GPIO.setup(13,GPIO.OUT) #Right Forward GPIO.setup(15,GPIO.OUT) #Right Backward
global hadEvent global x
global y global a global b global up global down global left global right
hadEvent =False x =False
y =False a =False b =False up =False
down =False left =False right =False
pygame.init()
pygame.joystick.init()
j =pygame.joystick.Joystick(0) j.init()
def game_controller(events):global hadEvent
global x global y global a global b global up global down global left global right
for event in events:
if event.type ==pygame.JOYBUTTONDOWN:hadEvent =True
x =j.get_button(0) y =j.get_button(3) a =j.get_button(1) b =j.get_button(2)
if x ==1:x =True
print(“x”) elif y ==1:
y =True print(“y”)
elif a ==1:
a =True print(“a”)
elif b ==1:b =True print(“b”)
elif up ==1:up =True print(“up”)
elif event.type ==pygame.JOYBUTTONUP:hadEvent =False
x =j.get_button(0) y =j.get_button(3) a =j.get_button(1) b =j.get_button(2)
if x ==1:
x =False elif y ==1:y =False elif a ==1:a =False elif b ==1:b =False
elif up ==1:up =False
elif event.type ==pygame.JOYAXISMOTION:hadEvent =True
if event.axis ==1:
if event.value <=-1:
up =True print(“up”)
elif event.value>=1:down =True print(“down”)
else:
down =False up =False
elif event.axis ==0:
if event.value <=-1:left =True print(“left”)
elif event.value>=1:right =True print(“right”)
else:
right =False left =False
while True:game_controller(pygame.event.get())
if up ==True:#Forward GPIO.output(11,GPIO.HIGH) #Left Forward GPIO.output(13,GPIO.HIGH) #Right Forward
elif down ==True:#Backward GPIO.output(12,GPIO.HIGH) #Left Backward GPIO.output(15,GPIO.HIGH) #Right Backward
elif right ==True:#Right GPIO.output(11,GPIO.HIGH) #Left Forward GPIO.output(15,GPIO.HIGH) #Right Backward
elif left ==True:#Left GPIO.output(12,GPIO.HIGH) #Left Backward GPIO.output(13,GPIO.HIGH) #Right Forward
else:
GPIO.output(12,GPIO.LOW) GPIO.output(11,GPIO.LOW) GPIO.output(13,GPIO.LOW) GPIO.output(15,GPIO.LOW)
This code operates by importing Pygame, which is a Python package. Pygame is used for constructing videogames through Python. It adds several features, such as interpreting and translating input values from a video game controller. Because of the simplicity of an SNES controller, there were no extra steps needed. Towards the beginning of the program, I defined the GPIO pins to be used for motor control. I then listed variables I planned to use, and assigned the connected controller to pygame.joystick() and then j. I then created an event system where a value sent by the controller is defined as an event, for example, pressing a button or moving a joystick. I then specified the events I care about, such as movement on the directional pad (d- pad) or a button being pressed. I assigned a value of 1 to a variable if the event it is connected to occured. I also wrote additional code to convert the numeric value 1 to the Boolean True. At the end, there is an infinite loop that fetches the values of events that were triggered. If any of the d- pad values are triggered, the program sends signals to the motors through the GPIO pins. After running this code, the robot responded smoothly to the SNES controller. I did not need any other code for controlling this prototype.
Testing Prototype 2b
Once again, I started by recording the mass of the robot. Using a standard kitchen scale, I recorded the mass of the robot to be 0.71 kg. Prototype 2b ended up being heavier than prototype 2a, despite the removal of the battery packs, but this can be attributed to the motors which were heavier in prototype 2b. Prototype 2b was measured to be 15 cm long x 18 cm wide x 12 cm tall. Prototype 2a and 2b are the same size despite the changes between the two, the overall structure of the robot did not change. Prototype 2b was once again able to meet the size constraint. Prototype 2b had the ability to attach to ferrous surfaces and was the first prototype that could climb up on vertical ferrous surfaces. Figure 9 shows Prototype 2b climbing a vertical steel door. Prototype 2b mounted 3 cameras, and all of them sent back acceptable feeds, which was a large improvement over prototype 2a. Prototype 2b cost $170 to build compared to the $120 of prototype 2a. This increase can be attributed to the cost of cameras and the cost of better motors.
4.7 Prototype 3:Custom Polycarbonate Chassis
After building the last two prototypes, I wanted to apply the knowledge I had gained to create a new prototype that was smaller, more compact, and more efficient. To do this, I planned to design my own chassis, and refrain from using tapes and superglue to hold parts together.
Building Prototype 3
To start building my robot, I took a polycarbonate sheet and cut my chassis out of it. For my chassis, I chose a simple 6 cm wide x 11 cm long rectangle. I chose that size and shape because it was simple and based off of preliminary measurements I took, it was the smallest feasible size for mounting the parts I had chosen. After cutting out the chassis with a saw, I smoothed out the edges and corners with a file and sandpaper. I then set the Raspberry Pi on the rear end of the chassis and marked where all of the holes were, so that I would be able to drill them out. I then set the rear wheel on the underside of the chassis and marked holes for it. I also marked holes for the motors I chose at the front of the chassis. The motors I chose were Pololu 12 V gearbox motors with a gear ratio of 298:1. The motors also came with mounting brackets that attached to the motors and had holes for screws. I finally marked a large hole between the Pi and the motors for the inspection camera.
After drilling all of the holes, I screwed down all of the parts except for the Pi. Before I screwed down the Pi, I laid down a thin sheet (4 mm thick) of packing foam underneath where the Pi would be to absorb shock and prevent contact between the metal on the Pi and the bolts and nuts on the robot. I also attached a folded metal hanger tape with the same bolts as the Pi. The hanger tape formed a bridge over the Pi. I cut a smaller 4.5 cm wide x 5.5 cm long piece of polycarbonate to screw to the top of the metal hangar. I screwed a driver board to the top of the smaller polycarbonate. For the wide-angle camera, I folded and cut thin scrap metal to form a pouch for the camera with a hole for the lens. The pouch had sides that folded in and held the camera. The pouch also had a flat bottom that extended out to either side. I screwed the metal pouch down with two of the screws that also held the motors. I slid the inspection camera down into the hole that had been drilled for it. The Pi NoIR camera was held by a retaining block that was hot glued to the top of the Ethernet port on the Pi. For the wheels, I used 60 mm diameter x
8 mm thick Pololu plastic wheels. To magnetize the wheel, I covered it in a thin layer of double sided tape and put the magnets in a ring around it. I the covered the magnets with a single layer of duct-tape for protection and traction. After finishing the wheels, I attached a 3V LED light on either side of the wide-angle camera holder. I also used double sided tape to attach an ultrasonic sensor to the bottom of the robot.
The robot utilizes an HC-SR04 ultrasonic distance sensor. The HC-SR04 is a very common and popular hobby ultrasonic distance sensor. The sensor is also the least expensive and easiest to use of its type to demonstrate sensor integration. The HC-SR04 is designed mainly with compatibility and simplicity in mind, allowing it to be easily connected to a Raspberry Pi or Arduino.
The HC-SR04 functions by sending a sound wave, which bounces off the object at which the sensor points, and then receiving the sound wave. The time between the sending and the reception of the sound wave is recorded and output. The time can then be multiplied by the speed of sound and divided by 2 to identify the distance between the sensor and the surface it is pointed towards. The HC-SR04 has 4 pins for connection purposes. The pins are ground, voltage, trigger, and echo. The ground pin is to be connected to ground. The voltage pin is to be connected to a+5V source. The trigger pin will cause the sensor to produce a sound wave for as long as it is receiving +3V. The echo pin sends back +5V in a burst as long as the wait time for the sensor to receive the signal. The sensor has a range of 2 cm to 400 cm. On my robot, the HC-SR04 serves to demonstrate that an ultrasonic sensor can be mounted underneath the robot. A more expensive, advanced ultrasonic sensor can be mounted to measure the thickness of the metal surface and identify degradation.
Wiring Prototype 3
For the wiring of prototype 3, many elements stayed the same from prototype 2b but one changed. Because the Pololu wheels blocked the micro USB port on the Pi, I was unable to use it for power. After some research, I found that I could use the GPIO pins instead. I cut a USB to micro USB cable so that one portion was the USB end and a length of cable. Within the cable were two separate wires. I split and stripped those wired. I then soldered the exposed parts of the wires to the female end of a breadboard jumper. I covered my work with heat shrink tubing. I used a multimeter to tell which end was positive voltage and which end was negative. I connected the positive wire to GPIO 9, and the negative end to GPIO 14. Those two GPIO’s were 5 V &ground respectively. After connecting the USB end of the charging cable to a 5 V adapter, the Pi ran perfectly. Once again, wires were soldered to the leads of my motors, and connected back to my driver board. The driver board was connected to GPIO 11, 12, 13, &15 for control and GPIO 2 &6 for 5V and ground. The driver board was also connected to a 12 V power supply. The LED lights were wired and soldered in parallel. They were attached a 330Ω resistor, GPIO 16 &18 for power, and GPIO 9 for ground. The ultrasonic sensor which was added to this prototype was wired to GPIO 4, 29, 30, and 31. Pin 4 was used for voltage, 29 was for output, 31 was for input, and 30 was for ground. The NoIR camera was once again connected to the Pi, while the other cameras are connected to my laptop. The robot is still controlled by a USB SNES controller. The wiring diagram is shown in Figure 10.
Programming Prototype 3
To save myself the work of setting up and configuring the Pi, I moved the SD card from prototype 2b to prototype 3. Because the only new need of code for prototype 3 was for the ultrasonic sensor, I mainly just simplified and commented my SNES code, only adding a few extra lines, as shown below.
#Developed By Nikhil Devanathan 2017
#Program to control Raspberry Pi robot with wired USB SNES controller #Uses directional pad (d-pad) for motor movement
#Leaves button and triggers open for mapping
#Imports necessary packages into python
import pygame #Package that is used for game controller mapping import RPi.GPIO as GPIO #Allows control over binary pins on Pi from gpiozero import DistanceSensor
#Sets GPIO pins for motor control GPIO.setmode(GPIO.BCM)
GPIO.setup(18,GPIO.OUT) #Left Backward GPIO.setup(17,GPIO.OUT) #Left Forward GPIO.setup(27,GPIO.OUT) #Right Forward GPIO.setup(22,GPIO.OUT) #Right Backward GPIO.setup(23,GPIO.OUT) #Light1\
GPIO.setup(24,GPIO.OUT) #Light2/ Work together to power LED lights
#Conifgures ultrasonic sensor
ultrasonic =DistanceSensor(echo =6, trigger =5, threshold_distance =0.02)
#Creates variables for controller mapping
global hadEvent global x
global y global a global b global up global down global left global right
#Assigns Variables for controller mapping hadEvent =False
x =False y =False a =False b =False up =False
down =False left =False right =False
#Initializing pygame and controller pygame.init() pygame.joystick.init()
j =pygame.joystick.Joystick(0) j.init()
#Defining controller event system def game_controller(events):
#Defining variables for use in controller event system
global hadEvent global x
global y global a global b global up global down global left global right
#Searches for an event in the system for event in events:
#If a button is pressed
if event.type ==pygame.JOYBUTTONDOWN:#Set map values
hadEvent =True
x =j.get_button(0) y =j.get_button(3) a =j.get_button(1) b =j.get_button(2)
#If a button is released
elif event.type ==pygame.JOYBUTTONUP:#Set map values
hadEvent =False x =j.get_button(0) y =j.get_button(3) a =j.get_button(1) b =j.get_button(2)
#If there is axial montion on the directional pad
elif event.type ==pygame.JOYAXISMOTION:
#Set values for y axis hadEvent =True
if event.axis ==1:
if event.value <=-1:up =True
elif event.value>=1:down =True
else:
down =False up =False
#Set values for x axis elif event.axis ==0:
if event.value <=-1:left =True
elif event.value>=1:right =True
else:
right =False left =False
lightOn =False #Value to use with b button light control
#Infinite Loop while True:
#Get an event from the event system game_controller(pygame.event.get())
#Motor controls beased on directional pad values if up:#Forward
GPIO.output(17,GPIO.HIGH) #Left Forward GPIO.output(27,GPIO.HIGH) #Right Forward
elif down:#Backward GPIO.output(18,GPIO.HIGH) #Left Backward GPIO.output(22,GPIO.HIGH) #Right Backward
elif right:#Right
GPIO.output(17,GPIO.HIGH) #Left Forward GPIO.output(22,GPIO.HIGH) #Right Backward
elif left:#Left
GPIO.output(18,GPIO.HIGH) #Left Backward GPIO.output(27,GPIO.HIGH) #Right Forward
else:
GPIO.output(18,GPIO.LOW) #Reset GPIO.output(17,GPIO.LOW) GPIO.output(27,GPIO.LOW) GPIO.output(22,GPIO.LOW)
if a:#If a is pressed, for holding light on GPIO.output(23,GPIO.HIGH) #Light1 GPIO.output(24,GPIO.HIGH) #Light2
else:#If a is released, for turning light off GPIO.output(23,GPIO.LOW) #Light1 GPIO.output(24,GPIO.LOW) #Light2
if b:#If b is pressed, for holding solid light if lightOn:#If the light is on
GPIO.output(23,GPIO.LOW) #Light1 GPIO.output(24,GPIO.LOW) #Light2 lightOn =False #Declare that the light is off
else:#If the light is off GPIO.output(23,GPIO.HIGH) #Light1
GPIO.output(24,GPIO.HIGH) #Light2 lightOn =True #Declare that the light is on
if y:#If Y button is pressed
#Scan distance to ground with ultrasonic sensor u =ultrasonic.distance
print u
The only changes made to this program were the addition of comments throughout the program, and the deletion of unnecessary code segments.
Testing Prototype 3
Using a standard kitchen scale, I recorded the mass of the robot to be 0.26 kg. The mass of prototype 3 was significantly reduced compared to every other model. Prototype 3 was measured to be 14 cm long x 9 cm wide x 12 cm tall. Prototype 3 was the smallest of the prototypes and was more than a factor of two smaller than prototypes 2a &2b. Prototype 3 had the ability to attach to ferrous surfaces and was able to move on ferrous surfaces of speeds of
0.18 meters/second, making it the fastest prototype. Prototype 3 mounted 3 cameras, and all of them sent back acceptable feeds. Prototype 3 cost $175 to build compared to the $120 of prototype 2a and the $175 of prototype 2b. This can be attributed to the cost of cameras and the cost of smaller motors. Sample images from the three cameras are shown in Figure 11 and the results of robot testing are shown in Tables 1 and 2. The final prototype can be seen in Figure 12.
Source:Design and Development of a Low-Cost Inspection Robot
製造プロセス