NVlabs / NVlabs/ASPIRE

start_perception_servers.sh reports PyRoKi DOWN on a fresh clone: fixed 90s wait is shorter than the first-run example-robot-data download

Open Beginner friendly
#17 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
191
Forks
12
Avg merge
3d 18h
Merged PRs (30d)
1

Description

Summary

scripts/common/start_perception_servers.sh sleeps a fixed 90 s and then probes each port exactly once. On a fresh clone the PyRoKi server needs longer than that, because loading panda_description triggers a first-time clone of example-robot-data (~353 MB). The script therefore prints FAIL port 8116 (PyRoKi): DOWN and exits 1 for a server that comes up and works correctly about a minute later.

Where

scripts/common/start_perception_servers.sh:130WAIT=90, followed by a for i in $(seq $WAIT -10 10) sleep loop and a single curl per port.

Observed

First run on a clean host, following the README setup exactly:

Waiting 90s for models to load...
  Checking servers...
FAIL port 8114 (SAM3): DOWN
OK port 8115 (GraspNet): UP
FAIL port 8116 (PyRoKi): DOWN
  Last 5 lines of /tmp/pyroki.log:
    INFO:pyroki_server:Loading robot URDF 'panda_description' with Pyroki...
    Cloning https://github.com/Gepetto/example-robot-data.git...
Some servers failed. Check the logs above.

Probing the same port roughly a minute later:

port 8116: 404      # i.e. up and serving

and the log shows a clean startup:

INFO:     Uvicorn running on http://127.0.0.1:8116 (Press CTRL+C to quit)

~/.cache/robot_descriptions/example-robot-data is 353 MB after that first run, so this is a first-run-only failure — the second start is fast. That is exactly the fresh-clone path the README documents, though, which is where a new user meets it.

(The SAM3 failure in the same output is unrelated and expected here: this account is not on the facebook/sam3 gated-repo allowlist.)

Suggested fix

Replace the fixed sleep plus single probe with a poll-until-ready loop and an overall deadline, so a slow first start is distinguished from a dead process:

deadline=$((SECONDS + WAIT))
until [[ "$(curl -s -o /dev/null -w '%{http_code}' --max-time 3 "http://127.0.0.1:$port/health")" != "000" ]]; do
  (( SECONDS < deadline )) || { echo "FAIL port $port ($NAME): DOWN"; ...; break; }
  sleep 2
done

A generous deadline for the first run (or a note in the README that the initial PyRoKi start downloads example-robot-data) would also work.

Environment

Fresh clone at f4c8939, Linux x86-64, .venv-libero (Python 3.12), launched via the documented command with --no-molmo.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with scripts/common/start_perception_servers.sh around line 130 and inspect the WAIT loop and port checks. Reproduce the documented fresh-clone launch with --no-molmo, then verify that a slow PyRoKi startup is polled until ready or reported down only after the overall deadline. Confirm the existing server-status output still identifies failed services.

Written by the indexing model from the issue text.

Assessment

Tech stack
bash, python
Domain
devops
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
78/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.