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

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

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

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

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

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

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

ネット上に、使用した詳細の情報がほとんどなく、サンプルもないので最初は、チンプンカンプンだった。

コマンドマニュアルと製品仕様書の読み込みに、長時間没頭するしかなかった。

USB経由のシリアル通信が基本だ。変換ICがポピュラーなので、MACでもラズパイでも特別なドライバーをインストールする必要もなく認識する。

ホスト側からモジュールに送る信号は、マニュアル通りに与えなければならない。

以下、大事な点をメモがわりに書いておこう。

（１）最初は、マッチングはどうするのかと思ったが、結局、相手のデバイスIDを指定して送ることになっている。ある意味、TCPIPのようなものである。そこには、自己のデバイスIDも書き込むことになっている。製品情報からデバイスIDを生成する方法は、製品仕様書に書いてある。

（２）MACの場合は、USBシリアルデバイスをオープンするときにO_NONBLOCKを指定した方がいい感じなのだが、ラズパイの場合は、これを指定するとエラーになるので外す。これで、半日ロスした。Cのプログラム自体は、ほとんど両者でほとんど同じものが使える。

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

2号機テスト飛行の解析（３）

 2号機のテスト飛行を、近所の農家のSさんの畑を借りて実行した。

Sさんには、日頃からいろいろお世話なってい流。私が下ケ傍示から二之袋の竹の人がやっている早朝のラジを体操に向かうとき、いつも散歩しているSさん夫婦に出会う。中の良い姿を見るのに癒される。また、私の二之袋にある畑用に、玉ねぎの苗を200本以上もらったりもした。そのSさんが、私のドローンのテスト飛行用に、下ケ傍示ベースと二之袋ベースの間にある、絶好の場所を提供していただいたのだった。

テスト飛行の様子はyoutubeにアップしたので、以下から見ていただきたい。

https://youtu.be/Z2vkQfhJmpc

結果的に墜落状態になったが、過去のテストと比べて、より高い位置で空中遊泳をした飛行になった。

色々な課題が浮かび上がったテスト飛行だったが、いつものように、まず、ログの分析を与えておこう。

機体のロール方向とピッチ方向の傾き、それに対応したモータースピード（実際の回転ではなく、モーターに加えた電圧レベルと考えたら良い）のデータは次のようになる。

図をクリックすれば拡大されるのでそれを見ていただきたい。上部のオレンジと青の線は、ロールとピッチ方向の傾きだ。揺れがずれながら（期待が渦巻き状態になり）拡大している。最後は破綻している。（縦のスパイク状の変化は、システムが発生する誤差であり、無視して良い）

下の四つの色のグラフは、各モータースピードである。PID制御がかかっているので、機体の傾きに対応する形で、モータースピードの調整が行われている。

図を見る限り、調整が、揺れを拡大する作用を引き起こしてしまっているようだ。これが生じるのは、これまでのシミュレーションでも何度も明らかにしてきたので、その現象が綺麗に実現していると見ることができる。

ロールが大きくなると、それに反応する形でモーター４の速度が増大し、モーター３の速度が低下している。ピッチが大きくなると、モーター１の速度が増大し、モーター２の速度が低下している。

ただ、実際に我々がコントロールする時意識するように、傾きそうになった時に、その実際の傾きが大きくなる前に、それに専攻する形で速度制御をすべきだ。しかし、図では多少の制御の先行はみえているのだが、それが遅すぎるために揺れが増大してしまっていることが考えられる。

この制御の先行性を実現するのが、実はPID制御のD制御なのだ。そこで、PID制御のP（傾きに直結した制御）とD（微分制御）の状態をグラフ化すると以下のようになる。

オレンジと黄色の線は、それぞれ、ピッチ制御のP制御とD制御を表している。P制御は、傾きの変化にそのまま逆向きのトルクを与えようとする制御だが、D制御は、それを微分した形になっている。わかりやすくいうと、P制御がサインカーブならば、D制御は、それを微分したコサインカーブというのに対応する。実際サインカーブを微分したコサインカーブが、4分の１周期だけ、サインカーブに先行する形を示すように、動いている。つまり、次の動きを予想しながら、それに対応するためには、D制御を強めなければならないということである。

上図を見ても、D制御のレベルが相対的に小さいの、P制御が優位になっていると考えられる。

次回は、D制御を少し強めて、揺れの拡大を抑えられないか試す必要がある。これが、まず何よりもの重要な次回の課題だ。

さらに次回に向けて、現在システムの起動のために、WIFI は使わないので、直接、ラズパイのディスプレイとキーボード、マウスを繋いでいるが、これによって色々細かい調整ができなくなっているので、無銭モジュールを導入しこれを回避したいと考えている。

次回のテスト飛行前は、ちょっと時間がかかりそうだ。