ROSの学習を開始するときは、通常、シミュレーターのモデルではなく、物理プラットフォームで作業する必要があります。実際、Gazeboはモーションアルゴリズムだけを研究したり、ROS自体を教えたりするのに十分ですが、実際のプラットフォームで作業することで、実際のホイールの動きに関するすべての問題をすぐに理解できます。まあ、そして多くの場合、プラットフォームは単にプロジェクトの前提条件として必要です。
将来的には、ラウンドから始める方が良いです。明らかな理由で、このような構成では、突出部分のサイズを考慮せずに軸を中心に回転できます。Uターンの長方形は、たとえば狭い廊下ではあまり便利ではありません。3つ以上のトリックを展開する必要がある場合もあると、ドライバーは理解できると思います。
既製のプラットフォームを購入する
市場に出回っている既製のプラットフォームは多くありません。それらはROSのWebサイトにリストされています。
同時に、ロシアでの彼らのコストは仕事を始めるのに十分高いです;最も安いオプションはタートルボットバーガー3--549ドルです。ロシアで約90,000ルーブルの再販業者を直接見つけました。
中国では、45〜50 trで購入できます...いずれにせよ、これらは小型で運搬能力のあるプラットフォームであり、実際のタスクを実行することはできません。
プラットフォームは自分で構築できます。さまざまなガイドと構成があります。しかし、平均すると、次のようになります。
- SlamtechA1-A2クラスのリダー
- ギアボックス付きコレクターモーターをベースにした安価なホイール
- , PWM , UART + rosserial.
- Single Board Computer — Raspberry, Jetson Nano
- 2
- gmapping + amcl/rosbot_ekf + move_base
コレクターモーターはノイズが多く、消費量が多く、ギアボックスが必要なため、私たちはコレクターモーターが好きではありませんでした。ここで、プラットフォームはかなり重いと見なされていると言わなければなりません。インターロックされたギアボックス+モーター写真のモーターのようなものは機能しません。
したがって、BLDCホイールモーターがムーバーとして選択されました。現時点で最も手頃なオプションは6.5ホバーボードホイールです。 ROSからそれらを管理することだけが残っています。
しかし、その後、1つの問題が表面化しました。ゴルフロボットで作業しているときでさえ、そのようなプラットフォームの低速での回転に重大な問題が見られました。ロボットはかなりぎくしゃくした向きになりました。
この動作の理由は単純です。スライドする摩擦力は、ターンの動きに対する抵抗に重要な役割を果たします。そして、それらには特異性があります-抵抗は表面自体の質量と性質に依存します-それが小さなボルトが最初の2〜3回転で大きな構造を保持する理由です。
したがって、ホイールを中央で狭くして回転させることは、かなり無意味になります。抵抗はほとんど変化しません。ゴム製のホイールが草や土にこすれ、それらはまったく均一ではなく、力が劇的に変化する可能性があります。その結果、ギアボックスのようなものが作られました-低速ではホイールのモーメントを制御し、直接の動きで-速度自体。
寄木細工の床やリノリウムで運転するときは、状況は良くなるはずですが、残念ながら、摩擦係数はほぼ同じです（滑り止めの靴もゴム製であることを忘れないでください）。
そしてその結果、10〜15キログラムの重さのロボットがすでに目に見えるジャークで展開し始めています。
問題の2番目の部分は、かなり弱いSBCボードと組み合わせたROSdiff_driveパッケージによって追加されます。
これが私が理解できたもののリストです
管理はリアルタイムの実装を使用して実行されますが、他のパッケージが管理を操作するときにこのアプローチを期待する必要があることは考慮されていません。
ここで、リアルタイムはイベントへの即時の応答ではなく、イベントが物理的な時間の保証された間隔で処理されることを保証することを覚えておく必要があります。それら。毎分（必然的に毎回）調整される条件付き水力発電所もリアルタイムシステムです。
ルートプランナーのトピックがメッセージで詰まる可能性があります。ポジショニングおよびルートプランニングサブシステムの場合、この動作は通常、フロー処理を停止して再開するか、その場でプロセスを調整しようとします。
その結果、弱いSBCでは、パスの継続的な再計算を伴う状況が発生します。、またはローカリゼーションの検索はかなり長いプロセッサ時間を消費します-そしてRTコンポーネントに追いつくために多くの試みがなされるほど、より多くの時間が蓄積されます。純粋な形では、正のフィードバック。この場合はまったく必要ありません。
これに加えて、プラットフォームの位置が急激に変化し、リダーが弱くなると、gmappingがすぐに機能しなくなり、最大0.5秒の一時停止が観察されました。これも、ルートプランナーを大いに困惑させます。
モーターは個別に制御されるため、SBCとドライバーの単純な実装を使用する場合、ホイールは多少の遅延で制御されます。
ここでの問題はさらに単純です。通信チャネルを介して2〜4個のホイールを制御する必要があります。したがって、制御信号が並んで、左輪、右輪、左輪、右輪の順に送信され始めます。
その結果、ホイール自体、さらに悪いことに、エンコーダーからのホイールの位置が、パスの計画とモーターの制御の間のPICの形成に寄与し始めます。
組み込みのオドメトリは非常に単純です。
コマンドとオドメトリの戻りを同期させる簡単な方法を探していなかったので、それを見つけることができませんでした。同期は常に入力でのいくつかのコマンドの待機に関連付けられていますが、それらは時間的に規則的ではなく、その結果、オドメトリは出力に残り始めます。おそらく読者は簡単な方法を提案するでしょう-ここでは私たちは自分たちをROSの第一人者とは考えていません。
そのようなアセンブリが適切に動作することを保証することに成功しませんでした。より正確には、変位の加速を0.05〜0.1 m / s ^ 2に、角速度を0.03 rad / sに過小評価することができました。
私は持っているといいと思いました：
- 安いプラットフォーム
- 同期ホイールステアリング
- ホイールの動作と取り扱いに基づく走行距離測定の計算
- さまざまなコントロールを備えたターンモーションモード
- さまざまなモードでのさまざまな制限
最後に何が起こったのか
コントローラーはジャイロスクーターボードから取られ、ホイールコントロールは、動きを開始して回転するときにトルクコントロールが使用されるように記述されています。また、カートが直進して特定の速度に加速されると、速度制御モードがアクティブになります。どちらのモードでも、エンコーダーからのデータは、速度とモードを考慮してコントローラー内で処理され、データは10〜15ミリ秒前に何らかの予測で出力されます。
エンコーダーは常にコントローラーで読み取られ、2〜3要素のバッファーに蓄積され、遅延して送信されます。肝心なのは、制御を受信すると、コマンドが実行された後にのみ応答が返されるということです。変更されたエンコーダー値が受信されるまで、バッファーはブロックされます。しかし、オドメトリは発行されており、すでに送信された最後の値を使用するだけです。
なぜなら上記の問題はすべて、いずれにせよUARTポートからの同期送受信の制御を同期する必要があるという事実に要約され、diff_driveパッケージに強制シンクロナイザーを導入することは不合理であると考えたため、独自の制御パッケージを作成しました。
これはgithub.com/Shadowru/hoverboard_driverにあり、現在アクティブにファイナライズされています
。パッケージは次のように起動ファイルに含まれています。
<node name="hoverboard_driver" pkg="hoverboard_driver" type="node" output="screen">
<param name="uart" value="{ }"/>
<param name="baudrate" value="115200"/>
<param name="wheel_radius" value="0.116"/>
<param name="base_width” value="0.43"/>
<param name="odom_frame” value="odom"/>
<param name="base_frame” value="base_link"/>
</node>
uartポート自体には適切なアクセス権が必要です。一部のプラットフォームでは、ユーザーが常にアクセスできるとは限りません。例として、hoverboard_driver / scripts /jetson_nano_serial.shディレクトリにあるJetsonNanoの場合、OSの起動時に権限を設定するスクリプトが添付されています。
パケット自体には、コントローラーからのデータストリームの読み取りと、トピックへの関連情報の発行が含まれます 。hoverboard_msgの
ようなパケットを使用したhoverboard_driver / hoverboard_msg
メッセージ構造は次のとおりです。int16state1-
ホイール1の
内部情報
int16state2-ホイール2の内部情報int16speed1-ホイール1の瞬間速度
int16speed2-ホイール2の瞬間速度
int16batVoltage-バッテリー電圧
int16boardTemp-コントローラー温度
int16error1-ホイール1エラー
int16error2-ホイール2エラー
int32pulseCount1-ホイール1エンコーダーカウンター
int32pulseCount2-ホイール2エンコーダーカウンター
さらに、hoverboard_driver /オドメトリトピックは一般的なメッセージを受信しますnav_msgs ::オドメトリ
位置は次のように計算されます：
パラメータwheel_radius-radiusに基づくメートル単位のホイール、base_width-ホイールの中心間の距離。前の位置から読み取った位置までの間に各ホイールがどれだけ移動したかを計算します。
double curr_wheel_L_ang_pos = getAngularPos((double) feedback.pulseCount1); double curr_wheel_R_ang_pos = getAngularPos((double) feedback.pulseCount2); double dtime = (current_time - last_time).toSec(); double delta_L_ang_pos = curr_wheel_L_ang_pos - raw_wheel_L_ang_pos; double delta_R_ang_pos = -1.0 * (curr_wheel_R_ang_pos - raw_wheel_R_ang_pos);
次に、各ホイールの加速度を計算します
wheel_L_ang_vel = delta_L_ang_pos / (dtime); wheel_R_ang_vel = delta_R_ang_pos / (dtime);
次に、各軸に沿ったロボットの線形加速度を計算します
robot_angular_vel = (((wheel_R_ang_pos - wheel_L_ang_pos) * wheel_radius / base_width) - robot_angular_pos) / dtime; robot_angular_pos = (wheel_R_ang_pos - wheel_L_ang_pos) * wheel_radius / base_width; robot_x_vel = ((wheel_L_ang_vel * wheel_radius + robot_angular_vel * (base_width / 2.0)) * cos(robot_angular_pos)); robot_y_vel = ((wheel_L_ang_vel * wheel_radius + robot_angular_vel * (base_width / 2.0)) * sin(robot_angular_pos));
その結果、完全なセット（線形加速度、角加速度、およびそれらに時間を掛けたもの）が得られ、ロボットの位置の変位が得られます。
robot_x_pos = robot_x_pos + robot_x_vel * dtime; robot_y_pos = robot_y_pos + robot_y_vel * dtime;
その後、オドメトリメッセージが送信され、オドメトリフレームとベース間のtf変換が送信されます。
入力のコントローラーは、速度とターンの2つのパラメーターを持つ1つのパケットによって制御され、パケットはほぼネイティブにツイストから送信されます。速度は円周で除算され、ターンが取得されます。
double v = vel.linear.x;
double rps = v / rpm_per_meter;
double rpm = rps * 60;
int16_t speed = static_cast(rpm);
角加速度は係数の乗算の形でホイール速度の差に変換され、ホイールベースを考慮してさらに再計算が追加されますが、実際にはこれは大型で重いロボットにのみ必要です。
double w = vel.angular.z;
int16_t steer = static_cast<int>(-1 * w * 30);
その結果、安価な部品で非常に安定したトロリー制御を実現することができました。
私たちはあなたの大多数のようにロボットを作成します。主力製品を積極的に開発しています。パイロットテストが行われ、生産の準備が整いました。ゴルフボールを集めるロボットです。
カスタムロボットと派生ソリューションを開発しています。これは、技術仕様やスケッチから完成品までの作業である場合もあれば、作業の一部である場合もあります。
ほとんどの場合、ロボットは外界と相互作用するために車輪を必要とします。速度と位置を正確に制御できるため、ほとんどの場合、これらはブラシレスモーターです。
小型ロボットの場合、ジャイロスクーターのホイールがよく使用されますが、これは大量生産とこのソリューションの価格のために正当化されます。ロシアのエンジンの価格表を見たことがある人なら誰でも、大量生産の重要性を理解しています。
コントローラに関しては、ほとんどの場合、これらはモデルesc、vesc、odrive、BLD-300B、または自家製のソリューションです。
本物のロボットを作り、ガゼボの呪いを解くために簡単に入るには、ほとんどの開発者は簡単に入るためのクジラが必要です。現実の世界では、理想とは大きく異なります。
時々、予測できないことが起こり、センサーにノイズが多く、リアルタイムでバッファーがオーバーフローします。このビデオデバイスでは、以前にコンタクタとリモートキルスイッチでテストしました。
やがて神経を節約するのに役立つ何かを提供します。これは、ケース（平行パイプとシリンダー）、2つのモーターホイール、バッテリー、充電器、およびオドメトリを提供し、ROSパッケージですぐに使用できるフラッシュコントローラーを組み立てるためのキットです。 19.000摩擦。ミリングカッティングよりも安価で、複合材料、ファスナー、クッション付きスイベルホイールのコストがかかります。
お電話いただくか、ROSオンラインのプラットフォームをお申し込みください。一緒にロボットを作りましょう。
プラットフォームについては、 12月5日に開催されるロボットオペレーティングシステムのミートアップで詳しく説明します。参加者の登録はすでに開始されています。
→視聴者登録