Djinious
Real parts, simulation-ready
Every component carries its full record — specification, interfaces, manufacturing source and unit cost, compliance flags — and a functional model. Pick a motor; you also picked its dynamics.
Components library
DjiniousWorkshopSystem integrationFrom product intent to aGPU-verified digital twin.
System integration · GPU physicsIntegratePrepare
DjiniousWorkshop runs your device as a system of functional models — motors, ESCs, battery, flight controller — and closes the loop through NVIDIA Isaac Sim rigid-body physics on the GPU.
DjiniousWorkshop
- Isaac Sim · PhysX 6-DOF
- 6.0.1Isaac Sim · PhysX 6-DOFRun on NVIDIA DGX Spark · GB10
- Gated GPU validation checks
- 4/4Gated GPU validation checksReachability, level hover, analytic agreement — on every merge to the airframe bridge
- Analytic ⇄ Isaac altitude Δ
- < 0.5 mAnalytic ⇄ Isaac altitude ΔOver the hover window
- One image swap
- MIL · SIL · HILOne image swapSame orchestration, same signals, same scopes
What it is
Functional models. Physical 3D simulation. One loop.
Design tools stop at the drawing; physical truth starts after you build. Requirements live in documents, components in spreadsheets, simulation in a separate silo, and real dynamics only appear on the bench. DjiniousWorkshop closes that loop: the part you pick, the system you wire and the physics that validate it are the same record end to end.
The device as a system
Wire the parts into a co-simulation on the canvas — radio, flight controller, ESCs, motors, propellers, battery, airframe — each block a real functional model exchanging real signals.
System canvasIsaac Sim closes the loop
Per-rotor thrust and torque from the functional models drive a 6-DOF PhysX rigid body on the GPU; pose, IMU and GPS stream back into the running system.
NVIDIA Isaac SimContainerized co-simulation
Each functional block runs as its own container on Docker Swarm. Model-, software- and hardware-in-the-loop are the same run with a different image — swappable on a live run.
MIL · SIL · HILValidated on the GPU
A gated end-to-end suite runs the airframe bridge against Isaac Sim — reachability, a level hover and agreement with a deterministic analytic model — before it ships.
RUN_ISAAC_E2EBuild-ready handoff
Bill of materials, interfaces, costs and manufacturing data are already attached to every part — the same model that flew in simulation becomes the package that goes to production.
BOM · PBSInside the product
See it working.
Every capture below is the running product.
01 · Compose
A drone becomes a system, one wire at a time.
Radio, flight controller, ESCs, motors, propellers, battery and airframe — each block a real functional model, wired into one co-simulation on the canvas. Wire it and the co-simulation runs live: real signals, not stand-ins.
- Every block is a real component record with a functional model attached.
- Each component model is a real FMI 2.0 FMU.
- The system you wire on the canvas is the system that reaches the twin.
DjiniousWorkshop
02 · Physics-in-the-loop
Isaac Sim closes the loop on the GPU.
The airframe block hands off to NVIDIA Isaac Sim: per-rotor thrust and torque from the functional models drive a 6-DOF PhysX rigid body, and pose, IMU and GPS stream straight back into the running system — scopes, 3D twin and all.
- Functional models compute thrust, torque and control at every step.
- Isaac Sim's PhysX engine resolves real rigid-body dynamics on the GPU.
- Not a lumped curve fit: full body pose and orientation, native IMU, ground contact and per-rotor wrench — the same interface a real flight stack sees.
DjiniousWorkshop
03 · Digital twin
The physics is real — and we proved it.
Live scopes read airframe position and rate signals streamed back from Isaac Sim. Over the hover window, Isaac’s PhysX altitude tracks a deterministic 6-DOF analytic model to within half a metre — the GPU simulation and first principles agree. The recorded mission is a real take-off, hover and landing computed by the same functional models and Isaac Sim physics.
- Bridge reachability: ping → ok.
- Hover, finite and level: imu_az = 9.81 m/s².
- Isaac ⇄ analytic altitude: Δ < 0.5 m over hover.
- Camera frame: RGBA, rendered on GB10 — suite 4/4 green.
DjiniousWorkshop
04 · Under the hood
One bridge, two physics engines.
The airframe block speaks one small protocol to whatever is computing rigid-body physics underneath it — ping, connect, setInputs, step, getOutputs. Swap the fast analytic 6-DOF model for NVIDIA Isaac Sim’s GPU rigid body and nothing upstream changes — every functional model, every wire on the canvas, every scope — because it is a change to one endpoint, not to the design.
- The same bridge protocol lets a SIL or HIL node drive real software or hardware through an adaptor.
- Isaac Sim doesn't just compute the physics — it renders the scene those bodies live in, on the same GPU.
DjiniousWorkshop
Live digital twin
A recorded flight, replayed in your browser.
Drag to orbit. This is the real closed-loop mission, not an animation.
Real closed-loop mission — takeoff, 2 m hover, climb to 5 m, descent, landing. FMU flight controller + Isaac Sim physics, recorded co-sim states resampled to 10 Hz · 2× playback · no keyframes.
AI & agents
A library agents can work in
The Workshop is API-first: every capability is a typed operation that people, the in-app assistant and external agents call through the same path.
In-app assistant
The assistant can import components from suppliers and help finish a part record in the library.
External agents
An embedded MCP server lets AI agents operate the app over API-key-secured JSON-RPC.
Typed operations
Component search, read, import, propose and approve, simulation start, CFD solve and scene import are published as Provider Interface operations.
Capabilities
What ships in the Workshop
Four working areas around one component warehouse.
Components library4 capabilities
Functions, modules, components
Three layers of abstraction — a function taxonomy, reusable modules, atomic SKUs with strict interfaces — so the same component can sit in different modules and the same module can fulfil different functions.
Typed component classes
Optional parameter schemas per class (for example motor.bldc, sensor.imu, valve.solenoid) validate a part’s specification across mechanical, electrical, electronic, fluidic and software domains.
Assets per part
Thumbnails, USD 3D models, datasheets, EDA schematics and PCBs attached to the component record.
Import from suppliers
Components imported from distributor APIs such as DigiKey, or from shop pages without an API through LLM-driven extraction against the component schema — one code path for the UI, the in-app agent and external agents.
System canvas3 capabilities
Co-simulation diagrams
Blocks, sources, sinks, clocks, scope taps and sw↔hw adaptors wired with the library’s parts into a running system.
Containerized runs
One Swarm service per container node on a shared overlay; live signal values stream to the canvas and the scopes.
Hot swap
Change a single node from MIL to SIL or HIL on a running stack; Swarm performs a rolling update while the run continues.
Aerodynamics1 capabilities
CFD cases
Author an external-aerodynamics case, launch a solve and watch it converge live — geometry, surface-pressure field and residual and force charts, inside the Workshop.
Workspaces and product structure2 capabilities
Simulation workspaces
A workspace links system diagrams, CFD cases and referenced library components without owning them — the same record can belong to more than one workspace.
Product breakdown structure
A project’s product decomposed into assemblies and parts, with part numbers, revisions, quantities, links to library components and a flat BOM export — including parts that are never simulated, such as fasteners and purchased items.
Trust
A governed warehouse
Inbound parts never overwrite a curated one, and every run that reaches the twin is checked on the GPU.
Status lifecycle
Components move proposed → active → deprecated → obsolete, with rejected as a terminal state; illegal transitions are refused.
Provenance
Parts that arrive from another application carry their source application and reference; consumers never see uncurated parts unless they ask.
Gated validation
The GPU end-to-end suite — reachability, level hover, analytic agreement, camera frame — runs on every merge to the airframe bridge.
Guarded bridges
Bridge endpoints for SIL and HIL adaptors are DNS-resolved and refused if they point at loopback, private, link-local or metadata addresses unless explicitly allowlisted.
In the digital thread
What it takes in. What it hands on.
DjiniousWorkshop does its part of the engineering loop and passes its evidence along — and it works just as well on its own.
DjiniousWorkshopSystem integrationOn its own
On its own, DjiniousWorkshop is a component warehouse and a co-simulation bench: bring a real part list, wire it, close the loop through Isaac Sim and see the physics.
Use cases
DjiniousWorkshop in use.
1 worked case.
Book a demo
See it on your problem.
Watch a design meet real physics. Bring a real part list — we’ll wire it, close the loop through Isaac Sim, and show you the physics.
- Your use case
- The component library
- The Isaac-backed digital twin
Along the thread
Works well with
DjiniousEngineeringOrchestrationThe AI systems engineer: it takes the assignment and carries the whole project through a traceable System Ledger.
DjiniousLabModelling & simulationMulti-domain system models, digital replicas and a mathematical toolbox, driven by AI.
DjiniousSafeCertifiable codeLean 4 specifications and kernel-checked proofs turned into panic-free embedded Rust, up to SIL 4.
DjiniousWorkflowAgent automationGraph automation any stage can call on: build a process, run it, watch it and audit it.