HCRラボ ロボティクス研究

Table of Contents

このブログ記事は、コロラド・スクール・オブ・マインズでの学部時代におけるロボティクスの旅路を記録しています。CSCI473で情熱を見つけたことから、2020年夏のCSフィールドセッションプロジェクト、そして2021年2月から2021年9月までのHuman Centered Robotics（HCR）ラボでの研究活動までを網羅しています。

Background

私は2018年秋学期にコロラド・スクール・オブ・マインズで学部課程を開始しました。専攻はロボティクスとインテリジェントシステムに焦点を当てたコンピュータサイエンスでした。そして2022年春に卒業しました。

私は人生の早い段階で自分の情熱を見つけることができて幸運でした。高校時代、何が好きで何が得意かを見極めるために多くの時間を費やしました。試行錯誤の末、私の情熱はコンピュータサイエンスであると分かりました。また、この時期にコードを通じて構築することへの圧倒的な愛情も見つけました。

マインズでは、Dr Hao Zhangの指導の下、Human Centered Robotics（HCR）ラボで働く機会を得ました。私は2020年春に彼のクラス「ヒューマンセンタードロボティクス」（CSCI473）を通じてDr. Zhangに初めて出会い、COVIDと授業の混乱の後、2021年春初めに彼のラボで働くことができました。

Human Centered Robotics (CSCI473) Class

マインズのHuman Centered Robotics（CSCI473）は、私の大学経験の中で数少ない、深い影響を与えたクラスの一つでした。このクラスはDr. Hao Zhangが担当しました。クラスの成績はわずか3つのプロジェクトで構成されており、各プロジェクトはロボティクスの核心概念を紹介する挑戦的な課題を提示しました。これらのプロジェクトは以下から成ります：

  1. ロボットオペレーティングシステム（ROS）の学習
  2. ロボット壁追従のための強化学習
  3. 骨格ベース表現を用いたロボットによる人間行動の理解

🧩 ロボットオペレーティングシステム（ROS）の学習

これは私たちに割り当てられた最初のプロジェクトでした。プロジェクトは3つのタスクで構成されていました：

  1. 開発環境のセットアップ
  2. Gazeboシミュレータの理解
  3. ROSの「Hello World」作成

タスク1と2では、開発環境をセットアップし、Gazebo入門チュートリアルに従うだけでした。これには以下が含まれます：

一方、タスク3は本当の挑戦でした。このタスクはturtlesimを使用し、タートルにマインズの「M」ロゴを描かせることでした：

このタスクはシンプルに聞こえましたが、見た目以上に難しかったです。このプロジェクトを通じて、オープンループとクローズドループシステムの概念を学びました。プロジェクトと私の解決策の詳細はROS Move Turtleプロジェクトページで確認できます。

🧩 ロボット壁追従のための強化学習

これは私たちに割り当てられた2番目のプロジェクトで、大学で取り組んだ中で最も難しいプロジェクトの一つでした。プロジェクトの説明は以下の通りです：

このプロジェクトでは、学生は壁に沿って走行し障害物に衝突しないように自律移動ロボットを教えるための強化学習アルゴリズムを設計・実装します。学生はROS Melodic上のGazeboシミュレーションを使用し、Tritonという全方向移動ロボットをシミュレートし、提供された環境マップを使用します。ロボットにはレーザー距離スキャナを搭載し、ステアリングと速度コマンドでロボットを制御しながらセンシングと学習を行います。学生はUbuntu 18.04 LTS上で動作するROS MelodicでC++またはPythonを用いて本プロジェクトをプログラミングする必要があります（プロジェクト1と同じ開発環境）。また、学生はLATEXを使用して標準的なIEEEロボティクス会議のフォーマットに従ったレポートを作成する必要があります。

強化学習アルゴリズムとしてはQ-Learningを使用するよう指示されました。また、クラスで提供されたStingrayのGazeboシミュレーション環境も使用しました。StingrayはTritonモデルと物理ロジックで構成されていました。ロボットがたどる迷路も提供されました。全体として、環境は以下のようになっていました：

プロジェクトの全体説明はcsci473-p2.pdfをご覧ください。私の解決策はあまり良くなく多くの欠陥があったため、GitHubやウェブに公開しませんでした。また、正しい環境でコードを動作させるのは非常に困難で面倒です。しかし、クラスに提出したデモ動画はありますので、私の解決策を見ることができます。こちらで視聴できます：

🧩 骨格ベース表現を用いたロボットによる人間行動の理解

3番目のプロジェクトの説明は以下の通りです：

このプロジェクトでは、学生は複数の骨格ベース表現（成果物1）を実装し、Kinect V1センサーで収集された公開アクティビティデータセットを使用して、サポートベクターマシン（SVM）（成果物2）で人間の行動を分類します。さらに、学生は成果物3として標準的なIEEEロボティクス会議のフォーマットに従い、LATEXでレポートを作成する必要があります。

このプロジェクトは挑戦的でしたが、2番目のプロジェクトほど難しくはありませんでした。主な目的は、Kinect V1センサーのデータとMSR Daily Activity 3D Datasetから取得したデータ、そしてサポートベクターマシンを使用して特定の人間の動作/行動を分類することです。このプロジェクトと私の解決策の詳細はPredict Human Actions Using LIBSVMプロジェクトページで確認できます。

CSCI473 結論

CSCI473は、Minesでの学部時代に受講した中で、最も優れたクラスの一つ（あるいは最高）です。これらのプロジェクトは多くを学ばせ、履歴書に記載できる素晴らしいプロジェクトカタログを持つことができました。また、テストが得意ではなかった私が、プロジェクトの完成で力を発揮できた最初のクラスでもありました。このクラスを通じてDr. Hao Zhangと出会い、最終的にマインズのHuman-Centered Robotics（HCR）ラボで研究助手のポジションを得ることができました。

CSフィールドセッション（2020年夏）

CG_GUI_19

2020年夏、CSCI473を修了しHCRラボに参加する間に、私はコロラド・スクール・オブ・マインズのコンピュータサイエンス学部課程の一環としてCSCI370、すなわち「高度ソフトウェア工学」を履修しました。CSCI370は、学生が企業向けのソフトウェアソリューションを設計、実装、文書化するコースです。学生は学んだ知識を実際のコンピュータサイエンス問題に応用できます。コースの詳細はこちらで確認できます。

このコースでは、取り組むプロジェクトや企業を自分で選択できます。各プロジェクトと企業の詳細が記載されたPDFが提供されました。最終的に、Lunar Outpostという会社が掲示した「高度な月面ナビゲーションのためのリアルタイム車輪スリップ検出とエラー補正」というプロジェクトに取り組むことにしました。名前が長いため、プロジェクトの別名を「Wheel Slippage Detection（車輪スリップ検出）」と呼びます。

問題

Lunar Outpostは自律型月面ローバーの開発を目指すスタートアップです。月面には大量の月塵があり、これが車輪のスリップを多く引き起こすことが知られています。車輪スリップは自律システムが実世界の位置情報を失う原因となるため、理想的ではありません。地球上では、GPSデータを使用してスリップによるオフセットを補正します。しかしGPSは、30以上のナビゲーション衛星が地球を常に周回し、独自の信号を送信してコンピュータが位置を計算できる場合にのみ機能します。月面には現在そのようなGPSは存在しません。したがって、GPS以外の方法で車輪スリップを検出する必要があります。プロジェクトの問題に関する詳細なレポートはこちらで閲覧できます。

チーム

このプロジェクトは単純なものではなかったため、チームで取り組む必要がありました。チームはコロラド・スクール・オブ・マインズの学生5名で構成されていました：

このプロジェクトは単純なものではなかったため、チームで取り組む必要がありました。チームはMehmet Yilmaz（私）、Kane Bruce、Braedon O’Callaghan、Liam Williams、Kevin Grantで構成されていました。

このプロジェクトでは、ROS、C++、Python、Linux、Raspberry Pi、Arduinoのいくつかの知識が必要でした。メンバーの多くはこれらの技術のいずれかに経験がありましたが、私だけがROSの経験がありました。なぜなら、2020年春学期のHuman Centered Robotics（CSCI473）クラスでROSを使用していたからです。そのため、初期段階で私は全員にROSの基本と開発方法を教える手助けをしました。

課題

このプロジェクトでは多くの課題がありましたが、最大の課題はテスト用の実機ロボットにアクセスできなかったことです。これはCOVIDの影響で全てがリモート化され、Lunar Outpostのラボや施設で作業できなかったためです。その結果、シミュレーションを使用せざるを得ませんでした。

Also, we went through some academic research from the WVUナビゲーションラボ to get an idea of how the Wheel Slippage problem could get solved for Lunar Outpost’s use case. Which, for us, as undergraduate sophomores and juniors, was more difficult than we expected.

Another challenge we faced was the amount of time we had to work on this project. CSCI370 is a one month class. But the problem itself is a massive problem that many companies and academics have been trying to solve/perfect for decades. So one month is far from enough time to solve this issue. But, despite all these challenges we pushed through and made sure to deliver.

Conclusion

After working through all the research and development, we determined that it is almost impossible to simulate proper moon physics digitally, so really trying this algorithm in a simulation is no good and not going to yield any meaningful research in wheel slippage detection in space and on the moon. We concluded that setting up a proper test environment using something like sand and real hardware, like a Husky robot, is far more important for this type of research. We did update the wheel slippage detection code to work as a ROS node and it functioned properly and could easily be imported into real hardware for testing. This project allowed me to take a leadership role, educate my peers on ROS development, and gain experience with Python, ROS, and Gazebo while tackling a complex problem I had never encountered before. Most importantly, this experience further solidified my passion for robotics and reinforced my desire to pursue research in the field, setting the stage for what would come next in my robotics journey.

Starting At The HCR Lab

After completing CSCI473, my CS Field Session in the summer of 2020, and my Fall 2020 semester, I decided to pursue research in robotics. I had such great experiences with both CSCI473 and the CS Field Session that I decided I wanted to do research for the HCR Lab. Since I had met Dr. Zhang the year prior, I decided to email him and ask about any opportunities the lab might have in January 2021. Within about 2 weeks, Dr. Zhang expressed interest, presented me with research options, and offered me a role in the lab. I then started working for the lab in February 2021.

Introduction Video

Here’s my introduction video that I recorded a few months into my time in the HCR Lab. It was recorded in May 2021 and covers the research I would focus on in the HCR Lab during the summer of 2021:

My Project

Throughout my time in the HCR Lab, I mainly focused on the Triton project. The Triton project is a mobile robot developed by the ヒューマンセンタードロボティクスラボ at the Colorado School of Mines. It’s a triangular omni-wheel ground robot powered by NVIDIA’s Jetson Nano.

The Triton, in a simple overview, consisted of the following parts:

  • NVIDIA Jetson Nano
  • NVIDIA’s Seed Studio A205 Carrier Board
  • Arduino Mega
  • 64 GB Micro SD Card
  • Custom 3D printed body
  • 3 mecanum wheels
  • 1 AR Battery
  • Custom circuits for optimized power distribution and wiring
  • Intel’s Realsense D435 Camera
  • Some LEDs

It was designed, built, and manufactured around 2018-2020 as a robot for educational purposes. By the time I joined, the Triton was pretty established, and the lab was considering making a new version of it. However, the main issue with the Triton was its software. The Triton could move, charge, and function in a basic sense but did not really do anything intelligent. It even lacked the ability to make more advanced movements.

バッテリーチャージャー設定 テストエリアレイアウト
初期テスト段階のトリトン 棚にあるトリトン

To start addressing this, the lab set up an area where we could keep track of the Triton. To do this, they created a 2-meter by 2-meter area with 8 Optitrack Flex (Infrared Red) Cameras in a square-like shape about 6-7 feet above the floor.

エリア I1 エリア I2

Along with having this area built, each Triton had three gray sphere balls attached at the top of their bodies.

With this setup, we had effectively built our own small-scale GPS system that allowed us to get the exact coordinates in meters of a Triton in our area of interest. By using the Optitrack infrared cameras and the Optitrack gray spheres in a triangular shape, we could pinpoint the exact coordinates of a Triton in our area. This allowed us to apply a closed-loop system for better accuracy in movement.

The Optitrack system provided position and orientation data at about 120Hz with sub-millimeter accuracy when properly calibrated. Each Triton’s three reflective markers formed a unique triangular pattern that the system could track as a rigid body. The coordinate system was calibrated so that (0,0) was at the center of the tracking area, with X and Y axes aligned to the room’s geometry. But despite this precise positioning data, the Triton still struggled with movement.

With this setup, one core feature we wanted to provide the Triton was the ability to move to a specific coordinate. The user, or their software, could provide a (x, y) coordinate within their area of interest. Then the robot would move to that coordinate as fast, accurately, and seamlessly as possible. When I joined, this feature existed but it wasn’t working very well. Here is a simple animation showing how the original moving logic worked:

I did not record the original solution in action, so I created this simple animation showing you the old moving logic in action. Knowing this, what are the issues with this method?

  1. It’s really slow
  2. It makes the robot take up a lot of space just to go to a specific point. This made it difficult for us to use this solution when multiple Tritons were moving around.

So why was this behavior happening? The issue was that the Triton first turned, changing its alpha, until it pointed toward the target point within a specific margin of error. Then it would sprint forward, and after its theta was off from the target by a specific amount, it would stop and start turning again until the alpha was within that acceptable range for the target goal. Then it sprints again and keeps doing this until it gets to the point. Also, as it got closer and closer to the goal point, the turning and sprinting speed would get much slower to make sure it didn’t overshoot. This resulted in the Triton having unnatural movement, taking forever to get to a target point, and requiring so much area just to get to a specific target point. So with all of these issues, and given how essential this feature was for the development of the Triton project, when I started working at the HCR Lab, my first task was to develop more effective solutions that would allow the Triton to better navigate to a goal point.

Knowing this, I spent a lot of time doing research on the best possible way of addressing this problem. Ironically, I was taking a class called フィードバック制御システム入門 (EENG307) at Mines. Early in that class, we learned about the concept of オープンループコントローラ and クローズドループコントローラ. Knowing this, and after some discussion I had with the professor of that class and my smart roommate, it became clear that this goal of getting the Triton to a goal point was a closed-loop system problem.

ホワイトボード制御システム図

Now, after extensive testing and research, I developed two distinct controller approaches for the Tritons:

Method 1: Distance-Theta Controller

This approach used two separate proportional controllers running simultaneously:

  • Distance Controller: Calculated the Euclidean distance to the target and applied a proportional gain to determine forward/backward velocity
  • Theta Controller: Calculated the angular error between the robot’s current heading and the desired heading to the target, applying a separate proportional gain for rotational velocity

The algorithm continuously calculated the Euclidean distance to the target and the angular error between the robot’s current heading and the desired direction. Two separate proportional gains were applied to generate linear and angular velocities respectively.

This resulted in the Triton naturally turning toward the goal while simultaneously moving forward, creating smooth curved paths. The key advantage was that the robot always kept its front face oriented toward the destination, which was crucial for camera-based applications.

Method 2: X-Y Coordinate Controller

This approach treated the robot like a 2D plotter, with independent control of X and Y movement:

  • X Controller: Directly controlled east-west movement based on X-coordinate error
  • Y Controller: Directly controlled north-south movement based on Y-coordinate error

The implementation calculated X and Y coordinate errors independently, applied separate proportional gains, and then transformed these global velocity components into the robot’s local coordinate frame using rotation matrices. This transformation was necessary because the robot’s omni-wheel drivetrain required velocities in its own reference frame, not in global coordinates. This method produced the most direct paths to targets and was significantly faster, but the robot’s heading would drift since there was no explicit orientation control.

実装では X と Y の座標誤差を独立して計算し、別々の比例ゲインを適用し、そしてこれらの全体速度成分を回転行列を用いてロボットのローカル座標系に変換しました。この変換が必要だったのは、ロボットのオムニホイール駆動系が全体座標ではなく自身の基準フレームでの速度を必要としたためです。この手法は目標への最も直接的な経路を生成し、かなり高速でしたが、明示的な姿勢制御がないためロボットの向きがドリフトしてしまいました。

For method #1, I went into full detail about this method in my Move Turtle (TurtleSim) blog. I highly recommend you read this blog to get all the details on how PID controllers work in general, as well as how method #1 works. I developed method #1 using ROS’s TurtleSim, then transferred that code to the Triton and updated it to account for a more real-world environment.

手法 #1 については、私の Move Turtle (TurtleSim) ブログ でこの手法を詳細に説明しています。PID コントローラが一般にどのように機能するか、そして手法 #1 がどのように動作するかを知るために、ぜひこのブログを読むことを強くおすすめします。手法 #1 は ROS の TurtleSim を用いて開発し、そのコードを Triton に移植して、より実世界に近い環境に対応できるように更新しました。

Method #2 used a quite different but equally effective approach. Instead of thinking about the robot’s orientation and distance to the goal, this method treats the movement like a coordinate plane problem. The controller continuously calculates the error in both X and Y directions separately. For example, if the robot needs to move from (0,0) to (2,3), it sees this as needing to correct a 2-meter error in X and a 3-meter error in Y. Two proportional controllers worked simultaneously: one adjusted the robot’s velocity in the X direction based on X-error, while the other handled Y-direction movement based on Y-error. This created a more direct path to the goal, similar to how a 3D printer head moves, and allowed for smooth diagonal movements. The robot didn’t need to explicitly turn to face its target, making this method particularly effective in tight spaces or when precise positioning is required.

手法 #2 はかなり異なるが同様に効果的なアプローチを採用しました。ロボットの向きや目標までの距離を考える代わりに、この手法は動きを座標平面の問題として扱います。コントローラは X と Y の両方向の誤差を別々に継続的に計算します。例えば、ロボットが (0,0) から (2,3) に移動する必要がある場合、X 方向に 2 メートル、Y 方向に 3 メートルの誤差を修正する必要があると見なします。2 つの比例コントローラが同時に動作し、1 つは X 誤差に基づいてロボットの X 方向の速度を調整し、もう 1 つは Y 誤差に基づいて Y 方向の動きを処理します。これにより、3D プリンタのヘッドが動くような、より直接的な目標への経路が作られ、滑らかな対角移動が可能になります。ロボットは目標に向かって明示的に回転する必要がなくなるため、狭い空間や高精度な位置決めが求められる場面で特に効果的です。

Both methods proved to be significantly faster and more reliable than the original approach. To see these new methods in action, check out the Tritons in Action Playlist, which shows all the Tritons in action with the new methods.

両手法とも元のアプローチよりもはるかに高速で信頼性が高いことが証明されました。これらの新しい手法の実演を見るには、Tritons in Action プレイリスト をチェックしてください。新手法で動作するすべての Triton が掲載されています。

What once took 30-45 seconds for a simple point-to-point movement now took around 8-12 seconds. More importantly, the Triton could now navigate more efficiently in tight spaces, which became useful for our multi-robot scenarios.

かつては単純な点対点移動に 30〜45 秒かかっていたものが、現在は約 8〜12 秒で完了します。さらに重要なのは、Triton が狭い空間でもより効率的にナビゲートできるようになり、マルチロボットシナリオで有用になったことです。

Development Challenges and Debugging

Implementing these controllers wasn’t straightforward and involved several significant debugging challenges:

これらのコントローラを実装することは簡単ではなく、いくつかの重要なデバッグ課題が伴いました：

Coordinate System Transformations: One of the trickiest aspects was getting the coordinate transformations right. The Optitrack system provided data in its own coordinate frame, the robot had its local coordinate frame, and I needed to convert between them accurately. Early implementations had robots moving in the wrong directions because I had mixed up rotation matrix calculations.

座標系変換: 最も厄介な点の一つは座標変換を正しく行うことでした。Optitrack システムは独自の座標フレームでデータを提供し、ロボットはローカル座標フレームを持っていたため、両者を正確に変換する必要がありました。初期の実装では回転行列の計算を混同したため、ロボットが誤った方向に動いていました。

Real-World vs. Ideal Behavior: The biggest challenge was accounting for real-world factors that don’t appear in textbook control theory. The robot’s wheels had different friction characteristics, the motors didn’t respond identically, and there was always some latency in the communication chain from Optitrack to the control software to the robot’s Arduino. I spent weeks tuning proportional gains and adding deadband filters to account for these physical realities.

実世界 vs. 理想的な挙動: 最大の課題は、教科書の制御理論には現れない実世界の要因を考慮することでした。ロボットのホイールは摩擦特性が異なり、モーターの応答も同一ではなく、Optitrack から制御ソフトウェア、そしてロボットの Arduino へと続く通信チェーンには常に遅延がありました。これらの物理的現実に対応するため、比例ゲインの調整やデッドバンドフィルタの追加に数週間を費やしました。

Oscillation and Stability Issues: My first implementations suffered from oscillation problems where robots would overshoot their targets and wobble back and forth. This taught me about the importance of derivative terms in PID controllers and the need for proper gain tuning. I eventually settled on predominantly proportional control with carefully tuned gains rather than full PID, as the system’s inherent damping was sufficient for most applications.

振動と安定性の問題: 最初の実装では、ロボットが目標をオーバーシュートし前後に揺れ動く振動問題が発生しました。これにより、PID コントローラにおける微分項の重要性と適切なゲイン調整の必要性を学びました。最終的には、システム固有の減衰が多くの用途で十分であると判断し、フル PID ではなく、慎重に調整した比例制御を主に採用しました。

Multi-Robot Interference: When multiple robots operated simultaneously, I discovered unexpected interference patterns. Robots would sometimes “fight” over the same space or create deadlock situations where they’d block each other indefinitely. This led me to implement coordination mechanisms and collision avoidance algorithms.

マルチロボット干渉: 複数のロボットが同時に動作すると、予期しない干渉パターンが見られました。ロボット同士が同じ空間を「争」ったり、互いに永遠にブロックし合うデッドロック状態を作り出すことがありました。これを受けて、協調メカニズムと衝突回避アルゴリズムを実装しました。

Multi-Triton Control System

Once I had solved the single Triton movement problem, the lab’s next challenge was getting multiple Tritons to work together simultaneously. This became one of my main focus areas and ended up being a significant contribution to the project.

単一の Triton の移動問題を解決した後、ラボの次の課題は複数の Triton を同時に連携させることでした。これが私の主な注力領域の一つとなり、プロジェクトへの重要な貢献となりました。

The original system could only control one Triton at a time, which severely limited the research possibilities. The lab wanted to simulate scenarios where multiple autonomous vehicles needed to coordinate their movements, like self-driving cars communicating with each other to optimize traffic flow and create better SLAM (Simultaneous Localization and Mapping) maps.

元のシステムは一度に 1 台の Triton しか制御できず、研究の可能性が大きく制限されていました。ラボは、複数の自律走行車が相互に通信して交通流を最適化し、より良い SLAM（同時定位とマッピング）マップを作成するようなシナリオをシミュレートしたいと考えていました。

To solve this, I implemented a multi-processing approach using Python’s multiprocessing library. Each Triton got its own dedicated process that could run independently while still being coordinated by a central control system. This allowed multiple Tritons to move simultaneously without interfering with each other’s control loops.

この課題を解決するために、Python の multiprocessing ライブラリを用いたマルチプロセス方式を実装しました。各 Triton は独立して実行できる専用プロセスを持ち、中央制御システムによって調整されます。これにより、複数の Triton が互いの制御ループに干渉せず同時に動作できるようになりました。

Multi-Robot Architecture Design

The system architecture I developed consisted of several key components:

私が開発したシステムアーキテクチャは、いくつかの主要コンポーネントで構成されていました：

Main Controller Process: This served as the central coordinator, handling user interface interactions, path planning, and high-level coordination between robots. It maintained the global state and distributed commands to individual robot processes.

メインコントローラプロセス: これは中央コーディネータとして機能し、ユーザーインターフェースの操作、経路計画、ロボット間の高レベルな調整を担当しました。グローバルな状態を保持し、個々のロボットプロセスへコマンドを配布しました。

Individual Robot Processes: Each Triton had its own dedicated Python process that handled:

  • Real-time PID control calculations at ~50Hz
  • Communication with the robot’s hardware (Arduino/Jetson)
  • Local path execution and obstacle avoidance
  • Status reporting back to the main controller

個別ロボットプロセス: 各 Triton は専用の Python プロセスを持ち、以下を処理しました：

  • 約 50Hz のリアルタイム PID 制御計算
  • ロボットのハードウェア（Arduino/Jetson）との通信
  • ローカル経路実行と障害物回避
  • メインコントローラへのステータス報告

Shared Memory Communication: I used Python’s multiprocessing.shared_memory and Queue objects to enable efficient communication between processes. This allowed for real-time coordination without the overhead of network communication.

共有メモリ通信: Python の multiprocessing.shared_memory と Queue オブジェクトを使用して、プロセス間の効率的な通信を実現しました。これにより、ネットワーク通信のオーバーヘッドなしでリアルタイムの調整が可能になりました。

Synchronization Mechanisms: To prevent conflicts when multiple robots needed to coordinate (like avoiding collisions), I implemented semaphores and locks that allowed robots to request exclusive access to certain areas of the workspace.

同期メカニズム: 複数のロボットが調整（衝突回避など）を必要とする際の競合を防ぐため、ロボットが作業領域の特定エリアへの排他的アクセスを要求できるようにセマフォとロックを実装しました。

The challenge was ensuring all robots could operate their control loops independently while still maintaining global coordination. Each robot process ran its own PID calculations and sent motor commands directly to the hardware, while the main process handled higher-level coordination like collision avoidance and path planning.

課題は、すべてのロボットが制御ループを独立して動作させつつ、グローバルな調整を維持することでした。各ロボットプロセスは独自に PID 計算を行い、ハードウェアへ直接モーターコマンドを送信しました。一方、メインプロセスは衝突回避や経路計画といった上位レベルの調整を担当しました。

マルチトリトン交差点テスト 初期マルチトリトン設定

将来のマルチエージェント作業のためのドローンを搭載した Triton

The multi-Triton system opened up entirely new research possibilities. We could now simulate:

マルチトリトンシステムは全く新しい研究の可能性を開きました。現在、以下のシナリオをシミュレートできます：

  • Vehicle-to-vehicle communication scenarios

  • Coordinated path planning with obstacle avoidance

  • Swarm robotics behaviors

  • Multi-agent SLAM mapping

  • Formation control and following behaviors

  • 車両間通信シナリオ

  • 障害物回避を伴う協調経路計画

  • 群ロボティクスの挙動

  • マルチエージェント SLAM マッピング

  • 編隊制御と追従動作

Here’s what the lab setup looked like with multiple Tritons running simultaneously:

以下は、複数の Triton が同時に稼働しているラボのセットアップ例です：

緑のグリッド上のロボット ロボットグリッド設定

I also developed a user-friendly interface that allowed researchers to visually define paths for each Triton. You could literally draw the path you wanted each robot to follow, and they would execute these paths with perfect coordination. This was incredibly useful for setting up complex experiments without having to manually code every movement.

また、研究者が各 Triton の経路を視覚的に定義できるユーザーフレンドリーなインターフェースも開発しました。実際にロボットがたどるべき経路を描くだけで、完璧に調整された状態でその経路を実行させることができました。これにより、すべての動作を手動でコード化することなく、複雑な実験を設定するのに非常に役立ちました。

The system could handle up to 5 Tritons simultaneously, each running its own PID controllers while being coordinated through the central control system. The performance was impressive, with all robots maintaining their individual accuracy while working together as a team.

システムは最大 5 台の Triton を同時に扱うことができ、各々が独自の PID コントローラを実行しながら中央制御システムで調整されました。パフォーマンスは印象的で、すべてのロボットが個々の精度を保ちつつチームとして協調して動作しました。

Here’s a playlist showing the Tritons in action, from single-robot control to multi-robot coordination: Tritons in Action Playlist

以下のプレイリストで、単一ロボット制御からマルチロボット調整までの Triton の実演を見ることができます：Tritons in Action プレイリスト

Depth Sensor Integration and Coordinate Correction

Another major advancement I worked on involved utilizing the Intel RealSense D435 depth cameras mounted on each Triton. While the Optitrack system gave us incredibly precise positioning data, I wanted to explore how the robots could use their onboard sensors to improve their spatial awareness and correct for coordinate errors.

私が取り組んだもう一つの大きな進歩は、各 Triton に搭載された Intel RealSense D435 深度カメラを活用することでした。Optitrack システムが非常に高精度な位置データを提供してくれる一方で、ロボットが搭載センサーを用いて空間認識を向上させ、座標誤差を補正できるかを探求したいと考えました。

The idea was that Tritons could use their depth sensors to detect other Tritons in their vicinity and cross-reference their positions. This would serve multiple purposes:

このアイデアは、Triton が深度センサーを使って近傍の他の Triton を検出し、位置を相互参照できるようにすることでした。これには以下のような複数の目的があります：

  1. Error Correction: If the Optitrack system had any calibration drift or temporary occlusion, robots could use visual confirmation of each other’s positions to maintain accurate coordinate systems.

    誤差補正: Optitrack システムに校正ドリフトや一時的な遮蔽があった場合でも、ロボットは互いの位置を視覚的に確認することで正確な座標系を維持できます。

  2. Enhanced SLAM: By having multiple robots with depth sensors working together, we could create much richer maps of the environment with redundant data points.

    強化された SLAM: 深度センサーを搭載した複数のロボットが協働することで、冗長なデータポイントを用いたはるかに豊かな環境マップを作成できます。

  3. Collision Avoidance: Real-time depth sensing would allow robots to detect and avoid each other even if the central control system had communication delays.

    衝突回避: リアルタイムの深度測定により、中央制御システムに遅延があってもロボット同士を検知し回避できるようになります。

I began experimenting with algorithms that would allow Tritons to:

私は、Triton が以下を実現できるようなアルゴリズムの実験を始めました：

  • 他のトリトンを、その特徴的な三角形の形状と反射球マーカーを使用して検出する
  • 深度データを使用して相対位置と姿勢を計算する
  • これらの測定値をOptitrackデータと比較して不一致を特定する
  • 正確さを維持するために、リアルタイムで座標系を調整する可能性がある

コンピュータビジョン実験

私は、いくつかの段階で機能するコンピュータビジョンパイプラインを実験するのにかなりの時間を費やしました:

コンピュータビジョンテストのために向き合う2つのトリトン トリトンのカメラのクローズアップ
テスト用に向き合う2つのトリトン
向き合う2台のロボット レース直前の2つのトリトン

深度データ処理: Intel RealSense D435はRGBと深度データの両方のストリームを提供しました。私は主に深度データを扱い、30Hzで取得される640x480の距離測定配列として受け取りました。最初の課題は、このノイズの多い深度データをフィルタリングして有意義な幾何情報を抽出することでした。

物体検出試行: 複数段階の検出アルゴリズムを実験しました。床レベルの物体を特定するために深度画像をセグメント化し（壁や天井などを除去）、おおよそ0.3x0.3メートルのフットプリントを持つ物体を探すことにある程度成功しました。エッジ検出と幾何解析を使用して特徴的なトリトンのプロファイルを識別しようとしましたが、結果はまちまちでした。

マーカー認識実験: 各トリトンに付いている3つの反射球は、最も有望な検出特徴のように思えました。ブロブ検出アルゴリズムを使って、深度画像内の3つの明るい点の特徴的な三角パターンを識別しようと実験しました。制御された照明条件下でいくつか有望な結果が得られましたが、一貫して信頼できるわけではありませんでした。

座標融合研究: ビジョンベースの位置推定とOptitrackデータを融合するアプローチを調査し、基本的なカルマンフィルタ実装を含めました。概念は、Optitrackデータが利用可能なときはそれに重みを置き、必要に応じてビジョンにフォールバックするというものでしたが、ラボでの在籍期間が終了する前に完全に機能させることはできませんでした。

性能課題: これらすべての処理をロボットの制御ループと同時にリアルタイムで実行させることは困難でした。アルゴリズムをJetson Nanoの処理能力を圧迫せずに約10-15Hzで動作させるための最適化手法を試みました。

残念ながら、ラボを離れる前にこのコンピュータビジョンの作業を完全に完了させることはできませんでした。いくつか有望な初期結果と深度センサー処理に関する多くの学びがありましたが、システムを完全に信頼できる状態に持っていくことはできませんでした。これは、他の人が将来的に構築できる興味深い研究方向として残っています。

以下は、私がコンピュータビジョンアルゴリズムをテストしている動画です:

以下は、実験中の深度センサーのビューです:

深度センサー統合作業は完了しませんでしたが、この概念は自動運転車シナリオのシミュレーションなど、外部インフラに依存せずに車両同士が互いを認識する必要がある応用に期待できることが示されました。私が始めた研究方向は、ラボの将来の作業に貢献できる可能性があります。

ドキュメントと知識の保存

私がHCRラボで最も重要な貢献の一つ、そして最も誇りに思うことは、すべてのプロジェクトドキュメントを整理し保存したことです。ラボに参加したとき、トリトンプロジェクトの知識は複数のプラットフォームと形式に散らばっていました。重要な情報は以下に分散していました:

  • 卒業したさまざまな学生が所有するGoogleドライブアカウント
  • 受信トレイに埋もれた古いメール
  • ランダムなDropboxフォルダ
  • 複数のGitHubリポジトリ
  • 組織が一貫していないGitLabリポジトリ
  • 特定の人だけが解読できる手書きノート

この断片化されたドキュメントは大きな問題でした。新しい学生は、始め方を把握するだけで数週間を費やし、卒業や退職に伴い貴重な知識が常に失われていました。

私はこの問題を体系的に解決することに取り組みました。トリトンプロジェクトに関連するすべてのドキュメント、コード、ビデオ、ノートを追跡するのに無数の時間を費やし、すべてを集中化されたGitLabリポジトリに明確で論理的な構造で整理しました。

デスク上のトリトン テーブル上の複数のトリトン（合計8台、うち5台が組み立て中）

棚に置かれたトリトン（良い角度）

集中化されたドキュメントには以下が含まれます:

  • ビルドガイド: トリトンをゼロから組み立てるためのステップバイステップの手順
  • ソフトウェア設定: 開発環境のセットアップに関する完全なガイド
  • コードドキュメンテーション: 明確な説明が付いた十分にコメントされたコード
  • ハードウェア仕様: 詳細な部品リスト、配線図、PCB設計
  • トラブルシューティングガイド: 一般的な問題とその解決策
  • ビデオチュートリアル: 私はYouTubeに指導ビデオを作成・アップロードし、詳細なOptitrackキャリブレーションチュートリアルを含む:

私は将来の貢献が整理されアクセスしやすいように、ドキュメント標準も確立しました。私が作成したリポジトリ構造は、ラボのすべての後続作業の基盤となりました。

既存のドキュメントを整理するだけでなく、重要な知識ギャップを埋めるオリジナルのガイドやチュートリアルも多数作成しました。これには新しいラボメンバー向けの詳細なセットアップ手順、包括的なトラブルシューティングガイド、複雑な手順のビデオウォークスルーが含まれます。

その影響は即座かつ持続的でした。新しい学生は数週間ではなく数日で作業に追いつくことができました。私が作成したドキュメントリポジトリは、私が退職した数年後もラボで使用され続けており、トリトンプロジェクトの唯一の真実の情報源となり、将来の研究者のために無数の時間/日数を節約しています。

メンタリングと知識移転

私のHCRラボでの時間で最もやりがいを感じた側面の一つは、他者を指導し、得た知識を共有する機会でした。作業が進みトリトンシステムに熟練するにつれ、新しいチームメンバーの訓練にますます責任を持つようになりました。

ラボ後継者のメンタリング

学位取得とeBayでの仕事に集中するために最終的にラボを離れる準備をしていたとき、私の退職後にトリトンプロジェクトを引き継ぐ2名を徹底的に訓練しました。これは単に操作方法を見せるだけでなく、根本的な原理を真に理解させ、継続的にイノベーションを起こせるようにすることでした。

数週間にわたり彼らと密に協働し、以下を実施しました:

  • PID制御システムの数学的基礎
  • 複数ロボットを調整するためのマルチプロセッシングアーキテクチャ
  • 深度センサー統合とコンピュータビジョンアルゴリズム
  • ドキュメントシステムとその保守方法
  • デバッグ手法と一般的な障害モード

知識移転は非常に徹底的でした。実際のデバッグセッションを共に行い、既存コードの修正・拡張をさせ、ゼロから新しいトリトンを独立してセットアップできるようにしました。

高校メンターシッププログラム

さらにやりがいを感じたのは、ラボのアウトリーチプログラムを通じて高校生を指導した経験です。これは、ロボティクス、コンピュータサイエンス、研究を教育段階で紹介する絶好の機会でした。

包括的なカリキュラムを設計し、以下をカバーしました:

コンピュータサイエンス基礎:

  • 主要言語としてPythonを使用したプログラミング概念
  • オブジェクト指向プログラミングの入門
  • アルゴリズムとデータ構造の理解

ロボティクス概念:

  • センサーの動作とインターフェース方法
  • アクチュエータ制御とモータシステム
  • 自律システムとフィードバック制御の基礎

ROS（ロボットオペレーティングシステム）:

  • パブリッシュ/サブスクライブメッセージングシステムの理解
  • ノードとサービスの作成
  • ランチファイルとパラメータサーバの使用

実践的プロジェクト作業:

  • 私たちは、トリトンのヘッド上のLEDシステムを制御するROSサービスの作成に協力した
  • 彼女は、既存システムと統合するクリーンで文書化されたコードの書き方を学んだ
  • 彼女が作成したLED制御サービスは、トリトンのコードベースの永続的な一部となった

このメンタリングが特に特別だったのは、プログラミングについてほとんど何も知らなかった彼女が、活発な研究プロジェクトに有意義なコードを貢献するまでに成長したことです。彼女は「変数とは何ですか？」という質問から、ROS通信のデバッグや独自のサービス実装まで独力で行えるようになりました。

彼女が開発したLED制御システムにより、研究者はシンプルなROSコマンドでトリトンのヘッドLEDの色やパターンを簡単に変更できるようになりました。これは一見単純に思えるかもしれませんが、ROSアーキテクチャ、ハードウェアインターフェース、適切なソフトウェア設計パターンの理解が必要でした。彼女の貢献は現在もラボで使用されています。

このメンタリングは、彼女にとってだけでなく私にとっても教育的な経験でした。複雑な概念を消化しやすい部分に分解し、根本的な原理を再考することを強いられました。誰かに教えることで、私自身がより優れたエンジニア・研究者になることができました。

博士研究との協働

私がラボで過ごした時間の中で最もプロとしてやりがいを感じた点の一つは、自己走行車アルゴリズムを研究テーマとする博士課程の学生、Pengと密に協働したことです。私がTritonシステムに加えたソフトウェアの改良は、彼の博士研究を支えるのに役立ちました。

Pengの研究は、自己走行車シナリオをシミュレートするために正確で信頼性の高いマルチロボット協調が必要でした。私が動作制御とマルチロボットシステムに加える改良の前は、これらの実験ははるかに実施が困難でした。ロボットは遅く、精度が低く、効果的に協調できませんでした。

私の貢献は、以下の複数の領域でPengの研究を支援しました：

交差点管理研究: 改良されたPIDコントローラとマルチロボット協調により、Pengは複数の「車両」（Triton）が動きを調整する必要がある交差点シナリオをシミュレートできるようになりました。タイミングと位置決めが向上したことで、これらの研究がより実現可能になりました。

車両間通信: 私が開発したマルチプロセッシングフレームワークにより、Pengはシミュレートされた車両間の通信プロトコルを実装・テストできました。各Tritonは他のロボットと協調しながら意思決定を行うことができ、自己走行車が必要とするような動作を模倣できました。

SLAM とマッピング研究: 深度センサー統合作業により、Pengは同時定位とマッピング（SLAM）研究に追加データを得られました。協調されたセンシング機能を持つ複数ロボットが利用できたことで、より包括的なマッピング実験が可能になりました。

私たちの協働が特に価値あるものとなったのは、単に私が彼の研究を支援しただけでなく、真のパートナーシップだったからです。Pengの自律車両に関する理論的理解は、私の実装に重要な示唆を与えてくれました。彼のフィードバックと要件は、システムをより堅牢で有能にするよう私を駆り立てました。

私たちはラボで何時間も一緒に過ごし、シナリオのデバッグやさまざまな制御戦略の議論、Tritonプラットフォームが成し得ることの探求を行いました。Pengは同僚であり友人でもあり、彼と働くことで学術研究が実際にどのように機能するかを多く学びました。

私が構築したシステムはPengの博士論文作業の有用な一部となりました。実践的なエンジニアリング貢献が自律車両技術の研究を支えるのを見ることは非常に充実感がありました。堅実なエンジニアリングと研究が協働して有用な成果を生み出すことへの関心がさらに強まりました。

ラボを離れた後も、Pengとは連絡を取り続けました。自分の仕事が退職後も重要な研究に貢献し続けていると知ることは、非常にやりがいのあることでした。

視点：LLM以前の開発時代

このすべての作業が、LLM以前のソフトウェア開発時代に行われたことは注目に値します。すべては2020年から2021年（主に2021年）にかけて行われ、ChatGPT、Claude、Perplexity、あるいはCursor IDEのようなAI搭載開発ツールは存在していませんでした。

すべてのコードはゼロから書かれ、すべてのアルゴリズムは学術論文や教科書を通じて調査され、すべてのデバッグセッションはプリントステートメント、デバッガ、体系的テストといった従来の手法に依存していました。座標変換やPIDチューニングの問題で行き詰まったとき、AIアシスタントに概念の説明やデバッグ支援を求めることはできませんでした。

このため開発プロセスは格段に困難でしたが、同時に教育的でもありました。私は次のことを行わなければなりませんでした：

すべてを手動で調査: PID制御理論を理解するには教科書や学術論文を読む必要がありました。座標変換を把握するには手計算で数学を解く必要がありました。すべての概念は実装前に完全に理解しなければなりませんでした。

AI支援なしでデバッグ: ロボットが予期せぬ方向に動いたり目標付近で振動したりしたとき、論理を体系的に追跡し、デバッグ出力を追加し、仮説を一つずつ検証する必要がありました。問題の可能性を示唆したりエラーパターンを解釈したりするAIは存在しませんでした。

第一原理から学ぶ: 「ロボティクスでマルチプロセッシングをPythonでどう実装するか」といった質問をすぐにAIに投げかけられないため、基礎概念を深く理解しなければなりませんでした。この経験は、並行プログラミング、制御システム、コンピュータビジョンの堅固な基盤を築くことを強制しました。

ドキュメンテーションは重要: 後でAIにコード説明を頼れないため、極めて明瞭なドキュメントとコメントを書く必要がありました。この規律は、知識を他者に移転する際に計り知れない価値を発揮しました。

振り返ってみると、現代のAIツールがあれば開発の多くの側面が加速したでしょうが、ツールなしで作業したことで、より深い問題解決能力と基盤システムへの徹底的な理解が身につきました。今日利用可能な開発ツールがあったら、プロジェクトはどれほど違ったものになっていたかを考えるのは興味深いです。

離れるという難しい決断

HCRラボでの仕事が大好きだったものの、2021年後半になると多くの学生が直面する難しい決断—複数の機会と責任のバランス—に直面しました。私はeBayでフルタイムのソフトウェアエンジニアとして働きながら、Minesでコンピュータサイエンスの学位を取得し、HCRラボの研究にも貢献していました。

eBayでの機会は重要でした。初めての大規模なソフトウェアエンジニアリング役職であり、貴重な業界経験と安定した収入をもたらしました。しかし、フルタイムの仕事を続けながら学位取得と研究に意味のある貢献を続けることは、単に持続不可能でした。何かを犠牲にせざるを得ませんでした。

私がコース負荷を減らしてラボの作業にもっと時間を割くことをDr. Zhangに相談したとき、彼は強く反対しました。彼の論理は明快でした：学位取得が最優先であり、eBayでの業界経験はキャリア発展にとって価値があると。研究に集中するために授業を落とすことは魅力的ですが、長期的には最善の決断ではないと考えていました。

そのため、2021年9月、約8か月間の集中的なラボ作業を経て、研究助手の役割から退き、学位取得とeBayでの仕事に専念するという難しい決断を下しました。当時、これは私にとって最も厳しいプロフェッショナルな決断の一つでした。

正式にラボを離れた後も、構築したシステムに関して誰かが助けを求めたときはサポートを続けました。必要に応じてドキュメントを更新し、デバッグに関する質問に答え、リモートでトラブルシューティングを支援しました。プロジェクトの成功に対する私の投資と人間関係は、公式にチームの一員でなくなったからといって消えるわけではありませんでした。

振り返りと回顧

現在、2025年、4年が経ち、あの時期を複雑な感情で振り返っています。私のキャリアはウェブ開発とAI/MLエンジニアリングへと深く進み、これらは非常にやりがいがあり、成長とインパクトの機会を提供してくれました。

テーブル上のトリトンの俯瞰図

しかし、心の奥底には「もしも」の疑問が残ります。ロボティクスは、正直言って今でも私の真の情熱です。物理システムと向き合い、コードが実世界の動きや振る舞いに変換される様子は、ウェブ開発やAIの仕事ではなかなか再現できない何かがあります。

別の道を選んでいたらどうなっていただろうかと時々考えます。ロボティクス研究に残る方法を見つけていたら？ 学部卒業後すぐに大学院に進んでいたら？ 業界経験よりラボの仕事を優先していたら？

しかし、すべての道にはトレードオフがあることも認識しています。ウェブ開発とAIで培ったスキルは非常に価値があります。業界経験は大規模なソフトウェアエンジニアリング、ユーザーエクスペリエンス設計、そして何百万人が利用する製品を構築する実務的な課題について教えてくれました。これらの経験は、全体として私をより優れたエンジニアにしてくれました。

HCRラボでの作業は、今日の問題解決アプローチに今も影響を与えています。PID制御システムに必要な体系的思考は、ソフトウェアシステムでフィードバックループを設計する際に現れます。ドキュメンテーションと知識保存のスキルは、以降のすべての役割で不可欠でした。メンターとしての経験は、ジュニア開発者と協働し、チーム内で知識共有を促進する方法を形作っています。

最も重要なのは、実世界にインパクトを与える挑戦的な技術課題に取り組むときに自分が最も活き活きとするということです。ロボットの動きアルゴリズムを最適化するであれ、ユーザーの目標達成を支援するAIシステムを構築するであれ、価値ある難題を解くことに喜びを感じます。

永続的な影響

HCRラボでの経験を振り返ると、比較的短期間で達成したことの多さに驚かされます。私が構築したシステムはTritonプラットフォームの運用方法を根本的に変え、これらの改良の多くは現在も使用されています。作成したドキュメントリポジトリはプロジェクト全体のナレッジベースとなり、築いたメンターシップ関係は関わった人々に長期的な影響を与えました。

しかし、最も重要なのは、情熱を持って取り組む問題に対して自分が何ができるかを実感させてくれたことです。その8か月間に私は：

  • プラットフォームを制限していたロボットの動作制御システムを改善した
  • ゼロからマルチロボット協調システムを構築した
  • コンピュータビジョンとセンサーフュージョン機能を統合した
  • 包括的なドキュメントとナレッジマネジメントシステムを作成した
  • 複数のメンバーを指導し、知識移転を支援した
  • 自律車両に関する博士レベルの研究を支援した

This wasn’t just about the technical achievements, though those were meaningful to me. It was about learning that with persistence and systematic thinking, you can make useful contributions even as an undergraduate student.

未来とロボティクス

While my career has taken me in other directions, my passion for robotics hasn’t diminished. I still follow developments in the field, I’m excited about advances in robot learning and autonomous systems, and I occasionally work on personal robotics projects in my spare time.

Who knows what the future holds? The skills I’m developing in AI and machine learning are increasingly relevant to robotics. The industry experience I’ve gained has taught me how to build robust, scalable systems. Perhaps there’s a future where these different threads of my experience come together in unexpected ways.

For now, I’m grateful for the time I spent in the HCR Lab and the experiences it provided. It was a formative period that shaped both my technical skills and my understanding of what kinds of work I find most fulfilling. Even though I sometimes miss it, I know that the lessons I learned and the approaches I developed continue to influence everything I do.

The robots are still there, still serving researchers, still enabling important work. And that’s pretty wonderful.