仮想空間で学んだロボットを実機へ戻す3段階――OmniverseとIsaac Simの違い、LAS点群がそのまま使えない理由

私は比較的新しめの技術の依頼を受けることも多くあります。GISやそれに伴うAI活用や点群データを扱うことが多く、その延長で「現実の現場をデジタルツイン化し、その中でロボットを訓練できないか」と相談を受けました。

例えば、ドローン測量やLiDAR計測で取得した現場データを仮想空間に再現し、フィジカルAIの移動ロボットを走らせる。そこで不整地、傾斜、段差、障害物などへの対応を学習させ、その結果を実機へ反映するという構想です。

ただし、実際に試してみると、単に3Dデータを用意すればよいわけではありませんでした。

特に、次の3点は分けて考える必要があります。

さらに、ドローンやLiDARで取得したLAS形式の点群をIsaac Simへ入れようとしても、思ったように動かないことがあります。

今回は、これらの関係を実際の検証視点から整理します。

※正式な表記は「NVIDIA Omniverse」「NVIDIA Isaac Sim」です。

NVIDIA OmniverseとIsaac Simは何が違うのか

OmniverseとIsaac Simは、似たような画面で3D空間を扱うため、最初は違いが分かりにくいところがあります。

しかし、両者は同じ種類のソフトではありません。

Omniverseは3Dデータとアプリケーションをつなぐ基盤

NVIDIA Omniverseは、産業用デジタルツインやロボットシミュレーションなどの3Dアプリケーションを構築するための、ライブラリやマイクロサービスの集合です。

OpenUSDを中心に、異なる3Dソフト、CAD、シミュレーター、レンダリング、データ処理をつなぐ役割を持っています。つまり、Omniverseは一つの完成したシミュレーターというより、3Dデータを統合し、その上に必要なアプリケーションを作るための土台です。

Isaac Simはロボットを試すためのシミュレーター

Isaac Simは、Omniverseのライブラリ上に構築された、ロボットシミュレーション、試験、合成データ生成のためのオープンソースのリファレンスフレームワークです。

ロボットモデルを配置し、物理演算を設定し、カメラ、LiDAR、IMUなどのセンサーを再現し、ROS 2などと連携して動作を検証できます。

学習を担当するのがIsaac Lab

さらに、ロボットの強化学習や模倣学習を本格的に行う場合は、Isaac Sim上に構築されたIsaac Labを利用します。

Isaac Labは、強化学習、デモンストレーションからの学習、モーションプランニングなどのロボット学習を扱うためのフレームワークです。

整理すると、次の関係になります。

名称主な役割分かりやすい例えNVIDIA OmniverseOpenUSDを中心に3Dデータやアプリを統合する基盤都市や道路などのインフラNVIDIA Isaac Simロボット、物理、センサーを再現するシミュレーターロボットの試験場NVIDIA Isaac Lab強化学習や模倣学習を行う環境ロボットの訓練学校ROS 2・メーカーSDK学習結果や命令を実機に伝える仮想空間と実機を結ぶ橋

したがって、OmniverseとIsaac Simは競合する別製品ではありません。

という関係です。

「学習内容を実機へ戻す」とは何を意味するのか

「シミュレーションで学習した内容を実機に戻す」と聞くと、仮想空間で覚えた動きを、そのまま実機へコピーするように思えます。

しかし、実際に戻すのは単なる動作記録ではありません。

ロボットのセンサー値や姿勢などを入力すると、それに応じた行動を出力する学習済みモデル、あるいはポリシーを実機側で動かします。

例えば、入力と出力は次のような関係になります。

入力
・ロボットの姿勢
・関節角度
・関節速度
・IMU
・カメラ
・LiDAR
・接地状態
・目標速度
・周辺の地形

　　　↓

学習済みモデル

　　　↓

出力
・進行方向
・走行速度
・関節の目標位置
・関節速度
・姿勢の変更
・停止や回避の判断

Isaac Labでも、ロボットが受け取る観測値と、ロボットへ与える行動を定義して学習タスクを構築します。

ただし、どこまでをAIに担当させるかによって、実機への反映方法は大きく異なります。

私は、これを次の3段階に分けて考えています。

第1段階：経路・速度・行動判断を学習する

第1段階では、ロボットメーカーが用意した標準の歩行制御や姿勢制御をそのまま利用します。

AIが判断するのは、その上位にある行動です。

例えば、次のような内容です。

• どのルートを通るか

• どの場所で減速するか

• 障害物の左右どちらを通るか

• 危険を感じたら停止するか

• バッテリー残量から帰還するか

• 車輪走行と歩行をいつ切り替えるか

• どの場所から点検対象を撮影するか

• 通信が弱くなった場合に引き返すか

この段階では、AIがロボットの関節を直接動かすのではなく、「前へ進む」「右へ曲がる」「速度を落とす」といった比較的上位の命令を出します。

メーカー標準の安全機能や姿勢制御を残せるため、最初の事業化としては最も現実的です。

また、ロボットごとの違いを吸収しやすく、限定的なフィジカルAIだけではなく、別メーカーの四足歩行ロボット、車輪型ロボット、AMRなどにも展開しやすくなります。

第2段階：歩行・姿勢制御そのものを学習する

第2段階では、ロボットの関節位置、関節速度、トルクなどを学習モデルが直接または半直接的に制御します。

学習対象には、次のようなものがあります。

• 不整地で姿勢を維持する

• 斜面を安定して上り下りする

• 段差を越える

• 滑ったときに姿勢を戻す

• 搭載物による重心変化へ対応する

• 外力を受けても転倒しない

• 路面に応じて脚の出し方を変える

• 消費電力と安定性を両立する

• 転倒しそうな場合に姿勢を立て直す

この段階になると、ロボットの質量、重心、関節特性、モーター応答、通信遅延、接地摩擦などを、シミュレーション上でかなり正確に再現する必要があります。

また、実機側に低レベル制御を受け付けるSDKや開発モードがなければ、学習モデルを配置できません。

同じ3DモデルがIsaac Simに読み込めたとしても、実機の関節へ命令を送れなければ、Sim-to-Realには進めないということです。

第3段階：移動と作業を一体で学習する

第3段階では、移動だけではなく、ロボットアーム、グリッパー、カメラ、工具などを含めて、作業全体を学習させます。

例えば、次のような仕事です。

• 対象設備まで移動する

• カメラを点検箇所へ向ける

• ドアを開ける

• レバーやバルブを操作する

• 部品を持ち上げる

• 荷物を運搬する

• 狭い場所に合わせて姿勢を変える

• 作業後に安全な場所へ戻る

この段階では、移動制御、姿勢制御、物体認識、把持、接触、作業手順を一体化しなければなりません。

人が操作したデータを収集して模倣学習に使用したり、シミュレーション上で大量の作業パターンを生成したりする方法もあります。Isaac Labには、少数の手動デモから追加デモを生成して学習に利用する仕組みも用意されています。

市場としては非常に大きい一方で、最初からこの段階を目指すと開発対象が広がりすぎます。

そのため、まずは第1段階、第2段階から実績を作り、将来的に第3段階へ広げる方が現実的だと考えています。

シミュレーションから実機へは一方向ではない

理想的な流れは、シミュレーションで一度学習して終了することではありません。

現場データを取得
　　　↓
デジタルツインを作成
　　　↓
ロボットモデルを配置
　　　↓
シミュレーションで学習
　　　↓
別のシミュレーターや条件で再検証
　　　↓
安全条件を付けて実機へ配置
　　　↓
実機の走行ログを回収
　　　↓
現実とシミュレーションの差を分析
　　　↓
物理条件を補正して再学習
　　　↓
再び実機へ配置

この循環を作ることが重要です。

Isaac Labの公式資料でも、シミュレーションでの学習から現実のロボットへの配置までを一連の流れとして整理しています。また、摩擦、質量、位置、センサー条件などを変化させるドメインランダム化によって、シミュレーションと現実の差を小さくする方法が利用されています。

ただし、実機上でAIが勝手に学習を続けるオンライン学習は、初期段階では避けた方がよいと考えています。

実務では、

という流れの方が管理しやすく、顧客への説明もしやすくなります。

ドローンやLiDARで取得したLASが、Isaac Simでうまくいかない

私はドローン測量やLiDAR計測で取得したLAS形式の点群を、Isaac Sim上に載せようと試しています。

しかし、単純にLASを読み込ませるだけでは、思ったように表示されなかったり、表示できてもロボットが正しく走れなかったりします。

この原因は、点群データの精度が低いからとは限りません。

そもそも、LASとIsaac Simでは、データを使用する目的が異なります。

LASは「点の集合」であり、物理計算用の地面ではない

LASやLAZは、現実空間から取得した大量の点を保存するための形式です。

それぞれの点には、座標、高さ、反射強度、色、分類などの情報を保持できます。

しかし、点と点の間に面が存在するとは限りません。

人間が画面を見ると地面、壁、建物、配管などを認識できますが、物理シミュレーターから見ると、単に空間中へ点が並んでいるだけです。

そのため、点群が画面に見えていても、

• ロボットの足が地面をすり抜ける

• 車輪が接触しない

• 段差として認識されない

• 衝突判定ができない

• 経路探索用の障害物にならない

• 摩擦を設定できない

という問題が起こります。

Isaac SimのDebug Drawで表示される点群についても、公式資料では物理シーンとは相互作用しないと説明されています。また、占有格子地図を生成する機能も、USDステージに衝突形状が設定されていることを前提としています。

つまり、

なのです。

LASは一般的な3Dモデル変換の対象に入っていない

Omniverseの一般的なAsset Converterでは、FBX、OBJ、GLTF／GLB、STLなどをUSDへ変換できます。

一方、一般的なAsset Converterの対応形式一覧には、LASやLAZは含まれていません。

そのため、LASを3Dモデルと同じ感覚でIsaac Simへドラッグし、即座にシミュレーション用の空間へ変換する、という流れにはなっていません。

なお、2026年7月24日に公開されたOmniverse Kit 110.2では、E57、PTS、LAS／LAZをPotree 2.0形式へ変換するサンプルスクリプトが、Point Cloud Manager向けに追加されています。

これは点群活用にとって大きな前進です。

ただし、Potree 2.0への変換は、主に大規模点群をストリーミング表示するための仕組みです。Omniverseの点群拡張も、Potree形式のデータをRTXレンダラーへストリーミングする構成になっています。

したがって、

は、依然として別の処理です。

点数が多すぎる

ドローンや地上型レーザースキャナーで取得した点群は、数千万点から数億点になることがあります。

点群は非常に大きくなりやすく、表示や操作に大きな計算負荷がかかることは、NVIDIAの点群拡張の資料でも説明されています。

これをそのままシミュレーション空間へ持ち込むと、

• 読み込みに時間がかかる

• GPUメモリを大量に使用する

• ビューポートが重くなる

• 物理演算の更新速度が低下する

• 強化学習を並列実行できない

• センサーシミュレーションが遅くなる

といった問題が起こります。

特に強化学習では、同じ環境を何百、何千と複製して試行することがあります。

そのため、現実を細かく再現した高密度点群を、そのまま学習環境として使うのは効率的ではありません。

点群にはノイズ、欠損、不要物が含まれる

現場のLASには、シミュレーションに不要な点も含まれています。

例えば、次のようなものです。

• 植生

• 移動中の車両や人

• 水面の誤計測

• 反射による異常点

• 空中に残った孤立点

• 建物の内側や裏側の欠損

• ドローンから見えなかった部分

• 細い配管や電線

• 一時的に置かれた資材

点群としては現況を正しく表していても、物理演算用の形状にすると穴、突起、段差、壁の欠損などが発生する可能性があります。

NVIDIAの再構成シーン向け資料でも、再構成形状が不完全またはノイズを含む場合、深度情報の精度が保証されず、占有地図の品質はUSDステージ内の衝突形状に依存すると説明されています。

LASは捨てず、役割を分けて使う

点群がIsaac Simでそのまま使いにくいからといって、LASが不要ということではありません。

むしろ、LASは現実空間の記録として非常に重要です。

必要なのは、点群を一つの用途だけで使おうとせず、役割を分けることです。

1．現況確認・証拠用の点群レイヤー

元のLAS／LAZは、測量成果や現況確認のために保持します。

• 実際の形状を確認する

• 断面を計測する

• 過去データと比較する

• 変化箇所を抽出する

• シミュレーション結果を現場へ戻す

このレイヤーは、点群ビューアーやPotree形式などを使って表示します。

2．表示用の軽量3Dレイヤー

点群から表示用メッシュを作成します。

見た目をある程度維持しながら、ポリゴン数やテクスチャを軽量化します。

このレイヤーは、利用者がデジタルツインを見るために使用します。

3．物理演算用の衝突レイヤー

ロボットが接触する地面、壁、階段、段差、障害物を、簡略化したメッシュや高さモデルとして作成します。

このレイヤーには、

• コライダー

• 摩擦

• 反発

• 接触判定

• 通行可能・不可能の属性

などを設定します。

物理演算では、見た目の細かさよりも、安定して接触判定できることが重要です。

Isaac Simの公式資料でも、単純な衝突形状にするほどシミュレーション性能が向上し、接触点を減らすことが大きな効果を持つと説明されています。

つまり、高精細な表示用メッシュと、簡略化した物理用メッシュを分けるべきです。

現実的なLASからIsaac Simへの変換フロー

私が考える現実的な流れは、次のようになります。

ドローン・LiDARで現場を取得
　　　↓
LAS／LAZを保存
　　　↓
対象範囲を切り出す
　　　↓
ノイズ除去・点群分類
　　　↓
地面・構造物・植生・障害物を分離
　　　↓
ローカル座標へ変換
　　　↓
表示用メッシュを作成
　　　↓
物理演算用の簡略メッシュを作成
　　　↓
USDへ変換
　　　↓
コライダー・摩擦・属性を設定
　　　↓
Isaac Simでロボットを走行
　　　↓
学習・検証
　　　↓
結果を実座標へ戻してGISに表示

地面については、用途によってDEM、DSM、ハイトマップ、三角形メッシュなどに変換できます。

建物や設備については、すべてを高精細に再現するのではなく、ロボットの走行やセンサーに影響する形状を優先します。

例えば、ロボットの検証では次の形状が重要です。

• 地面の傾斜

• 段差の高さ

• 階段の踏面と蹴上げ

• 通路幅

• 天井高

• 壁や柱

• 配管

• 穴や溝

• ロボットが接触する障害物

• 方向転換に必要な空間

一方、遠くにある樹木の細かな枝や、走行に影響しない小さな凹凸まで、物理モデルへ入れる必要はありません。

「LASをUSDへ変換するサービス」だけでは足りない

ここで重要なのは、単なるファイル変換ではないということです。

LASをUSDへ変換して画面に表示するだけでは、ロボットシミュレーション用のデジタルツインにはなりません。

必要なのは、

です。

この処理には、測量、点群、GIS、3Dモデリング、物理演算、ロボット制御の知識が必要になります。

逆に考えると、ここは大きな差別化要素になります。

多くの会社は、ロボット本体やAIには詳しくても、現場の点群をどのように取得し、どのように軽量化し、どこまでを物理モデルにすべきかという部分を持っていません。

一方、測量会社や点群処理会社は、現場の取得には強くても、Isaac SimやSim-to-Realまで扱っていない場合があります。

この間をつなぐことができれば、

• 現場計測

• 点群処理

• デジタルツイン作成

• ロボットモデル配置

• 走行可能性検証

• 学習環境作成

• 学習済みモデル作成

• 実機導入支援

• 実機ログの再反映

までを、一連のサービスとして展開できるのではないかと思い日々実験しております。下記動画は当初行ったシミュレーションを外部でも確認できるようにした。

最初に目指すべき範囲

最初から、ロボットの関節制御をすべてAIに任せる必要はないと思います。

まずは、第1段階の行動判断を中心にするのが現実的です。

具体的には、

• 点群から走行可能領域を作る

• スタート地点と目的地点を設定する

• 段差、傾斜、幅員を判定する

• 安全なルートを選ぶ

• 危険箇所で減速する

• 通過できない場所を回避する

• 搭載物による制限を判定する

• シミュレーション結果を報告書にする

という機能です。

その後、対象ロボットのSDKや安全条件が確認できた段階で、第2段階の歩行・姿勢学習へ進みます。

さらに、ロボットアームやヒューマノイドを対象にする場合は、第3段階として移動と作業を組み合わせかと思います。

まとめ

今回の内容を簡単に整理すると、次のようになります。

そして、シミュレーションで学習した内容を実機に戻す範囲には、次の3段階があります。

1. 経路、速度、行動判断を戻す

2. 歩行、関節、姿勢制御を戻す

3. 移動と作業を一体化して戻す

また、ドローンやLiDARから得たLASは、現実空間を記録した重要な点群ですが、そのままでは物理演算用の地面にはなりません。

です。

そのため、元の点群を保持しながら、表示用モデル、物理演算用モデル、GIS・属性情報を分けて作る必要があります。

私は今後、単に見せるだけのデジタルツインではなく、

を目指していきたいと考えています。