Specify the event the application must recognise
Start with a plain description: a person enters a zone, a hand reaches a target, an object is lifted or a visitor presses a button. Then state what should happen on screen and how quickly it needs to feel responsive. “Add a tracking camera” leaves the required information and behaviour undefined.
A sensor supplies observations. Software interprets them and connects them to the experience. A camera that produces a useful image does not automatically deliver the body positions or product identities required by your application. Ask the tracking supplier to describe the complete chain.
Compare classes by task
| Class | Information it can provide in a suitable system | Question to test |
|---|---|---|
| RGB camera with vision software | Image-based detections or recognised features | Does the chosen software recognise the required action in the real scene? |
| Depth camera with tracking software | Distance information and application-dependent spatial interpretation | Are the required body parts or objects usable throughout the action? |
| Proximity or presence sensor | A defined nearby or occupied state | Does the threshold trigger at the intended visitor position? |
| Physical switch or contact input | A deliberate action at a known control | Does one action produce one clear response and a reliable release? |
| Tagged object or dedicated controller | An identified object or control signal, depending on the system | Can the guest use it naturally and can staff reset it for the next session? |
A simple trigger can be a good choice when the concept only needs a simple trigger. More detailed sensing is useful when the experience actually needs the additional information. Ask what complexity is removed or added for the guest and operator.
Depth cameras are not one interchangeable technology
RealSense describes stereo depth as using two camera views to calculate depth. Orbbec describes its Femto Bolt time-of-flight method as deriving depth from emitted and returned near-infrared light. Read the stereo overview and the ToF explanation. These are different measurement approaches; neither description selects a universal event winner.
Have the supplier verify the exact model, software, mode and environment. Orbbec's SDK documentation explicitly separates supported devices, firmware and platforms. Its compatibility information illustrates why the software combination matters. A substitute sensor should be accepted through the application's tests, not solely through a matching connector.
Worked example: a reactive product display
Imagine a hypothetical display with two possible behaviours. In the first, an animation starts whenever a visitor approaches a marked area. In the second, the visitor moves a hand to select and manipulate one of three virtual product parts.
The first brief needs a reliable presence decision, a clear activation boundary and sensible behaviour while someone remains nearby. Ask whether a simple presence sensor meets the requirement before commissioning full-body interpretation. Test passers-by and a guest who stops at the boundary.
The second brief needs richer spatial information and an interaction design. Request a prototype showing the actual hand actions with the intended screen and sensor. Check incorrect selections, a lost hand and the response when two people reach in. The more complex behaviour brings software and testing work as well as hardware choices.
Make calibration visible through acceptance tasks
Ask the team to demonstrate that physical positions map to the intended screen responses. For a spatial selection, mark representative test positions and verify the displayed target at each. For a presence trigger, approach from the intended route, pause and leave. Do not judge calibration only by a technical status indicator.
Record the accepted camera position, scene layout and software version. If the sensor or target surface moves, ask which checks must be repeated. Keep an operator procedure for recovery when the application loses its input, and test that procedure before opening.
Questions for a proposal
What observation is required and what should the application do with it?
Which hardware, software and licences are included?
What space, lighting, surfaces and participant behaviour will be tested?
How are false triggers, lost tracking and additional people handled?
Who calibrates, accepts and resets the installed system?
Send the action description and layout through interactive installation design. Request a small proof of the uncertain behaviour before committing to the full visual build.