キャチロボ The Minimalists 技術公開記事

目次

• はじめに
• ハード
• 回路
• ソフト
• チーム運営

AIによる要約

本記事は、第15回キャチロボバトルコンテストに出場したチーム「The Minimalists」による機体設計・開発の記録です。
コンセプトは「最小限で勝ち切るロボット」。XY方式と比較して軽量・シンプルな構成を実現できるRθ方式を採用し、主要機構を最適化しました。

• ハード面では、流用部品と3Dプリンタを活用しながら、メインアームにアブソリュートエンコーダを搭載してバックラッシュを補償。伸縮機構にはフレキラックを導入し、軽量アルミ角柱で強度を確保しました。また、最速アームには真空ポンプ＋ソレノイドの吸着機構を採用し、3.4秒での3ワーク回収を実現しました。

• 回路面では、Raspberry Pi Pico 2を中心にマイコン・通信・電源を一体化した基板を設計。LEDインジケータやシルク印刷でデバッグ効率を高め、PCBAサービスで短納期かつ低コストの実装を実現しました。

• ソフト面では、R/P軸それぞれにS字軌道生成・フィードフォワード・PD制御・外乱オブザーバを組み合わせた加速度制御を実装。システム同定により慣性パラメータを推定し、4kHz制御周期を達成しました。RP2350のデュアルコアを活用し、SPI直叩きによるCAN通信高速化など、組込み環境での最適化も行いました。

• チーム運営では、設計・製作のレビュー文化を確立し、依存関係に基づくタスク管理を導入。ハード／回路／ソフトの全てでレビュー体制を構築し、品質と効率の両立を目指しました。

本記事では、これらの工夫を「ハード」「回路」「ソフト」「チーム運営」の4章に分けて整理しています。汎用的に応用可能な技術や運営手法も含めて記載しているため、他のロボコンやロボット開発に取り組む方の参考になれば幸いです。

※ここで紹介する内容はすべて実践記録であり、同じ方法で必ずしも正常動作を保証するものではありません。試す場合は自己責任でお願いします。

はじめに

第15回キャチロボバトルコンテストに「The Minimalists」というチームで出場した機体の記録です。できるだけ汎用的に活用できる技術や考え方をまとめました。ここで紹介している内容はあくまで記録であり、同じように試してもうまく動作しない場合や故障する場合があります。その点については自己責任でお願いします。

ハード

目的・要件 （こあ2ー）

今回の機体は「ミニマムなスタイルで優勝できるロボットを作る」という方針で設計しました。XY方式とRθZ方式を比較したところ、XY方式は精度が高い一方で構造が大きく重くなりやすく、自由度が増えるリスクもありました。Rθ方式は軽量でアクチュエータ数を抑えられ、今回のフィールド条件にも適していたため、今回はRθ方式を採用しました。

全体構成（こあ2ー）

ロボットはRθ型メインアーム、シューティング機構、妨害機構、最速アームで構成しました。手先自由度を減らすことで軽量化と制御性の向上を図り、戦略的には共通エリアの掌握を前提としました。

メインアーム（こあ2ー）

メインアームは昨年度のRθロボットの機構を流用し、開発コストを削減しました。θ回転部はM3508モータと40:120のギアを組み合わせ、大径ベアリングを用いた支持構造を採用しました。ギアは昨年POMをCNC加工して製作したものを再利用しました。本来であれば歯数は互いに素であることが望ましいですが、加工コストの観点から流用しました。位置制御性能を向上させるため出力軸にアブソリュートエンコーダを設置し、バックラッシュの影響を低減しました。効果は未知数ですが、出力部にダブルベアリングを組み込むことで、回転軸のブレ抑制を図っています。

R方向の伸縮については、昨年度の多段タイミングベルト機構を廃止し、フレキラックによる直動機構を新たに採用しました。M2006モータで駆動し、同軸に設置したマルチターンのアブソリュートエンコーダ（AMT223D-V）で位置を取得しています。高速動作時にエンコーダ軸の滑りが発生したため、接着剤で固定しました。CNC加工環境が使えなかったため多くの部品を3Dプリンタで製作しましたが、7月の完成から大会終了まで故障せず安定して動作しました。変形の許容度から、伸縮アームの構造材には15×30mmのアルミ角柱を使用しました。特に、断面二次モーメントの観点から角柱の高さを確保することで、重力方向への強度を優先的に確保しました。

シューティング機構（こあ2ー）

シューティング機構は今回の開発の中で特に工夫が必要だった部分です。手先の自由度をできるだけ減らす方針としたため、ワークの向きを調整する機能をシューティング側に持たせる必要がありました。当初は単純なワーク立て機構を検討しましたが、干渉や可動範囲の制約により実用化は困難でした。最終的にはスロープにワークを落とす方式をベースに、安定性確保のため小型サーボSG90を用いて最終位置を決める構造としました。全てのサーボを同じ動作にすることで、PWM一本で制御可能となったため、GPIOリソースの逼迫した状況で有効でした。

最速アーム（ハード担当のひとり）

機構要件

キャチロボでは共通エリア進出のため、自陣ワークを3つ回収する必要があります。本機構はこの3つを最速で取得することを目的としました。構成は根元部、昇降部、ハンド部に分かれます。

根元部

θ軸方向に回転するサーボモータを採用。ベアリングが1つのみの場合、片持ち構造となり剛性が低下するため、2つ距離を取り配置することで剛性を向上させています。

昇降部

ラック＆ピニオン機構を用いた機構を採用しました。

ハンド部

吸気ポンプとソレノイドを用いた吸着機構。位置誤差を許容するため爪機構を開発した。爪は床との接触を利用してアクチュエータなしでワーク位置を受動的に補正できます。

モータ選定

手先の質量を質点として考えると、根元モータに必要なトルクは、目標角加速度とアーム全体の慣性モーメントから算出されます。アーム自体を一様棒と仮定すると慣性モーメントIは以下で表されます。

I ＝ mL² ＋ \frac{1}{3}m’L²

目標角加速度aは運動方程式から算出される。これから必要トルク

τ＝I\ddot{\theta}

から求められる。
設計上必要なトルクは0.9N・mと見積もり、ストールトルク0.93N・mのDynamixel XC330-m288-tを採用しました。本来は安全率を考慮すべきですが、今回はハード要件を優先しました。

部品構成

サーボモータ2基、真空ポンプ・ソレノイド・吸着パッド各3基、昇降用角柱、3Dプリンタ製部品で構成しました。昇降用角柱を除く支柱はすべて3Dプリンタ材で代用し、軽量化を実現しました。強度面では当初懸念がありましたが、機構の質量を考慮すると十分な剛性を確保でき、実運用において問題なく機能することを確認できました。また、真空ポンプやソレノイドは根元に集約して配置することで、アーム先端の質量を抑え、慣性を小さくしました。

結果

動作結果としてはおよそ3.4秒で安定してワークを3つ取得することに成功しました。目標時間1.5秒にたいして時間が増加した要因としては、他機構との干渉をさけるため手先重心をアーム先端から離す必要があり、慣性モーメントが当初の想定より増加したためと考えられる。より速く、安定化を求める場合、安全率を十分にとったサーボの選定と手先の重心位置を寄せる必要があります。

回路（alicemagic）

概要

最小構成を目指し、マイコン・通信・電源管理を1枚基板にまとめました。JLCPCBで発注可能な10cm×10cmの2層基板で、部品はすべて表面実装かつJLCPCB Partsで入手可能なものを選定しました(大変カッコいい)。これで発注時にPCBAを選択すれば1週間ほどですぐ使える状態の基板が手元に届きます(大変嬉しい)。5枚中2枚のPCBAで送料込みの総額12,000円程度だったと思います。マイコンにはRaspberry Pi Pico 2を使用し、LEDインジケータやシルクでの役割表示を設けることでデバッグ効率を大幅に向上させました。
インジケータとして多数のLEDを配置し、それぞれの状態をシルクで明示しました。例えば「5Vが出ていないと点灯しない」「ポンプが動作中は点灯する」「マイコンのプログラム異常時に点灯する」といった具合に、動作状況を一目で把握できるようにしています。これによりソフト班のデバッグ効率が大幅に向上しました。さらに、マイコンのGPIO端子の近くには各ピンの役割を示すシルクを記載し、配線や開発時の利便性を高めています(こだわり)。

構成

基本的にPicoのGPIOですべての入出力を管理し、SPIでエンコーダやCANコントローラと通信、UARTを半二重変換してDynamixelを制御しました。

電源管理

非常停止スイッチで電源を遮断できるようにし、パワーMOSFETを利用して開閉しました。バッテリ電圧はPicoで監視しました。非常停止スイッチは2直列にしていて、機体と手元の両方のスイッチがオンにならないと機体が通電しないようになっています。しかしこれだけだとデバッグ時に面倒なのでソルダジャンパもついてたりします。24Vから5Vへの降圧はROHMのDCDCリンクを使ってます。電流をまあまあ引き出せてなおかつJLCPCBに在庫がある中で一番料金と性能の両天秤を取れる場所にいるのがこいつでした。とはいえ、Dynamixelの性能を最大限に引き出すため、現地入り後に外付けのDCDCコンバータを付け直したりしてるのですが……。

各部との接続とコネクタ

電源線にはXT60とXT30、信号線にはPAとXHを主に使っていました。PAの強みは抜き差しがしやすいことと線材間の接続用のシリーズ(PAL)が存在することだと思います。ただ圧着の難易度がやや高く従って信頼性に悖る場合があるのでなんとも……。
SG90サーボの配線が長く、挙動が不安定になり、即席でコンデンサを追加して対応しました。

開発体制について

先輩(いなみん)と私(alicemagic)で設計を行っていました。互いに密に連絡を取り合いながらレビューと再設計を何回か繰り返し完成まで持っていきました。勝手知ったる面々だったので非常にやりやすかったです。レビューに関しては下のほうで別の人が詳しく書いてくれてますのでそちらもどうぞ。

ソフト

今回の書いたコードはここで公開しています。

メインアーム制御（いなみん）

エンドエフェクタを一つに制限したため、40個のワークを180秒で集めるためには単純計算でひとつあたり4.5秒以下でとる必要がありました。高速に動かすため以下のブロック線図で制御しています。項目ごとに詳細を書きます。

S字軌道による軌道生成

次の目標点が決まったら、回転軸（以下R軸）・水平軸（以下P軸）でそれぞれS字軌道を生成します。最初は台形制御を用いていましたが、最後止まる時にカックンブレーキのようになったので、S字軌道に変更しました。実装コストを鑑みて、停止時のみS字軌道でそれ以外は台形制御になっています。

フィードフォワードによる制御

運動方程式に基づき、最適な経路を通過するのに必要な加速度から電流指令値を計算しています。

PD制御による誤差補正

現在の位置とS字軌道で本来通るべき位置の差分をPD制御で補完しています。D項は微分が必要になるのですが、エンコーダで取得される位置は離散値なので、不完全微分を入れてます。この時の不完全微分器のカットオフ周波数は3600rad/sとしました。制御周期の1/10を目安に振動的になる直前の周波数を採用しました。Pゲイン、Dゲインは以下の式を満たすように設定し、

Kp = \omega_n^2 ,\quad
Kd = 2 \omega_n

その上でハンドチューニングにより調整しています。PゲインとDゲインを掛けた後に、慣性の変動に対応するため、慣性を掛けています。

外乱オブザーバ

後は加速度制御を成立させるために残りの誤差を外乱オブザーバで補償しています。ギアのバックラッシュの影響が増幅されない範囲でフィルタのカットオフ周波数を決定しています。システム同定の時に得られた応答から今回使用するトルクの振幅で2Hz以上だと応答が異常に悪化することがわかっていたので、R軸は6rad/sとしました。P軸は振動的になる直前まで上げて40rad/sとしました。

システム同定

ここまでのフィードフォワード・PD制御・外乱オブザーバのすべてで、慣性パラメータを利用しました。慣性の推定には以下の手順を取りました。

1. チャープ信号の入力
   実機で、ハードが物理限界に達しない範囲の適切な振幅で、0.2〜4 Hz のチャープ信号をトルク指令値として入力しました。
2. 角加速度の算出と推定
   そのときの角加速度を計測し、最小二乗法によりパラメータを推定しました。
3. 物理モデルの構築
   • R軸：純慣性モデル
   • P軸：慣性＋粘性摩擦モデル
     としました。これは信号特性や機構構造から妥当と判断しました。
4. P軸長さに応じた慣性の変化
   R軸はP軸の長さに依存して慣性が変化するため、P軸長を100 mm単位で変化させ、同じ信号を印加して以下の式で同定しました。

   J(x) = I + m(x - c)^2

（(J(x))：慣性、(I)：変動しない慣性、(m)：可動部質量、(x)：現在のP軸長、(c)：重心位置）
5. 安全対策
安全のため、(J(x)) の値は適当な値でクランプして制御に用いました。

なお、ギア効率やトルク定数などは厳密に求めるのが難しいため、実機データをもとに最終的に物理モデルを再現することが重要です。

制御周期

加速度制御の実装において制御周期は最重要と考え、開発を進めました。R軸・P軸ともに 4kHz制御 を達成し、高精度な動作を実現しました。デュアルコアマイコンを用い、片方を制御専用としたことも大きく寄与しています。制御周期のボトルネックはシリアル通信ですが、エンコーダをSPI、モータをCAN で分離することで通信遅延を最小化しました。

組込みプログラム（けー）

マルチコアによる役割分担

Raspberry Pi Pico 2（RP2350）が持つデュアルコアCPUの性能を最大限に引き出すため、役割に応じて処理をコアに分割しました。

Core 0 (タスクコア): 軌道計算、シリアル通信、ハンドや妨害機構のシーケンス管理など、重いが周期性が厳密ではない処理を担当させています。
Core 1 (制御コア): 周期性が厳密に要求されるモーター制御や状態フィードバックの取得に専念させています。これにより、安定した4kHzの制御周期を実現しました。

コア間の通信には、FIFO（First-In, First-Out）キューと、共有メモリ上の状態変数を保護するためのミューテックス（mutex）による排他制御を組み合わせて使用しています。これにより、リアルタイム性を損なうことなく、安全なデータ共有を実現しました。

SPI通信の高速化による制御周期の向上

RoboMasterモーター制御にはCAN通信が必須ですが、RP2350にはCANコントローラが内蔵されていないため、SPI接続のCANコントローラIC「MCP25625」を採用しました。
当初はPico SDK標準のSPI関数を利用していましたが、ラッパー関数のオーバーヘッドが原因で制御周期は3kHzが限界でした。そこで、SPIペリフェラルのレジスタを直接操作する低レベル実装に切り替え、ボーレート切り替えなどを最小限の命令で実行できるようにしました。その結果、SPI通信のオーバーヘッドを大幅に削減し、制御周期を 4kHz まで向上させることに成功しました。

組込み環境における計算処理のTips

高速な制御周期を維持するため、計算処理に関してもいくつか工夫をしています。組込み開発では常識的なことかもしれませんが、特に意識した点です。

浮動小数点数の型を意識したコーディング

C++では、1.0のように記述した小数は倍精度浮動小数点数（double型）として扱われ、演算コストが高くなります。RP2350に載っているFPUでは、単精度（float型）の計算は高速でできますが、倍精度の計算は遅いです。そのため、1.0fのように末尾にfを付けてfloat型のリテラルとして明示的に扱うことを徹底しました。

除算から乗算への置換

一般的に、マイクロプロセッサにおいて浮動小数点数の除算は乗算に比べて数倍から数十倍のサイクル数を必要とします。そのため、ループの中のx / 2.0fのような処理は、あらかじめ逆数を計算しておきx * 0.5fのように乗算に置き換えることで、わずかですが計算負荷を削減するよう努めました。

制御ループ内でのシリアル通信（printf）を避ける

printf関数などを使ったシリアル通信は、デバッグには非常に便利ですが、非常に重い処理です。4kHz（0.25ms）のような高速な制御ループ内で安易に呼び出すと、それだけで処理時間が周期をオーバーしてしまい、制御が破綻する原因になります。今回のプロジェクトでは、デバッグメッセージの出力を管理するDebugManagerクラスを作成し、必要な情報だけを一定周期で表示することで、制御への影響を最小限に抑えました。

コンパイル時計算の活用 (constexpr)

C++のconstexprキーワードを使うと、変数の計算をコンパイル時に行えます。これにより、プログラム実行時には計算結果の数値が既に埋め込まれている状態になるため、実行時のCPU負荷をゼロにできます。ギア比や制御ゲインなど、プログラム実行中に変化しないパラメータは積極的にconstexprで定義しました。

コード管理まわり（けー）

これまで参加してきた学ロボでは、実機で動作確認ができればそのままマージする文化があり、コードレビューは徹底されていませんでした。その結果、コード品質が個人のスキルに依存し、チーム全体の技術力向上にはつながりにくいという課題がありました。そこで今回は、コード管理の方法を見直し、品質と効率を高めるためにいくつかの工夫を導入しました。

コードレビューの徹底

動作するコードでも、潜在的なバグや改善点が隠れている可能性があります。そのため、読みやすさや実装の妥当性といった観点から相互レビューを実施し、品質向上とバグの早期発見を図りました。特に、制御理論が絡まないシーケンス管理などはメンバー間で暗黙知が共有されにくいため、レビューが理解促進に役立ちました。

ただし、コードレビューは時間と労力がかかります。そこで、GitHub CopilotにPRをレビューさせたうえで、人間のレビューを行う方式を採用しました。Copilotが概要やアルゴリズムの指摘をまとめてくれるため、その後のレビューが効率的になりました。

CIによるビルドチェック

手元の環境ではビルドできたのに、他の環境ではエラーになるといった問題を未然に防ぐため、CI（継続的インテグレーション）を導入し、コードがプッシュされるたびにビルドチェックが自動で実行される仕組みを構築しました。
正直なところ、今回は少人数チームでビルドシステムも比較的シンプルだったため、CIの恩恵を最大限に受けられたわけではありませんでした。RP2350のような組み込み開発の環境を、CIの実行環境（GitHub Actionsが提供するUbuntuの仮想マシン）上でゼロから構築するのは、思った以上に手間がかかります。
特にロボコンのような短期間のプロジェクトでは、CI環境の構築に時間をかけるべきか、その時間で他の開発を進めるべきか、導入の是非はチームの状況に合わせて慎重に検討する価値があると感じます。
とはいえ、この仕組みはチームの規模が大きくなったり、プロジェクトが複雑化したりした際には、コードの品質を担保する上で不可欠なものになります。将来的なプロジェクトへの良い布石となりました。

チーム運営（いなみん）

コンセプトの明確化

昨年の反省を踏まえ、今回はコンセプトを明確に設定しました。大掛かりな機構を作ったものの十分に動作できなかった経験から、「最小限で勝ち切れるロボット」 をテーマとしました。チーム名「The Minimalists」もこの方針に由来しています。

レビュー文化の確立

機体完成度を高めるため、タスクを問わずレビューを行う文化を確立しました。ハード・回路・ソフトそれぞれに2人以上対応可能なメンバーがいたため、必ず誰かがレビューできる体制を整えました。スケジュールにはレビュー工数も組み込み、品質を担保しました。ハード・回路・ソフトでそれぞれレビュー項目を作り、可能な限りレビューの品質を担保しました。
レビュー項目は以下の通りです。

• 全体：目的が明確か、実行可能性、共有状況、時期の妥当性、内容の十分性、使いやすさ
• 機構：干渉有無、可動域、剛性、整備性、配線・配管経路
• 回路：電圧・電流の妥当性、端子・線材の選定、保護回路、実装可能性、情報の十分性
• 制御：モジュールの機能を満たしているか、単体動作確認済みか、入力出力が明確か

設計レビュー・製作レビューの2段階に分け、CADや回路ソフト、単体モジュールでの確認のステップを踏むことで手戻りを削減を実現しました。

タスクの共有

タスク共有にはスプレッドシートを用いました。タスク固有の締切は設けず、依存するマイルストーンを明確にし、それぞれに目標日程を設定しました。依存関係をすべて記入し、被依存数を算出することでタスクの重要度を統計的に評価しました。この方法により、主観に依存しない重要度の管理が可能になり、面白い取り組みだったと感じています。レビュアーも明示して、レビューの形骸化を防ぎました。

情報共有

定例ミーティングは設けず、設計方針など重要案件があるときのみ臨時で実施しました。連絡にはLINEを使用しました。友人同士のチームという背景もあり、LINEで十分でした。

総括

コンセプトの明確化やレビュー文化の確立といった点では、少し硬いマネジメントを取り入れましたが、タスク・情報の共有では緩いコミュニケーションを大事にしました。メンバーにとって居心地が良く、自発的にのびのび作業できる環境を整えるという目的は達成できたかなと思います。