dronecodeのコーディングルールを拝見いたしました。
あまりにもざっくりしていることもあり、保守性や品質まではいき渡っていなさそうと感じています。
そこで、日本には、組み込み系ソフトについて、コーディングルールというのを事細かく定義してるものがあります。
例えば、
・MISRAとか
・IPAの「組込みソフトウェア開発向けコーディング作法ガイド[C++言語版]」や
・凡ミスによる障害の回避ルール
これらのルールをベースにArduCopterのコードの品質を上げていきたい。
また、その過程で、不安なコードがあれば、不安を軽減していきたい。
その情報や修正案などのアップしたいと思い、このディスカッションを立ち上げました。
何卒、よろしくおねがいいたします。
Replies
LOG_DISARMED=1 でARMする前からログが記録されると思います。
murata,katsutoshi said:
Pixhawkは時計用のバックアップバッテリーが無いので、これは仕方ないかなと思います。
murata,katsutoshi said:
室内で、電源を入れただけの状態「DISARMED」で、30分以上、放置していたらmission plannerの画面に「Bad AHRS」が表示されました。
再度、実施したところ、同じ30分ごろに、同メッセージが表示しました。
この現象は、すでに、DIYDronesで上がっていました。
AC3.3.3ではまだ解消していないような感じです。
ログ解析してみようとしたところ、ログファイルが作成されていませんでした。
電源を入れただけだとログファイルを作成するようになっていないのか、まだ、ソースの確認していませんが。。。
初期動作異常を解析するためにもログは必要と思う。
ログファイル作成のタイミングを調査します。
AC_PolyFence_loader.cpp の load_point_from_eepromメソッド、及び、save_point_to_eepromメソッドで、フェンスポイントYの取得/設定で、マジックナンバー「4」を使用しています。
これは、フェンスポイントXの次の位置、から取得、へ設定、するためにしている処理と思われます。
そこで、マジックナンバー「4」を使用せずに、sizeof(uint32_t)にすることで、保守性をあげたいと思いPR致しました。
Mission Planner で表示されるログ時間が時刻更新されるまで 2000/1/1 になっているようです。
この時刻設定について改善したいです。
この PR ソースに組み込まれました。(^^)
コメントありがとうございました。
===
このソースについてどのように値を確認したかをご紹介いたします。
SITLで値を確認するため、USB型プロポを使用しています。
シミュレートしながら値の確認ができます。
下記がその出力するための処理です。
1秒にしているのは、出力が遅いため、間引きしています。
static uint32_t before_time = 0u;
if((millis() - before_time) > 1000u) {
hal.console->printf("Drift target_roll=[%f]\n", target_roll); // TODO Debug
before_time = millis();
}
画像は、その値です。
murata,katsutoshi said:
branch/masterにコミットしちゃったので、ないものにしたかったんですが。。。
やり方の問題で、さらに悪化してしまいました。
今の状態からfork時の状態に戻せる知識がなく、レポジトリを削除して再度forkしました。
コメントやPRの仕方をググって真似て、再度、こちらをPRいたしました。
度数を100倍しているのでさらに細かい値が必要か?ということになりそうです。
murata,katsutoshi said:
ご提示いただきましたurlを参照して対処したいと思います。
今後もよろしくお願いいたします。
Goro Senzai said:
これに関しては、Pull Requestのコメントにも書かれていますが、複数箇所のコードを同時に変更しているため、Unrelatedと指摘されています。
Gitの作法に関しては、PRでもRandyさんやmagicrubさんが丁寧に説明してくれていますが、他のオープンソースコミュニティーと同じく、ArduPilotにも作法がありまして、Pull Requestに関しては:
- masterで開発せず、別の(develop)等で開発を行い、最新のmasterにrebaseしてからPRを投げる
- 同じモジュール・ライブラリー内の最小限の変更のみに留める(例えば、Copter, Plane, Roverで同じ変更があったとしても、それぞれ別のPRとして投げる)
- PRを投げる前に、必ず自分の環境でテストする
- 改行はLFを使う
- タブを使わずにスペース4つ
など、いろいろあります。
詳しくはこちらを読んでみてください。
http://ardupilot.org/dev/docs/contributing.html
特にこのページ:
http://ardupilot.org/dev/docs/submitting-patches-back-to-master.html
あと、PRのリストを眺めて、コメントを読んだり、複数モジュールの同一変更がどう分割されてsubmitされているのか等をみるのも参考になると思います。
では、めげずに頑張ってください!
murata,katsutoshi said:
Tom Pittengerさんから、「This PR contains unrelated changes」とコメントがありました。
この改善案は、fast_loop が2500usを超えた場合を想定しています。
そういうことが「無い」と断言できれば、不要な処理となります。
「無い」ってことですね。
不安が一つなくなりました。
murata,katsutoshi said: