Hi, and thank you for releasing this great work! We have been trying out InternDataEngine for a potential large-scale rollout and would appreciate your guidance on whether our observed throughput and failure patterns are expected under the published task configurations.
Across more than 100k plan calls, the overall plan success rate was 43.4%, while persisted trajectory time represented only 20.5% of the provisioned GPU time. We also observed strongly task-dependent IK/trajectory failures, along with recurring camera mounting/API compatibility warnings.
We are using the pipe mode provided in the codebase, with 1 plan worker and 1 render worker per GPU. Our environment details and observations are described below.
Environment and hardware
| Component |
Value |
| GPUs |
4 × 8 RTX 5090 |
| OS |
Ubuntu 24.04.2 LTS; kernel 5.10.134-013.5.kangaroo.al8.x86_64 |
| NVIDIA driver |
570.153.02; CUDA 12.8 |
| Isaac Sim |
5.1.0 |
| CuRobo |
0.7.4.post1.dev1+dirty |
| Python / PyTorch |
Python 3.11.15; PyTorch 2.7.1+cu128 (CUDA 12.8) |
Note: We used Isaac Sim 5.1.0 because we encountered rendering issues with Isaac Sim 4.1.0 on RTX 5090 GPUs.
Core issue
The main concern is low compute-to-product efficiency. Across the 36-hour observation window, persisted trajectory time amounted to only 20.5% of provisioned GPU time, while 42.2% of planning time produced no sequence. Because persisted episodes are counted before camera and other downstream quality filtering, the true usable product/input ratio may be lower.
| Metric |
Observed value |
| Plan success rate |
43.4% across more than 100k plan calls |
| Persisted trajectory / provisioned GPU time |
20.5% |
| Trajectory produced per GPU-hour |
12.3 min |
| Persisted trajectory / planning time |
30.0% |
| Planning time producing no sequence |
42.2% |
Approximately 70.7% of failed plan calls were attributed to IK/reachability failures (MotionGenStatus.IK_FAIL or KPAM_IK_NO_SOLUTION). We are not yet sure about the root cause, but our current hypothesis is that some combinations of randomization ranges and keypoint constraints may occasionally lead to unreachable targets with our current Isaac Sim setup. We would appreciate confirmation of the expected throughput and the recommended task- and embodiment-specific settings.
Hi, and thank you for releasing this great work! We have been trying out InternDataEngine for a potential large-scale rollout and would appreciate your guidance on whether our observed throughput and failure patterns are expected under the published task configurations.
Across more than 100k plan calls, the overall plan success rate was 43.4%, while persisted trajectory time represented only 20.5% of the provisioned GPU time. We also observed strongly task-dependent IK/trajectory failures, along with recurring camera mounting/API compatibility warnings.
We are using the
pipe modeprovided in the codebase, with 1 plan worker and 1 render worker per GPU. Our environment details and observations are described below.Environment and hardware
5.10.134-013.5.kangaroo.al8.x86_64570.153.02; CUDA 12.8Note: We used Isaac Sim 5.1.0 because we encountered rendering issues with Isaac Sim 4.1.0 on RTX 5090 GPUs.
Core issue
The main concern is low compute-to-product efficiency. Across the 36-hour observation window, persisted trajectory time amounted to only 20.5% of provisioned GPU time, while 42.2% of planning time produced no sequence. Because persisted episodes are counted before camera and other downstream quality filtering, the true usable product/input ratio may be lower.
Approximately 70.7% of failed plan calls were attributed to IK/reachability failures (
MotionGenStatus.IK_FAILorKPAM_IK_NO_SOLUTION). We are not yet sure about the root cause, but our current hypothesis is that some combinations of randomization ranges and keypoint constraints may occasionally lead to unreachable targets with our current Isaac Sim setup. We would appreciate confirmation of the expected throughput and the recommended task- and embodiment-specific settings.