総合制作の後半です。前の週（#F1）で、各自が自分のノードを記録データで検証しました。この週は、それをつなぎます。
つなぐ日は、たいてい一度ではうまくいきません。大事なのは、うまくいかなかったこと自体ではなく、どこで止まっているかを、どのツールで突き止めたかです。それが、このコース全体で身につけてきたことだからです。
この記事の位置
| 項目 | 内容 |
|---|---|
| コース | 延長コース F「総合制作」（2 週・回 F1〜F4） |
| この記事 | 第 2 週（回 F3・F4）。延長コースの最後です |
| 前に済ませておくこと | #F1（設計と単体検証） |
| ロボット | 回 F3 は机の上まで。回 F4 で先生の立ち会いのもと床で動かします |
この記事は延長コース Fの 2 回分（F3・F4）です。授業で受ける人は、記録を実習レポート（Word）の「回 F3」「回 F4」のシートに分けて書きます。スクリーンショットは、シートの中の「画面：」の欄（実験の表のすぐ下）に貼ります。延長コースのレポートは、コア（第 1〜12 回）とは別の 1 本にします。ファイルは Google Classroom で配られ、コースの最後に Google Classroom で 1 回だけ出します。期限は最後の実習から 1 週間後の 23:59 です。ひとりで学ぶ人も、予想と結果を同じ形でノートに残しておくと、あとで見返せます。
回 F3 つなぐ
この回は、班のノードをつなぎ、段階 1（記録データ）から段階 2（机の上）まで通します。
# つないだ形を、まず外から見る
ros2 node list
rqt_graph
ros2 topic list
# 期待した相手とつながっているか（1 本ずつ）
ros2 topic info -v /（つなぎ目のトピック）
| 打つもの | 意味 |
|---|---|
ros2 node list | 起動しているノードの一覧。班の全員のノードがそろっているかを数える |
rqt_graph | ノードとトピックのつながりを図で出す |
ros2 topic list | いま流れているトピックの一覧。設計シートにない名前が混ざっていないかを見る |
ros2 topic info -v /（つなぎ目のトピック） | そのトピックの型と、出す側・受ける側の数。片方が 0 なら、そこが切れている |
F3-1 まず外から形を見る
ここでは、動かす前に、つないだ形を設計シートの図と見比べます。
全員のノードを起動したら、動かす前に rqt_graph を見ます。設計シートの図と、実際の図を並べます。矢印が足りない、余計な矢印がある、名前が違う——ここで見つかるものは、動かす前に直せます。
F3-2 段階 1：記録データで通す
ここでは、記録を流して、上流から下流まで値が流れることを確かめます。記録の流し方は #F1 と同じです（ros2 bag play room_scan --loop）。止まっているところがあれば、上流から順に Hz を見て絞り込みます。
# 段階 2：机の上で、最後に出る指令を見る
ros2 topic echo /cmd_vel_test
# 流れが止まっている場所を探す（上流から順に）
ros2 topic hz /（知覚が出すトピック）
ros2 topic hz /（判断が出すトピック）
ros2 topic hz は、そのトピックが 1 秒に何回届いているか（average rate）を出し続けます。何も出ないまま止まっていれば、そのトピックには値が来ていません。Ctrl+C で止めて、次のトピックに移ります。
| 見る場所 | 出ているか | Hz | 止まっていたら疑うこと |
|---|---|---|---|
| 知覚が出すトピック | 入力（センサー）が来ているか | ||
| 判断が出すトピック | 型・名前の食い違い、条件が成り立っていない | ||
| 行動が出す指令 | 止める条件に引っかかったまま |
ros2 topic hz。3 つとも周期が出ていれば、鎖は端から端まで通っている
/go_stop と /go_stop_x が並び、/go_stop は Publisher count が 0、Subscription count が 1。受ける側だけがいて、出す側がいないと読める「動かない」を「どこで止まっているか」に言い換えるのが、この日の仕事です。使う道具は、コアの第 1 週から使ってきたものだけで足ります。
F3-3 段階 2：机の上で確かめる
ここでは、ロボットを机の上に置いたまま、出し先を /cmd_vel_test にして通します。行動のノードは、下のコマンドの 1 つ目のように -r cmd_vel:=/cmd_vel_test を付けて起動します。脚は動きません。出るはずの指令が出ているか、止まるはずの場面で 0 になるかを見ます。
# 段階 2（机の上）：行動のノードの出し先を /cmd_vel_test につなぎ替えて起動する
ros2 run （パッケージ名） （行動のノード） --ros-args -r cmd_vel:=/cmd_vel_test
# 段階 3（床）：先生の合図のあとに、つなぎ替え（-r ...）を外して起動し直す
ros2 run （パッケージ名） （行動のノード）
linear.x が 0.1 と 0.0 で切り替わる段階 2 で確かめられないことは、床でも確かめられません。ここで合格の線（#F1 の試験計画に書いたもの）に入るまで直します。
F3-4 突き止めた記録を残す
ここでは、うまくいかなかった場所と、どう突き止めたかを記録します。
うまくいかなかった場所を、次の形で残します。この記録が、レポートの中心になります。
1 行目は書き方の例です。「症状」には見えたこと、「使ったツール」には打ったコマンド、「分かったこと」にはそのコマンドの結果から読めたこと、「直した内容」には何をどう変えたかを書きます。
| 症状 | 使ったツール | 分かったこと | 直した内容 |
|---|---|---|---|
| （例）判断ノードの出力が出ない | ros2 topic hz・ros2 topic info -v | 受けるトピック名が 1 文字違っていた | launch の remap を直した |
この回で撮っておく画面
動画は撮りません。そのかわり、下の画面を撮って残します。授業で受ける人は、実習レポートの「回 F3」の、それぞれの「画面：」の欄に貼ります。ひとりで学ぶ人も、同じ画面を残しておくと、あとで値を見直せます。最初の 1 枚は、実習を始める前に端末で TZ=Asia/Tokyo date と打ち、日付と時刻が出た画面です。授業の日に実習したことの記録になります。講義用の環境の時計は世界標準時（UTC）なので、TZ=Asia/Tokyo を付けて日本時間で出します。
TZ=Asia/Tokyo dateとrobot-status（回の頭）- つないだ直後の rqt_graph（実験 F3-1 の欄）
- 段階 1 の
ros2 topic echo（実験 F3-2 の欄） - 段階 2 の
/cmd_vel_test（実験 F3-3 の欄） - 止まっていた場所を突き止めた画面（実験 F3-4 の欄）
- 直したあとの
ros2 topic hz（実験 F3-4 の欄）
本質の問い（回 F3）
- つないだときに出た食い違いを、どうやって突き止めたか。使ったコマンドと、そこから分かったことを順に書きなさい。
考え方のすじ道（答えを書いてから開く）
突き止め方には、順序があります。形 → 流れ → 中身の順です。
まず形（rqt_graph・ros2 node list）。つながっていなければ、中身をいくら見ても意味がありません。次に流れ（ros2 topic hz）。上流から順に見て、どこで止まったかを絞ります。最後に中身（ros2 topic echo）。値がおかしいのか、単位が違うのかを見ます。
この順で見ると、たいていの食い違いはすぐに見つかります。逆に、いきなりコードを読み始めると時間がかかります。外から見て絞ってから、中を読む。
回 F4 床で動かして、発表する
この回は、床で段階 3 を行い、測った値とつなぐまでの記録をもとに発表します。
- F4-1 先生の立ち会いのもと、囲いの中の床で動かします。#F1 で書いた試験計画の段階 3 を、そのとおりに実行します。記録データやシミュレーションの中で作った班（カメラや Nav2 を使う班）は、段階 3 もシミュレーションの中で見せます。
- F4-2 確かめる値（止まるまでの距離、かかった時間など）を測って書きます。
- F4-3 班ごとに発表します。動いている様子は、囲いの中でその場で動かして見せます。
発表に入れることは 4 つです。
| 入れること | 見せ方 |
|---|---|
| 何を作ったか | ノードの図（設計シート） |
| 設計どおりにつながっているか | rqt_graph と ros2 topic info -v |
| うまくいかなかった場所と、突き止め方 | 回 F3 の表（症状・ツール・分かったこと） |
| 止める仕組みがどこにあるか | 止める条件と、実際に止まった値 |
動いたかどうかは、評価の中心ではありません。うまくいかなかった班でも、どこで止まっていたかを突き止めて説明できれば、それが成果です。コアの第 6 週の発表と、同じ見方をします。
動かす前の確認
床で動かす前に、次を 1 つずつ確かめます。
- 床の前に、
-r cmd_vel:=/cmd_vel_testを付けたままros2 topic echo /cmd_vel_testで、出る指令が設計どおりかを確かめたか（F3-3） - 止める条件が働くことを、机の上で確かめたか
- 周りに人や物がないか。すぐに電源を切れる位置にいるか
- 先生の合図があるまで、動かさない。合図があったら、行動のノードを止め、
-r cmd_vel:=/cmd_vel_testを外して起動し直します（F3-3 のコマンドの 2 つ目）。これで出し先が本番の/cmd_velになります。打つのは自分です - ひとりで学ぶ人は、ほかの人に見ていてもらい、すぐ電源を切れるようにしてから打つ
ロボットの中の cmd_vel_guard は、どんな指令でも前後 0.6 m/s・左右 0.45 m/s・旋回 1.5 rad/s で切り、指令が 1 秒途絶えたら止めます。ただしこれは最後の守りです。速さは自分たちのノードで、これより十分小さくしておきます。
この回で撮っておく画面
動画は撮りません。そのかわり、下の画面を撮って残します。授業で受ける人は、実習レポートの「回 F4」の、それぞれの「画面：」の欄に貼ります。ひとりで学ぶ人も、同じ画面を残しておくと、あとで値を見直せます。最初の 1 枚は、実習を始める前に端末で TZ=Asia/Tokyo date と打ち、日付と時刻が出た画面です。授業の日に実習したことの記録になります。講義用の環境の時計は世界標準時（UTC）なので、TZ=Asia/Tokyo を付けて日本時間で出します。
TZ=Asia/Tokyo dateとrobot-status（回の頭）- 床での様子（写真）（実験 F4-1 の欄）
- うまくいかなかった場面（実験 F4-1 の欄）
- 突き止めたときの画面（実験 F4-1 の欄）
- 測った値（写真か画面）（実験 F4-2 の欄）
- 発表で見せた rqt_graph（実験 F4-3 の欄）
つまずきやすい点
| 症状 | 見るところ |
|---|---|
| つないだら誰も値を出さない | ドメイン ID がそろっているか。起動しているノードを ros2 node list で数える |
| rqt_graph に余計な矢印がある | 名前空間か remap。#06 でやったつなぎ替えを見直す |
| 机の上では動くのに床で動かない | 床でしか起きない条件（傾き、滑り、床や壁の材質）。段階 2 との違いを書く |
| 止まらない | 止める条件の層。自分たちのノードで止めているなら、安全層でも切れるか確かめる |
| 時間が足りない | 設計を小さくする。1 つの振る舞いが通ることを優先する |
まとめ
| やったこと | わかったこと |
|---|---|
| つないで形を見る | 動かす前に、rqt_graph で見つかる食い違いがある |
| 上流から Hz を見る | 「動かない」は「どこで止まっているか」に言い換えられる |
| 机の上で通す | 段階 2 で確かめられないことは、床でも確かめられない |
| 突き止め方を記録する | 使ったツールと順序が、そのまま成果になる |
| 床で動かす | 床でしか出ない条件がある。差を書く |
これで延長コースはすべて終わりです。受けたコースを通して、やってきたことは 1 つです。外から観察して、先に設計して、自分の値で確かめる。作るものが変わっても、この順序は変わりません。