Pixels to Motors の `llms.txt` にある最新の記録から、実験の失敗・想定外の動作・技術的なつまずきを中心に確認しました。 特に注目したのは、単に「失敗した」で終わらず、失敗の原因をどう切り分け、次の実験で何を変えたかが記録されている回です。 まず、2026年11月1日の LOG422 には、かなり具体的な実機実験の失敗が残っています。 - π0.5 を追加学習しても、ロボットアームの把持位置のずれは解消しなかった。 - 補正なしではブロックをつかめず、空振りした。 - さらに実験後、手首のサーボが約54度ずれたまま応答しなくなった。 - 次の対応として、成功データの追加点検、再学習、サーボの診断スクリプト作成を進めているところです。 [image](https://www.google.com/s2/favicons?domain=https://pixelstomotors.com\&sz=32) Pixels to Motors ## 1. LOG422（2026年11月1日） 学び直したAIでも、ロボットアームがブロックをつかめない [LOG422：学び直した π0.5 でも mechArm 270 には人の直しが要った](https://pixelstomotors.com/record/retrained-pi05-still-needs-human-corrections?utm_source=chatgpt.com) 実機実験で失敗 どこでつまずいたか 19回のお手本で学習した π0.5 に、人間が修正した5回の動作を追加学習させ、実機で9回テストしました。 結果は成功6回、失敗3回。ただし成功した6回もすべて人間の補正が入っています。 具体的には、 - ブロックをつかむ前に、ロボットの根元の角度が約2度足りない。 - つかんだ後、箱の縁にぶつからない高さまで持ち上げられない。 - 補正なしでは爪がブロックの角を押すだけで空振りした。 さらに9回目の終了後、手首のサーボが54度までずれて、電源を入れ直しても戻らなくなりました。 次にどう直したか - 人間が補正した成功データ6本を点検する。 - 使えるデータを追加して、π0.5を再学習する。 - 手首のサーボを個別に診断するスクリプトを作る。 面白いのは、AIの学習不足とハードウェアの故障を分けて考えていることです。AIが失敗したように見えても、実際には機械側の問題が混ざっている可能性があります。 [image](https://www.google.com/s2/favicons?domain=https://pixelstomotors.com\&sz=32) Pixels to Motors ## 2. LOG418（2026年11月1日） 画像認識AIが、実際のロボットではなく画面上の道の線を見ていた [LOG418：道の線を消すと、配膳ロボットの詰まりは3割しか拾えない](https://pixelstomotors.com/record/serving-robot-jam-detection-without-path-lines?utm_source=chatgpt.com) 検証結果が大幅悪化 どこでつまずいたか 配膳ロボットが30秒以上停止する場面を、画像の異常検知AI「PatchCore」で検出する実験です。 最初は、長い停止の約82%を検出できました。一見うまくいったように見えました。 ところが、AIが異常と判断した場所を画像で確認すると、ロボット同士の間だけでなく、Unityの画面に描かれた「ロボットの走行予定ルートの線」にも反応していました。 つまり、AIはロボットの詰まりを理解していたのではなく、シミュレーション画面特有の表示を手掛かりにしていた可能性があったわけです。 次にどう直したか Unityの録画から走行ルートの線を消し、同じ条件で撮り直して比較しました。 結果は次のとおりです。 | 検証項目 | 線あり | 線なし | | ---------- | ------ | ----- | | 長い停止の検出率 | 72% | 28% | | ロボット同士の詰まり | 23/43件 | 4/47件 | 一方、人とすれ違って止まった場面は、線がなくても17件中13件を検出できました。 ここから得た修正方針 シミュレーション画像をそのままAIに学習させるのではなく、実際の監視カメラに映るものだけを使う。 これは、シミュレーションで成功したAIを実環境に持ち込んだときに性能が落ちる、いわゆるドメインギャップの問題にもつながる重要な発見です。 [image](https://www.google.com/s2/favicons?domain=https://pixelstomotors.com\&sz=32) Pixels to Motors ## 3. LOG403（2026年10月29日） ロボットが失敗しても、AIに何を直せばよいか教えられなかった [LOG403：mechArm 270 の失敗を巻き戻し、直して覚えさせる](https://pixelstomotors.com/record/rewind-and-correct-pi05?utm_source=chatgpt.com) 従来方式の限界 どこでつまずいたか LOG401の実験では、赤いブロックを箱に入れる動作を15回試し、成功9回、失敗6回でした。 失敗の内容は、 - 爪がブロックの奥側に下りてしまう。 - つかんだ直後にブロックを落としてしまう。 ところが、従来の仕組みでは失敗したら最初からやり直すしかありませんでした。 AIに「どこで間違えたのか」「どう修正すればよかったのか」を伝える手段がなかったのです。 次にどう直したか ここで、MicroFactoryというロボット企業の学習方式を参考にしています。 新たに実装したのは次の3つです。 1. `b` キー：失敗した区間まで動作を巻き戻す。 2. `c` キー：関節を選んで1度ずつ人間が補正する。 3. 補正後の動きを、写真と関節角度のセットで記録する。 ここで重要だったのが、最初の設計上の思い込みを修正したことです。 当初は関節角度の数値だけを書き換えれば学習データになると考えていました。しかし、写真には修正前の動作が写っているため、数値だけ変えても正しい学習データにはなりません。 そこで、実機を動かしながら撮影し直す方式に変更しました。また、人間の手がカメラに写らないよう、操作をカメラの外から行う設計にしています。 この回の到達点 - 巻き戻し・補正機能を実装。 - アームを使わないテスト37件に合格。 - 別のAIによるコードレビューも通過。 ただし、この時点では実機テストはまだ行っていません。実際にAIの成功率が改善したわけではなく、実機で試す準備ができた段階です。 [image](https://www.google.com/s2/favicons?domain=https://pixelstomotors.com\&sz=32) Pixels to Motors ## 3つの失敗に共通すること 今回の記録を横断して見ると、研究の進め方に共通した特徴があります。 | 失敗の種類 | 最初の思い込み | 修正の方向 | | ------ | ----------------------- | ------------------- | | ロボット制御 | 追加学習すれば動作が改善する | 人の補正データと機械の状態を分けて検証 | | 画像認識 | シミュレーションで検出できれば実環境でも使える | 実際のカメラ映像に近い条件で再検証 | | 学習データ | 関節角度を直せばよい | 写真と動作をセットで撮り直す | 個人的に最も重要だと思ったのは、LOG403からLOG422への流れです。 LOG403では、人間が失敗を直して、その修正を学習データにする仕組みを考えました。 LOG422では、それを実際に使って追加学習したにもかかわらず、まだ人間の補正が必要でした。 つまり、 1. AIが失敗する。 2. 人間が失敗を修正する。 3. 修正内容を学習させる。 4. 再び実機で試す。 5. まだ失敗する部分を特定する。 という、実際のロボット開発に必要な改善サイクルが見えてきます。 なお、一覧には11月3日公開の LOG436（ゲームパッド操作）と LOG434（配膳ロボットの行き詰まり）もあります。今回は両記事の全文を取得できなかったため、上記3件は本文の実験内容と修正過程まで確認できた失敗記録から選んでいます。厳密な意味での最新3件とは区別しています。 [image](https://www.google.com/s2/favicons?domain=https://pixelstomotors.com\&sz=32) Pixels to Motors このサイトの面白さは、成功事例を並べることではなく、失敗を次の実験の材料に変えているところですね。 特にフィジカルAIの研究記録は、実機の失敗、数値による原因分析、コードの変更、再学習まで追えるので、研究の過程そのものに価値があると思います。