v13s/tancho-generator-v5

Tancho Generator — router v5 research release

A reproducible research baseline for generating numeric observation viewpoints. Developed in Japan by Vox, Tokyo; compute provided by Nebius AI Cloud. Released September 14, 2026.

This release contains two fine-tuned checkpoints and a deterministic input-based router. “v5” is the routing-policy version, not a fifth checkpoint or the upstream model version. It remains a reproducible historical research baseline. As of 22 September 2026 it is not used by Tancho's completed fixed-scene SITL reference path. The older Tancho release contains different weights and a different output protocol; its 21/40 result is not this release's metric.

Status after release

The selected fixed-scene completion path now uses a Hosted Reasoner to decide whether another observation is required, then compiles the requested view from trusted scene geometry. It made zero Generator calls while completing inspect → reobservation flight → no_action → return in one PX4/Gazebo mission. All eight frozen completion gates passed. See POST_RELEASE_STATUS.md.

That path is retained as a safety and integration baseline, not as the final Tancho architecture. The project objective requires a fine-tuned open-weight Cosmos 3 Edge Generator to generate the required observation set in the flown loop. The next candidate will use separate Reasoner and Generator contracts from one Cosmos 3 Edge derivative checkpoint: the Reasoner names the unanswered mission question, and the Generator emits a strict, versioned observation program describing the required view relationships. Trusted deterministic code will compile that program into exact viewpoints and routes. The model will not be asked to choose among artificial route candidates or emit coordinates.

Later Generator work did not replace the weights in this repository. A strict exact-coordinate candidate reached 31/32 on its outline set and 127/128 on its regression set, missing the predeclared 32/32 adoption gate. A separately frozen action-only evaluation reached 0/32 because every native response added forbidden structure. Neither path was adopted or flown. No checkpoint, router, saved output or reported v5 score in this repository changed.

On 22 September, a separate Observation Program v4 candidate was trained from a newer pinned Cosmos3-Edge parent. It uses one checkpoint for Reasoner and Generator roles and emits semantic observation requirements rather than numeric viewpoints. It reached 32/32 on a development set and 32/32 on a subsequently generated, single-attempt synthetic final set, including 16/16 paired image contrasts. Those v4 weights are not in this repository. Independent real-image final evaluation, fresh model-in-loop SITL, Orin NX measurement and public-package reproduction are still open, so this result does not qualify Release 1 or change the v5 claims below. Synthetic-final manifest SHA-256: db5ad7a152f0c25a9cea1e401b4a6fe195d610f7db23f3301e3cfd98c6654d80; raw-output-set SHA-256: 6a04ff494f0ce12844446929b19831105e1bd3c891180bed00ff73ec1d90ad9c.

What it does

Given a reference image and trusted numeric context (current/target coordinates, target size, required pixels, viewing direction, approved volume, speed and mission-time limits), the Generator emits a JSON list:

[{"offset_m": [0.0, 20.0, 15.0], "dwell_ms": 2000, "speed_mps": 3.0}]

This is a format illustration, not a certified plan. offset_m is the displacement from the target in local ENU metres; add the target position to obtain the viewpoint. The other fields are dwell milliseconds and outbound speed in m/s. A separate validator checks the unchanged answer.

This application Generator uses Cosmos's autoregressive tower. It does not train the application's Reasoner role (deciding what to observe), use the diffusion tower to produce a continuous camera trajectory, or execute flight control. The intended architecture remains observation objective → viewpoint sequence → detailed camera/aircraft trajectory → flight control.

Exactly what is released

Component	Path	Role
mixed240	checkpoints/mixed240/	Default viewpoint generation
balanced288	checkpoints/balanced288/	Eligible stationary observations only
router v5	tancho/viewpoint_router.py	Select once before inference
validators and pinned-backend helpers	tancho/, training/, run_request.py	Preserve raw output and check geometry
saved-output evidence	evidence/	Re-score the reported v5 answers without new inference

Each checkpoint is the original 31-file retained export (4,905,905,551 bytes), including the fine-tuned AR tower and frozen vision encoder. The two exports total 9,811,811,102 bytes before code and documentation. Framework configuration/assets in the exports do not mean diffusion/VAE weights were fine-tuned or that the export alone is a full Cosmos multimodal snapshot. Loading uses the pinned Cosmos Framework and base-overlay procedure in REPRODUCE.md, not a plain transformers.from_pretrained call or an HF-hosted inference endpoint.

Router eligibility requires all of:

• Remaining mission time after return margin is exactly 1, 2, or 3 seconds.
• Trusted-input preflight is undetermined rather than an established invalid/infeasible request.
• Conversion of the current position to relative coordinates and back is exact.
• A current-position, 1000 ms stationary validation probe passes every check.

Eligible inputs use balanced288 with an explicit current-relative-position input. All other inputs use mixed240 and the original relative-coordinate prompt. The probe is only an eligibility check; it is not returned as a model answer. There is one generation per request, without answer repair, retry, or cross-model fallback. The 1/2/3 seconds describe remaining mission budget, not inference latency or flight-control frequency. The included snapshot also contains older explicit policies and protocol helpers as dependencies; only viewpoint-router-v5 is the advertised release. Neither move432 nor the experimental timing-input router is released here.

Measured results and unresolved failures

Success means passing the contract and all evaluated numerical geometry/envelope checks together. These results are from the fixed v4-versus-v5 comparison on September 13, 2026.

Evaluation group	Cases	v4 accepted	v5 accepted
New stationary, 1-second budget	64	56	60
New stationary, 2-second budget	64	53	60
New stationary, 3-second budget	64	53	60
Previously evaluated stationary regression cases	128	111	122
Movement required	64	15	15
Normal numeric conditions	224	221	221
Current viewpoint valid, 4-second boundary	32	0	0
Current position on the wrong side	32	0	0

New stationary success is 180/192 (93.75%), with 22 paired improvements and 4 regressions against v4. This is not overall accuracy. The 352 cases outside the stationary branch had identical raw outputs across policies. All 1,344 original generations and their input/model identities were audited; the original GPU and temporary disk were deleted. The adopted implementation passed 93 related CPU tests.

The movement and boundary failures remain unresolved. balanced288 had previously failed a broad deployment comparison due to movement regression; v5 adopts it only within the stationary branch. Later movement/timing experiments do not change these weights or results.

The 544 new numerical geometries were not in earlier packs; 128 cases are explicitly reused regression cases. Reference images reuse the existing evaluation split. Normal cases are 28 base scenes × 8 symmetry transformations, not 224 independent flights. Numerical geometry is synthetic and is not tied to reconstructed objects in the images. Camera scoring uses a fixed 3840-pixel width and 81-degree field of view. Passing does not establish image understanding, occlusion handling, actual image quality, field generalization, or flight safety. The evaluation informed adoption and is not an untouched external certification set.

Since release: one saved answer flown in simulation

Between September 14 and 15, 2026 the saved v5 answer for one request was flown in PX4 v1.16.2 and Gazebo Harmonic software-in-the-loop, on an airframe matched to a Holybro X650 in dimensions, mass, gimbal range and field of view. The viewpoints, dwell times and observation attitudes are the model's; the separate trajectory layer recompiled the flight under the vehicle's climb and descent limits, which lengthens the mission from the answer's 36.1 s to 123.0 s.

Seven runs of an identical payload: six valid, and every valid run passed its pre-registered gates. One run is invalid because two PX4 modules stopped publishing at arming, a simulator defect whose upstream fix is not in v1.16.2. Over the valid runs the observation-window heading error was −1.52° to +0.60°, the panel's horizontal image centre stayed inside the ±24 px gate (5–19 px off centre, explained by the estimated heading), and truth-referenced position tracking stayed within 0.114 m of the commanded path.

This exercises the downstream path (viewpoints → trajectory → flight control) in simulation only. The model is not run in the loop, the checkpoints and the router are unchanged, and real flight remains unvalidated. The simulation records are not part of this release.

Training provenance

Both runs started independently from pinned pretrained nvidia/Cosmos3-Edge revision a9d944e2c6a1bf9f48b92ad16348e70c5f1836ba; neither continues the retired parent-40 fine-tune.

Item	mixed240	balanced288
Training examples	480 mixed numeric cases	576 cases: 480 normal + 96 time-constrained
Epochs / updates	4 / 240	4 / 288
Learning rate / gradient accumulation	1e-6 / 8	1e-6 / 8
Evaluated retained export	Final 240-update export	Final 288-update export

For each model, 233 AR tensors were trainable and 437 vision tensors were frozen. Verification of 670 exported tensors is not a claim that all 670 were trained. Numerical teachers come from the project's geometry/planning code, not human-reviewed observation decisions. Training uses reference tiles from public GSI Omachi footage, with evaluation tiles separated within the same flight. The synthetic geometry varies independently of the reference imagery. See SOURCES.md.

Use and release verification

See REPRODUCE.md for download, CPU saved-answer rescoring, request preparation, and the pinned CUDA backend procedure. smoke.py re-scores 672 previously generated v5 answers; it makes zero model calls and does not measure fresh accuracy. Release verification checks exported bytes and downloaded package behavior; it does not add a new performance benchmark or a Jetson measurement.

Intended runtime is Jetson Orin NX 16GB, but latency, memory use with two checkpoints, and device deployment remain unmeasured. No learned-model real-flight execution has been validated. Upstream capabilities cannot be transferred into claims about this fine-tune.

The current fixed-scene SITL completion is a system-integration result, not an additional benchmark for these weights. It must not be combined with the v5 acceptance counts above as if they shared a test set or metric.

Licenses and attribution

Weights and upstream model artifacts retain OpenMDW 1.1. Original Vox code, documentation, and synthetic evaluation records are under MIT; third-party terms remain applicable to their artifacts. NOTICE.md records scope and attribution. No source footage, extracted frames, client materials, credentials, or complete internal run archives are distributed. NVIDIA, Nebius, and GSI do not endorse this release.

Contact: tancho@vox.delivery