automationkriz/syncro_multi_agente
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: rettifica - BUG 1 era falso allarme (mio errore in script python), chiarito comportamento _applyJoint sul child

Browse Source
This commit is contained in:
Marco
2026-06-09 16:46:26 +00:00
parent c82495c13f
commit ce0c076bea
1 changed files with 19 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
BRIDGE_NOTES.md
View File

@@ -80,25 +80,16 @@ Lato consumer (`automation_kriz`) ho aggiunto una pagina di ispezione live a `/l
Ispezionando l'export attuale (`329 joints, 28 asBuiltJoints, 9 motionLinks, 20 rigidGroups`) ho trovato tre problemi che impediscono al viewer di propagare il movimento sull'asse X (e probabilmente anche Y e PEN dipendono dagli stessi pattern). Servono fix lato `ExportKinematicGraph.py`.
### BUG 1 — `rigidGroups[].occurrences` è SEMPRE vuoto
### BUG 1 — ~~`rigidGroups[].occurrences` è SEMPRE vuoto~~ FALSO ALLARME
Tutti i 20 gruppi rigidi esportati hanno `occurrences: []`. Esempio dal file corrente:
```json
[
{"name": "Gruppo rigido 6", "occurrences": []},
{"name": "Gruppo rigido 17", "occurrences": []},
...
]
**Ritiro questo punto.** Era un errore nel mio script Python di diagnostica a terminale (avevo scritto `rg.get('occurrences', [])` invece di `rg.get('occurrenceNames', [])`), poi ho copiato la conclusione qui sopra senza ricontrollarla. Verifica fatta:
```
Keys di un rigid group: ['name', 'occurrenceNames', 'occurrencePaths', 'isSuppressed', 'isLightBulbOn', 'includeChildren']
Gruppo rigido 6 contenuto: ['end stop X PIastrina:1', 'binario SX:1', 'Cinghia T5:1']
```
Nel `BRIDGE_NOTES` precedente è scritto che `Gruppo rigido 6` doveva contenere `end stop X PIastrina:1 | binario SX:1 | Cinghia T5:1`. Nell'export reale quelle occorrenze NON ci sono. Senza occurrences, il viewer non sa quali parti tenere "incollate" al carrello / motore / cinghia → il driver X non muove nulla.
Possibili cause da verificare nell'add-in:
- Si itera `rigidGroup.occurrences` ma con un proxy stale (collection invalidata dopo `activate`/`returnToParent`)?
- Si guarda `nativeObject.occurrences` invece di farla risolvere via `assemblyContext`?
- Si filtra accidentalmente per `occ.isLightBulbOn` o `isSuppressed`?
Verifica veloce: in console Fusion durante export stampare `len(list(rg.occurrences))` per ogni `rg` in `rootComp.allRigidGroups` e confrontare con quello che finisce nel JSON.
Il JSON è conforme al contratto §2.3 (`occurrenceNames` + `occurrencePaths`). Anche `FusionRig.js` e `KinGraphPage.jsx` lato viewer leggono già correttamente `g.occurrenceNames`. Quindi BUG 1 non esiste, scusa il rumore.
### BUG 2 — `Collegamento movimento 14` (driver X) ha `joint1: null`
@@ -126,18 +117,21 @@ Nel BRIDGE_NOTES precedente è scritto "ignorabili, propagazione passa dai rigid
Fisicamente è il motore stepper che è fissato al telaio e fa girare la puleggia. Nel JSON è il contrario. Il viewer applica sempre la rotazione al `child` mantenendo fermo il `parent`, quindi vede il motore ruotare nel vuoto e la puleggia (che dovrebbe seguire) sta ferma.
Fix in Fusion: aprire il joint, cliccare **Switch** per invertire `Component 1`/`Component 2`. Sospetto valga anche per gli altri driver — andrebbero controllati tutti e cinque con questo criterio:
- `parent` = pezzo che resta solidale al telaio (o al precedente livello cinematico)
- `child` = pezzo che si muove rispetto al parent
**Risposta alla domanda "il viewer applica al child?"**: sì, lo applica al `child` (più tutti i compagni del/dei rigid group che contengono il child). Codice in `FusionRig.js#_applyJoint` + `_worldDelta`:
```js
// d.origin viene dal joint, d.axis dal joint, d.child dal joint
const T1 = new THREE.Matrix4().makeTranslation(d.origin.x, d.origin.y, d.origin.z);
const R = new THREE.Matrix4().makeRotationAxis(d.axis, value);
const T2 = new THREE.Matrix4().makeTranslation(-d.origin.x, -d.origin.y, -d.origin.z);
// la matrice ottenuta viene poi applicata a `child` e a tutti gli oggetti in `rigidComponent`
```
Quindi sì, serve premere `Switch` in Fusion. Stessa verifica da fare per `Motore asse Y`, `Asse Penna `, `asse Z pneumatico M5?` e `Motore A` (asBuilt): controllare per ognuno che `child` = il pezzo che si muove rispetto al telaio del livello precedente, `parent` = il pezzo solidale al livello precedente.
In ogni caso il fix è **lato Fusion**, non lato codice viewer.
### Patch temporanea lato viewer (in valutazione, non ancora applicata)
Se i fix 1-3 lato Fusion richiedono tempo, lato viewer posso aggiungere:
- una mappa `viewerOverrides.json` con `{ jointName: { swapParentChild: true } }` per simulare il fix BUG 3 senza modificare l'export
- una mappa `viewerRigidGroups.json` con i contenuti che `Gruppo rigido N` dovrebbe avere, in attesa del fix BUG 1
- una mappa `viewerMotionLinks.json` per ricostruire i `joint1` mancanti del BUG 2
Sono workaround sporchi: preferisco fixare l'export quando possibile e tenere il viewer privo di patch ad-hoc. Fammi sapere se preferisci che proceda comunque con gli override per sbloccare le demo nel frattempo.
~~Override `viewerOverrides.json` / `viewerRigidGroups.json` / `viewerMotionLinks.json`.~~ Saltato. Visto che BUG 1 non esiste e BUG 2 non è bloccante per i driver puri (la propagazione passa dai rigid groups, che ora il viewer legge correttamente), aspetto solo il fix Fusion del BUG 3 e proviamo subito.
### Per gli altri driver