ArduPilotは「組み込みソフト」、だったら保守性や品質をあげていきたい。

murata,katsutoshi August 28, 2016 at 3:08pm

PX4Flowのファームウェアを疑って、いろいろこねくりまわしていました。

この結果をもとに、Linux用ドライバを再度確認してみます。

murata,katsutoshi said:

同じファームワエアのPX4Flow を Pixhawk に接続し、DISARMED状態で連続稼働を行いました。

結果：2.9Hハングしませんでした。（ログを確認するために、電源断しました。）

Navio2(OS Linux)のドライバ、他にもバグがありそうな感じです。

murata,katsutoshi August 28, 2016 at 2:45pm

同じファームワエアのPX4Flow を Pixhawk に接続し、DISARMED状態で連続稼働を行いました。

結果：2.9Hハングしませんでした。（ログを確認するために、電源断しました。）

Navio2(OS Linux)のドライバ、他にもバグがありそうな感じです。

murata,katsutoshi August 28, 2016 at 3:09am

この改善案は、採用いただきました。
ありがとうございました。

Goro Senzai said:

これはわかりやすくてよいですね。

murata,katsutoshi said:

ArduPlane / control_modes.cpp の readSwitch メソッドの判定条件がもう少しシンプルにできると思います。

下記のようなスケールで判定値を決定しています。

-------900(255)-------1230(0)-------1360(1)-------1490(2)-------1620(3)-------1749(4)-------2199(5)-------(255)

改善前

    if (pulsewidth <= 900 || pulsewidth >= 2200) return 255;            // This is an error condition
    if (pulsewidth > 1230 && pulsewidth <= 1360) return 1;
    if (pulsewidth > 1360 && pulsewidth <= 1490) return 2;
    if (pulsewidth > 1490 && pulsewidth <= 1620) return 3;
    if (pulsewidth > 1620 && pulsewidth <= 1749) return 4;              // Software Manual
    if (pulsewidth >= 1750) return 5;                                                           // Hardware Manual
    return 0;

改善案

    if (pulsewidth <= 900 || pulsewidth >= 2200) return 255;            // This is an error condition

    if (pulsewidth <= 1230) return 0;　★この条件を入れることでシンプルになります。
    if (pulsewidth <= 1360) return 1;
    if (pulsewidth <= 1490) return 2;
    if (pulsewidth <= 1620) return 3;
    if (pulsewidth <= 1749) return 4;              // Software Manual
    return 5;

murata,katsutoshi August 25, 2016 at 2:37pm

PX4Flow 、約1時間15分位でハングしました。（USB出力は影響なさそうです）

LED_ACT をトグル制御している処理を調査してみます。

murata,katsutoshi said:

PX4Flow が連続稼働で、１Hぐらいでハングする現象まだ出ています。

LED_COMって、どうもUSBへの出力を示しているようです。

とりあえず、「USB出力をしない」設定にして、動作確認を進めています。

デバッグとしては、LED_ERRを「ここは！！」という所に仕込んで確認するしかないかな、とちょっと仕込み中です。

ハートビートチェックはメッセージで確認しています。

murata,katsutoshi said:

PX4Flow が何をしているか、USART3 の出力を取り続けることで、止まったときの値を確認することにしました。

https://pixhawk.org/dev/px4flow

Data Output

The PX4FLOW module outputs MAVLink packets on USB and serial port. Use QGroundControl to read data from the module.

USART3: MAVLink at 115200, 8N1 baud: OPTICAL_FLOW message, OPTICAL_FLOW_RAD message, HEARTBEAT message

USB: Baud rate is not relevant (USB ignores it): OPTICAL_FLOW message, OPTICAL_FLOW_RAD message, HEARTBEAT message, image.

I2C: latest Flow value i2c_frame and accumulated Flow i2c_integral_frame values since last I2C readout available for readout.

murata,katsutoshi said:

稼働させたまま、約2時間後に見てみたら、青LEDが点灯しっぱなしになっていました。

長時間稼働させるとスタックオーバーフローみたいなことが発生しているのだろうか？

：

murata,katsutoshi August 25, 2016 at 1:17pm

PX4Flow が連続稼働で、１Hぐらいでハングする現象まだ出ています。

LED_COMって、どうもUSBへの出力を示しているようです。

とりあえず、「USB出力をしない」設定にして、動作確認を進めています。

デバッグとしては、LED_ERRを「ここは！！」という所に仕込んで確認するしかないかな、とちょっと仕込み中です。

ハートビートチェックはメッセージで確認しています。

murata,katsutoshi said:

PX4Flow が何をしているか、USART3 の出力を取り続けることで、止まったときの値を確認することにしました。

https://pixhawk.org/dev/px4flow

Data Output

The PX4FLOW module outputs MAVLink packets on USB and serial port. Use QGroundControl to read data from the module.

USART3: MAVLink at 115200, 8N1 baud: OPTICAL_FLOW message, OPTICAL_FLOW_RAD message, HEARTBEAT message

USB: Baud rate is not relevant (USB ignores it): OPTICAL_FLOW message, OPTICAL_FLOW_RAD message, HEARTBEAT message, image.

I2C: latest Flow value i2c_frame and accumulated Flow i2c_integral_frame values since last I2C readout available for readout.

murata,katsutoshi said:

稼働させたまま、約2時間後に見てみたら、青LEDが点灯しっぱなしになっていました。

長時間稼働させるとスタックオーバーフローみたいなことが発生しているのだろうか？

：

murata,katsutoshi August 23, 2016 at 9:45am

PX4Flow が何をしているか、USART3 の出力を取り続けることで、止まったときの値を確認することにしました。

https://pixhawk.org/dev/px4flow

Data Output

The PX4FLOW module outputs MAVLink packets on USB and serial port. Use QGroundControl to read data from the module.

USART3: MAVLink at 115200, 8N1 baud: OPTICAL_FLOW message, OPTICAL_FLOW_RAD message, HEARTBEAT message
USB: Baud rate is not relevant (USB ignores it): OPTICAL_FLOW message, OPTICAL_FLOW_RAD message, HEARTBEAT message, image.
I2C: latest Flow value i2c_frame and accumulated Flow i2c_integral_frame values since last I2C readout available for readout.

murata,katsutoshi said:

稼働させたまま、約2時間後に見てみたら、青LEDが点灯しっぱなしになっていました。

長時間稼働させるとスタックオーバーフローみたいなことが発生しているのだろうか？

：

murata,katsutoshi August 21, 2016 at 4:37pm

効率を選ぶか可読性を選ぶか悩むところですよね。

頻繁にアクセスされるなら処理時間が短い方が良いですし。

初期化とかアクセス少ないものは多少効率悪くてもみやすい方が良いというのもありますし。

PRして、お考えを知りたいと思いました。

結果は、せんざい様の考えの有無について不明のまま、採用となりました。

下記では一行になっていますが、実際は各フラグごとに行を変えています。

Goro Senzai said:

ここは頻繁に呼ばれるところではないので、可読性を優先させたのではないでしょうか？

murata,katsutoshi said:

APMrover2 の capabilities.cpp の init_capabilities メソッドの処理について

同変数の各ビットに設定するために３回呼んでいます。

    hal.util->set_capabilities(MAV_PROTOCOL_CAPABILITY_MISSION_FLOAT);
    hal.util->set_capabilities(MAV_PROTOCOL_CAPABILITY_PARAM_FLOAT);
    hal.util->set_capabilities(MAV_PROTOCOL_CAPABILITY_MISSION_INT);

ビッドが異なることから１回で可能です。

    hal.util->set_capabilities(MAV_PROTOCOL_CAPABILITY_MISSION_FLOAT | MAV_PROTOCOL_CAPABILITY_PARAM_FLOAT | MAV_PROTOCOL_CAPABILITY_MISSION_INT);

murata,katsutoshi August 21, 2016 at 4:24pm

コメントありがとうございます。

そういう表示ルールがあったんですね。知りませんでした。

Goro Senzai said:

確か、ARMEDが記録されていない限り、ステータスはDISARMED、というのが暗黙のルールだったと思います。

murata,katsutoshi said:

APM:Copter V3.4-dev (dbdd86ad) で「DISARMED」状態でログされることを確認しました。

DISARMED状態であることが「Mechanical Failure」には表示されない様です。
DISARMEDのログ出力が可となったため、解析情報として「DISARMED」を示す表示必要と感じました。

Mission Plannerについてもソース理解を進めてみます。

murata,katsutoshi August 21, 2016 at 4:07pm

コメント、とても参考になります。

ありがとうございます。

バッテリ利用可能時間以上に継続稼働させていることもあり発見しにくい現象かもしれません。

LEDの点灯状態でどのシーケンスで止まっているか、これから調査します。

これからも、よろしくお願いします。

Goro Senzai said:

確かOpticalFlowのスレッドにも書いたと思いますが、少なくとも以前チェックした際には、PX4 Native Stack用のPX4FLOW ファームウェアと、ArduPilot用のファームウェアには互換性がなかったと思います。

https://github.com/PX4/Flowは、アップストリームのPX4 Native Stack用で、ArduPilot用は下記の別ブランチがソースのはずですが、そちらをコンパイルしても動きませんでした。

https://github.com/priseborough/px4flow/tree/klt_flow

当時は時間もなかったので深く追求せず、用意されているバイナリを使っていましたが、ArduPilot版はメンテされていないので、いずれは、継続して改良が加えられているアップストリーム版と統合できればと考えています。

長時間稼働は、そもそもバッテリーがそんなに持たないため経験がないのですが、PX4 Native Stack版とArduPilot版のどちらも同じ症状であれば原因も同じバグではないかと思います。

Goro Senzai August 21, 2016 at 7:01am

確かOpticalFlowのスレッドにも書いたと思いますが、少なくとも以前チェックした際には、PX4 Native Stack用のPX4FLOW ファームウェアと、ArduPilot用のファームウェアには互換性がなかったと思います。

https://github.com/PX4/Flowは、アップストリームのPX4 Native Stack用で、ArduPilot用は下記の別ブランチがソースのはずですが、そちらをコンパイルしても動きませんでした。

https://github.com/priseborough/px4flow/tree/klt_flow

当時は時間もなかったので深く追求せず、用意されているバイナリを使っていましたが、ArduPilot版はメンテされていないので、いずれは、継続して改良が加えられているアップストリーム版と統合できればと考えています。

長時間稼働は、そもそもバッテリーがそんなに持たないため経験がないのですが、PX4 Native Stack版とArduPilot版のどちらも同じ症状であれば原因も同じバグではないかと思います。

PX4/Flow

Firmware for PX4FLOW board. Contribute to PX4/Flow development by creating an account on GitHub.

Japan ArduCopter Group