ANSI E1.59: Object Transform Protocol

Editor's Note: Maya Nigrosh (she/her) has always had a passion for technology and live performance. She was hired for her first professional gig at age 12, and is now an ETCP-certified Entertainment Electrician and holds an MFA in Lighting Design from the Carnegie Mellon School of Drama. Maya is a Principal Software Engineer on the First Experience Technology Team at Sonos, and serves as the co-chair for ESTA's E1.59 (OTP) Task Group. Her ESTA participation pre-dates her employment at Sonos.

Across a hotel boardroom table strewn with hard candy wrappers, empty cups of coffee, tea, water, and one conspicuous Diet Coke, ardent voices boom, fervently arguing about how much space to allocate for a single timestamp. “Octets,” or is it “bytes,” this time? Shall it be four, so we can save some space? Or eight, so that we can have microsecond resolution? Who could possibly want that much granularity? What if we used strings? What layer should it be in?

This is the scene at a pre-pandemic ESTA task group meeting in Dallas, Texas (well, not quite Dallas—Westlake, TX—a city boasting four restaurants, a liquor store, and the now defunct Westlake History Museum). The task group is ANSI BSR E1.59, the Object Transform Protocol (OTP). ESTA, in this case, is the Entertainment Services and Technology Association, an international trade association and standards body dedicated to strengthening the entertainment industry through connection, education, and empowerment. Since the 1990s, ESTA have sponsored the Technical Standards Program (TSP), the only ANSI-accredited Standards Development Organization dedicated to the needs of the entertainment technology industry. Their first published standard, DMX-512A (ANSI E1.11), is an entertainment lighting protocol which still serves as the communication backbone for much of the architectural and theatrical lighting world.

And the voices? Those are Task Group members—volunteers (not quite volunteers, really, as a yearly participation fee allows them admission to this argument) who hail from around the world, representing a multitude of end-users, manufacturers, and anyone with a general interest in the work. On any other day, many ESTA volunteers work for companies that are in competition with one another. In Westlake, however, they have come together to argue about timestamps...and maybe write a standard.

OTP

The Object Transform Protocol (OTP) started as a graduate school thesis project, but was vaulted from the theoretical to the possible when ESTA’s Control Protocols Working Group (CPWG) decided to take it up. The need for OTP was incontrovertible—there was no complete, interoperable way to communicate spatial information about objects in an entertainment context. For each new installation, engineers, and, indeed, implementors who did not want to be engineers, had no choice but to create bespoke conversions between existing protocols such as BlackTrax, PosiStageNet (PSN), EtherCat, and other proprietary standards. The smörgåsbord of protocols was, in fact, such a distraction, that the original project request for OTP suggested that “This standard will allow systems engineers to spend less time on establishing communication and more time innovating artistic solutions.”

The charter of OTP was to provide “a mechanism to transfer object transform information such as position, rotation and velocity over an IP network” in order to “coordinate visual and audio elements of a production.” And, because of that, the assembled task group was truly cross-disciplinary, spanning several of ESTA’s Working Groups—representing the interests of rigging, lighting, projection, video, media, and audio. Everyone needed a way to share this information.

OTP wasn’t intended to re-invent the wheel—it needed to work with existing equipment, existing network topologies, and existing infrastructure—just to add some extra functionality. So, OTP is built on top of IP, and can function in both IPv4 and IPv6 environments.

OTP Message Structure

Figure 1: PDU Segments, and Figure 2: OTP PDU Encapsulation

Each Message in OTP is transported in a wrapper called a Protocol Data Unit (PDU). These PDUs are each comprised of three segments: Vector, Length, and Data. The Vector acts as a key that identifies the type of Data that the PDU contains. Length describes the length, in octets, of the Data portion. The Data segment is where things get more interesting. This is the payload of the PDU, and its contents depend on the type of Message being transported. Some Data segments may have sub-fields, may be empty, or may contain entire additional PDUs. The information in the Data segment is how OTP does its work.

Figure 3: OTP Transform Message, and Figure 4: OTP Advertisement Message

Figure 5: OTP Message Layering

Within the encapsulating PDUs, OTP is divided into layers. The message wrapping structure helps define different types of OTP Messages, and it also breaks them up so that a receiving component can filter out only the messages that it wants to hear, without needing to parse all of the data fields in the message.

OTP Components

OTP Messages are exchanged between what it calls Producers and Consumers.

A Producer is any network component that transmits OTP Transform Messages. Think of motion capture equipment attached to a performer, a moving light, or an automation server in charge of a curtain or some stage machinery. Producers might generate the information themselves, or they may merely gather and aggregate information from a variety of smaller, less-resource-capable sources.

Consumers, then, are the intended targets of Producers. They could be things like a visualizer, a projection-mapping media server, an Atmos sound system, a theatrical lighting console, or anything that wishes to react to spatial information.

At present, OTP Messages are broken into two main layers: OTP Transform Messages and OTP Advertisement Messages.

OTP Transform Messages

OTP Transform Messages tell stories about Points. The Point is a basic building block—it is the smallest, indivisible component of an Object in OTP. A single Point can describe a single Object, or an Object can be made up of many Points. Each Point lives within a Group. That Group can describe a single Object, many Objects, or simply a set of logically-related Points. Each Group is held within a System, which acts as an administrative abstraction that collects related Objects. Systems are also one of those layer filters, and they can provide a convenient way to partition network traffic (more on this later!).

Figure 6: Two Example Systems: Systems contains an automation controller driving three separate Objects--a truss, a turntable, and a curtain. System2 is a set of drones, divided into two Groups.

Each OTP Point is uniquely defined by its Address, which is just a combination of its System Number, Group Number, and Point Number, separated by ‘/’s. So, in the figure above, the Address for the leftmost Point (on the truss on the left) is 1/1/1, and the Address of the rightmost Point (on the drone on the far right) is 2/2/1.

Transform Message Modules

Each OTP Transform Message describes the state of a System at a given instant in time. In its Data segment are many Point PDUs, each of which carries information about a specific Point, in the form of Module PDUs. A Module can describe any of the characteristics of a Point. At the time of this publication, the OTP specification provides the following Standard Modules:

• Position: the x, y, z position of a Point, relative to a reference frame

• Position Velocity/Acceleration: the positional velocity and acceleration of a point, described as linear velocities and accelerations in each of the x, y, z directions

• Rotation: the intrinsic Euler rotation for each of x, y, z, calculated using the Tait-Bryan ZYX convention

• Rotation Velocity/Acceleration: the rotational velocity and acceleration of the Point using intrinsic Euler rotation for each of x, y, z, calculated using the Tait-Bryan ZYX convention

• Scale: a unitless absolute scale for the Point, calculated with ‘1’ as its reference size

• Reference Frame: a description of another System, Group, and Point that shall be used as a frame of reference

OTP also encourages the use of Manufacturer-Specific Modules, which don’t need to be part of the ESTA standards ratification process in order to be used. Manufacturer-Specific Modules are distinguished by an ESTA-assigned Manufacturer ID and a Module Number. Creators of Manufacturer-Specific Modules can choose to publish descriptions of the contents of their Modules in order to allow interoperability, or they may use them to support proprietary information.

As OTP evolves and changes, it is expected that additional, commonly-used Modules will be added to the standard. In fact, at the time of this writing, the OTP Task Group have re-opened the standard, and are working on two new Standard Modules which will describe video cameras and camera lenses.

OTP Transform Messages are intended to be sent in real time--between 20 and 1000 times a second. Because of this, OTP uses a number of techniques to conserve network utilization and to make sure that Consumers and Producers only hear the information that they are interested in. One of these techniques is using the System number to determine the multicast group to use. In an IPv4 network, OTP Transform messages for a given System show up on 239.159.1.<System Number>. In an IPv6 network, they would arrive on ff18::9f:00:01:<System Number>. Consumers have the ability to subscribe to only those multicast addresses that they’re interested in.

In addition to network-assisted multicast, OTP Advertisement Messages can also be used for traffic shaping and for gathering metadata. OTP Advertisement messages are sent much less frequently, and can help to drastically reduce bandwidth on resource-constrained systems.

OTP Advertisement Messages

There are three types of OTP Advertisement Messages: System Advertisement Messages, Module Advertisement Messages, and Name Advertisement Messages.

Consumers can request System information by sending a System Advertisement Message. Producers respond, unicast, to this message, by sending an OTP System Advertisement Message containing a list of the System Numbers they report. Because the System Number determines the multicast group upon which OTP Transport Messages will be sent, a Consumer can then choose which multicast groups to subscribe to, without needing to receive data from Systems it is not interested in.

Once a member of the correct multicast groups, Consumers transmit a Module Advertisement Message every 10 seconds, advertising the list of Modules that they want to hear about. Producers then only transmit Modules that they have been requested to report.

Name Advertisement Messages are an optional, but valuable, part of the standard. Upon request from a Consumer, a Producer uses the Name Advertisement Message to share human-readable text names for each of the Points for which it carries data. These strings could be used in a variety of ways, most of which are to create a more welcoming experience for the end-user.

And that’s truly the point of OTP. To create the best, immersive experience for the end-user, the audience, you. OTP has provided a multidisciplinary, common language by which components moving in physical space can communicate about their actions. With OTP doing the heavy lifting, it’s delivered on its promise in its original project request. To give implementors “...more time innovating artistic solutions.” The possibilities are endless. Consider projection-mapping video over a morphing landscape, in time with a movie. Imagine being able to seamlessly track, illuminate, and acoustically reinforce a performer as they move. Or, think about live, positional audio in a dynamically changing physical environment. These are only the beginning of what we can do with OTP.

For more information about OTP, check out https://otprotocol.org/ or download the published standard at https://tsp.esta.org/tsp/documents/published_docs.php (search for ANSI E1.59).

All images in figures: Source: ANSI E1.59 - 2021, Entertainment Technology -- Object Transform Protocol © 2021 Entertainment Services and Technology Association.