タグ付けされた質問 「design」

ロボットの機械的、電子的またはプログラム的な設計。

4
火星探査機はなぜそんなに遅いのですか?
火星探査機は通常非常に遅いです。たとえば、好奇心の平均速度は1時間あたり約30メートルです。 なぜそんなに遅いのですか?それは、特定の電力制限によるものですか、それとも他の理由によるものですか?それが遅い理由の一番の理由は何ですか?

4
ロボット工学では、他の構成よりもクワッドコプターが一般的であるのはなぜですか?
ヘリコプターロボットで行われているほとんどすべての研究がクアッドコプター(4つのプロペラ)を使用して行われていることに気付きました。なぜトリコプターを使用して行われる作業がこれほど少ないのですか?それともプロペラの数が違うのですか?4つのプロペラがクワッドコプターを最も人気のある選択肢にしましたか?
21 quadcopter  design  uav 

5
ローターまたはマルチコプターの中心にバッテリーを配置する方が良いでしょうか?
マルチコプターにバッテリーを取り付けるための3つのアプローチを見てきました。 機体の中心近くにしっかりと取り付けられたすべてのバッテリー 機体の中央の下にぶら下がっているバッグ内のすべてのバッテリー 各ローターは、その近く/下にしっかりと取り付けられたバッテリーを共有しています。(たとえば、各モーターの下にすべてのバッテリーの1/4が取り付けられたクワッドコプター)。 どのデザインが最適で、なぜですか?最適な設計がない場合、設計間の利点/トレードオフは何ですか?私が見落としている他のデザインはありますか? (この質問はマルチローターフライングマシンに焦点を当てています。地上車両については、「車輪またはロボットの中心に重量を分散させる方が良いでしょうか?」を参照してください)。

3
火星探査機の設計者がトラックよりもホイールを好むのはなぜですか?
通常、火星探査機はトラックではなくホイールを使用します。スピリットは、その柔らかい土壌から抜け出せる可能性が高いと思います。一般に、火星の表面構造は事前に知られていないため、困難な地形のために事前にペアリングして、トラックを使用する方が賢明です。 火星探査機は通常、トラックではなくホイールを使用するのはなぜですか?

3
5 Vで多数(27)のサーボを駆動する最良の方法は何ですか?
この質問が少し曖昧に聞こえるかもしれないことをおpoびします。私は、さまざまなサイズの27個のサーボを含むロボットプロジェクトに取り組んでいますが、どのように電力を供給すべきかを考えるのに苦労しています。 私はいくつかの(3-6)5 W 18650バッテリーボックスを使用してそれらを駆動することを望んでいましたが、最小のモーターはそれぞれ2.5 Wを使用するため、1つのバッテリーボックスは2つしか駆動できません。明らかに、より大きなサーボはさらに多くの電流を使用するため、少数の18650を使用するこの計画は実行不可能になります。 ロボットには12 Vのカーバッテリー用の十分なスペースがありません。1つ追加するには、必要なサーボモーターのサイズを再計算する必要があります。さらに、サーボモーター用に12 Vを5 Vに変換する方法がわかりません。 PSモーターの失速電流はどうですか?電源は、それが供給するすべてのモーターのストール電流を(同時に)供給できるのか、それとも動作電流のみなのか?サーボモーターが失速した場合(もしそうであれば)にヒューズを使用すべきですか?ヒューズまたはサーキットブレーカーを使用する必要がありますか?5 Vのヒューズを製造していますか?もしそうなら、どこで入手できますか? 18650ボックスのより大きなバージョンのようなものが最も望ましいでしょう。

2
ホイールvs連続トラック(タンクトレッド)
安いVex Roboticsのタンクトレッドを使用して小型のロボットを構築しています。しかし、タンクトレッドのピッキングの選択は、ほとんど純粋にホイールよりも楽しいように見えるという事実に基づいています。ホイールと比較した場合、実際に多くの利点または欠点があるかどうかは実際にはわかりません。 ホイールと連続トラックの両方の長所と短所は何ですか?


3
Mecanumホイールの効率の計算
私は最初のロボティクスチームの一員であり、ロボットにメカナムホイールを使用することを検討しています。 Mecanumホイールと通常のホイールを使用する利点と欠点は何ですか?Googleを見ると、Mecanumホイールはより多くの機動性を提供するように見えますが、それほど牽引力はありません。他の利点または欠点はありますか? 通常のホイールと比較して、Mecanumホイールはどのような点でも効率が低いのですか?もしそうなら、どれくらいで決定する定量化可能な方法がありますか? 前方、側方、または任意の角度で移動する効率(または非効率)および/または速度を計算するために使用できる方程式はありますか? メカナムホイールを備えたロボットの写真:

3
FPGAをRoboticsで使用する必要があるのはいつですか?
FPGAは、このようなIOポイントの多くとしての良さを持っているが、その後、再びあなたが非常に低レベルで物事を考える必要があるフリップフロップと物事がまだ成熟していない領域の開拓者-例えば、この質問を参照してくださいここでの開発、ツールについてFPGA-これは現在私の理解です!現在、FPGAは、このようなロボットハンドで優れた器用さを実現するために使用されています。現在、一部の人々は、次のような高速プロトタイピングおよび「将来を見据えた」設計のためにFPGAを販売していますが、それらを完全には理解していません。そう ロボット工学のプロジェクトではいつFPGAを選択すべきですか?

3
低速(30Hz)システムで高速(200Hz)リアルタイムシステムを制御するにはどうすればよいですか?
現在、複数の制御された自由度とセンサーを備えた移動ロボット+取り付けアームを設計しています。 私は2つの部分でアーキテクチャを検討しています: アームモーターとエンコーダーを制御するための一連のリアルタイムコントローラー(XenomaiなどのRTOSを実行するRaspeberry Piまたはベアメタルマイクロコントローラー)。マイクロコントローラーの数に応じてx = 1,2,3…でこれらのマシンをRTxと呼びましょう。この制御ループは200Hzで実行されます。 ROSを実行してSLAM、mocapを計算し、高レベルのロジックを実行する強力なバニラLinuxマシン(ロボットのタスクを決定し、モーターの希望する位置と速度を計算します)。この制御ループは30Hzで実行されます。 より多くのモーター、より多くのセンサー、より多くのPC(外部のモーションキャプチャーなど)を考慮して、フレームワークをスケーラブルにする必要があることを知っています。 私の主な問題は、さまざまなRTxがPC1と通信する方法を決定することです。ロボットアーキテクチャ(HRP2など)に関連する論文を見てきましたが、ほとんどの場合、高レベルの制御アーキテクチャについて説明していますが、低レベルと高レベルでスケーラブルな方法で通信する方法に関する情報はまだ見つかりません。私は何か見落としてますか? 高速RTマシンを接続して、モーター制御をPC1で保証するために、TCP / IP、CAN、およびUARTを検討しました。 TCP / IP:確定的ではありませんが、簡単に配置できます。非決定性は本当の問題ですか(とにかく遅い30Hzでしか使用されないため)? CAN:低速で、非常に信頼性が高く、車をターゲットにしています(ロボットでCANを使用する例がいくつかありますが、エキゾチックに見えました) UART:モーター制御用のRTマシンが1つしかなかった場合、UARTを検討していましたが、このポートは多くのRTxでうまくスケールしないと思います。とても使いやすい… 現時点では、私にとって明らかな解決策はありません。また、特定の信頼性が高くスケーラブルなソリューションを使用した深刻なロボットの例は見当たらないため、選択する自信がありません。 誰かがこの点または指摘する文献について明確な見解を持っていますか?ロボットで使用される一般的なまたは主流の通信ソリューションはありますか?

2
アッカーマンステアリングと運動学に関する標準的な二輪車/三輪車の違いは?
次の宿題の質問がありました。 アッカーマンステアリングを備えたロボットと運動学に関する標準的な自転車または三輪車の一般的な違いは何ですか? しかし、車のようなロボット(2つの固定後輪と2つの従属調整可能な前輪)は三輪車のようなロボット(1つの調整可能な前輪が中間)。 次に、2つの後輪の間の距離をゼロに近づけると、自転車が手に入ります。 そのため、これら3つの移動ロボットの違いはわかりません。不足しているものはありますか?

1
水中グライダーの適切な寸法の選択
私は潜在的に構築しているよ水中グライダー、遅いですが、非常に低い消費電力で動作することができ潜水艦の種類を。しかし、それが効果的に機能するためには、コンポーネント、特に翼の寸法がその成功にとって重要であることをほのめかすいくつかの情報源を見つけました。 しかし、私はこれらの次元がどうあるべきかについて非常にまばらな情報を見つけました!それが原因で少し試行錯誤するのはうれしいですが、いくつかの作業を保存するために、重要な寸法がどうあるべきかについて誰かが情報を持っていますか?
12 design  underwater  auv 

4
モバイルロボットの向きと非ロボットオブジェクトの相対的な方向を表す、人に優しい用語は何ですか?
ロボット工学プログラミングでは、向きは主に、中心位置からのx、y、およびz座標で与えられます。ただし、x、y、z座標は、選択する場所が多数ある場合({23、34、45}、{34、23、45}、{34、32、45}など)、人間がすばやく理解するのに不便です。 、{23、43、45}は特に人間にやさしいわけではなく、ヒューマンエラーが発生しやすくなっています)。しかし、より一般的な英語の方向記述子は、多くの場合、迅速に選択するには言葉が多すぎるか、または不正確すぎます(たとえば、「ロボット1の右前肩にある正面カメラ」は言葉が多すぎますが、「前」/「前」は不正確です-です最先端のカメラか、それとも前向きですか?) 海軍および航​​空分野では、車両の位置は、一般に、前部、後部(または船尾)、港、および右舷と呼ばれます。一方、車両に関連する移動方向は、文字盤を基準にして与えられることがよくあります(たとえば、前部前方は「12時」、後部後方は「6」、右舷およびポートの左側は、それぞれ「3」と「9」です。この言語は、「前」や「前」などの用語よりも正確な迅速な人間のコミュニケーションをサポートします。モバイルロボット工学に同等の用語はありますか?

2
クワッドローターをターゲットに向けて導く
クワッドローターに取り組んでいます。-私はその位置を知っている私が行ってみたい、 -目標位置、及びそのI計算Aベクターから -私の目標に私を取る単位ベクトルを:b caaabbbccc c = b - a c = normalize(c) クワッドローターは回転せずにどの方向にも移動できるため、私がやろうとしたのは ロボットのヨー角でを回転させるccc コンポーネントに分割するx 、yバツ、yx, y それらをロール角とピッチ角としてロボットに渡します。 問題は、ヨーが0°±5の場合、これは機能しますが、ヨーが+90または-90に近い場合、失敗し、誤った方向に進みます。私の質問は、ここに明らかな何かが足りないのですか?
9 quadcopter  uav  navigation  slam  kinect  computer-vision  algorithm  c++  ransac  mobile-robot  arduino  microcontroller  machine-learning  simulator  rcservo  arduino  software  wifi  c  software  simulator  children  multi-agent  ros  roomba  irobot-create  slam  kalman-filter  control  wiring  routing  motion  kinect  motor  electronics  power  mobile-robot  design  nxt  programming-languages  mindstorms  algorithm  not-exactly-c  nxt  programming-languages  mindstorms  not-exactly-c  raspberry-pi  operating-systems  mobile-robot  robotic-arm  sensors  kinect  nxt  programming-languages  mindstorms  sensors  circuit  motion-planning  algorithm  rrt  theory  design  electronics  accelerometer  calibration  arduino  sensors  accelerometer 

2
必要なパワーとトルクは何らかの形で関連していますか?
私は屋外ロボット工学用の新しいプラットフォームを設計しており、プラットフォームを動かすために必要なパワーやトルクを計算する必要があります。それを動かすのに約720 W(モーターあたり360W)の総電力が必要であると計算しましたが、必要なトルクを計算する方法がわかりません。 それは本当に必要なパワーを持ち、トルクを無視することに関するだけですか、それとも簡単に計算する方法がありますか? プラットフォームの既知のパラメータは次のとおりです。 プラットフォーム全体の重量:75 kg。 ホイールの数:4。 動力輪の数:4。 ホイールの直径:30 cm。 モーター数:2。 必要な速度:180 RPM(3 m / s)。 必要な加速度:> 0.2 m / s ^ 2

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.