Ardupilot的なフライトコントローラーをRaspberry Pi Picoで自作した話¶
こんにちは。しろうです。おひさ。
これはpyspaアドベントカレンダーの16日目です。なお、この記事にはチェックも含めて一切AIを使っていません。
https://adventar.org/calendars/11686
3行まとめ¶
Raspberry Pi Pico 2 W で動くよ。 Embedded Rust + Embassy で書いたよ
と言っても、ほぼ全てをAIに書いてもらったよ。最近のAIはすごいね
レポジトリは pico_trail 。
今の規模感は以下のとおり。docs以下が結構多いけど、後述するTDLのおかげでなんとかなってる感じ。
src以下 30000行 (ユニットテスト込み)
docs以下 75000行
きっかけ¶
最近Ardupilotをいろいろ触っています。と言っても、空飛ぶドローン(UAV)のためではなく、地上や水上ドローン(USV)だったりしますが。
しかし、Ardupilotは互換品も含めて、買うと結構高い。趣味でやる分には400Hzで姿勢制御とかそんな高性能なものは不要なので安くできないかなぁって思ってました。てか、むしろ自分で作れるんじゃね?って思ってるけど、いや、おれ電子工作全く分からないし…って。そんなところで、なんとなくAmazonを見てたらこの 「Freenove Raspberry Pi Pico W 用 4WD カーキット 」というものが目に入った。
電子工作やったことないので、そもそもなにが必要なのかとか配線とか全然全く分からないのだけど、キットならばおれにもできそう、安いし、って思ったのがきっかけ。
まずはこれを見てくれ¶
Mission Planner でRaspbery Pi Pico 2WにUDPで接続し、BluetoothのJoystickで車をマニュアル操作してるところ。もちろん元キットにはこんな機能はまったくない。
本当は自動航行までやりたかったけど、GPSを乗っけて緯度経度を取るところまでしかできていない。あともう少しなので、冬休みの宿題かな。
Mission Planner画面がこのスクショ。位置情報に加えてバッテリー情報も取れてるし、ARM/DISARMもできる。また、GUIDED Modeという、指定した位置まで自動でいけ、ということまで指示できる(まだ自動で動くところまではできてないけど)。
なお、位置情報だけどスクショに載ってるのは実際に実験している場所じゃないよ。OFFSETを環境変数で指定してビルドすると、すべての緯度経度がその分ずれるというプライバシー保護機能がある。こんな不要な機能まで実装しちゃえるのが自作の良いところ。
ハードウェア¶
上の動画ではブレッドボードがそのまま載せられたあられもない姿になっているけど、本来はこんなかっちょいいキットなんです。顔付いてるし。
このキット (セールで6300円)に加えて以下を買った。全部で1万5000円ぐらい。
Raspberry Pi Pico 2 W (2680円)
Ali ExpressでGPSモジュール (2000円)とIMU(9軸高精度加速度計) (670円)
モノタロウ で電池と充電器
電池はAliでは買いたくなかったので
4726円
ブレッドボードとか
I2CとかPSIとかUARTとか、全然知らないのでなんじゃらほいと思いながらいろいろ調べつつ買った。
組み立て¶
写真取るの忘れてたけど簡単。ただ、説明書で組み付ける順番がちょっとおかしいので、一回モーターを全部はずしてやり直したりした。はんだ付けは一切必要なし。差し込んでネジ止めするだけでできる。電子工作初心者でもできた。
組み立ては このページ に載っている。配線図も載ってるので、GPSモジュールとIMUを後付で載せるためにずっとにらめっこしてた。
ということで、今の形はこちら。ブレッドボードが直でつけられたり、なぜか垂直にGPSモジュールがくっついてたり、なんて醜い姿に…配線がびよーんとなってるけど、そのうちなんとかする。あと、IMUはまだ使えてないので配線してない。なお、ブレッドボードは100均の耐震ジェルマットでくっつけてる。これでいいのかは分からない。
AI駆動開発¶
実装言語として Tiny go という案もあったけどEmbedded Rustにした。Rustは文法を一通り学んで2chのAAをクロールして収集するツールを書いたぐらいしか勉強したことがない。そんなんで実装できるのか?と思う人もいるのだろうけど、Claude Codeを始めとする最近のAIコーディングの進歩は凄まじく、プロンプトを書くだけで実装が出来上がっていくのです。
TDL¶
といっても、無秩序にプロンプトを書いていくとすぐに破綻するのはこれまでの短いAIコーディング経験上明らか。
佐藤太一さんの 実践AI駆動開発 に感銘を受けて、Traceable Development Lifecycle (TDL) を使わせてもらっています。具体的には kopi で使用されているtdl文書テンプレートをちょっと変えたりして使わせてもらっている。
TDLに従って、Analysisをしろ、RequirementやADRを作れ、Taskを作れ、実装しろ、とかプロンプトに入れていくだけで実装が出来上がってくる。
各フェイズで必ず出来上がってきたドキュメントを読んで承認するのがポイント。本来はドキュメントにはコードを含めないほうが良いという話だけど、まあ趣味だしいっかってぐらいでゆるくやってます。眠いときはno look approveしてるし。
また、各文書間がリンクされているのが非常にいい。タスクを実装していて、あれ?これ違うんじゃね? と思ったら、Analysisまで戻って修正しろ、ということがリンクを辿ることで簡単にできる。リンクを辿るということは、余計な文章まで探しに行く必要がない。 つまり、コンテキストの消費が少ないということだ。素晴らしい。
上記の資料ではdocs以下は3万行とのことだったけど、こちらは7万5千行。それでも今のところあんまり破綻していないのはTDLとrustのおかげだと思う。もうちょっと大規模になるとまた変わるかもしれない。
AI駆動開発とRustの相性の良さ¶
Rustは難しい言語とされている。「難しい」というのは概念が理解できなくて「コンパイルできない」ということだったりする。しかし、それのおかげもあってか、コンパイルができればちゃんと動くし、できない時のエラー表示が非常に丁寧。つまり、エラーを見るだけで問題が解決できるということ。これが非常にAIコーディングと相性が良い。Task文書を作り、「そのとおりに実装しろ」と書くだけであとは、実装してエラーがなくなるまでひたすらコンパイル & 修正をしてくれる。そして、エラーがなくなったときは動くときだ。これが素晴らしい。
このあたりは AI駆動組み込み開発における「Rustの必然性」 という記事にも言及されてたりする。
ハードウェアはつらい¶
今までほとんどソフトウェアだけをやっていて、ハードウェアの開発ってほぼしたことなかった。
ソフトウェアは計算機の中で完結する。テストも楽だ。でも、ハードウェアだとそうもいかない。ファームウェアを書き込むにはリセットボタンが必要なので、物理的に手を伸ばして押す。やり直したらまた押す。大変。(ラズパイpicoをもう一つ買ってdebug probeも作ったんだけど配線上の問題で使えなかったのだ)
そもそも自動での統合テストができない。「Joystickを上に動かしたらモーターが回ること」を自動でテストするのなんて(趣味レベルでは)無理。そりゃMavlinkメッセージを送るとかはできるけど、じゃあそれで本当に動くの？とか考えるとテストは手動でやるしかない。温かみのある手動CD/CIだ。
そんなことはハードウェア屋さんにとっては当たり前なんだろうけど、自分で作ってみて実感した。やっぱり自分でやることが大事。
まとめ¶
ハードウェアはつらいけど楽しいね。「モノ」が絡むものはまだしばらくはAIにはできなさそう、と思う。まだもうちょっとこの分野でソフトウェアしかできないおれができることはあるだろうな、という感覚はある。本当にそうかは知らないけど。
明日は Yoshifumi YAMAGUCHI さんの「バイクの話」です。おれも昔はバイク乗ってたなぁ。250ccのSPADAというやつ。でもこの15年以上乗ってないので話を聞くのはとても楽しみです。
Comments
comments powered by Disqus