Systems · Automation-Derived Position Data

Flying by Foy

Performer flying, from manually operated rigs to motorized winch systems. Whether usable position data exists depends on the rig.

What it is

Flying by Foy is a performer flying specialist. The work spans manually operated systems -- pendulum rigs, tracks and single-purpose winches run by trained operators -- through to motorized and computer-controlled flying with programmed cues and multi-axis moves. Foy normally supplies equipment together with the riggers and operators who run it, so on most productions the flying system arrives as a package with its own crew, its own safety regime and its own rehearsal schedule. That matters for integration, because the flying department is a discrete organization inside the production rather than infrastructure the venue owns. Whether the rig can report where a performer is at all depends on which system was specified for the show and how it was configured. Confirm that with Foy early, in writing, before anything downstream assumes it.

How we work with it

Ask one question first: does the flying control system already know axis position in engineering units, and will the vendor publish it. If yes, the rest is a translation problem -- take what the system emits, convert axis position into a stage coordinate the lighting or media department can use, and carry it on a network segment separate from anything safety-related. If no, the honest options are a vendor development request with cost and lead time attached, or a dedicated sensor on the performer. Either way the path stays one-directional and read-only. Position derived from a flying system is advisory: it never becomes an input to a safety decision, nothing downstream ever writes back, and every consumer needs defined behaviour for the moment the feed stops mid-flight.

Foy typically arrives as a department with its own operators, so access is negotiated with people before protocols

Manual rigs carry no position data at all; the question only arises on motorized, encoded axes

Axis position is not stage position until the track, pickup and rigging geometry is worked through

Anything derived from a flying system is advisory data and never feeds a safety function

The honest read

Right when

  • The flight runs on a motorized, encoded system and the flying crew can already see position on their own control
  • The move is constrained -- a track, an arc, a fixed pickup -- so axis position maps cleanly to stage position
  • The cue you need to serve is the flight itself, not the performer once they are back on deck

Look elsewhere when

  • Performers need tracking on deck as well as in the air; one source covering both beats stitching two together
  • The rig is manually operated, or the vendor will not expose data and the schedule cannot absorb a development request
Common questions

Can we get position data out of a Foy flying system?

Sometimes, and it depends on the system specified for your production and on what Foy is willing to expose. Motorized, encoded systems know axis position internally; whether that leaves the controller in a documented, third-party form is a commercial and engineering question for the vendor, not something to infer from a spec sheet. Ask during pre-production, in writing, and get the answer before a lighting design depends on it.

Is derived flying position safe to use for automated followspots?

For a cue-following light, yes, with conditions. The feed has to be treated as advisory, latency has to be measured on the actual installed system rather than assumed from a datasheet, and fixture behaviour on loss of data has to be defined in advance -- hold, fade, or hand back to a manual operator. Nothing derived from the flying system should ever influence the flying system itself.

For shows in planning — or in trouble