teleop --cameras and collect-data. Both commands grab and encode the cameras entirely on the GPU via almond_axol.video.gst_zed: the zed-gstreamer source elements (zedxonesrc / zedsrc) feed the Jetson hardware NVENC (nvvidconv / nvv4l2h264enc), and an in-process appsink pulls the encoded H.264 access units (for the headset view) and raw frames (for the dataset). WebRTC transport itself stays on aiortc (a normal Python dependency) — this command does not install the webrtcbin/libnice path.
apt-installs the GStreamer tools/plugins and the GObject-introspection typelibs + build deps (gstreamer1.0-tools,gstreamer1.0-plugins-bad,gir1.2-gstreamer-1.0,gir1.2-gst-plugins-base-1.0,libgirepository1.0-dev,gobject-introspection,libcairo2-dev,pkg-config).- Builds PyGObject (
pygobject>=3.50,<3.52) into the axol environment so the in-process pipeline can readappsinkbuffers. PyGObject is not a usable PyPI wheel (it builds against the system gobject-introspection), so it can’t be a normal dependency — the same reasonzed.installbuildspyzedhere. - Verifies its own deliverables — that PyGObject can import
gi+GstApp(theappsinkreader) and that the NVENC elements (nvvidconv,nvv4l2h264enc) are present — and fails if any are missing. The NVENC elements aren’tapt-installable; they ship with the Jetson L4T BSP. The zed-gstreamer source elements (zedxonesrc/zedsrc) are not gated here — they’re built separately bygst.build-zed, which the one-command install runs right after this command, so their absence is expected on a first install and is reported only as an informational note (not a warning).
teleop / serve startup — those entry points just run; install (the source-plugin build gst.build-zed and the Jetson clock setup jetson.setup) is owned by the installer.
Best-effort and idempotent: it skips when the stack is already present, and is a no-op on machines without
apt-get. When the gst stack is unavailable the cameras fall back to the ZED Python SDK grab path (higher latency).