Buying XR is easy. Making it actually train someone is not.

Most XR training projects fail in the same place. The headsets arrive, the environment looks impressive, and nobody can say whether anyone learned anything. Bring me your XR project and we will work out what it actually has to do, how it fits the training pipeline you already run, and how you prove it changed readiness. Then I help you build it on Varjo headsets, from requirements through integration to the day your instructors run it themselves. I have written training requirements inside a General Command and run laser engagement and synthetic training systems as an instructor, so the conversation starts from how units actually train.

Site under construction

I am adding studies and tools as they are ready. Some material is currently available in Polish only. If something you need is missing here, write to me.

Where to meet me

MSPO 2026, Kielce, 8 to 11 September. Varjo will have a stand at the exhibition and I will be there, on the defense and simulation side. If you are going, it is the easiest place to walk through a project face to face.

Arrange a meeting
15+ yearsDefense and military training
Former officerPolish Armed Forces
Both sidesRequirements writer & instructor
Wrocław, PLWorking across Europe
What I do

From your idea to a working Varjo-based trainer

01

Training gap analysis

Before anyone buys anything: what your training pipeline actually fails to deliver, and whether XR is the right instrument for it. Sometimes the honest answer is that it is not.

  • Mapping the existing pipeline, from classroom to live exercise
  • Where throughput, cost, risk or repeatability break down
  • What XR realistically replaces, and what it never will
  • Where a low-cost trainer protects a much larger capital programme
02

Solution design and requirements

Turning a training need into a specification an engineer can build and a procurement officer can evaluate. This is the step most projects skip, and it is why they drift.

  • Learning objectives translated into system requirements
  • Fidelity decisions: where realism matters and where it wastes budget
  • Varjo headset selection matched to the task, plus tracking and integration choices
  • Acceptance criteria written around training outcomes, not specifications
03

Building it together on Varjo

Development partnership with integrators, OEMs and training centres putting Varjo XR into their products and training rooms. I work as the training-domain side of the team, not as an outside reviewer.

  • Scenario and curriculum design grounded in real tactical procedure
  • Integration with simulators and training systems already in service
  • Bridge and part-task trainers alongside full-mission systems
  • Iterative validation with instructors and end users during development
04

Measuring training effectiveness

The question everyone eventually gets asked and almost nobody can answer. It is the area I follow most closely in the research literature, applied to your system.

  • Eye-tracking as a measure of attention, workload and expertise
  • Cognitive load assessment and objective readiness indicators, a working prototype to look at
  • Adaptive scenarios that adjust to the trainee in real time
  • Before and after comparison against conventional training
05

Rollout, adoption and instructor enablement

The part most XR programmes underfund, and the reason so many headsets end up in a cupboard. A system nobody has trained the instructors to use will be judged a failure regardless of how good it is. I stay on after delivery: embedding the system into the training curriculum, training the instructors who will run it every week, building the evaluation loop that keeps it improving, and reporting outcomes in a form the organisation funding it can actually read. For a first XR deployment this determines whether there is ever a second one.

Use case

What a vehicle crew trainer project actually looks like

This is not a client reference and names no customer. It is the pattern: the shape these projects take, the decisions that determine whether they work, and the places they usually go wrong. Land systems are where I am most at home, so this is the example worth writing down.

The situation

A unit is converting to a new infantry fighting vehicle or tank. Three crew roles, commander, gunner and driver, each needing different skills and different amounts of repetition. One full-mission simulator exists or is on order, and it trains one crew at a time. Several hundred soldiers have to be converted. Live training on the vehicle is expensive, weather-dependent and rationed by ammunition and range availability. The delivery schedule does not wait for any of this.

How the pieces fit together

SHARED SYNTHETIC ENVIRONMENT One tactical picture, one terrain, one scenario Commander Physical controls, kept real XR visual and environment Situational picture Gunner Physical controls, kept real XR visual and environment Fire control Driver Physical controls, kept real XR visual and environment Motion cueing NETWORKED: THREE STATIONS BECOME ONE CREW INSTRUCTOR STATION Scenario control, live monitoring, after-action review, recorded performance data
Reference architecture, not a product. Where the split between physical and virtual falls, and whether the instructor station and after-action review are treated as core rather than optional, is what separates a training device from a demonstrator.

XR trainer

GUNNER’S SIGHT PICTURE STAB DETECTION RANGING 1,850 m FIRE HIT 1 2 3 4 5
Schematic drawing, not a product and not a specific customer installation. It illustrates one decision from the section above: which parts of a crew station have to remain physical, and which can move into XR without training loss.
  • 1. XR headset
  • 2. Original gunner control handles
  • 3. Station geometry
  • 4. Seat
  • 5. Motion platform

Decisions that determine the outcome

  • What stays physical, what becomes virtual. Controls the crew operates under stress should stay physical. The rest of the environment can move into XR without training loss.
  • Which crew station you build first. Gunner and commander usually return the most training value per euro. The driver needs motion cueing and costs the most.
  • Individual or collective. Networked stations turn three separate trainers into a crew trainer, and crew coordination is where the real capability sits.
  • Motion or no motion. It matters for the driver and for vehicle-behaviour cues. For gunnery and procedural work it often adds cost without adding learning.
  • What the instructor sees. Without a usable instructor station and after-action review, you have a demonstrator, not a training device.

Where these projects usually go wrong

  • Fidelity is written as hardware parameters instead of training objectives, so the system is impressive and trains the wrong thing
  • The synthetic environment is chosen before the training requirement is written, and everything afterwards bends to fit it
  • Nobody names who runs the device week to week, so it becomes dependent on one enthusiast and dies when they post out
  • Instructors get two days of training at handover and nothing after that
  • Nothing is measured, so when the funding question arrives there is no answer beyond opinion

What good looks like

Crews reach the vehicle already knowing the procedures, so range time is spent on what only live training can teach. Throughput stops being capped by a single simulator. Instructors run the system themselves, without a call to the supplier. And the organisation can show what changed, in numbers, when it is asked to justify the next purchase. That last point is what buys the second system, and it is the part most programmes never prepare for.

The same pattern, with different variables, applies to bridge trainers in a delivery gap, procedural stations ahead of a full-mission simulator, and unmanned platform operator training. If your project looks like any of these, the first conversation will be short and useful. For what this class of system looks like once it is fielded, Varjo documents driving, gunnery, heavy weapons and JTAC training with primes including Rheinmetall, BAE Systems and Patria: Varjo, land operations training.

Use case

What an unmanned platform operator station built on XR looks like

This is not a client reference and names no customer. It is a pattern for companies that deliver ground control stations, autonomy and command systems to the military. You own how the platform behaves and where its data comes from. This material is about the layer that gets built last: what the human sees, and when they have to decide.

The situation

The customer adds unmanned platforms faster than it adds people. Every platform type arrives with its own station, its own screen layout and its own operator. The command centre or station container fills up with screens, space, power and hands run short, and the operator learns three consoles instead of one. Meanwhile your autonomy is mature enough to run the task on its own, so the operator spends most of the mission watching a system that does not need them, and is then expected to be sharp in the one minute when it does. The question asked at every demonstration is always the same: how many people do I have to seat at these platforms. The answer depends not on the autonomy, but on how the station is built.

How the pieces fit together

YOUR LAYER: AUTONOMY AND DATA EXCHANGE The same for air, ground and surface platforms Air platform Autonomy flies the task Sensor feed and detections Raises exceptions only Ground platform Autonomy drives the route Sensor feed and detections Raises exceptions only Surface platform Autonomy holds the course Sensor feed and detections Raises exceptions only THE SAME WAY OF WORKING IN EVERY DOMAIN MY LAYER: THE OPERATOR STATION IN AN XR HEADSET Fleet board, take-over view, decision request and log, training mode on the same interface
Concept drawing, not a product. The split of responsibility is deliberately sharp. You keep the autonomy, the sensors and the data exchange. I own what the human sees and how they confirm a decision. I take no piece of your system, I add the one that usually nobody wants to build.

Three zones of attention

ZONE 2. CENTRE OF ATTENTION, ABOUT 30 DEGREES DRIVING VIEW VEHICLE 0.87 HDG 274 · SPD 11 km/h 34U DA 35621 48119 the feed is here, the map is at the side ZONE 1. PERIPHERY, NO INTERACTION Video latency 140 ms Driving: semi-autonomous Roll 9 degrees FPV, azimuth 040, 00:22 ZONE 3. ON DEMAND MAP 300 m trafficability, route friendlies in sector sensor footprint ZONE 3. ON DEMAND OTHER PLATFORMS Tarantula 02 moving MULES 01 halted take over control FIELD OF VIEW 120 BY 105 DEGREES
The rule that orders the whole layout. If a piece of information does not change what the operator does in the next ten seconds, it is not in the periphery. If it does not change a decision within ten minutes, it is not in the centre. Everything else waits dimmed at the side and brightens under the operator's gaze. A flat monitor gives you one plane and tabs, so this rule cannot be enforced on it.
  • 1. Periphery, at most three fixed elements plus whatever may interrupt
  • 2. Centre, about 30 degrees, the only place viewed consciously
  • 3. Side panels dimmed, brightened by gaze

Operator station

FIXED DISPLAYS THE STATION NO LONGER NEEDS FLEET BOARD ! TAKE-OVER VIEW DECISION REQUEST AND LOG Observe, hand over, report SUPERVISING EXCEPTION RAISED TAKING OVER ONE PLATFORM DECISION REQUESTED, THEN LOGGED 1 2 3 4 5
Schematic drawing, not a product and not a specific installation. It illustrates one decision from the section below. The controls stay physical, the screens disappear from the station, and through the headset cameras the operator keeps seeing their real workstation and the people beside them.
  • 1. XR headset with passthrough
  • 2. Physical controls, kept real
  • 3. Fleet board, one tile per platform
  • 4. Take-over view for one platform
  • 5. Decision request to the commander, and the log

What XR brings to the station

  • Peripheral awareness recovered. In remote operation the operator does not feel the roll, hear the drivetrain, or see anything out of the corner of the eye. A 120 by 105 degree field of view puts roll, latency and autonomy mode exactly where the brain looks for them. On a 27-inch monitor the periphery is an office wall, and there is nowhere to place that information.
  • Layers instead of tabs. The three attention zones only work when the interface has depth and sides. On a flat screen every extra panel takes space away from the driving view, so information discipline dies at the first requirements review.
  • Readability without zooming. Fifty-one pixels per degree is enough to read a detection, the coordinates and the weapon state in one glance. The same effect on monitors means several large screens per seat, and a command centre has many seats.
  • Gaze and gesture instead of clicking. Eye tracking at 200 Hz lets the operator expand a panel with a look and confirm with a pinch, so the hands stay on the controls. Directional audio gives the azimuth of a threat before the operator has seen anything at all.
  • Eye tracking as a sensor of the operator's state. The same eye-tracking channel that drives the interaction also measures how the operator is working. The system sees whether the latency indicator and the turret sector are being scanned at all, whether attention has narrowed into a tunnel on the driving view, and it estimates cognitive load from the dynamics of eye movement and pupil response. No monitor or mouse produces this signal, and in the headset it is built in and needs no extra hardware. How to compute these indicators is shown in a working prototype: measuring cognitive load from eye tracking.
  • Fatigue visible before it becomes an error. Over a long shift, the frequency of peripheral scanning drops and reaction time to exceptions grows. The system can show this to the shift leader and recommend swapping in a rested operator, before fatigue turns into a rolled-over machine or a missed contact. Crew rotation stops being a supervisor's intuition and becomes a decision based on measurement.
  • Contact with the surroundings. The operator works far from the platforms, in a command centre or a station container. The headset cameras show the real joystick, the notepad and the neighbouring stations, so the operator hears and sees the rest of the shift, can take an order from a superior and hand the station over to a successor without removing the headset. Without this, the headset isolates the operator from the team, and that is the first objection raised in any evaluation.
  • Shared session and replay. The operator and the commander can work on the same object, and the whole session can be replayed from any participant's perspective, including the gaze trace. After the exercise the instructor sees not only what the operator did, but what they were looking at before they did it, and what they never noticed. Replay is what training centres buy, and what you use to prove a requirement was met.
  • A second product from the same code. The station connected to a simulation is a ready-made operator trainer, so training stops taking hours away from the real platforms.
  • One device, many different people. With rotating operators, the same station serves a dozen people across shifts. Automatic interpupillary adjustment from 56 to 72 millimetres, support for prescription glasses and a design meant for shared use make an operator change a matter of seconds, not a separate service problem.

Decisions that determine the outcome

  • A station for a rotating crew. Operators change, so the interface has to be learnable in hours, and the station shows what running the platforms requires, not the picture of the whole operation.
  • Supervision instead of piloting. If the operator has to drive every platform individually, the number of stations grows with the amount of equipment. If the autonomy runs the task and raises exceptions, one person covers several platforms, and that stops being a promise in a proposal and becomes a parameter you can measure.
  • The definition of an exception. Low classification confidence, a target near a no-fire area, a weakening link, energy running out. This list has to be settled at the start, because it, not the interface graphics, determines the operator workload.
  • The driver is not the decider. The person at the controls drives the machine. The decision to use an effector is made by a soldier with the mandate to make it, and that is where the authorisation and the log entry with author and time live. The operator station therefore sends a request with the target data filled in, and does not have an engage button.
  • What stays physical. What the operator touches under stress stays within reach. The screens move into the headset and stop taking up space and power at the station. Camera passthrough keeps contact with the rest of the shift, so the operator is not cut off from what happens beside them.
  • The same interface for training. The station connected to a simulation is a ready-made operator trainer. Training stops taking hours away from the real platforms, and you get a second product from the same code.

Where these projects usually go wrong

  • The interface gets built last, from whatever budget and time remain, and it is what gets judged at the demonstration
  • Every platform brings its own station, so instead of one console you end up with a room full of consoles
  • The interface shows everything at once, so the operator is overloaded when nothing is happening and lost in the moment that matters
  • A weakening link only shows after the fact, because the last known position looks the same as the current one
  • Nothing is logged, so after the exercise there is no way to reconstruct who decided what, or to prove a requirement was met

I work solely on the human-machine layer, on Varjo hardware, and I do not compete with you for the autonomy, the platforms or the contract. I come in as the partner responsible for the operator station, from requirements and the demonstration scenario, through integration with your ground station, to documentation and instructor training. If you are building a ground control station and wondering whether XR adds anything beyond an effect at a trade fair, the first conversation will be short and useful. For what this class of system looks like once it is fielded, Varjo documents driving, gunnery, heavy weapons and JTAC training with primes including Rheinmetall, BAE Systems and Patria: Varjo, land operations training.

Studies and tools

Material you can open right now

Three studies built on open sources and two tools that calculate on your own numbers. Everything runs in the browser, with no login and nothing sent to a server, every formula is written out, and none of it names a supplier. If you believe a figure is wrong, write to me, I will correct it and record the correction.

How many people need training and how many stations that takes

Land equipment under contract in fifteen countries of Central, Eastern and Northern Europe, converted into crew positions, training hours and the number of trainer stations required, broken down by equipment category and by country.

10,883armoured, artillery and support vehicles under contract
36,439crew positions to be trained
170trainer stations on the default assumptions

Four assumptions move on sliders: hours per crew, years to train the fleet, station hours per year and personnel turnover. Both tables recalculate live. At zero turnover it comes out at about fifty stations; at thirty per cent, over three hundred. Same fleet, different decision.

Open the study

The training hour gap for tank crews

A comparison of gunner training programmes in Poland, the United States and Germany on source documents. The Polish programme provides for no gunnery trainer hours at all. The American one sets a standard of four hours a month per crew and concedes that real availability is 3.75. The bottleneck turns out to be familiarisation with the vehicle rather than gunnery, and that is the part of the programme easiest to move off the tank.

Open the study

XR training cost and throughput calculator

Derives the cost of an hour on the equipment and an hour on an XR station from your own numbers, then shows how many crews a year you would train and what is actually limiting you. None of the defaults are claims about your market, they are just a starting point to replace.

Open the calculator Talk through your own numbers

Measuring cognitive load from eye tracking

A research prototype. An animation shows what happens in an operator's eye during a task, and the tool below it turns an eye tracking recording from a Varjo headset into a load index over time. No headset to hand, so there is a full set of demo data one click away. Along with the list of things the method cannot do, because in pupillometry that list matters more.

Open the prototype

XR or a projection dome. How to choose a simulator display

XR headsets against projection domes as the visual system of a training simulator. Cost per station, floor space, mobility, team training, integration with a motion platform and what each option lets you measure. It does not name a winner, it sets out the criteria on which the decision actually turns, because the honest answer depends on what you are training.

Open the study

About

I have been on every side of this table

I started as a mechanised infantry platoon commander in the 20th Bartoszyce Mechanised Brigade, responsible for a platoon of soldiers, their vehicles and their readiness. Then three years commanding a cadet platoon, and five years as an academic teacher at the Military University of Land Forces in Wrocław, leading the tactical laser simulation team: instrumented field exercises on Saab GAMER, classes in the VBS synthetic environment, system maintenance, and procurement specifications for new training equipment. Those years in uniform are why I know what a training unit actually needs on a Tuesday morning, as opposed to what a capability roadmap says it needs.

I then served at the General Command of the Polish Armed Forces, as a major and specialist in the Training Devices Division of the Training Inspectorate. I worked on the Tactical Simulators of the Modern Battlefield programme for armoured and mechanised forces and advised on requirements for the Comprehensive Battlefield Simulation System (KSSPW). That is where I learned how a requirement is written, who quietly influences it, and why a technically superior system can still lose.

Since 2023 I have been on the commercial and technology side, working with motion platforms and, today, Varjo XR across defense, aerospace and industrial training customers in Poland, the Baltics, the Nordics and wider CEE. That means seeing what integrators are actually building, which hardware choices hold up in a training centre, and which XR projects deliver and which quietly stall.

That combination is the point. Plenty of people can build an XR environment, and plenty understand military training, but the two rarely sit in the same head. Projects fail in the gap between them: a beautiful simulation that trains the wrong thing, or a sound training concept implemented in a way instructors will not use. That gap is where I work.

I work in English and Polish, from Wrocław, across Europe.

Research interest

Making XR training measurable

Alongside the commercial work I follow one question closely, and intend to pursue it as doctoral research: everyone agrees XR trains people, but almost nobody can prove how well, or adapt the training to the individual while it is happening. It is the same question clients keep running into, which is why I keep reading in it rather than treating it as a side interest.

Adaptive tactical XR scenarios driven by eye-tracking and AI

Armies are fielding equipment faster than they can field the trainers for it. Existing XR simulators deliver environmental realism but have no real-time adaptation layer based on what the trainee is actually doing with their attention. The direction I am working towards integrates immersive XR, eye-tracking and an adaptive engine so that a tactical scenario reshapes itself in real time to the operator's cognitive load and skill level, validated experimentally against conventional training.

Cognitive load theory Endsley situation awareness Pupillometry Intelligent tutoring systems Manned-unmanned teaming Training effectiveness measurement

The operator station of an unmanned turret

In an unmanned turret the operator has no direct vision. All situational awareness arrives through a single image. Move that image into a headset and you move the entire perceptual channel, not part of it. What remains are three groups of physical elements between which the operator has to divide attention, and that is exactly what makes the distribution of attention measurable.

where the station display was WHERE THE OPERATOR LOOKS SIGHT PICTURE HAND CONTROLLER PANELS 1 2 3 4 5
Schematic drawing based on open descriptions. Panel placement is indicative, and the content of the sight picture is not reproduced, because that needs first-hand source material.
  • 1. XR headset where the station display was
  • 2. Wheel-type hand controller
  • 3. Weapon and fire mode selection panel
  • 4. System panels
  • 5. Station inside the hull, with no direct vision

Applied focus

  • Operators of automated weapon systems and turrets, including the ZSSW-30 station on the BORSUK IFV
  • Teleoperated unmanned ground platforms, where the operator works from an indirect camera image
  • Integration of XR headsets with national simulation systems already in service
  • Cost-effectiveness of XR training against conventional and full-mission alternatives

Why it matters for the work

It keeps the advice grounded in evidence rather than assumptions. When a client asks whether XR will actually improve readiness, which effect sizes the literature supports, or how to write a procurement that measures training outcomes instead of headset specifications, that is the same ground.

From theory to workbench

None of the above is only a plan. A piece of that workbench can be looked at today: a prototype measuring cognitive load from eye tracking data, with the formulas written out and an honest list of what the method cannot do. It also sits in the Studies and tools section above.

Work in progress

Nothing below is published yet. These are drafts I am preparing for conference submission in 2027, listed so you can see where my thinking is going rather than as a publication record.

  • Eye-tracking and artificial intelligence in adaptive XR training of unmanned platform operators. Literature review, in draft.
  • Immersive XR in the training and readiness assessment of civil protection and civil defence personnel. Conference chapter, in draft.
  • When the headset sees more than the instructor. Popular science article on VR, eye-tracking and AI in training, in draft.
  • Earlier academic articles and scientific conference organisation during the university lecturer period, 2016 to 2021.
Approach

How an engagement usually runs

STEP 01

Intro call

Thirty minutes on your project. What you train, where the pipeline is failing, and what you have already tried. If XR is the wrong answer for it, I will say so on that call.

STEP 02

Scoped assessment

Your training gap mapped against what XR can and cannot solve, with a concrete recommendation and a rough cost envelope. Useful even if we stop there.

STEP 03

Build and rollout

Requirements, the Varjo hardware that fits them, development alongside your team, effectiveness measurement and rollout. Delivered in phases, with a review at each milestone.

Contact

Bring me your XR project

Whether you are scoping a first XR trainer, building XR into a product, or holding headsets you cannot yet prove are working, tell me what you are trying to train and I will tell you how to get there on Varjo. The first call is free and reasonably direct.