dronecodeのコーディングルールを拝見いたしました。
あまりにもざっくりしていることもあり、保守性や品質まではいき渡っていなさそうと感じています。
そこで、日本には、組み込み系ソフトについて、コーディングルールというのを事細かく定義してるものがあります。
例えば、
・MISRAとか
・IPAの「組込みソフトウェア開発向けコーディング作法ガイド[C＋＋言語版]」や
・凡ミスによる障害の回避ルール
これらのルールをベースにArduCopterのコードの品質を上げていきたい。
また、その過程で、不安なコードがあれば、不安を軽減していきたい。
その情報や修正案などのアップしたいと思い、このディスカッションを立ち上げました。
何卒、よろしくおねがいいたします。
Replies
これはわかりやすくてよいですね。
murata,katsutoshi said:
確か、ARMEDが記録されていない限り、ステータスはDISARMED、というのが暗黙のルールだったと思います。
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);
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;
下記、改善案をPRさせていただき、採用いただきました。
if (c == 'c') {
break;
} else if (c == 0x03 || c == 'q') {
murata,katsutoshi said:
Navio2 + Raspberry Pi 3でArdupilotをGDBでデバッグする手順を記します。
GDBでデバッグできるのは、組み込み開発には必須です。
デバシリはあくまで保守用なので。
デバッグオプションを指定します。
waf configure --board=navio2 --debug
クリーン
waf clean --targets bin/arducopter-hexa
デバッグオプションが有効かを確認
waf -v --targets bin/arducopter-hexa
クリーン
waf clean --targets bin/arducopter-hexa
ビルド
waf --targets bin/arducopter-hexa
cd ./build/navio2-debug/bin
sudo ./arducopter-hexa -A udp:192.168.0.15:14550
Raspberry Pi 2/3 with BCM2709!
デバッグ開始
ps -axでプロセスIDを確認
sudo gdb
attach プロセスID
b ArduCopter.cpp:474
c
APM:Copter V3.4-dev (dbdd86ad) で「DISARMED」状態でログされることを確認しました。
DISARMED状態であることが「Mechanical Failure」には表示されない様です。
DISARMEDのログ出力が可となったため、解析情報として「DISARMED」を示す表示必要と感じました。
Mission Plannerについてもソース理解を進めてみます。
せんざい様、TOMI様
コメントありがとうございます。
機体、修理中なので、修理がおわりましたら確認してみます。
Goro Senzai said:
せんざい様
わかりやすく、ご説明いただきありがとうございます。
非飛行状態における異常検出について、条件を加えることで対処できるかもしれません。
確認してみます。
Goro Senzai said:
Bad AHRSが頻出する件は、3.3.2でフィルターが入って治ったはずですが、長時間平坦でないところに置いておくとIタームが蓄積してエラーになるのかもしれません。
AHRSのエラーは、加速度計のキャリブレーションをやり直すことで解決することが多いですが、キャリブレーション自体、水平なデスク、垂直な壁面、水平器等を使って完全に静止した状態で行っても、温度変化でセンサー出力がドリフトするので、高価なセンサー機器がやっているように、温度変化や他のセンサーの値をモニタリングしながらアクティブに補正を行っていく仕組みを実装しないと安定した動作は難しいのではないかと思います。
murata,katsutoshi said:
-
3
-
4
-
5
-
6
-
7
of 9 Next