2024-05-25

RoboCupジャパンオープン2024に出場してきた(後編)

RoboCup ジャパンオープン2024に出場記の後編です。

前編では大会一日目までの話を書いたが、1勝2分けの好発進で2日目のCompilationErrorとの試合で引き分けに持ち込めれば得失点差で決勝リーグに進めることがわかっていた。

hans-robo.hatenablog.com

4/28 （大会2日目）

朝

今日は決勝リーグ進出がかかった大切な試合！

”Keep programming!”
”Programmer, never sleep”

午前2時：4/28 by HansRobo · Pull Request #332 · ibis-ssl/crane · GitHub
- 1日目に修正した変更をマージ
- ZJUNLict戦でのPK戦不具合の修正
午前4時：
StealBallスキルの復活 by HansRobo · Pull Request #337 · ibis-ssl/crane · GitHub
- エラーを吐いていて使っていなかった相手のボールを奪う動きのバグを修正
- 結局GitHubCopilotの出力したコードをそのまま使ったのがバグの原因だった
午前5時：
SimpleKickoff実装 by HansRobo · Pull Request #338 · ibis-ssl/crane · GitHub
- 1日目にキックオフの動きがおかしかったのでシンプルなものに変更した
午前6時：
ボール先回り by HansRobo · Pull Request #339 · ibis-ssl/crane · GitHub
- フィールド外に出そうなボールの先回りをするプログラムを実装

ホテルの朝ご飯が始まった瞬間に凸して会場出発までの時間を睡眠にあてた。

アドレナリンで眠くはないが流石に寝ないと死んでしまう。

CompilationError

実は前日にチームリーダーのお兄さんと仲良くなっていたCompilationErrorとの対戦。ここで引き分けに持ち込めれば決勝リーグに進出できる。
絶対勝ちたいと思う一方で、勝ち進めると4徹目が確定するので流石にちょっと...という気持ちもあった。

流石ZJUNLictに勝ったことのあるチームだけあって、試合中のボール支配率はCompilationErrorの圧勝で、きれいなパス回しを見せていた。

一方で、ibisのデフェンスもよく動き、徹底的なマンツーマンマークとゴール前の壁の構築でシュートチャンスをよく潰していた。

しかし、前半終了間際に遂にibisは初失点を喫する。
それもディフェンスに戻ってきた味方ロボットが押し込むカタチのオウンゴールで....
せめてバシッと決められたかった...

youtu.be

一方で、色々とこれまで調整してきた甲斐があって、実装した動きが思い通りに動いている場面も多く見られた試合になった。

徹夜で実装したボールの先回りは、割とうまく動いていたようだ。

youtu.be

また、ゴール前でのパスを検知したらパス先のロボットを特定した上で守備に回る、という動きをゴールキーパーに入れていたのだが、この試合中にその動きを実際に見ることができた。

動画を見ても「ボールを追いかけているだけじゃん」とピンと来ない人もいると思うが、ボールとほぼ同じ速度でゴールキーパーが動く、という動作はボールを追いかけているだけでは絶対に実現できないものなのだ。大会サーバー側での認識遅れ・AI内での遅れ・ロボット側での司令を受けてから動き出すまでのハードウェア的な遅延を考えると、どうしてもボールに対して1テンポ・2テンポ遅れてしまうのが現実だ。

youtu.be

結局、動画では相手のシュートが外れる形で終わるが、これもゴールキーパーが圧をかけていてミスを誘った結果だとも解釈できるので狙い通りではある。

ところどころ良い動きを見せたものの、結局試合状態は変わらず、0-1で敗北に終わってしまう。

若干の悔しさはあるものの、やれることは全部やって今のibisの全力が出し切れていたこと、SSL未経験者チームの初出場にしては十分すぎるほどの試合結果だったこと、そして何よりようやく寝れることもあって安堵の気持ちが大きかった。

試合後、CompilationErrorのお兄さんと健闘を称え合ったあと、お兄さんがドリブラの構造や調整シーンを見せてくれた。

ドリブラの後ろにはバネやダンパがあるわけではなく、スポンジが配置されていて衝撃を吸収しているらしい。

このスポンジをハサミでカットして入念に調整を行うようだ。どうやら日本のフィールドは海外のフィールドと比べて摩擦係数が違うのかかなり調整には苦労したよう。

強いドリブラの秘訣の一つは、F1マシンのタイヤのようにドリブラを超高速回転させることで摩擦熱でドリブルバーのラバーを溶かして粘着させることにあるんだとか....なんじゃそりゃ.........

道理でドリブルするときの音が全然違ったわけだ....

審判3

すべてを終えたので、メンバーには寝てと言われたがアドレナリンがバシバシで眠くなかった。
審判関連の仕事は他のメンバーがやってくれた。
ロボコン時代の同期と後輩が来ていたので久々に立ち話をしていた。

審判4

Roots vs KIKSの試合の主審を担当した。
正直あまり記憶が残っていないので多分問題なく進んだのだろう。

4/29 （大会3日目）

大会期間内初めてのまともな睡眠！
気持ちの良い目覚め！
軽い心！
スッキリとした頭！！！

審判5

主審担当。
この日ある決勝戦と3位決定戦はibisとRootsさんが審判担当になっていたが、初出場のチームに決勝戦の主審は酷だということでRootsさんが先に決勝戦の審判に立候補して頂いたようだ。
ありがたい限りである。
3位決定戦は中国チーム同士の対決なのでコミュニケーションは英語。

大会結果

決勝までが終わり、

1. RoboDragons
2. KIKS
3. ZJUNLict
4. Compilation Error

という結果になった。

ibisは順位こそ出ていないものの、5位か6位くらいだと思うのでよくやったと思う。

練習試合（Roots）

全試合終わったあとの時間は練習時間に当てられるのだが、迷わずRootsさんに練習試合の対戦をお願いした。

ibisのAIであるcraneはRootsさんが公開しているconsai系ソフトウェアにめちゃめちゃお世話になっており、Rootsさんのソフトウェアを見てSSLを学んだと言っても過言ではない。
リーグが違って対戦が叶わなかったので、日頃の感謝を込めた正拳突きである。
なぜか、ibisのAIが大会サーバーからの司令を受け取れず、かなりグダグダになってしまった。（大会中に発生しなくて良かった.....）

この試合でもゴール前パスに反応するゴールキーパーを見ることができた。

youtu.be

この場面ではパスに失敗しているが、他の試合を見ている感じではRootsさんのゴール前のパスは昔よりかなり洗練されて来ている印象なのであとでソースコードを見て勉強させてもらおうと思う。

練習試合（KIKS）

光栄なことに、KIKSさんから練習試合のお誘いを頂いた。

時間は1枠しかないのでRootsさんとの練習試合を早めに切り上げて後半はKIKSさんとの練習試合にあてた。

相変わらずibisのAIの不調が続き、グダグダな試合進行。

中でも嬉しかったのは以下の場面。少しズルい状況からスタートするのだが、両チームインプレイの状態でゴールの端を狙ってゴールを決めることに成功する。

もちろん、これはあくまでも不公平な状態からスタートしているので現状の実力を反映したものではないのだが、それでもこの状況でしっかりゴールを決められることが確認できた意義は大きかった。

youtu.be

来年の大会では正々堂々、正式なゴールを決めにいくぞ！

最後に

チーム結成から6年弱、出場までにコロナの影響を受けたり、研究で忙しくて全く進捗が出なかったり、そもそもあまりSSLに対してモチベがなかった期間もあった。

それでも、こうして大会出場に漕ぎ着けることができて本当に嬉しい。

大会期間中は本当に楽しくて、身体的にはかなり無理をしてしまったがアドレナリンと脳汁がドバドバでやめられなかった。後悔はしていない。

これだけの大会デスマーチに耐えられる体力はもう無いんじゃないかと思っていたので、自分でも少し驚いているというのが正直なところだ。

デスマーチはやらないに越したことはないが、ここぞとやりきれる体力はこれからも頑張って維持したいと思う。

大会を経て、ibisのできていること・できていないことが沢山判明したので来年の大会までにはしっかりと対策をして上位チームと互角に戦えるところまで持っていきたいところだ。

来年の大会には強くてニューゲームな新チームも現れるようなので非常に楽しみである。

SSLをやっていて本当に良かった。

SSL最高！

2024-05-13

RoboCupジャパンオープン2024に出場してきた(前編)

ibisというプライベートチームでRoboCupのJapanOpen2024の車輪小型リーグに初参戦してきました。
色々と書いていたら長くなってきたので、とりあえず前編を出します。

この記事はソフトウェアの視点から書きますが、メカ班視点の記事はこちらに manjuu.hateblo.jp

開発習慣などの記事はこちら

hans-robo.hatenablog.com

※この記事は最大3徹状態の記憶が含まれます。事実と異なった記述があればこっそり教えてください。

4/25（移動日）

仕事を終えて荷造りをして新幹線で滋賀へ向かう。

荷造りすっぞ！！！ pic.twitter.com/CHoh4cBlAx
— ハンス (@Hans_Robo) 2024年4月25日

ホテルについたら、実家に泊まると言っていたはずの他のメンバーに遭遇した。
なんでやねん。

大会前の最後の追い込みが始まる――――

休むのはロボットに任せて頑張るぞ pic.twitter.com/hTNch0t821
— ハンス (@Hans_Robo) 2024年4月25日

”Keep programming!”
”Programmer, never sleep”*1

4/26（準備日）

この日は大会の準備日。最低限の動作確認は完了させたい。

チームリーダーのくじ運が悪すぎてラスボス引いてウケる（ウケない）

デビュー戦は世界最強クラスのチームが相手らしいです。
助けて https://t.co/ihvWMYtMBy
— ハンス (@Hans_Robo) 2024年4月26日

でもやるしか無いので、徹夜で頑張るしか無い！

ちなみに、この日もフィールドを使って練習できる時間があったのだが、チームリーダーは一番最初を枠を引いてきた。
つくづくくじ運の悪い男だ。もっと準備時間をくれ。

”Keep programming!”
”Programmer, never sleep”

4/27（大会1日目）

激動の一日だった。この日は3試合をこなしたほか、主審もやった。

ZJUNLict戦

YouTube配信

www.youtube.com

初戦なこともあり、かなり違反が多くて相手には申し訳ない試合になってしまった。
一方、ロボットは基本的に調子よく動いていて一安心した。
世界大会優勝経験のある強豪ということでボコボコにされるだろうと身構えていたが、調整不足のようであまり振るわない動きをしていた。

調整時間中も「キッカーが蹴らないんだけど」「ごめん、OFFになってた」みたいな基本的なやり取りが聞こえていた気がするので研究室の新入生なのかもしれない。

もちろん、基本押され気味ではあるのだがデフェンスがよく動いていてなんとかしのいでいた。
あと、相手がダイレクトシュートのチャンスを幾度か見逃していたのも気になった。
世界大会ではダイレクトシュートコースが空いているなんていうことは基本ないので、考慮されていないのかも？（それマジ？）

多すぎるファール

試合進行上、ロボットが入ってはいけないエリアがあるのだが、エリア回避の動作でロボットの半径分の考慮をすっかり忘れていて、ギリギリエリアに侵入してしまうということを繰り返し、かなりの数のファールを記録した。

また、敵のフリーキックなのに味方ロボットが突撃してしまい、違反を取られるというハプニングも発生した。そのようなプログラムを書いた覚えはなく、毎回再現するわけではないので迷宮入りしてしまう。結局、原因判明は夕方のRi-one戦を待つことになる。
結局、この試合でファール66回・イエローカード3回を記録するが、初出場のチームにしては少ない方らしい。

ペナルティキック

デフェンスエリアから脱出中のロボットがボールに触って蹴ってしまうハプニングがあり、ペナルティキックとなった。ペナルティキック中、関係ないロボットはボールから1m以上下がらないといけないというルールがあるのだが、誤ってロボットのディフェンスエリア回避をONにしてしまっており、デフェンスエリアに引っかかって盛大に相手PKを邪魔してしまうというやらかしをしてしまった。当然PKはやり直しになったが、相手がボールにバックスピンをかけすぎてPK失敗判定が下り、九死に一生を得た。（SSLのPKでは相手ゴール方向以外へボールを進めてはいけないというルールがあり、バックスピンでボールが戻るだけでPK失敗となる）

PKが終わったところで試合時間オーバーで試合終了。
なんと、強豪相手に引き分けに持ち込むことができたが、前述の通りかなりファールをしてしまっているのでなんとも申し訳ない感じになってしまった。　　

審判1 (Sasa-kamati vs Roots)

RoboCupの大会では、参加チームが持ち回りで審判をやる。
それは初参加の我々とて例外なく回ってくる。
審判は毎試合2チームが担当し、メインとサブのチームにそれぞれ役割が割り振られる。
このときはサブのチームに割り当てられた。

サブのチームの仕事内容

チームから2人出す必要があり、それぞれ「Assistant Referee」「Vision Expert」を担当する。

「Assistant Referee」
主審の補助をする役職だ。
具体的には判定が難しいときに主審の相談相手になったり、ボールを手動で動かす必要があるときにパシられる役になったりする。

「Vision Expert」
天井のカメラ画像からロボットの位置などを計算し、各チームへ情報を送る「SSL Vision」というソフトウェアの面倒をみる役職だ。
通常、この役職は暇なことが多いが稀にロボットが認識されなくなったりするので、そのときにパラメータの調整などを行って改善する。

審判2 (KIKS vs RoboDragons)

遂にやってきた審判のメイン担当回。
メンバーはそれぞれルールを読んで来ているものの、日々ルールを違反しないようにソフトウェアを書いている自分が一番ルールを把握しているだろうということで、主審は自分になった。
ただ、この初主審のこの試合、相手が悪かった。
対戦するKIKSとRoboDragonsは世界大会常連の日本の2TOPである。
当然試合状況は目まぐるしく変化するし、両チームとも試合慣れしていて、少しでも怪しい判定をすると容赦なくチャレンジカードを切ってくる。
良い経験にはなったが気疲れがすごかった。

GreenTea戦

YouTube配信

www.youtube.com

GreenTeaは我々ibisより後に設立されたチームだが、一足先に大会に出場するようになった先輩チームだ。
メンバーのバックグラウンドがibisと似ていることもあり、メンバーには知り合いも多い。
出場する前から煽り合っており、ぜひボコボコにしたい相手だった。

次のRCAPに出場した暁には某緑茶に勝って公式戦初勝利するんだ…
— ハンス (@Hans_Robo) 2021年11月27日

ぼこぼこにしてやるZE☆（）
— しゅねーてっく (@MakerSchnee) 2021年11月27日

しかし、試合が始まってみると絶望的に試合が進まない。致命的に相性の悪いのだ。結果は0-0で引き分け。
次こそは！待ってろ、GreenTea！！

致命的に相性の悪い相手

コート中央付近で戦っている分には問題はないのだが、一度コートの角に入り込むともうだめだ。
一度ゴールキックで角に入るといつまで経ってもそこから抜け出さないのだ。
角にほとんどのロボットが固まっているせいで、パスを出そうにも角、フィールド外に出てもゴールキックで角、と試合が全く進まない。途中、仕方がないのでタイムアウトを取って、ゴールキーパーのパス先を強制的にフィールド中心に変更してからかなりマシになったようにも思うが、結局時間内に得点変化はなく引き分けに終わった。

怪しくなってくるキックオフ

パラメータチューニングの副作用なのか、このGreenTea戦あたりからキックオフ動作が怪しくなっていた。キックオフで蹴る直前にウェイポイントを置いているのだが、そこに到達する前に止まってしまい、いつまで経っても到達判定が出ずにキック動作に進めずキックオフができないのだ。

修正できた大量ファール

ZJUNLict戦で問題となった大量ファールは修正が間に合ったので、かなり減らすことができた。
基本的にこの手のファールはロボット同士がぶつかったり、立入禁止エリアに侵入してしまうことで発生する。
前者はロボットのスピードを落としたりして付け焼き刃の対策しかできなかった。
一方、後者についてはibisのソフトウェアでは立ち入り禁止区域をGridMapで保持しており、その設定を少し変えるだけで対応できた。
ちなみに、この試合ではGreenTeaよりもファール数が少なかったようだ。

この試合ではかなりGreenTeaのロボットに邪魔されることが多かったですが、しっかり障害物回避を効かせてエレガントに避けているのが見れてよかったです。 youtu.be

Ri-one戦

YouTube配信

www.youtube.com

Ri-oneもまた我々ibisより後に設立されたすごいチームだ。

新参ながらすごいチーム、Ri-one

これがまたすごいチームで、ibisがうかうかしている間に世界大会に出場して3位の成績を収めている*2。
ibisが泥仕合の末、引き分けになってしまったGreenTeaも過去の大会では10-0でボコボコにしたこともある。 RoboDragons・KIKSに続き、Rootsと同じかそれ以上に強くて新参チームの中では頭一つ抜けたチーム、というのが個人的なRi-oneのチーム評価だったのでibisも欲張らず「勝てたらラッキー」くらいに考えていた。

しかし、今大会ではどうしたことか、ロボットに何やら問題があるらしく大会前から連日徹夜している様子。

3年目にしてヤバイチーム、Ri-one

聞くところによると、新機体の開発に伴って既存のロボット全てが動かなくなる変更をしたらしい。
どうしてそんなことになったか分からないが、初出場のibisよりも遥かに大変そうで大変そうだった（語彙力）

試合ができるか心配だったが、なんとか間に合ったようで、ibisとの対戦の時は多少怪しい動きもありつつも動いているようで一安心。

ちょっと動きの怪しいチーム、Ri-one

ロボットの調子が悪いのかソフトウェアの不具合なのか見分けがつかなかったが、それなりに動き出してからも少し怪しい動きをしていた。
ディフェンスエリアからボールを排出する動きがなかったり、ボールプレイスメントを邪魔したりと、ソフトウェアもリビルドされてルール対応がリセットされてしまっているのかも？と感じた。

ibisもibisでソフトウェアの状態遷移がうまく行かず2回ほどタイムアウトを取っている。

また、この試合は通信トラブルの多い試合であった。

通信トラブルとibisロボットの暴走

試合途中でGameControllerが混線して試合進行が止まるハプニングがあったが、配信解説担当によるとこの手のネットワークトラブルはこれでもかなり今年は少ないらしい。

試合開始後、しばらくするとibisのロボットが暴走を始める。何が起こったのかと調べてみると、ロボットまでのpingが1秒を超えている。どうやら、隣のブースのRi-oneとWiFiアクセスポイントのチャンネルが被っていて、ibisのAPが競り負けていたようだ。 Ri-one側ではチャンネル変更ができないということで、ibis側がチャンネルを変更し、事なきを得た。（自分の記憶では書いたとおりなのだが、配信解説では別リーグのAPと混線しているという説明がなされていて、真相は結局わからない）

初得点！！！！

通信トラブルから明けた直後に、なんとibis始まって以来初めての得点を決める！
しかも完璧なパスシュートで！！もう脳汁ドバドバ。

配信の奥の方をよく見ると、確かにフリーキックからのパスシュートをしているのがわかる。

youtu.be

怪しいキックオフ

ところで、Ri-oneもキックオフができないことが多々あり、GreenTea戦からキックオフ不調なibisと相まってどちらもキックオフができない奇妙な試合となった。最後の方には、キックオフできないので強制開始コマンドでスタートするなど中々カオスになっていた。

通信が改善されてからはibisはよく動き、1点目ほどエレガントではないものの追加で2得点を決めることができた。
結果は0-3で初勝利！！
Ri-oneさんの調子が悪かったとは言え、勝利は勝利。
長年の悲願だったので嬉しさがこみ上げてくる。

また、本調子になったRi-oneさんと来年の大会で戦いたいものです。

このRi-one戦での得点を稼いだせいで、明日のCompilationError戦で同点に持ち込めば決勝進出できるらしい。これは徹夜で頑張るしか無い！

”Keep programming!”
”Programmer, never sleep"

交流会

実はRi-one戦の裏でお寿司を食べながらSSL交流会が開催されていたらしい。
試合が終わって急いでいくと、試合をしていた我々の分はちゃんと残されてありました。優しい！

初勝利直後のお寿司ほど美味しいものはない....

交流会ではibisのロボットが大人気でした。

夕方のSSL交流会でibisのロボットが大人気でした。
興味を持っていただいた皆さんありがとうございました！
大会後にSSL semiの発表をはじめとしたアウトプットをしていこうと考えているのでお楽しみに！！#ibis_ssl pic.twitter.com/VP2AUwwTLh
— ibis (@team_ibis) 2024年4月27日

後編に続く...

*1:https://spiralray.sakura.ne.jp/blog/archives/1024#:~:text=%E2%80%9DKeep%20programming!%E2%80%9D%0A%E2%80%9DProgrammer%2C%20never%20sleep%E2%80%9D

*2:2つあるリーグのうち、魔境ではない方のリーグでの成績。それでも設立数年のチームがこの成績を収めるのは驚異的なことと言えよう

2024-05-05

社会人になってロボコンに出場した

RoboCupの日本大会であるRoboCup Japan Open 2024に出場した。活動自体は学生の頃からやってきたが、社会人になってからのほうがうまく立ち回れたと思うのでそこらへんについて少し書こうと思う。
再現性は保証できないので、参考程度に読んでもらえると良いかも知れない。

大会の振り返りについてはまた別に記事を書こうと思うが、忘れていても怒らないでほしい。

チームについて

ibisというプライベートチームに所属している。

www.ibis-ssl.tokyo

RoboCupは成り立ちがアカデミアなこともあり、全体的に研究室チームが多いが、サッカーの小型車輪リーグはロボットの製作費が安い（ほんまか？）こともあって近年日本のプライベートチームが増えている。そんな中、ibisは2018,19年頃に設立された。当時学部4年くらいだったが、コロナや半導体不足、研究など色々なことがあって、正直あまり開発が進まなかった期間も長かった。でも、社会人になって進捗のリズムをうまく掴み、今回のJapanOpen2024に向かって着実に進捗を積み重ねることができた。チームメンバーは、社会人が継続的な趣味進捗を生み出すことの難しさ、趣味活動におけるモチベーションの重要性を深く理解してお互いに敬意をもって活動している。進捗をだすとエラいと言ってもらえる心理的安全性と、確かな技術を背景として上を目指していけるポテンシャルのある素晴らしいチームだと思う。

大会結果について

1勝1敗2分けで予選落ち。ただ、初出場にも関わらずほぼ不具合なしで、自分たちの思うような動きをして大会に切り込めたのでとても満足。日本ロボット学会賞もいただけて、自己肯定感アゲアゲ。

RoboCup Japan Open 2024のサッカー小型・車輪リーグで日本ロボット学会賞をいただきました！
今後のさらなる飛躍を期待されているので、期待に応えるべく今後も活動していきます！#ibis_ssl pic.twitter.com/reyhTZMWvi
— ibis (@team_ibis) 2024年4月29日

表彰状に「大会を席巻する可能性を示しました」って書かれるの気持ちよすぎる。

さて、以降はこの結果に繋がった個人的な趣味開発体制について書いていく。

持続的開発

大会参加が決まるまでは正直漫然と開発しているところがあり、ルールへの準拠が全くできていなかったり重要なところに結構穴があったりした。しかし、いざ大会に参加するとなるとそうも言ってはいられない。 AI班（に限った話ではないが）は1人しかいないため、まず大会までのロングスパートをかけることにした。テーマは「持続可能な開発」である。瞬間風速は高くても続かなければ結局開発時間の総量は減ってしまう。人員が自分しかいない現状に対し、相手は明らかに1人で開発するには大き過ぎるソフトウェアである。したがって、とにかく長期的に見て開発時間の総量を増やす必要があった。

朝型開発

まず、始めたことは生活を朝型に直すことである。それまでは夜に開発をしていたが、その時間を朝に移動した。夜、つまり仕事のあとは仕事の疲れから休みたくなってしまったり、夕食の血糖値スパイクにやられてしまうことも少なくない。また、一日の終わりなので、仕事中にあれやりたい、これやりたいとやりたいことが溜まったり買い物に洗濯など家事で時間がなくなってしまうこともあった。これは自分が悪いのではなく、人間なら仕方ないよね、と開き直った上でたどり着いた答えが朝型開発である。朝早くに起きて、最低限の身支度をし、近くのカフェに開店凸する。そこで朝食を採った後、PCを開いて3時間ほど作業をして、時間になったら家に帰って仕事をする。正直、これが本当に続くのだろうか？と思ったのだがこれが意外と続いたので自分でも少し驚いた。

この生活はSSLの活動以外にも良い影響があった。今まで、勤務時間の少し前に起き出して仕事をすることが多かったが、午前中はあまり脳が覚醒しておらずパフォーマンスが悪かったようである。しかし、朝型生活を始めてから午前中に頭がハッキリするのが自分でもよく分かった。これならもっと早く始めておけばよかった。ただ、朝型だと午前にかなり活動しているので昼頃には少し疲れて来る。これに対しては昼休みに昼寝を挟むことで午後からもパフォーマンスを保つことができた。

仕事を終えた後の時間も精神的にかなり自由になった。朝に進捗を出してしまっているので、家事に時間が取られてしまっても焦ることはないし、ゆっくりリラックスしても罪悪感に苛まれることもない。ジムに行って運動不足を解消したり、さらに追い進捗を積み重ねることもできる。

計画的な開発

こうして開発習慣が身につき、また一つ良いことが起きた。計画的な開発とタスクマネジメントが出来るということである。

今までは、開発時間の絶対総量が足りなかった。そのため、タスクマネジメントをしようにも、「タスクマネジメントしている時間があるならさっさと進捗出さんかい！！」となるわけである。趣味開発あるあるである。

しかし、開発時間の量が増えてくるとその壁を打ち破れる日がやってくる。逆にタスクマネジメントをして計画的に開発をしないと統率が取れなくなってきたとも言える。自分の場合は発生したタスクは全てGitHubのIssueに登録し、タスクの取捨選択・スケジューリングをして取り組んだ。今までGitHubのモバイルアプリは2段階認証専用アプリだったのだが、タスクをすべてIssue化するようになってからはタスク管理アプリへと変貌を遂げた。

Issue化したタスクは、GitHubのProjectでガントチャートの如く計画を立てて実行した。正直、Projectはやり過ぎだと思うが、それでも2ヶ月くらいは続けることができた。

github.com

うちのチームの場合、大会に出場することにしてから1,2ヶ月に1回くらいの頻度で自分の家に集まってロボットを動かす練習会をすることになっていた。これが開発を引き締める良い締切になり、「次の練習会であれをやるんだ！」とモチベーションの面でも良い影響があった。

今後について

大会出場をきっかけに持続的な趣味進捗を生み出せる習慣が身についたのは大きな財産だと感じている。ただ、ここに書いたことは仕事があまり忙しくないことであったり、在宅勤務・フルフレックスで働けることなどそれなりに多くの条件がそろって成り立っていることも同時に理解している。朝型生活以外の部分に関しては、今後の状況に応じて変えていこうと思っているところである。

現状考えていることをいくつか書いてこの記事を終わりにする。

Projectでガントチャートを組むのはやり過ぎなのでやめる。趣味なのに義務感が出てくるので良くなかった。
GitHubのIssueのタスク管理では、ラベルを使った優先度管理を始めようと思っている。
大会でのデスマーチを支える体力を維持したいので定期的な運動は欠かさないようにしたい。

2023-12-08

設定ファイルから見るLiDARシミュレータの世界

この記事はLiDAR Advent Calendar 2023の12/06分の記事です。

いろんなシミュレータのLiDARに関する設定ファイルの読書感想文です。

3D LiDARの簡単な分類

シミュレータの話に入る前に、一度シミュレーション対象であるLiDARをみておきましょう。ここでは細かな動作原理の違いを考えずに出力される点群の特徴をざっくりと捉えていきます。

回転式LiDAR

昔からよくあり、現在でも主流のLiDARの種類です。レーザーと受光センサのユニットを水平に回転させるため、水平360°にセンシングできることが特徴です。 1ユニットでは縦方向に視野を広げることができないため、ピッチ角を変化させた複数ユニットを用いることが多いです。垂直方向の点群密度を増やすにはユニットを増やす必要があるため、水平方向の点群密度に対して縦方向の点群密度は粗くなりがちです。

SolidState式LiDAR

回転式（機械式）と対比されることが多いSolidState式は機械的な可動部が存在しない（または小さい*1）LiDARの種類です。

回転式とは違って光源を動かさずに光を曲げたり加工したりして走査する必要があるため、回転式に比べて水平視野はどうしても狭くなります。一方で構造次第で垂直方向にも自由度を持てるので、垂直方向の点群密度を容易に上げることが可能です。カメラの画像のような縦横比がほぼ同じ解像度をもつLiDARが多いですが、独自のスキャンパターンを持つLiDARも少なくありません。

シミュレータ選手紹介

今回見ていくシミュレータの選手紹介です。オープンソースで提供されているもののみを対象としています。 3D LiDARは自動運転で使われることが多い関係上、自動運転向けシミュレータが多くなりました。

シミュレータ	概要
Gazebo	ROS向けデフォルトのシミュレータ
Choreonoid	産総研発の国産シミュレータ
UnitySensors	Unityでセンサをシミュレーションするためのシミュレータ、というよりはライブラリ?
CARLA	自動運転業界でデファクトスタンダードになっているシミュレータ
LGSVL	旧Autoware向け標準シミュレータ
AWSIM	現Autoware向け標準シミュレータ

各シミュレータの設定ファイル

一番最初に触れたように3D LiDARはそれぞれ独自の構成を持っています。 LiDARシミュレータで多くの種類のLiDARに対応するために、構造の違いをパラメータの違いで表現できるように一般化して実装されます。この構造の一般化方式が色濃く出るのがLiDARセンサのために設定ファイルです。
さぁ、設定ファイルからLiDARシミュレータの世界に飛び込んでみましょう。

※一部ソースコードも含みますが、一般化できていれば設定ファイルとして扱います。

Gazebo(Classic)

垂直・水平方向に過不足なく表現力を持ったフォーマットです。 LiDAR以外にも深度カメラでも使えるように配慮されたフォーマットのように思えます。

<ray>
  <scan>
    <horizontal>
      <samples>32</samples>
      <resolution>1</resolution>
      <min_angle>-3.14156</min_angle>
      <max_angle>3.14156</max_angle>
    </horizontal>
    <vertical>
      <samples>3</samples>
      <resolution>1</resolution>
      <min_angle>-0.02</min_angle>
      <max_angle>0.02</max_angle>
    </vertical>
  </scan>
  <range>
    <min>0.05</min>
    <max>70</max>
    <resolution>0.02</resolution>
  </range>
</ray>

Choreonoid

最低限のシンプルなパラメータで構造を表現しています。視野角を下限上限の2パラメータではなく角度の1パラメータで表現しているため、上方向などある方向に偏った視野をもつ3D LiDARを表現できないことに注意です。

yawRange: 180
yawStep:  0.4
pitchRange: 30.0
pitchStep: 2.0
scanRate:  20
maxDistance: 100.0

参考：URL

UnitySensors

このシミュレータは設定ファイルを持たず、それぞれのセンサーに専用実装を持っています。しかし、以下のように実質設定ファイルとなっている箇所もあります。

[SerializeField]
private RotatingLiDARScanPattern _scanPattern;
[SerializeField]
private float _minDistance = 0.0f;
[SerializeField]
private float _maxDistance = 100.0f;
[SerializeField]
private float _maxIntensity = 255.0f;
[SerializeField]
private float _gaussianNoiseSigma = 0.0f;

参考：URL

スキャンパターンは現状以下のようなものがサポートされているようです

名前	特徴
RotatingLiDARScanPattern	回転式LiDAR用の実装。垂直方向の角度は細かく設定できるようになっているのが特徴
CSVLiDARScanPattern	CSVファイルからスキャンパターンを読み込む。Livoxのような複雑なパターンも再現可

CARLA

回転式LiDARに特化した設定ファイルとなっています。回転式以外の表現は難しいですが、流石自動運転向けと言ったところで大気減衰率やドロップオフ（点群の消失）に関するパラメータが充実しており、天候によるLiDARセンシングの変化もシミュレーションできるようになっているようです。

Blueprint attribute	Type	Default
`channels`	int	32
`range`	float	10.0
`points_per_second`	int	56000
`rotation_frequency`	float	10.0
`upper_fov`	float	10.0
`lower_fov`	float	-30.0
`horizontal_fov`	float	360.0
`atmosphere_attenuation_rate`	float	0.004
`dropoff_general_rate`	float	0.45
`dropoff_intensity_limit`	float	0.8
`dropoff_zero_intensity`	float	0.4
`sensor_tick`	float	0.0
`noise_stddev`	float	0.0

参考：URL

LGSVL

こちらも回転式LiDARに特化した設定ファイルになっています。カスタムLiDARでは一様にならないことも多い各センサーの垂直方向の角度は細かく設定できるようになっているのが特徴で、形状の表現力としてはCARLAよりも上になります。

Name = "Lidar32-NonUniform",
LaserCount = 32,
MinDistance = 0.5f,
MaxDistance = 100.0f,
RotationFrequency = 10, // 5 .. 20
MeasurementsPerRotation = 1500, // 900 .. 3600
FieldOfView = 41.33f,
VerticalRayAngles = new List<float>
{
  -25.0f, -1.0f, -1.667f, -15.639f,
  -11.31f, 0.0f, -0.667f, -8.843f,
  -7.254f, 0.333f, -0.333f, -6.148f,
  -5.333f, 1.333f, 0.667f, -4.0f,
  -4.667f, 1.667f, 1.0f, -3.667f,
  -3.333f, 3.333f, 2.333f, -2.667f,
  -3.0f, 7.0f, 4.667f, -2.333f,
  -2.0f, 15.0f, 10.333f, -1.333f
},
CenterAngle = 10.0f,

参考：URL

AWSIM

UnitySensorsのCSVLiDARScanPatternに似てレーザー一本一本を設定することができます。注目すべきはtimeOffsetでタイミングのズレを設定できるところです。 UnitySensorsも同じく任意形状のスキャンパターンを設定できますが、時刻の設定ができないためLivoxのようなレーザーが一本しかないLiDARしか表現できません。一方で、AWSIMは複数本のレーザーを持つLiDARはもちろんの事、フラッシュ式のようなタイミングが特殊なLiDARに対する表現力を持っています。また、この設定項目があるということは、スキャン中にセンサーが移動することによる点群の歪み*2もシミュレーションできるのかもしれません。

public static LaserArray VelodyneVLP16 => new LaserArray
{
    centerOfMeasurementLinearOffsetMm = new Vector3(0.0f, 37.7f, 0.0f),
    focalDistanceMm = 0.0f,
    lasers = new[]
    {
        new Laser {verticalAngularOffsetDeg = +15.0f, verticalLinearOffsetMm = +11.2f, ringId = 0, timeOffset = 0.0f },
        new Laser {verticalAngularOffsetDeg = -1.0f, verticalLinearOffsetMm = -0.7f, ringId = 8, timeOffset = 0.002304f },
        new Laser {verticalAngularOffsetDeg = +13.0f, verticalLinearOffsetMm = +9.7f, ringId = 1, timeOffset = 0.004608f },
        new Laser {verticalAngularOffsetDeg = -3.0f, verticalLinearOffsetMm = -2.2f, ringId = 9, timeOffset = 0.006912f },
        new Laser {verticalAngularOffsetDeg = +11.0f, verticalLinearOffsetMm = +8.1f, ringId = 2, timeOffset = 0.009216f },
        new Laser {verticalAngularOffsetDeg = -5.0f, verticalLinearOffsetMm = -3.7f, ringId = 10, timeOffset = 0.011520f },
        new Laser {verticalAngularOffsetDeg = +9.0f, verticalLinearOffsetMm = +6.6f, ringId = 3, timeOffset = 0.013824f },
        new Laser {verticalAngularOffsetDeg = -7.0f, verticalLinearOffsetMm = -5.1f, ringId = 11, timeOffset = 0.016128f },
        new Laser {verticalAngularOffsetDeg = +7.0f, verticalLinearOffsetMm = +5.1f, ringId = 4, timeOffset = 0.018432f },
        new Laser {verticalAngularOffsetDeg = -9.0f, verticalLinearOffsetMm = -6.6f, ringId = 12, timeOffset = 0.020736f },
        new Laser {verticalAngularOffsetDeg = +5.0f, verticalLinearOffsetMm = +3.7f, ringId = 5, timeOffset = 0.023040f },
        new Laser {verticalAngularOffsetDeg = -11.0f, verticalLinearOffsetMm = -8.1f, ringId = 13, timeOffset = 0.025344f },
        new Laser {verticalAngularOffsetDeg = +3.0f, verticalLinearOffsetMm = +2.2f, ringId = 6, timeOffset = 0.027648f },
        new Laser {verticalAngularOffsetDeg = -13.0f, verticalLinearOffsetMm = -9.7f, ringId = 14, timeOffset = 0.029952f },
        new Laser {verticalAngularOffsetDeg = +1.0f, verticalLinearOffsetMm = +0.7f, ringId = 7, timeOffset = 0.032256f },
        new Laser {verticalAngularOffsetDeg = -15.0f, verticalLinearOffsetMm = -11.2f, ringId = 15, timeOffset = 0.034560f },
    }
};

参考：URL

最後に

本当はもっと色々なことを書こうと思っていたのですが、想像以上に長くなりそうだったので別の記事に分けようと思います。それではまた次の記事で。

*1:これをSolidStateに含めるかは会社や文献によりまちまちです。小さい可動部が存在する広義のSolidStateLiDARと差別化するため、True-Solid-Stateを名乗るLiDARもあります

*2:イメージし辛い方はカメラで発生するローリングシャッター現象のLiDAR版、と言えば分かるでしょうか？いや、もっと分かりにくいか...

2022-12-15

ディープラーニングとやらの力をお借りして喋らせるやつの力をお借りして喋るROS2パッケージをババーっと作った

この記事はROS2アドベントカレンダー2022，12/14（つまり昨日）の記事です．

ROS2のカレンダー | Advent Calendar 2022 - Qiita

遅れてすみません．

はじめに

ロボコンに出ました．ロボットを喋らせました．

Unfortunately our robot could not restart for the last challenge of WRS FCSC Trial at #IROS22, because of a damaged power line. We are glad to have the opportunity to demonstrate our manipulation system at the exhibition.

Many thanks for cheering our challenge! pic.twitter.com/VKpUuG2hCQ
— Cross Progress (@CrossProgress) 2022年10月26日

これはこれでロボットらしくて良かったです．

でも大会終わって思ったんですよ，もうちょっと流暢に喋らせたいなって．

で，作りました．

ディープラーニングとやらの力をお借りして喋らせるやつの力をお借りしてしゃべるROS2パッケージを！

github.com

今回はこれを作った話について書こうと思います．

下調べ

まず，今どんな喋るROSパッケージがあるのか調べてみました．
ロボコンで使ったのはこれです．お世話になりました．

github.com

知り合いが作ってるパッケージも見つけました．

github.com

よく見たらこちらの方が少し世に出たのが早いんですね．
きっと作者の方は思ったのでしょう，「なければ作れば良いのでは」と

他にも色々見てみましたが，バックエンドがespeak系だったり最近のイケてそうな声が出せそうなROS(2)パッケージはありませんでした．

なければ作れば良いのでは

という訳で僕も作り始めました．

バックエンドはVOICEVOXを使うことにしました．
VOICEROIDやVOICEPEAKも見ていたんですが，せっかく作るからには色々な人に使ってもらえるようにしたかったので有料の壁はやっぱり高かったです．（ごめんなさい）

その点，VOICEVOXは無料しかも商用利用可でここまで高品質な話し声を出せるのは素直にすごいと思いました．（ちゃんとマネタイズできてるのか気になってくる社会人1年生であった）

voicevox.hiroshiba.jp

探していると，なんとDockerコンテナも提供されていてなんとまぁ使いやすいことでしょう！

https://hub.docker.com/r/voicevox/voicevox_engine

共通化

早くパッケージを作りたい気持ちを抑えて，ふと思いました

GitHub - ActiveIntelligentSystemsLab/japanese_tts_ros: 日本語テキストを音声として出力するROS node
GitHub - hakuturu583/openjtalk_ros: ros bridge for openjtalk

はじめに出てきたこの2つのパッケージ，めちゃめちゃ似ているんですよね．

よく考えたらそれもそう，音声合成で喋らせるROSパッケージって

合成音声エンジンに音声合成をさせる
出てきた音声ファイルを再生する

をやっているだけなんですよね．

このまま，僕が上の2つのパッケージを参考にしてまた似たようなパッケージを作ってもいいかもしれません．

でも基本のところが同じなら1つのパッケージで色々な合成エンジンを切り替えられると楽しいんじゃないかと思ったわけです．

プラグイン化計画

さて，色々なエンジンを切り替えるとなると，まずは各エンジンに対して音声合成させる部分をプラグインに切り出す．

そして，共通処理を扱う母艦プログラムを作れば，あとは母艦プログラムに好きなプラグインを差し込めばいけそうな気がしてきました．

イメージはこんな感じ

という訳でできたのがこちら！

github.com

設計は甘いとは思いますが，なにせ基本の音声合成の手順が単純なのでこれでも色々な音声合成エンジンに対して簡単にプラグインを実装できるようになったのではないかと思います．

OpenJTalkプラグイン

母艦プログラムができてもプラグイン実装がないとこのプログラムは喋りません．

まずは試しにOpenJTalkのプラグインを作ってみました．

github.com

自分が作ったプログラムを通して聞く音声はなんだか少し温かみがある気がしました（寝ろ

VOICEVOXプラグイン

さて，待ちに待ったVOICEVOXプラグイン．
遠回りが過ぎましたが準備はバッチリであとはこれを実装するのみです！

VOICEVOXはどうやらDockerコンテナを立ち上げると，HTTPのAPIサーバーが立ち上がってそれを叩けば音声合成ができるようです．

今回はC++でプログラムを作るのでMicrosoftのC++ REST SDKというライブラリを使ってAPIを叩くことにしました．

github.com

このライブラリのクセがなかなか強くて途中ちょっと苦労もしましたが，無事出来上がったのがこちらです！

github.com

おお，喋る！！
実装終わったのは昨日(12/14)の夜，それも仕事のミーティングが長引いて疲れ果てていましたが，流石にちょっと感動しました．
（その後，頭の死んでいた僕はTwitterのTLに流れて来るツイートを読ませてひとしきり遊びました．）

このリポジトリのREADMEだけはしっかりと書いたので是非みなさんも試してみてください！

あ，ROS2 Humbleでしか動作確認していないので気をつけてくださいね．

動かなかったりしたらIssue・プルリク待ってます．

最後に

ふとした思いつきをババーっとプログラム書いて，ババーっとこうして記事に書きましたがやっててとても楽しかったです．
こんな雑な記事を書くのもはじめてでしたが，こういうスピード感ある記事執筆もアドカレ感が出ていいなと思いました．

プログラムは色々雑ですが，それでも基礎部分は割といい感じに設計したつもりです．これからも雑な部分は少しづつ直していこうと思いますので，使ってみたり，別のプラグイン作ったよ〜って人は是非教えてほしいです．泣いて喜びます．

2022-12-01

ROS2でヘッダファイルのインストール先が変わったらしい

※この記事はCalendar for ROS2 | Advent Calendar 2022 - Qiita，2日目の記事である
※である調で書いてしまったので文章が多少高圧的に感じられるかもしれないがご容赦願いたい

ROS2 Humbleを早々と試している人々の中には既に気付いている方もいらっしゃるかもしれない．
そう，ヘッダファイルのインストール先が変わっているのである！！

嘘だと思うなら下の画像を見て欲しい．

GalacticとHumbleでフォルダ構成が違うことが分かっていただけると思う． Galacticではstd_msgsフォルダの直下にmsgフォルダがあるのだが，Humbleではさらにもう一つstd_msgsフォルダを挟んでいる．

この記事では，この変更がどうして行われたかを解説していく．

読み進める人への注意 : この記事は要求される事前知識が多い割に読んで得られる知見は少ない．ROSの勉強にはなると思うが...

事前知識

記事を読み進める前に頭に入れておきたい事前知識たち．単語を見て理解できるなら飛ばしてもらって構わない．

マージインストール

詳細

コマンド

colcon build --merge-install

起こること

パッケージのインストール先が変わる例えば，ヘッダファイルのインストール先は以下のようになる

インストールの種類	ヘッダファイルのインストール先
通常	`colcon_ws/install/<package_name>/include`
マージインストール	`colcon_ws/install/include/<package_name>`

得られる効果

環境変数の汚染がマシになる*1

全パッケージのlibフォルダを環境変数に入れようとすると，通常インストールの場合では各パッケージにそれぞれに対して colcon_ws/install/<package_name>/libを追加する必要がある．しかし，マージインストールしているとcolcon_ws/install/libを追加するだけで事足りる．

因みに自分が確認した限りでは通常インストールで膨れ上がる環境変数は以下の通り

AMENT_PREFIX_PATH
CMAKE_PREFIX_PATH
PYTHONPATH
LD_LIBRARY_PATH

ワークスペースのオーバーレイ / アンダーレイ

詳細

Creating a workspace — ROS 2 Documentation: Galactic documentation

簡単に言うと，ROSのワークスペースが複数あって，両方で source path/to/setup.bash をした時，先にsourceしたワークスペースのことを「アンダーレイ」，後にsourceしたワークスペースのことを「オーバーレイ」と呼ぶ．

aptでインストールしたROSパッケージのバージョンが気に入らない時，手元のワークスペースにソースコードをcloneしてビルドすると思いますが，このような状況ではこの仕様がうまく働く．

もし，オーバーレイのパッケージが優先されない場合，オーバーレイである手元のワークスペースにソースコードからビルドしたにもかかわらず，アンダーレイにあるaptでインストールしたバージョンの使用を強制されるかもしれない．

何が問題だったのか？

ヘッダファイルのインストール先が変わる原因となる現象は下のIssueで報告されている． github.com

一言で言うと，「特定の状況でをファイルの参照先がおかしくなる」 のである．

特定の状況とは以下のようなものだ

システム以外にアンダーレイ / オーバーレイのワークスペースがある
アンダーレイ / オーバーレイのワークスペースに同じ名前のパッケージがある
アンダーレイでマージインストールを利用している

このような状況は特におかしなものではない．

特に，aptでインストールされる/opt/ros/humble以下のワークスペースはマージインストールと同じ状態になっており，aptでインストールしたパッケージをオーバーレイにクローンする

そして，ros2コマンドでアンダーレイ / オーバーレイ両方のワークスペースに存在するパッケージを呼び出しても，オーバーレイのパッケージが優先されることで解決されるはずである．

しかし，今回のIssueではマージインストールを併用した場合，オーバーレイが優先されなくなってしまうという報告がなされているのである．

詳しく

今回のバグを再現するために作られたリポジトリを簡素化して説明する

GitHub - jacobperron/overlay_bug_reproduction: Reproducing a dependency bug involving an overlay workspace

以下のような構成のワークスペースとパッケージを考える

それぞれのパッケージの情報として，パッケージの名前，パッケージのインクルードパス（パス），他のパッケージへの依存を書いている．

ここで，理想的な依存関係は当然こうなる

しかし，実際は以下のようになってしまうというのが今回の問題である．

では，どうしてそんなことが起こっているのか，更に細かく見ていく．
Dパッケージを中心に書くとこうなる

では，次にそれぞれがヘッダファイルを持っていると考えてコンパイラの気持ちになってみる．

d.hppは以下の手順でプリプロセスでインクルードが展開されていく

ここで，③のA/a.hppの展開を更に詳しく見てみる

まず，A/a.hppを展開するにはファイルがどこにあるか探すわけだが，コンパイラは依存パスを順番に精査していく．本来なら，オーバーレイのAパッケージがある~/ros2_ws/install/A/includeでA/a.hppが見つかって欲しい. しかし，依存パスの順番的に，はじめにアンダーレイの /opt/ros/humble/includeを探索するのだが，この配下にはA/a.hppが存在するため，間違ったファイルがヒットして展開なされてしまうというわけだ．

もちろん，ここでアンダーレイでマージインストールなされていなければ，Bのパスを通じて間違ったAのパスにつながることもないので問題は発生しない．

どう対策したのか？

対策の検討

問題に対して，OpenRoboticsのShaneLoretzs氏によって4つの対策案が挙げられています．

それぞれ簡単に紹介すると

①CMake でインクルードディレクトリを並べ替える
②ヘッダファイルを1階層深い場所にインストールする
③colconでパッケージの重複を検知してどうにかする
④colconでパッケージの重複を検知して知らせる（そして解決はユーザーに任せる）

といった感じになる．詳しくは原文を参照して欲しいが， ①③はかなり無理がある解決策で④は解決そのものを諦めている．

という事で，選ばれた②について説明していく．ちなみに，④も②の予防策として採用されることになっている．

選ばれた解決策

「ヘッダファイルを1階層深い場所にインストールする」とはどういうことかと言うと， CMakeLists.txtで

install(DIRECTORY include/ DESTINATION include)

と書いてヘッダファイルをインストールしていたところを，

install(DIRECTORY include/ DESTINATION include/${PROJECT_NAME})

と書いて更に1階層深い場所にインストールする，ということである．

そう，これこそがタイトルにもある「ROS2でヘッダファイルのインストール先が変わったらしい」と言うことである！！！！

では気になるのは，なぜこれが問題の解決策になるのか？ということであろう．

インストール先が変えることによる効果

まず，対策前後のアンダーレイにおけるマージインストールの結果を見ていこう

対策の前後がそれぞれ記事の冒頭に示した比較画像のgalactic/humbleのようになっていることがわかるだろう．

また，install文が変わったことによって，インストール先だけではなく，依存パスも変化する． Dパッケージの場合は次のように変化する．

赤太字で示した場所が変化点である．

この変更によって，問題の原因であった「Bのパスを通じて間違ったAのパスにつながる」ことがなくなったことにお気づきだろうか？

インストールする階層を1つ深くするだけでマージインストール時にもユニークなパスになるようにできるとはよく考えたものである．

解決策の実装

さて，この解決策というのは，アンダーレイのワークスペースに格納される可能性のあるパッケージに実装されなければならない．とりわけ，aptでインストールされて/opt/ros/humble以下にマージインストールされるros/rosdistroに掲載されたリポジトリ群は絶対にアンダーレイになってしまうわけで早急な実装が求められる．

かくして，ROSコミュニティの面々はひたすら解決策の実装に明け暮れるのであった...

ちょうど一年前の話である．

当時rollingだったそれらの解決策がマージされたパッケージたちは，humbleのパッケージとして世に放たれた．
マージから1年後，humbleでヘッダファイルのインストール先が変化したことに気付いた筆者はこうしてこの記事を書くことになったわけである．

*1:envコマンドで確認推奨

*2:これはオーバーレイされる順番にインクルード・ディレクトリをCMake上でソートすることによって実現されている，はず

2022-06-08

ROS2パッケージをリリースしよう！準備編

ROSのbloomを使ったパッケージリリースについてはネットに素晴らしい有用な記事があるのですが， GitHubの仕様変更やROS2の公式リリースリポジトリ置き場など，新しい部分については日本語情報が少ないので情報を残しておきます．

準備するもの

パッケージをリリースするには以下のものが必要です．

必要なもの	備考
GitHubアカウント	当然必要
GitHubアクセストークン	リリース用ツールに権限を与えるのに使います
リリースしたいROS2リポジトリ	これがないと始まらない
リリース用リポジトリ	作り方は2通り

GitHubアカウント，リリースしたいROS2リポジトリは当然あるものとして，残りの2つについて解説します．

GitHubアクセストークン

本来なら，パッケージのリリースではたくさんのGitHub上での操作を人間が手動で行う必要があります．
bloomはそんな大変な作業を人間に変わって自動でやってくれるツールです．
しかし，GitHub上での操作には認証が求められるため，ツールにアクセス権限を付与する必要があります．

また，近年GitHubではパスワードによる認証が禁止されたため，パスワードを求められた際にはアクセストークンを入力する必要があります．

詳しい作成方法はこちらです.

アクセストークン作成ページ　：　https://github.com/settings/tokens

アクセストークンには「repo」と「workflow」の権限を設定してください．

リリース用リポジトリ

パッケージをリリースするためにはソースコードが入ったリポジトリとは別に，<パッケージの名前>-release という名前のリリース用のリポジトリが必要です．
リリース用リポジトリの中身はパッケージの内容を基にbloomが勝手に管理するので開発者はリポジトリを作るだけでOKです．

リポジトリの作成場所ですが，自分の場所に作る方法・公式の場所に作る方法の2通りあるのでそれぞれについて説明します．

公式の場所に作る方法

公式のリリースリポジトリの置き場所がこちらです．

github.com

ここにリリースリポジトリを作る手順は以下のとおりです．

issueを立ててリポジトリの追加をお願いする
リポジトリが追加される

手順自体は簡単ですが，メンテナの方の対応を待たなければいけませんので，時間がかかることは理解しておいてください．
急ぎの場合は「自分の場所に作る方法」を検討するのも手です．

issueを立ててリポジトリの追加をお願いする

こちらのリポジトリにIssueを立てて，リポジトリ追加のお願いをしていきます．

github.com

Issueを追加しようとすると，3つのIssueテンプレートが現れるので，「New release team」を選択して次に進みます．

チーム名（英小文字とアンダーバーのみ）
リリースしたいリポジトリ
メンテナの情報

の3つの情報を埋めてIssueを立てられたらメンテナの人がリポジトリを作ってくれるのを待ちます．
Issueをどう書けばいいかわからない場合は過去のIssueを参考にしてみましょう.
例えば，自分が立てたIssueがこれです↓

github.com

大抵，1週間以内にメンテナ欄に追加したユーザーはOrganizationに追加され，チームの追加，空のリリースリポジトリの作成までをros2-gbpのメンテナの方がやってくださいます．

ここまで来たらようやく，リリースリポジトリの準備が終わりです．
最後に作業をやって頂いたメンテナの方への感謝を忘れずに！

自分の場所に作る方法

これはROS1のリリース用リポジトリと同じです．自分で好きなOrganizationなり自分のユーザーディレクトリなりに<パッケージの名前>-releaseという名前の空リポジトリを作るだけです．気軽にリリースしたい場合や，急ぎのリリースの場合はこちらの方が良いかもしれません．

作成したリリースリポジトリに`master`ブランチを作る

最近，GitHubではリポジトリを新規作成した時のデフォルトブランチは masterからmainに変わりました．しかし，bloomは古いツールなので，masterをデフォルトブランチとして扱うため，masterブランチの作成が必須です．

準備完了

これでリリースに必要なものは揃いました！
ということで，準備編はここまでです．

あとのリリースの手順は，GitHubのパスワードを求められた時にアクセストークンを入力するところ以外はネットにある日本語情報を参考にすると良いでしょう．
この記事は特に分かりやすくて良いですね!

qiita.com

気が向けば，リリース編も書こうと思いますが，期待しないでください．

参考

アクセストークン周りに関して

wiki.ros.org

公式の場所へのリリースリポジトリ作成に関して

docs.ros.org

4/28 （大会2日目）

朝

CompilationError

審判3

審判4

4/29 （大会3日目）

審判5

大会結果

練習試合（Roots）

練習試合（KIKS）

最後に

4/25（移動日）

4/26（準備日）

4/27（大会1日目）

ZJUNLict戦

審判1 (Sasa-kamati vs Roots)

審判2 (KIKS vs RoboDragons)

GreenTea戦

Ri-one戦

初得点！！！！

交流会

チームについて

大会結果について

持続的開発

朝型開発

計画的な開発

今後について

3D LiDARの簡単な分類

回転式LiDAR

SolidState式LiDAR

シミュレータ選手紹介

各シミュレータの設定ファイル

Gazebo(Classic)

Choreonoid

UnitySensors

CARLA

LGSVL

AWSIM

最後に

はじめに

下調べ

なければ作れば良いのでは

共通化

プラグイン化計画

OpenJTalkプラグイン

VOICEVOXプラグイン

最後に

事前知識

マージインストール

コマンド

起こること

得られる効果

ワークスペースのオーバーレイ / アンダーレイ

何が問題だったのか？

詳しく

どう対策したのか？

対策の検討

選ばれた解決策

インストール先が変えることによる効果

解決策の実装

準備するもの

GitHubアクセストークン

リリース用リポジトリ

公式の場所に作る方法

issueを立ててリポジトリの追加をお願いする

自分の場所に作る方法

作成したリリースリポジトリにmasterブランチを作る

準備完了

参考

作成したリリースリポジトリに`master`ブランチを作る