Patent Description:
An amusement or theme park generally includes a variety of entertainment systems or attractions that provide a unique experience for guests of the amusement park. For example, the amusement park may include different attraction systems, such as a roller coaster, a drop tower, a water ride, dark ride and so forth. Some attraction systems may include an environment with animated figures and special effects, which help immerse guests in the experience of the attraction system. However, installation and configuration of the features may be difficult, and it may be challenging to monitor different installed features that provide data in real time using different formats and of different complexity. Therefore, improved features and techniques are useful to handle ride and attraction data more efficiently to provide a desirable effect or experience for the guests.

<CIT> describes a ride system for an amusement park that includes a ride vehicle configured to accommodate a rider and configured to travel along a ride path, a head mounted display configured to be worn by the rider, and a control system. The control system is configured to display a virtual instruction to the rider via the head mounted display, receive a signal from a user input device associated with the rider, determine that the signal received from the user input device corresponds to the virtual instruction, and trigger a movement of the ride vehicle in response to determining that the signal corresponds to the virtual instruction.

The invention provides, a data reporting system for an attraction includes a primary wireless communication network, a secondary wireless communication network, and a ride vehicle of the attraction. The data reporting system for the attraction also includes a controller of the ride vehicle configured to provide ride vehicle operation data indicative of characteristics of the ride vehicle during operation, and communication circuitry that communicates a first subset of the ride vehicle operation data to the primary wireless network and a second subset of the ride vehicle operation data to the secondary wireless network, where the first subset of the ride vehicle operation data is at a lower bandwidth than the second subset of the ride vehicle operation data.

In one embodiment, a data reporting system for an attraction may include a ride vehicle having a sensor configured to generate position information of the ride vehicle in the attraction, a vehicle controller configured to generate a log data of ride vehicle operations, and communication circuitry that communicates the position information via a primary wireless communication network and the log data via a secondary wireless communication network. The data reporting system may also include a server that is configured to receive the position information from the primary wireless communication network and the log data from the secondary wireless communication network and to combine the position information and the log data.

In one embodiment, a method includes a data reporting system generating operation data of an attraction, communicating a first subset of the operation data in real-time via a restricted wireless network, determining a status of the attraction, and selectively communicating a second subset of the operation data via a secondary wireless network based on the status of the attraction being indicative of a time between cycles of the attraction.

Further, to the extent that certain terms such as parallel, perpendicular, and so forth are used herein, it should be understood that these terms allow for certain deviations from a strict mathematical definition, for example to allow for deviations associated with manufacturing imperfections and associated tolerances.

The present disclosure is directed to a layered reporting system that may be implemented with amusement park attractions including shows, rides, promotions, and so forth. As provided herein, a layered reporting system facilitates intake, communication, processing and/or analysis, and storage of data of various components of an attraction, e.g., an amusement attraction. The data can relate to audio, visual, and physical effects that can be experienced by riders in a vehicle, as well as features of a game, including player interaction with the various game effects and dynamic experiences based on the interaction. Riders may also be equipped with a virtual reality/ augmented reality (AR/VR) headset with additional features to provide a more immersive experience. These attraction components generate respective operation data, and some of the operation data can be considered "fast" data that is communicated quickly, e.g., close to or in real time, to a controller to permit feedback actions based on analysis of the data.

In one embodiment, one or more components of the layered reporting system may generate, collect, and publish or transmit real-time fast operation data (e.g., health data) relating to the status of the one or more components during operation of the ride. For example, ride vehicle operation data may include, but is not limited to, operation status, malfunction identification, position data, speed, status of riders, sensor measurements, or status of coupled devices such as headsets. Thus, the higher priority fast data may be structured to facilitate faster communication and may be compressed, communicated at lower bandwidth, and/or or transmitted on access-restricted communication pathways that are dedicated to fast data communication. The operation data also includes "slow" data that is lower priority and that can be communicated at higher bandwidths to include more information. The slow data may be communicated in real-time or may be batch communicated on a separate communication pathway to the fast data.

While fast data and slow data are communicated via separate pathways, the fast data and the slow data may have one or more common destinations and may be jointly provided to particular processing and/or storage layers. Accordingly, provided herein are layered data reporting techniques that provide attraction operation information and analytics at varying levels of detail and accuracy depending on the desired result. Real-time fast data, without any real-time slow data, can be fed into safety analytics to permit the attraction controller to respond quickly to deviations in ride vehicle positions or to vehicle shutdowns while the ride is operational. In addition, the real-time fast data may enable the attraction controller to modify a current loading decision based on the real-time fast data. For example, the real-time fast data may indicate that a ride vehicle may only be able to accommodate fewer riders than normal. Thus, the attraction controller may provide instructions to one or more team members to modify the current loading procedure to account for the change in capacity for the ride vehicle. Accordingly, the fast data may be time-sensitive data that is both communicated during and, in embodiments, acted on in real-time while the ride is in operation. The real-time fast data is communicated via a dedicated communication pathway to avoid bottlenecks or slowdowns that may be associated with slower and higher bandwidth data. More highly detailed operation slow data can be combined with the fast data at one or more analytics layers that model past rides, identify baseline values/trends and spot outliers, as well as predict if performance metrics might become outliers to facilitate pre-emptive maintenance and improve attraction uptime and guest show performance.

With the foregoing in mind, <FIG> illustrates an embodiment of a layered reporting system <NUM> in accordance with the present disclosure. The layered reporting system <NUM> may be implemented to report data generated in an attraction environment through one or more client layers, one or more server layers, one or more wireless network communication layers, and one or more storage layers. As illustrated, the attraction environment includes one or more ride vehicles <NUM> that respectively include vehicle game clients <NUM> that receive vehicle operation data from one or more hardware or software elements of the ride vehicle <NUM>.

The vehicle game clients <NUM> may be implemented as hardware or software as provided herein, and operate to communicate with one or more servers, e.g., a vehicle game server <NUM>. The one or more vehicle game clients <NUM> may include components, discussed further below, that are configured to collect and publish or communicate ride vehicle operation data to the vehicle game server <NUM> via the primary wireless network <NUM>. The ride vehicle operation data may include, but is not limited to, power levels, test logs, malfunction data, etc. In some embodiments, certain high priority ride vehicle operation data may be communicated to the vehicle game server <NUM> via a wired or wireless connection. Data on the vehicle game server <NUM> may then transmitted, via a restricted primary wireless network <NUM><NUM>, to a ride data server <NUM>. In addition, or alternatively, the vehicle game clients <NUM> and/or the vehicle game server <NUM> may communicate lower priority highly detailed data directly to ride data server <NUM> via a secondary network <NUM>, illustrated as an analytics wireless network. As mentioned above, the secondary network <NUM> may have higher bandwidth than the primary wireless network <NUM><NUM> to accommodate larger data set sizes. Moreover, the highly detailed data may provide a log of historical or more long-term perspectives of a respective component of the system <NUM>. It should be noted that the vehicle game server <NUM> may also compile operation data from the vehicle game clients <NUM> into highly detailed data and then communicate it to the ride data server <NUM> via the secondary network.

In one embodiment, one or more components of the layered reporting system may collect and transmit highly detailed data, e.g., slow data, relating to the performance of the components. The highly detailed data may be collected by the vehicle game clients <NUM> of the ride vehicles <NUM> and then communicated to the secondary network <NUM> having a higher bandwidth than the primary wireless network <NUM>, as mentioned above. It should be appreciated that the secondary network <NUM> may operate with closer radio and/or antenna proximity for effective communication, with line-of-sight communication, with slower handoffs between wireless access points, or any combination thereof, to accommodate the higher bandwidth. Via the secondary network <NUM>, the highly detailed data from the ride vehicles <NUM> may be communicated to the ride data server <NUM>. Highly detailed data may also be communicated from projection game clients <NUM> and/or a ride game server <NUM> to the ride data server <NUM>. From the ride data server <NUM>, the data may be uploaded to a cloud hosted analytics engine <NUM>. It should be noted that if the restricted wireless network <NUM> is not available to transmit data, the data may be stored on the ride vehicles <NUM> until the data can be transmitted. Real-time data related to operation of the ride vehicles <NUM> may be sent to the ride data server <NUM> via the restricted wireless network <NUM>, e.g., a primary wireless network of the attraction environment <NUM>. It should be noted that the restricted wireless network <NUM> is limited access, e.g., cannot be accessed by the riders within the attraction. The restricted wireless network may only require or operate using a low bandwidth, similar to that of standard Wifi. In addition, the health data of one or more projection game clients <NUM> may be sent to the ride game sever <NUM> and then to the ride data server <NUM> via a hardwired connection. Once at the ride data server <NUM>, the data may be uploaded to the cloud hosted analytics engine <NUM>.

As the riders travel through the attraction, the layered reporting system permits real-time data to be transmitted to the restricted primary wireless network <NUM>. To manage the data load, the ride vehicles <NUM> may be equipped with data feedback mechanisms to limit data transmissions in order to preserve the primary wireless network <NUM> and/or the secondary network <NUM>. Data load management may also be facilitated by positioning the ride vehicles <NUM> at various wireless access points throughout the ride, such that no one wireless access point is overwhelmed by an influx of data. The position of the ride vehicles <NUM> may be done automatically through ride logic, or manually when the ride is not operational. For example, the ride may not be operational between ride cycles or during an unloading/loading process for guests and when the ride vehicles <NUM> are generally stationary. In an embodiment, the ride logic operates to distribute ride vehicles <NUM> throughout a loading/unloading area to distribute data loads for different wireless access points in the area and based on a data volume to be transmitted. If one wireless access point is at capacity, the controller of the attraction can, in embodiments, instruct other ride vehicles to move autonomously to other locations associated with other wireless access points.

When the ride is not operational, highly detailed vehicle operation data may be transmitted over the primary network <NUM>, the secondary network <NUM>, or any combination thereof. In an embodiment, the highly detailed vehicle operation data is restricted to the secondary network <NUM> while the ride is operational, but can be communicated via the primary network when the ride is not operational. In an embodiment, communication from the system to the ride vehicle <NUM> can occur via the secondary network. In one example, such communications via the secondary network <NUM> to the ride vehicle <NUM> may modify the code/software generating the highly detailed vehicle operation data, configure the software generating the highly detailed vehicle operation data, or place data/logic on a ride vehicle that changes how data is interpreted. This can impact what data is considered fast and slow data and the frequencies in which the data is recorded/reported/sent/received. The highly detailed data may offer insight to larger and/or longer term problems that may arise during one or more ride-throughs. Further, the highly detailed data may relate to activities that are auxiliary to the ride, such as activities that are available for riders while they wait in a queue. For example, the ride may have sensors disposed throughout the queue that may detect signals from handheld devices that relate to the ride. The sensors may collect data relating to how often a rider interacts with activities while in the queue.

The ride data server <NUM> may also receive data from other components of the system, such as one or more projection game clients <NUM>, via the primary wireless network <NUM>. The projection game clients <NUM> may include any suitable projectors, augmented reality/ virtual reality (AR/VR) headset, etc. The projection game clients may be distributed throughout the attraction, with the AR/VR headsets being located on the ride vehicles <NUM> and the projectors being part of the environment. In an embodiment, certain headset information may be generated and collected by the ride vehicle game client <NUM>.

The projectors, the AR/VR headset, or other physical objects may be configured to send health data to the ride game server <NUM> via the primary wireless network <NUM>. The operation data of the projection game clients <NUM> may include, but is not limited to, status, power levels, test logs, malfunction data, etc. In some embodiments, the data of the projection game clients <NUM> may be communicated to the ride game server <NUM> via a wired connection. For stationary projection game clients <NUM>, the wired connection may run through or on the ground of the attraction environment to a central computing system. Mobile projection game clients <NUM> on the other hand, may be adapted to accommodate a wired connection, tethered to the ride vehicle <NUM>. Additionally, or alternatively, the loading stations and/or maintenance bays (mentioned above) may include an adapter to connect to the AR/VR headset <NUM> to collect health data and communicate to the ride game server <NUM>.

Once the data of the projection game clients <NUM> is communicated to the ride game server <NUM>, it may then be communicated to the ride data server <NUM> via the primary wireless network <NUM>. In addition, or alternatively, the projection game clients <NUM> may communicate highly detailed data directly to ride data server <NUM> via the secondary network <NUM>. As mentioned above, the secondary network <NUM> has a higher bandwidth than the primary wireless network <NUM> to accommodate larger data set sizes. Moreover, the highly detailed data may provide a more long-term perspective of a respective component of the attraction environment. The ride game server <NUM> may also compile health data from the projection game clients <NUM> into highly detailed data and then communicate it to the ride data server <NUM> via the secondary network.

Once the data is at the ride data server <NUM>, it may be uploaded to the cloud hosted analytics engine <NUM>. Once the data is published into the cloud hosted analytics engine <NUM>, artificial intelligence and/or machine learning algorithms are employed to understand baseline values, trends, and spot outliers. The artificial intelligence and/or machine learning may also predict if performance metrics might become outliers to facilitate pre-emptive maintenance and improve ride uptime and the rider's experience.

The disclosed layered data reporting system may be used in conjunction with data generated by an attraction or other entertainment environment. As illustrated by <FIG>, an attraction environment <NUM> may include one or more features that enhance an immersive experience and that generate related operation data that is provided to the layered data reporting system. For example, in one embodiment, one or more ride vehicles <NUM> traverse a ride path <NUM>. The attraction environment <NUM> may include virtual game features such as those provided by projectors <NUM> onto a video display <NUM>. The video display <NUM> may include various selectable virtual displayed features that are capable of being selected by a game player (e.g., guest <NUM>) before the ride begins. The guest <NUM> may also be equipped with an augmented reality/virtual reality (AR/VR) headset <NUM>. The AR/VR headset <NUM> may have a display that includes virtual display features resembling those on the video display <NUM>. Both fast and slow operation data from the projectors <NUM>, video display <NUM>, and/or the AR/VR headset <NUM> may be provided to the projection game client <NUM>. As discussed, certain AR/VR headsets <NUM> may be tethered to the ride vehicle <NUM>, and their operation data may additionally or alternatively flow through the vehicle game client <NUM>.

The guest <NUM> may interact with virtual display features displayed on the display of the AR/VR headset <NUM>. The video projections may generate display instructions to display images in accordance with the environment <NUM>. The images may be determined based on the guest's <NUM> position on the ride path <NUM>. In addition, the same, similar, or additional visuals will be projected to a display on the AR/VR headset <NUM>. This will allow the guest <NUM> to interact with objects within the attraction environment while also being able to see additional visuals that may not be physically present within the environment <NUM>. Fast or high priority operation data collected by the projection game client <NUM> and provided to the ride data server <NUM> (<FIG>) may include headset malfunction data, display malfunction data, or timing data indicative of coordination of the display with corresponding audio, video, or special effects. Slow or low priority operation data may include detailed gaze direction information, detailed image display data, interaction data.

In addition, the projection game clients <NUM> or other clients of the system <NUM> (see <FIG>) may receive or collect operation data from interactive physical objects <NUM>, e.g., surface features that can reflect projections in accordance with the environment, that form dynamic physical barriers, visual interest, or special effect devices such as water sprayers, fog machines, wind machines, etc. Such physical objects <NUM> may also include robotic figures. Fast or high priority operation data from the physical object may include malfunction data that requires rerouting of the ride vehicle <NUM>, activation of alternate special effects, or disabling coordinated display sequences that are specific for or mapped onto the physical object as it moves. Slow or low priority operation data may include object movement tracking and object movement position relative to the ride vehicle <NUM>, projection mapping data to assess the accuracy of projection mapped displays, or gaze direction information to determine if the physical object is of interest to the riders <NUM>.

The layered reporting system <NUM> (see <FIG>) may be implemented for data reporting of operation data from an attraction (e.g., the attraction environment <NUM> of <FIG>). <FIG> is a block diagram of an attraction system <NUM> that may collect or receive operation data for reporting via the reporting system <NUM>. The system <NUM> includes an attraction controller <NUM> that is communicatively coupled to one or more ride vehicles <NUM>, and one or more AR/VR headsets <NUM>. The controller <NUM> may be communicatively coupled to other elements within the environment <NUM> as provided herein. The controller <NUM> may include separate control circuitry for facilitating interactive and dynamic elements, including display circuitry <NUM>. Additionally, the controller <NUM> may include or be communicatively coupled to tags or sensors <NUM> used for tracking the ride vehicle <NUM>, an input device of the operator interface <NUM>, an audio component <NUM>, a special effect controller <NUM> for controlling one or more physical effects (e.g., interactive physical objects <NUM>; see <FIG>), and a communication module <NUM> for communicating the fast and/or slow data. One or more disclosed features of the controller <NUM> may alternatively be implemented in the vehicle <NUM>.

In some embodiments, the controller <NUM> may send instructions to the ride vehicle <NUM> via the secondary network <NUM> when the ride is operational. The instructions may include, but are not limited to, instructions on how to collect data and/or instructions on determining if the collected data is fast data, or slow data. The determination of whether the data collected by a health data feedback system <NUM> of the ride vehicle <NUM> is fast data or slow data, may increase the efficiency of the layered reporting system <NUM>.

The ride vehicle <NUM> may include components that generate operation data, such as a motor <NUM> and a brake <NUM>. The movements of the ride vehicle <NUM> may include running (e.g., acceleration, deceleration), turning, and stopping of the ride vehicle <NUM>. The motor <NUM> may be powered by any suitable power source <NUM>, including, but not limited to, a battery, a solar panel, an electrical generator, a gas engine, or any combination thereof. The operations of the motor <NUM> and the brake <NUM> may be controlled by a vehicle controller <NUM>. For example, the vehicle controller <NUM> may control the motor <NUM> to adjust its output power to accelerate or decelerate the ride vehicle <NUM>. The vehicle controller <NUM> may also control the brake <NUM> to decelerate or stop the ride vehicle <NUM>. Further, the vehicle controller <NUM> may operate under instructions from the player via an operator interface <NUM> (e.g., to steer the vehicle based on operator control of a steering wheel or joystick). The operation data generated by components of the ride vehicle <NUM> is reported to the layered reporting system as provided herein. In one example, fast or higher priority data may include speeds outside of tolerances, while slow or lower priority data may include power fluctuations of the motor <NUM> that may be flagged for future maintenance.

The ride vehicle <NUM> may include a position feedback system <NUM> for monitoring its position in the attraction. In one embodiment, the position feedback system <NUM> interacts with one or more sensors or tags <NUM>. The vehicle position feedback system <NUM> may include a reader that may sense the sensors or tags <NUM> to provide the position information of the ride vehicle <NUM>. The reader then supplies the position information to the vehicle controller <NUM>, which in turn is then communicated to the vehicle game server <NUM> (<FIG>) via a communication module <NUM>. Additionally, a health or operation data feedback system <NUM> may include sensors or tags that collect real time health data of the ride vehicle <NUM>. The communication module <NUM> may also facilitate communication with the vehicle game server <NUM> to facilitate transmitting health data from the health data feedback system <NUM>. In this manner, the real time health data of the ride vehicle <NUM> may be communicated to the vehicle game server <NUM>, and ultimately the ride data server within a short time interval (e.g., <NUM>, <NUM>, <NUM>, etc.). In the case of the primary wireless network <NUM> being unavailable, the real time operation data may be stored in a memory of the vehicle controller <NUM> until the primary wireless network <NUM> is available.

Additionally, or alternatively, when the primary wireless network <NUM> is not available, the real time health data may be communicated to the ride data server <NUM> via the secondary network <NUM>. The highly detailed data from the ride vehicle <NUM> may also be communicated to the ride data server <NUM>, via the secondary network, when the attraction is non-operational. In some embodiments, the highly detailed data may be communicated to the ride data server, via the primary wireless network <NUM>, if bandwidth available.

The attraction environment may include various components that may allow for interaction of the riders <NUM> with the attraction environment and the ride vehicle <NUM>. Specifically, the AR/VR headsets <NUM> may include display circuitry <NUM> that may present visualizations to a display <NUM>. The visualizations may be the same or similar to the visualizations on the video display <NUM>. The AR/VR headsets <NUM> may also include an audio component 82that may project the same or similar audio to that of the audio component <NUM> of the attraction environment. This allows for the riders <NUM> to have an immersive ride experience and increase the enjoyment of the ride.

The AR/VR headsets <NUM> may also include a communication module <NUM>. It should be noted that the communication module <NUM> may be the same or similar to that of the communication modules <NUM>, <NUM>, as described above. The communication module <NUM> may communicate real time health data of the AR/VR headsets <NUM> to the ride game server <NUM> via the primary wireless network <NUM>, which then will be communicated to the ride data server <NUM> to be uploaded to the cloud hosted analytics engine <NUM>. Alternatively, or additionally, the communication module <NUM> may communicate highly detailed data directly to the ride data server <NUM>, via the secondary network, to be uploaded to the cloud hosted analytics engine <NUM>. The AR/VR headsets <NUM> may be communicatively coupled to the ride vehicle <NUM> such that in the case of the primary and secondary networks being unavailable, the AR/VR headsets real time health data and highly detailed data may be stored in the memory of the vehicle controller <NUM>.

In addition to being communicatively coupled to the ride vehicle <NUM>, the AR/VR headsets <NUM> may be physically tethered to the ride vehicle <NUM>. The connection may be facilitated via any suitable form of wiring that may allow for information to be communicated over. In certain embodiments, the power source <NUM> may also provide power to the AR/VR headsets <NUM> when the AR/VR headsets <NUM> are tethered to the ride vehicle <NUM>.

<FIG> is a flow diagram of a method of data reporting. First, components within the attraction (e.g., ride vehicles <NUM>, AR/VR headsets <NUM>, animatronics, etc.) may generate, collect, and store operation data, which includes a first subset of higher priority data and a second subset of data that is highly detailed and lower priority operation data, or any combination thereof, as indicated by block <NUM>. Each component may include elements configured to generate, collect, and store data. For example, the vehicle controller <NUM> may generate, collect, and store data. While controllers are not pictured in other components shown in <FIG>, it should be noted that the components within the attraction, including but not limited to, ride vehicles <NUM>, AR/VR headsets <NUM>, may include elements similar to that of the vehicle controller <NUM> such as a suitable memory capable of storing data and instructions, as well as a processor configured to generate data and execute the instructions stored within the memory. A subset of the operation data, the first subset, is automatically communicated in real-time as it is generated, independent of an attraction status (block <NUM>).

Responsive to collection of operation data, the system <NUM> may determine an attraction status, such as whether the attraction is operational, as indicated by block <NUM>. The attraction status may be operational while the ride vehicles are in motion during an attraction cycle or non-operational, e.g., in a time period between cycles of the attraction or when the ride vehicles are in motion or on a ride path. When the ride is operational, the system <NUM> transmits the high priority operation data via the primary wireless network <NUM>. The primary wireless network <NUM> may only transmit the real time operation data because of limited bandwidth, in contrast to data transmission protocols for the secondary network, which transmits logged data that is more data intensive and that may be batch transmitted via the secondary network when the ride is non-operational.

When the status is not operational, components within the attraction may generate, collect, and store no or very limited new operation data. However, the data stored within the respective memories of the components within the attraction during the ride cycle may be transmitted via the secondary network. Additionally, or alternatively, the data transmission of the real time data may be delayed to allow for the highly detailed data to be transmitted via the secondary network with priority, as indicated by block <NUM>. The data transmission delay may also occur when the primary wireless network <NUM> and/or the secondary network are unavailable.

In some embodiments, both the primary and secondary networks are available and transmit data, whereby the primary wireless network <NUM> may transmit only real time operation data, and the secondary network may transmit highly detailed data on real time or on a delayed or periodic schedule. The higher priority and lower priority data may be combined and then uploaded to the cloud hosted analytics engine <NUM>. The cloud hosted analytics engine <NUM> may be used to make decisions pertaining to the attraction based on real time health data, highly detailed data, or any combination thereof.

The lower priority and higher priority data may be combined based on time stamp information or data source or origin (e.g., power data from vehicle power system). In embodiments, the higher priority data may be present in the lower priority data, but in a more data-intensive form in the lower priority data.

Claim 1:
A data reporting system (<NUM>) for an attraction, the data reporting system (<NUM>) comprising:
a primary wireless communication network (<NUM>);
a secondary wireless communication network (<NUM>) separate from the primary wireless network (<NUM>); and
a ride vehicle (<NUM>) of the attraction, the ride vehicle (<NUM>) comprising:
a controller (<NUM>) of the ride vehicle (<NUM>) configured to provide ride vehicle operation data indicative of characteristics of the ride vehicle (<NUM>) during operation; and
communication circuitry that communicates a first subset of the ride vehicle operation data to the primary wireless network (<NUM>) and a second subset of the ride vehicle operation data to the secondary wireless network (<NUM>), wherein the first subset of the ride vehicle operation data is at a lower bandwidth than the second subset of the ride vehicle operation data.