Back to Details

vss-deploy-detection-tracking-3d

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

VSS Deploy Detection & Tracking — 3D (RTVI-CV-3D)

VSS 部署检测与跟踪 — 3D版（RTVI-CV-3D）

Bring up the RTVI-CV-3D stack from the warehouse blueprint: per-camera DeepStream perception (
vss-rtvi-cv-mv3dt
) + BEV Fusion (
vss-rtvi-cv-bev-fusion
) + mosquitto MQTT bus + broker + VST sensor stack — without the agent / LLM / VLM stack that comes with the full warehouse blueprint.
The actual compose machinery lives in 
deploy/docker/industry-profiles/warehouse-operations/warehouse-mv3dt-app/
. This skill drives the env overrides, calibration chain, and verification.
从仓库蓝图启动RTVI-CV-3D栈：基于单摄像头的DeepStream感知（
vss-rtvi-cv-mv3dt
） + BEV Fusion（
vss-rtvi-cv-bev-fusion
） + mosquitto MQTT总线 + 代理 + VST传感器栈 —— 不包含完整仓库蓝图中的agent/LLM/VLM栈。
实际的编排机制位于
deploy/docker/industry-profiles/warehouse-operations/warehouse-mv3dt-app/
。本技能负责环境变量覆盖、校准流程链和验证工作。

Routing

路由逻辑

Ask the user at most four questions, then dispatch.
最多向用户提出四个问题，然后进行调度。

Q0 — Profile size (overlays or not)

Q0 — 配置文件规模（是否包含叠加层）

Default to extended unless the user explicitly asks for minimal. Extended deploys ELK + 
vss-video-analytics-api-mv3dt
+ 
vss-kibana-init-mv3dt
+ 
vss-import-calibration-output-mv3dt
on top of MV3DT core — these are what the VST video wall needs to render bounding-box overlays. Without them, the video wall works but shows raw streams without overlays.
User answer
MINIMAL_PROFILE
What you getWhen to choose
extended (default)
""
MV3DT core + ELK + analytics API + Kibana. Overlays work in VST video wall. Recommended for a complete e2e experience."I want the full e2e experience", "I want to see bounding boxes", or no preference stated
minimal
"true"
MV3DT core only. ~5 fewer containers. No overlays in VST. Metadata still on Kafka/Redis."I only need the data", "edge / Thor host", "minimum footprint"
Note on selective ELK: there's no "minimal + ELK only" middle path in the current compose. Every 
${MINIMAL_PROFILE:+_extended}
-gated service comes up together (ES, Logstash, Kibana, video-analytics-api, kibana-init, import-calibration). 
bash
's 
:+
parameter expansion produces the 
_extended
suffix when 
MINIMAL_PROFILE
is set; extended switches the gating string back to plain 
bp_wh_kafka_mv3dt
which the active compose profile already matches. Either you accept the full extended bundle or you stay minimal.
默认采用extended（扩展版），除非用户明确要求minimal（精简版）。扩展版在MV3DT核心基础上额外部署ELK + 
vss-video-analytics-api-mv3dt
+ 
vss-kibana-init-mv3dt
+ 
vss-import-calibration-output-mv3dt
—— 这些是VST视频墙渲染边界框叠加层所需的组件。如果没有这些组件，视频墙仍可工作，但仅显示原始流，无叠加层。
用户回答
MINIMAL_PROFILE
部署内容适用场景
extended（默认）
""
MV3DT核心 + ELK + 分析API + Kibana。VST视频墙支持叠加层显示。推荐用于完整端到端体验。用户需求为“我想要完整端到端体验”、“我想看到边界框”，或未明确说明偏好时
minimal
"true"
仅MV3DT核心。少约5个容器。VST无叠加层。元数据仍存储在Kafka/Redis中。用户需求为“我只需要数据”、“边缘/Thor主机”、“最小资源占用”时
关于选择性ELK的说明：当前编排中没有“精简版+仅ELK”的中间选项。所有由
${MINIMAL_PROFILE:+_extended}
控制的服务会一起启动（ES、Logstash、Kibana、视频分析API、Kibana初始化、校准导入）。
bash
的
:+
参数扩展会在
MINIMAL_PROFILE
设置时生成
_extended
后缀；扩展版会将控制字符串切换回原始的
bp_wh_kafka_mv3dt
，与当前激活的编排配置文件匹配。要么接受完整扩展包，要么保持精简版。

Q1 — Data source

Q1 — 数据源

Ask this unless the source is explicit in the user's first message. A bare request like "deploy rtvi-cv-3d" does not imply 
sample
.
  • sample — the bundled 4-camera synthetic dataset (
    warehouse-4cams-20mx20m-synthetic
    ). Calibration ships in-tree; no AMC run needed.
  • videos — the user has local video files (any 
    *.mp4
    named after their cameras). Standalone AMC (
    auto_calib
    profile) will run if calibration is missing.
  • rtsp — the user has live RTSP URLs. Calibration via VIOS-driven AMC.
除非用户首次消息中明确指定数据源，否则需询问此问题。类似“deploy rtvi-cv-3d”的简单请求不代表使用
sample
（样本数据）。
  • sample — 内置的四摄像头合成数据集（
    warehouse-4cams-20mx20m-synthetic
    ）。校准数据已内置，无需运行AMC。
  • videos — 用户拥有本地视频文件（所有以摄像头命名的
    *.mp4
    文件）。如果缺少校准数据，将运行独立AMC（
    auto_calib
    配置文件）。
  • rtsp — 用户拥有实时RTSP地址。通过VIOS驱动的AMC完成校准。

Q2 — Calibration coverage (skip for 
sample
)

Q2 — 校准覆盖情况（样本数据场景跳过）

For 
videos
and 
rtsp
, check whether calibration is already on disk at the mount path the perception container expects:
bash
DATASET="${SAMPLE_VIDEO_DATASET:?}"          # the user's dataset slug; see Q3
CAL_DIR="${VSS_APPS_DIR}/industry-profiles/warehouse-operations/warehouse-mv3dt-app/calibration/sample-data/${DATASET}"
对于
videos
和
rtsp
场景，检查感知容器期望挂载路径下是否已存在校准数据：
bash
DATASET="${SAMPLE_VIDEO_DATASET:?}"          # 用户的数据集标识；见Q3
CAL_DIR="${VSS_APPS_DIR}/industry-profiles/warehouse-operations/warehouse-mv3dt-app/calibration/sample-data/${DATASET}"

Look for ANY of: calibration.json, plus camInfo/*.yml or *.yaml with either

检查是否存在以下任一文件：calibration.json，以及camInfo/目录下命名为'cam_'或'Camera'的*.yml或*.yaml文件（内置样本使用Camera*.yml，AMC可能生成cam_*.yaml —— 需扩大匹配范围）

'cam_' or 'Camera' naming (the shipped sample uses Camera*.yml, AMC may

—

produce cam_*.yaml — broaden accordingly)

—
test -f "${CAL_DIR}/calibration.json"
&& ls "${CAL_DIR}/camInfo/"*.{yml,yaml} 2>/dev/null

If the user supplied a calibration path themselves, validate that path instead — don't recompute. See `configure-cameras.md` for the authoritative camera-count discovery (parses `calibration.json`).
test -f "${CAL_DIR}/calibration.json"
&& ls "${CAL_DIR}/camInfo/"*.{yml,yaml} 2>/dev/null

如果用户自行提供了校准路径，则验证该路径即可 —— 无需重新计算。有关摄像头数量检测的权威说明，请参阅`configure-cameras.md`（解析`calibration.json`文件）。

Q3 — Detector + dataset slug (only when Q2 triggers AMC)

Q3 — 检测器+数据集标识（仅当Q2触发AMC时询问）

  • resnet
    (default, fast) or 
    transformer
    (slower, better under occlusion) — passed to the AMC 
    /v1/calibrate/<id>
    API at Step B (see 
    vss-generate-video-calibration/SKILL.md:48-62
    ).
  • A short kebab-case dataset slug used as 
    SAMPLE_VIDEO_DATASET
    (e.g. 
    customer-aisle-4cams
    ). This drives the calibration mount path and gets persisted in 
    .env
    .
  • resnet
    （默认，速度快）或
    transformer
    （速度慢，但遮挡场景下效果更好）—— 在步骤B传递给AMC的
    /v1/calibrate/<id>
    API（详见
    vss-generate-video-calibration/SKILL.md:48-62
    ）。
  • 短横线格式的数据集标识，用作
    SAMPLE_VIDEO_DATASET
    （例如
    customer-aisle-4cams
    ）。该标识会驱动校准挂载路径，并持久化到
    .env
    文件中。

Routing table

路由表

Q1Q2 resultPath
sample
(cal ships in-tree)
references/deploy-rtvi-cv-3d-stack.md
 directly
videos
cal present
references/deploy-rtvi-cv-3d-stack.md
 directly
videos
cal missing
references/calibration-workflow.md
 (videos mode) → 
references/configure-cameras.md
 → 
references/deploy-rtvi-cv-3d-stack.md
rtsp
cal present
references/deploy-rtvi-cv-3d-stack.md
 directly
rtsp
cal missing
references/calibration-workflow.md
 (rtsp mode) → 
references/configure-cameras.md
 → 
references/deploy-rtvi-cv-3d-stack.md
Every path converges on 
references/verify-and-view.md
 once 
up -d
completes. 
references/troubleshooting.md
 and 
references/teardown.md
 are linked but off the happy path.
Disambiguation rule. If the user mentions "warehouse" without "mv3dt" / "3D tracking" / "multi-view", consider routing to 
../vss-deploy-profile/references/warehouse.md
 instead — that's the full warehouse blueprint (2D / 3D / MV3DT + agents). This skill is for MV3DT only without the agent stack / LLM / VLM.
Q1Q2结果路径
sample
校准数据已内置直接跳转至
references/deploy-rtvi-cv-3d-stack.md
videos
校准数据已存在直接跳转至
references/deploy-rtvi-cv-3d-stack.md
videos
缺少校准数据跳转至
references/calibration-workflow.md
（视频模式）→ 
references/configure-cameras.md
 → 
references/deploy-rtvi-cv-3d-stack.md
rtsp
校准数据已存在直接跳转至
references/deploy-rtvi-cv-3d-stack.md
rtsp
缺少校准数据跳转至
references/calibration-workflow.md
（RTSP模式）→ 
references/configure-cameras.md
 → 
references/deploy-rtvi-cv-3d-stack.md
完成
up -d
指令后，所有路径都会收敛到
references/verify-and-view.md
。
references/troubleshooting.md
和
references/teardown.md
为关联文档，但不属于主流程。
歧义消除规则：如果用户提到“warehouse”但未提及“mv3dt”/“3D tracking”/“multi-view”，则考虑路由至
../vss-deploy-profile/references/warehouse.md
 —— 该文档对应完整仓库蓝图（2D/3D/MV3DT + agents）。本技能仅针对不含agent栈/LLM/VLM的MV3DT。

Prerequisites

前置条件

1. Repo path

1. 仓库路径

Locate 
video-search-and-summarization/
on disk. All compose commands run from 
<repo>/deploy/docker/
. If unknown, ask the user.
在磁盘上找到
video-search-and-summarization/
目录。所有编排命令均从
<repo>/deploy/docker/
目录运行。如果路径未知，请询问用户。

2. NGC CLI + key

2. NGC CLI + 密钥

$NGC_CLI_API_KEY
must be set. Both 
nvidia/vss-core/*
and 
nvstaging/vss-core/*
are valid orgs depending on which the user's key resolves to. See 
vss-deploy-profile/references/ngc.md
for setup if missing.
If the user previously ran 
ngc config set
but 
$NGC_CLI_API_KEY
isn't exported in this shell, the key is already on disk:
bash
NGC_CLI_API_KEY=$(awk -F'= ' '/^apikey/{print $2}' ~/.ngc/config 2>/dev/null)
test -n "${NGC_CLI_API_KEY}" && echo "key sourced from ~/.ngc/config"
Make sure the key value also lands in 
industry-profiles/warehouse-operations/.env:164
(
NGC_CLI_API_KEY=...
) — compose only reads it from there at 
up
time, not from your shell env.
必须设置
$NGC_CLI_API_KEY
。
nvidia/vss-core/*
和
nvstaging/vss-core/*
均为有效组织，具体取决于用户密钥对应的组织。如果缺少密钥，请参阅
vss-deploy-profile/references/ngc.md
进行设置。
如果用户之前已运行
ngc config set
但当前shell中未导出
$NGC_CLI_API_KEY
，则密钥已存储在磁盘上：
bash
NGC_CLI_API_KEY=$(awk -F'= ' '/^apikey/{print $2}' ~/.ngc/config 2>/dev/null)
test -n "${NGC_CLI_API_KEY}" && echo "key sourced from ~/.ngc/config"
确保密钥值也写入
industry-profiles/warehouse-operations/.env:164
（
NGC_CLI_API_KEY=...
）—— 编排仅在
up
阶段从此文件读取密钥，而非从shell环境读取。

3. 
HARDWARE_PROFILE
slug

3. 
HARDWARE_PROFILE
标识

The canonical 
HARDWARE_PROFILE
keys live in 
industry-profiles/warehouse-operations/blueprint-configurator/blueprint_config.yml
(lines 592–642). Use the slug from the table below — e.g. on an RTX A6000 (Ampere) host the value is 
RTXA6000
.
Pick from 
nvidia-smi --query-gpu=name --format=csv,noheader
:
GPU name
HARDWARE_PROFILE
MV3DT 
max_streams_supported
RTX PRO 6000 Blackwell
RTXPRO6000BW
18
H100 (NVL, SXM HBM3)
H100
13
RTX A6000 Ada Generation
RTXA6000ADA
6
L40S
L40S
7
L4
L4
2
RTX A6000 (Ampere)
RTXA6000
2
IGX Thor
IGX-THOR
7
DGX Spark
DGX-SPARK
4
The per-GPU MV3DT cap is enforced at deploy time. 
vss-configurator-mv3dt
computes 
final_stream_count = min(NUM_STREAMS, max_streams_supported)
and applies a 
keep_count
file-management op against 
${VSS_DATA_DIR}/videos/${SAMPLE_VIDEO_DATASET}/
so only 
final_stream_count
.mp4
files remain (sorted lexicographically, last N kept). If your GPU's 
mv3dt
cap (above table) is below your camera count, perception / 
mdx-raw
/ 
mdx-bev
run with the cap's worth of streams. Either pick a GPU with a higher cap or surface the cap explicitly to the user so they're aware which streams will be processed.
标准
HARDWARE_PROFILE
密钥位于
industry-profiles/warehouse-operations/blueprint-configurator/blueprint_config.yml
（第592–642行）。请使用下表中的标识 —— 例如，在RTX A6000（Ampere）主机上，值为
RTXA6000
。
从
nvidia-smi --query-gpu=name --format=csv,noheader
的输出中选择：
GPU名称
HARDWARE_PROFILE
MV3DT 
max_streams_supported
RTX PRO 6000 Blackwell
RTXPRO6000BW
18
H100 (NVL, SXM HBM3)
H100
13
RTX A6000 Ada Generation
RTXA6000ADA
6
L40S
L40S
7
L4
L4
2
RTX A6000 (Ampere)
RTXA6000
2
IGX Thor
IGX-THOR
7
DGX Spark
DGX-SPARK
4
每个GPU的MV3DT上限会在部署阶段强制执行。
vss-configurator-mv3dt
会计算
final_stream_count = min(NUM_STREAMS, max_streams_supported)
，并对
${VSS_DATA_DIR}/videos/${SAMPLE_VIDEO_DATASET}/
执行
keep_count
文件管理操作，仅保留
final_stream_count
个
.mp4
文件（按字典序排序，保留最后N个）。如果GPU的mv3dt上限（如上表）低于摄像头数量，则感知/
mdx-raw
/
mdx-bev
会以上限数量的流运行。请选择上限更高的GPU，或明确告知用户上限情况，让其了解哪些流会被处理。

4. App data on disk

4. 磁盘上的应用数据

VSS_DATA_DIR
must point at the extracted 
vss-warehouse-app-data
directory (separate from the repo). Pointing it at the repo's 
deploy/docker/
causes the deploy to stall: the configurator can't find the dataset, redis can't open its log file, and perception stays in 
Created
. Verify the path before deploy.
Pre-flight check before deploy:
bash
DATA_DIR="${VSS_DATA_DIR:?VSS_DATA_DIR not set in .env}"
DATASET="${SAMPLE_VIDEO_DATASET:-warehouse-4cams-20mx20m-synthetic}"

for sub in videos models data_log; do
  test -d "${DATA_DIR}/${sub}" || { echo "ERROR: ${DATA_DIR}/${sub} missing"; exit 1; }
done
VSS_DATA_DIR
必须指向已解压的
vss-warehouse-app-data
目录（与仓库分离）。如果指向仓库的
deploy/docker/
目录，部署会停滞：配置器无法找到数据集，Redis无法打开日志文件，感知服务会停留在
Created
状态。部署前请验证路径。
部署前预检：
bash
DATA_DIR="${VSS_DATA_DIR:?VSS_DATA_DIR not set in .env}"
DATASET="${SAMPLE_VIDEO_DATASET:-warehouse-4cams-20mx20m-synthetic}"

for sub in videos models data_log; do
  test -d "${DATA_DIR}/${sub}" || { echo "ERROR: ${DATA_DIR}/${sub} missing"; exit 1; }
done

For sample / videos modes — videos directory must exist

样本/视频模式下 —— videos目录必须存在

test -d "${DATA_DIR}/videos/${DATASET}"
|| { echo "ERROR: ${DATA_DIR}/videos/${DATASET} missing — wrong slug or app-data not extracted"; exit 1; }
test -d "${DATA_DIR}/videos/${DATASET}"
|| { echo "ERROR: ${DATA_DIR}/videos/${DATASET} missing — wrong slug or app-data not extracted"; exit 1; }

Sanity: video count should match calibration count.

sanity检查：视频数量应与校准数量匹配。

Some published app-data tarballs are known to ship the sample dataset with

部分已发布的app-data压缩包中的样本数据集视频数量可能少于数据集名称暗示的数量 —— 请验证，如果GPU的mv3dt上限足够高，可单独补充缺失的摄像头视频。

fewer videos than the dataset name implies — verify and source any missing

—

cams separately if your GPU's mv3dt cap is high enough to use them all.

—
ls "${DATA_DIR}/videos/${DATASET}/"*.mp4 2>/dev/null | wc -l
ls "${DATA_DIR}/videos/${DATASET}/"*.mp4 2>/dev/null | wc -l

Ensure every per-service subdir under data_log/ exists, then open perms.

确保data_log/下的每个服务子目录都存在，然后设置权限。

kafka / elasticsearch / redis run as different non-root UIDs against

kafka/elasticsearch/redis以不同的非root UID运行在绑定挂载的主机路径上 —— 没有777权限的话，守护进程会因“Permission denied”（kafka cluster_id）、“AccessDeniedException”（ES）或“Can't open the log file”（Redis）而退出。chmod 777是官方文档推荐的修复方法；请勿递归执行chown —— 请参阅data-directory.md了解每个UID的原理。

bind-mounted host paths — without 777 the daemons exit with

—

"Permission denied" (kafka cluster_id), "AccessDeniedException" (ES),

—

or "Can't open the log file" (redis). chmod 777 is the documented fix;

—

do NOT recursive-chown — see data-directory.md for the per-UID rationale.

—
mkdir -p
"${DATA_DIR}/data_log/analytics_cache"
"${DATA_DIR}/data_log/calibration_toolkit"
"${DATA_DIR}/data_log/elastic/data"
"${DATA_DIR}/data_log/elastic/logs"
"${DATA_DIR}/data_log/kafka"
"${DATA_DIR}/data_log/redis/data"
"${DATA_DIR}/data_log/redis/log" chmod -R 777 "${DATA_DIR}/data_log"

> **Easy miss, hard to recover from.** The `mkdir -p` + `chmod -R 777` step
> on `${DATA_DIR}/data_log` is required, not optional. Newly extracted
> `vss-warehouse-app-data` trees are owned by the extracting user (whoever
> ran `tar -xvf`) and container UIDs won't match. The deeper per-container
> UID table lives in [`../vss-deploy-profile/references/data-directory.md`](../vss-deploy-profile/references/data-directory.md);
> the same doc explains why recursive chown is the wrong fix.

If app-data isn't extracted yet: download via `ngc registry resource download-version "nvidia/vss-warehouse/vss-warehouse-app-data:<version>"` and `tar -xvf` (see [`references/deploy-rtvi-cv-3d-stack.md`](references/deploy-rtvi-cv-3d-stack.md) for tag discovery and full steps).
mkdir -p
"${DATA_DIR}/data_log/analytics_cache"
"${DATA_DIR}/data_log/calibration_toolkit"
"${DATA_DIR}/data_log/elastic/data"
"${DATA_DIR}/data_log/elastic/logs"
"${DATA_DIR}/data_log/kafka"
"${DATA_DIR}/data_log/redis/data"
"${DATA_DIR}/data_log/redis/log" chmod -R 777 "${DATA_DIR}/data_log"

> **易遗漏且难以恢复的步骤**：对`${DATA_DIR}/data_log`执行`mkdir -p` + `chmod -R 777`是必填步骤，而非可选。新解压的`vss-warehouse-app-data`目录归解压用户所有（即运行`tar -xvf`的用户），而容器UID与之不匹配。更详细的容器UID表位于[`../vss-deploy-profile/references/data-directory.md`](../vss-deploy-profile/references/data-directory.md)；该文档还解释了为何递归chown是错误的修复方法。

如果app-data尚未解压：通过`ngc registry resource download-version "nvidia/vss-warehouse/vss-warehouse-app-data:<version>"`下载并执行`tar -xvf`（标签查找和完整步骤请参阅[`references/deploy-rtvi-cv-3d-stack.md`](references/deploy-rtvi-cv-3d-stack.md)）。

5. Pre-flight (system)

5. 系统预检

nvidia-smi
, NVIDIA Docker runtime visible (
docker info | grep -i runtimes
), and 
docker run --rm --gpus all ubuntu:24.04 nvidia-smi
all green. Full driver / kernel / sysctl checks live in 
vss-deploy-profile/references/prerequisites.md
.
If any check fails, fix before continuing — don't proceed to deploy.
nvidia-smi
、NVIDIA Docker runtime可见（
docker info | grep -i runtimes
），且
docker run --rm --gpus all ubuntu:24.04 nvidia-smi
运行正常。完整的驱动/内核/sysctl检查请参阅
vss-deploy-profile/references/prerequisites.md
。
如果任何检查失败，请先修复再继续 —— 不要进行部署。

6. Browser reachability (cloud / corp-VPN hosts only)

6. 浏览器可达性（仅云/企业VPN主机）

If the user will view the VST video wall through a browser on a different network than the deploy host (cloud VM, corp VPN, ssh-tunnelled session), upstream firewall rules may block VST WebRTC (STUN to 
stun.l.google.com:19302
, plus random UDP for media). See 
references/verify-and-view.md#browser-reachability
 for symptoms and workarounds. Also: some hosts block the AMC microservice's default port (TCP/8010); if the user reports the AMC UI on 
:5000
works but its data calls fail, retry with a different 
VSS_AUTO_CALIBRATION_PORT
.
如果用户将通过不同网络的浏览器查看VST视频墙（云虚拟机、企业VPN、SSH隧道会话），上游防火墙规则可能会阻止VST WebRTC（连接
stun.l.google.com:19302
的STUN，以及随机UDP媒体流）。有关症状和解决方法，请参阅
references/verify-and-view.md#browser-reachability
。另外：部分主机会阻止AMC微服务的默认端口（TCP/8010）；如果用户报告AMC UI在
:5000
可访问但数据调用失败，请尝试更换
VSS_AUTO_CALIBRATION_PORT
。

How it fits together

组件关联关系

SKILL.md (this file — Q0/Q1/Q2/Q3 routing)
  └─ if cal missing ─> calibration-workflow.md
  │                     └─ chains to vss-generate-video-calibration (deploy + drive API)
  │                     └─ fetches /v1/result/{project_id}/mv3dt_result?result_type=amc
  │                     └─ lands calibration files at warehouse-mv3dt-app/calibration/sample-data/<slug>/
  ├─> configure-cameras.md (NUM_STREAMS sync, VST sensor trim)
  └─> deploy-rtvi-cv-3d-stack.md (compose up with bp_wh_kafka_mv3dt + extended/minimal)
        └─> verify-and-view.md (FPS, fusion_ready, mdx-bev, VST video wall + WebRTC checks)
SKILL.md（本文档 —— Q0/Q1/Q2/Q3路由）
  └─ 缺少校准数据时 ─> calibration-workflow.md
  │                     └─ 链接到vss-generate-video-calibration（部署+驱动API）
  │                     └─ 获取/v1/result/{project_id}/mv3dt_result?result_type=amc
  │                     └─ 将校准文件存储到warehouse-mv3dt-app/calibration/sample-data/<slug>/
  ├─> configure-cameras.md（NUM_STREAMS同步，VST传感器裁剪）
  └─> deploy-rtvi-cv-3d-stack.md（使用bp_wh_kafka_mv3dt + 扩展/精简版启动编排）
        └─> verify-and-view.md（FPS、fusion_ready、mdx-bev、VST视频墙+WebRTC检查）

Related Skills

相关技能

  • vss-generate-video-calibration
     — the AMC skill. Owns the 
    auto_calib
    compose profile, calibration API, and the 
    /v1/result/.../mv3dt_result
    export hook this skill consumes. 
    calibration-workflow.md
    chains into it.
  • vss-deploy-profile
     — cross-profile umbrella. Use that instead when the user wants the full warehouse blueprint (with agents / LLM / VLM), not just MV3DT.
  • vss-manage-video-io-storage
     — VIOS / VST API skill. Useful for the VST video wall (overlay viz) and for sensor management referenced in 
    configure-cameras.md
    .
The repo's authoritative warehouse-blueprint reference at 
../vss-deploy-profile/references/warehouse.md
 covers 2D / 3D / MV3DT inside the full warehouse stack — this skill is the MV3DT-only companion that trims the agent / LLM / VLM layer.
  • vss-generate-video-calibration
     — AMC技能。负责
    auto_calib
    编排配置文件、校准API，以及本技能调用的
    /v1/result/.../mv3dt_result
    导出钩子。
    calibration-workflow.md
    会链接到该技能。
  • vss-deploy-profile
     — 跨配置文件总览技能。当用户需要完整仓库蓝图（包含agents/LLM/VLM）而非仅MV3DT时，请使用该技能。
  • vss-manage-video-io-storage
     — VIOS/VST API技能。适用于VST视频墙（叠加层可视化）和
    configure-cameras.md
    中提及的传感器管理。
仓库中权威的仓库蓝图参考文档位于
../vss-deploy-profile/references/warehouse.md
，涵盖完整仓库栈中的2D/3D/MV3DT —— 本技能是仅MV3DT的配套技能，移除了agent/LLM/VLM层。