Loading [MathJax]/extensions/tex2jax.js

2025年3月2日日曜日

向かい風によってドローンの頭が上げるpitching moment に関する論文を読む

 Reduction of the head-up pitching moment of small quad-rotor unmanned aerial vehicles in uniform flow (2018, Hikaru Otsuka, Daisuke Sasaki and Keiji Nagatani, International Journal of Micro Air Vehicles 10-1)

https://journals.sagepub.com/doi/epub/10.1177/1756829317745318

という論文を読んだ。中身は、飛行体に対して向かい風が吹いてきた時に発生するpitch方向のhead up不安定性がドローンのローターの傾きを変えた時にどうなるかを調べている。

さまざまな実験を行った結果として、結論的に、モーターの向きを外側に向けて開くことによってその不安定性を低減できると主張している。

"Based on the experimental results, we conclude that rotor tilting to the outer side reduces pitching moment generation."

私の書いた前の記事の議論と整合的であるので嬉しい。

モーター平面をV型(inward tilt)にするとドローンの安定性は増大するか?

 概要

ドローンのモーター平面をV型に傾けるとより安定するといわれているようだが、理論的には、逆Vにした方が安定することを示す。


本文

あるYouTube動画を見ていたら、モーター平面を内側に傾ける(inward tiltというらしい)とドローンの安定性は増すのだという説明があった。聞いた一瞬はとても納得して、既存の大型のドローンのモーター平面がそうなっている理由がわかった気がした。しかし、理論的に考えて、本当にそうなのかと思った。

自分なりに考えてみた結果一概にそんなことは言えないような気がした。その理由を説明しよう。





図を見て考えみよう。単純化して、AOBで表されるのが、ドローンの機体を一方向から見た状況だと考えよう。機体の垂直方向は、Vで機体は右に少し回転した状態で、傾いている。モーターの平面は、内側に折れるように傾いていて、その傾き角度はβである。
両翼の長さは、それぞれ$l$である。

この状態で、復元力が、このモーター平面の傾きによって発生すれば良いわけである。
面倒なので、一番単純に考えてみる。
(1)機体の中心Oは、固定されている。ただし、自由に画面と水平に回転できる。
(2)機体の片側の重さ$m$は、モーターの場所に集約されている。
(3)モータの上昇力、スラスト$t$は、重さで測られ片側の重さと釣り合っている。
すなわち、$$t=m$$である。
今、A点における力のバランスを見てみよう。
動画では、復元力が発生する理由を、A点では、傾いているせいで、そこにかかる重力に比べて、上昇力が$$t\cos\beta<t=m$$となってしまっていて、下向きの力が大きくなっているからだと説明していた。
だが、それは、傾いているが故に発生する右向きの力を無視している。さらにmが働いている腕の長さも短くなってしまっていることを忘れているのではないだろうか。
そこで、A点において、左向きに回転する力(傾きを復元しようとする力)と、右向きに回ろうとする力(傾きをさらに増大させようとする力)のバランスを調べてみよう。
左向きに回転しようとする力と、腕の長さを掛け合わせたトルクは、
$$(m-t\cos\beta)l\cos\beta$$
である。
一方、さらに右向きに回転しようとするトルクは、
$$t\sin\beta l\sin\beta$$
である、
左向きの回転力から右向きの回転力を差し引く
$$ (m-t\cos\beta)l\cos\beta-t\sin\beta l\sin\beta$$
$$ = ml\cos\beta-tl\cos^{2}\beta -tl\sin^{2}\beta$$
$$ = ml\cos\beta-tl$$
$$ = l(m\cos\beta -t)$$
$$ = lm(\cos\beta-1)$$
$$ < 0$$
(ただし、ここで$t = m $を使っている)
この結果は、安定化するどころか、不安定性を増加させるという結論だ。
どこか、考え方が間違っているだろうか?

簡単な練習問題になるが、モーター平面が、逆に、下に開いたVの形をしていると、安定性が増すようなバランスになることがわかる。式の変形はそのままで良い。ただ、下向きの場合は上の式が負になるのは、復元力が働く、右回転することを意味するからだ。

ここで、もしかすると今までの議論が、ドローンの腕そのものが傾いていることに依存しているのではないかと疑問が湧いてきたので、さらに調べてみた。

次の図のように、腕そのものは傾いていず、まっすぐで、モーターだけが傾いている状況を考えてみよう。
今、モーターの傾きは、$\alpha$で、機体が$\beta$だけ傾いている状況を考えてみよう。他、腕がまっすぐになった以外は、前と同様の条件である。

次のような単純化を行おう。
(1)モーターの傾きと、機体の傾きがちょうど同じになった状態を考慮する
(2)その状態で、B点のスラストと重さのバランスは釣り合っている。すなわち相変わらず、$t=m$を想定する。
この状態で、左回転のトルクが発生すれば復元力があることになる。

ただ、これは計算をするまでもなく、先の機体の腕が傾いている状況の分析で$\beta$を$2\beta$にしただけで、計算過程は同じである。従って、結論も同じである。

機体の傾きが、前のモデルと同じでも、モーターが傾いているだけ、不安定性は増す可能性がある。また、逆向きにモーターが傾いていると、安定性は増加する。

2025年2月15日土曜日

3号機、ホバリングのログ解析

 3号機のホバリングの様子は、以下のYoutubeに投稿した。

https://youtu.be/ZYVSvt3-ws4

3回、試みているが、それぞれ様子が違う。ログを見てみる。まず、コントローラーから送っているスロットル値とPID制御によって与えられたスロットル値の様子は、以下のようになっている。


1回目は、全体が安定しているが、2回目と3回目は、後半が不安定になっている。

1回目の離陸では、1600くらい、80%で離陸している。そして、PID制御によるスロットルの変動の最大幅は、400前後である。合計すれば2000前後である。スロットルの最大値は、2047だからぎりぎりなのである。

次のグラフは、機体の傾き、ROLLとPITCHの様子と、PID制御のスロットル値の様子が、2回目と3回目は、機体の傾きに対して、極端なPID制御値が必要になってい。ので無理が表れている。




これでは見にくいかもしれないので、第1回目の離陸だけを取り出して詳しく見てみる。


太い青の線がROLLで、太い緑の線がPITCHだ。それぞれの目盛りは右側に示されていて、値は度である。モーターの番号は、前が北として、北西がモーター1(細い青線)、南東がモーター2(オレンジ細線)、南西がモーター(灰色)、北東がモーター4(黄色)である。赤で囲ったところを見てみよう。ロールが正で、ピッチが負である。ロールが正なので、2と4のスロットルを上げる必要がある。一方、ピッチが負なので、2と3のスロットルを上げ、4はスロットルを落とさなければならない。結局、しっかりスロットルを上げる必要があるのは、2で、しっかり落とす必要があるのは、1という事になる。図はその通りになっている。PIDは、よく反応しているのだ。


2024年12月7日土曜日

立ち上がらないraspberrypiのネットワーク

 raspberrypiのネットワークが立ち上がらなくなってしまっていた。差し当たって必要ないのでほっておいたが、今日、いろいろ調べてみた。

結局、raspi-confgで、network Configure をdhcpcdから、networkmanagerに変更したら立ち上がるようになった。理由は、わからない。

2024年8月15日木曜日

起動しないraspberrypiの修復

 前日の終了の仕方が悪かったのか、raspberrypi が起動しなくなった。You are in emergency mode・・・・・・を限りない感じで繰り返している。

https://www.jh4vaj.com/archives/26989

このサイトを参考にした。

WindowsにいれたVirtualboxのraspberryで問題のSDカードを認識させて上記サイトの最後の方にある、e2fsckをbootではなくファイルシステムの方に実行した。全てyesで、終了させる。再度起動させたら、正常起動した。ほっと胸を撫で下ろした。

2024年8月14日水曜日

再開

 昨年の2月に、財政的な理由で一時的に作業を中断した。が、ようやく、再開できる感じになってきた。かつての自分の頭が考えていたことが、少しずつ戻ってきている。

2022年12月14日水曜日

920MHz帯無線通信モジュールTY92SS-E2730を使う

 先にも書いたが、ドローン2号機上のコントローラーはラズパイ4で、それとのやりとりをもともとWIFI経由で予定していたが、機体がアルミパイプであるために通信が不安定で使い物にならなかった。そこで、プロポに変えた。プロポの信号取り出しもなんとか安定できるようになったが、そのシステムを最初、ディスプレイとかマウス、キーボードを繋いだ形で起動しなければならず、一旦動かしたのちにログの処理をするなどの場合に、再度繋ぎ直す必要があるなど、耐え難い不便があった。

そこで、無全モジュールを使ってコントローラーを動かすことを考えた。機体の制御はプロポを使うのだが、その他のシステム制御を担うべきものだ。

無線モジュールとして、TY92SS-E2730が秋月電子に二千数百円で売っていたので、それを使うことにした。920MHzで400メートル以上とどく。技適取得済みで免許は要らないことにも驚きだ。正々堂々と使える。

これは、XBeeモジュール用のUSBインターフェイス基盤(秋月電子、千数百円)と組み合わせて使うことが圧倒的に便利であることが色々試みた結果、事後的に分かった。そもそも、XBeeがなんであるかはよく知らないのだが、知らなくても使えることがいい。

多数のモジュールをネットワーク上に繋いだりもできるようだが、差し当たっては、1対1の通信ができれば良い。

それぞれを相互の送受信用に、二つずつ買って、コネクタを半田付けして組み立てた。ピン配列の向きに注意しないと、基盤を壊す可能性がある。




ネット上に、使用した詳細の情報がほとんどなく、サンプルもないので最初は、チンプンカンプンだった。
コマンドマニュアルと製品仕様書の読み込みに、長時間没頭するしかなかった。
USB経由のシリアル通信が基本だ。変換ICがポピュラーなので、MACでもラズパイでも特別なドライバーをインストールする必要もなく認識する。
ホスト側からモジュールに送る信号は、マニュアル通りに与えなければならない。
以下、大事な点をメモがわりに書いておこう。
(1)最初は、マッチングはどうするのかと思ったが、結局、相手のデバイスIDを指定して送ることになっている。ある意味、TCPIPのようなものである。そこには、自己のデバイスIDも書き込むことになっている。製品情報からデバイスIDを生成する方法は、製品仕様書に書いてある。
(2)MACの場合は、USBシリアルデバイスをオープンするときにO_NONBLOCKを指定した方がいい感じなのだが、ラズパイの場合は、これを指定するとエラーになるので外す。これで、半日ロスした。Cのプログラム自体は、ほとんど両者でほとんど同じものが使える。

また何かメモすべきものがあれば、追加するつもりだ。

向かい風によってドローンの頭が上げるpitching moment に関する論文を読む

 Reduction of the head-up pitching moment of small quad-rotor unmanned aerial vehicles in uniform flow (2018, Hikaru Otsuka, Daisuke Sasaki ...