VEHICLE MOVEMENT MANAGEMENT

Abstract

A method may include comparing, using a virtual map, a position of a vehicle to a position of an obstacle in an operating environment; and adjusting a trajectory of the vehicle to avoid the obstacle. A method may include receiving, from a sensor of a vehicle, data associated with an operating environment of the vehicle; identifying an object in the operating environment based on the data; classifying the object based on an object recognition process; and assigning a clearance envelope to the object based on the classification of the object. A method may include querying a virtual map of an operating environment, the virtual map including a characteristic for an object within the operating environment; and maintaining, by a vehicle, a clearance envelope with respect to the object based on the object characteristic. Additional methods and associated systems are also disclosed.

Claims

1. A method of managing vehicle movement through an operating environment, the method comprising: comparing, by a vehicle and using a virtual map, a position of the vehicle to a position of an obstacle in an operating environment; and adjusting, by the vehicle, a trajectory of the vehicle to avoid the obstacle.

2. The method of claim 1, further comprising updating, by the vehicle and on the virtual map, the position of the vehicle in the operating environment.

3. The method of claim 1, further comprising coordinating, by the vehicle, movement of the vehicle with movement of another vehicle through the operating environment.

4. The method of claim 1, further comprising updating the virtual map with an additional obstacle identified by the vehicle.

5. The method of claim 1, further comprising: detecting, by the vehicle, an environmental feature of the operating environment; and determining, by the vehicle, the position of the vehicle based on the detected environmental feature.

6. The method of claim 5, further comprising validating, by the vehicle, the virtual map based on the detected environmental feature.

7. The method of claim 1, wherein the virtual map is stored on the vehicle.

8. The method of claim 1, wherein the obstacle is another vehicle, an element of the operating environment, or an undesired area of the operating environment.

9. The method of claim 1, wherein the obstacle is undetectable to the vehicle.

10. A method of managing vehicle movement through an operating environment, the method comprising: comparing, by a processor and using a virtual map, a position of a vehicle to a position of an obstacle in an operating environment; and instructing, by the processor, a trajectory of the vehicle to avoid the obstacle.

11. The method of claim 10, further comprising: receiving, by the processor, an updated position of the vehicle in the operating environment; and updating, by the processor, the position of the vehicle on the virtual map.

12. The method of claim 10, further comprising coordinating, by the processor, movement of the vehicle with movement of another vehicle through the operating environment.

13. The method of claim 10, further comprising: receiving, by the processor, data associated with an additional obstacle identified by the vehicle; and updating, by the processor, the virtual map with the additional obstacle.

14. The method of claim 10, further comprising: receiving, by the processor, data associated with a detected environmental feature of the operating environment; and determining, by the processor, the position of the vehicle based on the received data.

15. The method of claim 10, wherein the processor is part of a centralized wayside computer.

16. A method of assigning clearance envelopes within an operating environment, the method comprising: receiving, by a processor and from a sensor of a vehicle, data associated with an operating environment of the vehicle; identifying, by the processor, an object in the operating environment based on the data; classifying, by the processor, the object based on an object recognition process; and assigning, by the processor, a clearance envelope to the object based on the classification of the object.

17. The method of claim 16, wherein the data comprises a segment point cloud generated by the sensor, and wherein the method further comprises removing, by the processor, points from the segment point cloud that are known based on a virtual map of the operating environment.

18. The method of claim 17, further comprising: converting, by the processor, at least some of the remaining points of the segment point cloud to a shape; and analyzing the shape based on an object database to associate the shape with an expected object.

19. The method of claim 16, further comprising scanning, by the sensor, the operating environment.

20. The method of claim 16, further comprising determining whether the object is known based on a comparison with a virtual map.

21. The method of claim 16, wherein the identifying comprises analyzing the object based on an object recognition algorithm to associate the object with an expected object.

22. The method of claim 21, wherein the expected object is a second vehicle.

23. The method of claim 16, wherein the clearance envelope comprises at least one of a vehicle protection envelope or a rider reach envelope.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 illustrates an example virtual map for use in map-based vehicle movement management.

[0011] FIG. 2 illustrates a schematic view of example minimum separation distances for a vehicle.

[0012] FIG. 3 illustrates an example point cloud used to detect one or more objects near a vehicle.

[0013] FIG. 4 illustrates an example object recognition algorithm to identify an object using the point cloud of FIG. 3.

[0014] FIG. 5 illustrates example clearance envelopes assigned to an object identified using the object recognition algorithm of FIG. 4.

[0015] FIG. 6 illustrates example clearance requirements for boundary types based on vehicle speed.

[0016] FIG. 7 illustrates an example virtual map for use in defining a clearance envelope for a vehicle.

[0017] FIG. 8 illustrates an example computing system for implementing various examples of the present disclosure.

DETAILED DESCRIPTION

[0018] The present disclosure leverages a dynamic and continuously updated virtual map to control operation of one or more vehicles, including AGVs, FRVs, ride vehicles, and other vehicles. For example, a ride vehicle may know its position in an attraction and update its location on the virtual map. The vehicle may compare its position to those of known obstacles on the virtual map. In some embodiments, the vehicle may compare its position to other vehicles or environmental elements on the virtual map. Vehicle travel trajectories (e.g., current and expected motion) may be evaluated to determine if the trajectories need to change to avoid obstacles on the virtual map. Depending on the application, the virtual map may be centralized (e.g., wayside) or decentralized (e.g., on each vehicle) or a combination of both. In addition, or alternatively, the vehicle itself may do the comparison, or a central wayside computer may do the comparison and send vehicle commands based on the comparison.

[0019] As a result, embodiments of the present disclosure may avoid interference with obstacles that are not visible to a vehicle, but their positions are known and represented by the virtual map. Additionally, or alternatively, embodiments of the present disclosure may provide coordination between vehicles by a centralized wayside computer (e.g., platoon synchronization and individual vehicle movement), coordination between vehicles and other elements by a centralized wayside computer, and/or traffic and fleet management (e.g., starting and stopping of vehicles, priority of movement, etc.). For example, map-based vehicle movement management may provide a more thrilling attraction, such as vehicles being able to get closer to each other and act as a group, among other new or unique effects. Additionally, or alternatively, map-based vehicle movement management may provide two-dimensional (2D) or three-dimensional (3D) protection and/or improved uptime as issues can be identified on the map and vehicles can avoid undesired areas. Additionally, or alternatively, vehicle protection may be simplified, and the need for pre-analysis of travel paths may be minimized.

[0020] In some embodiments, the present disclosure leverages smart vehicles that able to sense their operating environment (e.g., using sensors such as LiDAR and Radar). These sensors in conjunction with a representation of an operating space (virtual map) allow the vehicle to distinguish between objects that are represented in the virtual map, and objects that are not (i.e., unexpected objects). Once encountered and classified, unexpected objects can be added to the virtual map for use by other vehicles and objects. Unexpected objects may be assessed through an object recognition algorithm to determine if the unexpected objects are another vehicle operating in nearby proximity or another known object. As unexpected objects are identified, the vehicle can assign protections to the object or vehicle based on the observed dynamics of the vehicle and a clearance envelope shape associated with the type of identified object.

[0021] In this manner, the vehicle may assume responsibility for maintaining minimum distance requirements. In addition, the vehicle may make decisions in real time or near real time regarding the need for minimum spacing from other vehicles or objects. Such embodiments may also minimize the minimum distance needed by the vehicle (e.g., decrease the amount of protection needed by the vehicle compared to other smart solutions) because the vehicle will know how to assign both vehicle and guest/rider reach needed protections. Such embodiments may also allow for quick changes of vehicle motion and effectively remove the need for a virtual track and pre-analysis. By reducing the need of pre-analysis and other computational tasks, the techniques described herein may allow for faster processing and/or realize additional benefits, such as improved efficiencies in vehicle and guest/rider reach protection assessments using existing vehicles.

[0022] Embodiments of the present disclosure may define the operating environment of an AGV using a virtual map that the vehicle may continuously query to understand how to interact with its surroundings. Such embodiments may allow the vehicle to programmatically enforce clearance envelope rules based on the boundary conditions details in the virtual map. For example, embodiments disclosed herein may minimize the need for verifying reach envelope compliance with a vehicle and physical envelope (e.g. physically pulling a vehicle through a space). In this manner, teams may need to only verify that definitions of the virtual map are accurate, leaning on the intelligence of the vehicle to make sure that standoff distances are maintained based on the virtual map definitions. Such embodiments may support quicker path and profile changes in a given facility or environment as the vehicles protect themselves appropriately without the need for procedural checks.

[0023] FIG. 1 illustrates an example virtual map 100 for use in map-based vehicle movement management. The virtual map 100 (or map) may represent an operating environment 104, such as an attraction, an environment, or the like. The virtual map 100 may include data associated with one or more structures, vehicles, surfaces, boundaries, objects, or the like in the operating environment 104. For example, the virtual map 100 may identify (e.g., digitally) one or more obstacles 110 and one or more vehicles 112 in the operating environment 104 or ride area. As shown, the virtual map 100 may illustrate or otherwise identify the position of each vehicle 112 relative to the obstacles 110 in the operating environment 104. As detailed more fully below, this information may be used to manage an attraction, such as operation of the vehicle(s) 112 within the operating environment 104. Depending on the application, the virtual map 100 may be stored on a vehicle 112 (e.g., each vehicle 112) or external to the vehicle 112, such as on a centralized wayside computer (or combinations thereof).

[0024] The obstacles 110 may be any structure, surface, boundary, hazard, undetectable/negative space, or object within the operating environment 104. For example, the obstacles 110 may include show sets 114, a loading/unloading area 116, a pathway obstruction or danger 118, or a restricted area 120. The show sets 114 may be fixed or movable pieces of the attraction for viewing by a rider of a vehicle 112, such as screens, props, doors, animatronics, or stages, among other attraction elements. The loading/unloading area 116 may be an area of the operating environment 104 where riders may load into, or unload from, a vehicle 112. The pathway obstruction/danger 118 may be a surface imperfection (e.g., a crack or pit in the floor, a slippery surface, etc.), a broken vehicle, a fallen show piece, dropped personal belongings, or other objects within the operating environment 104, such as along an intended path of the vehicle 112 through the attraction. The restricted area 120 may be any area within the operating environment 104 in which positioning of a vehicle 112 is undesired. For example, the restricted area 120 may be a hazardous area, a construction zone, or an area within which undesired viewing of the show sets 114 may occur.

[0025] Such examples are illustrative only, and the obstacles 110 may include other objects or configurations. For example, at least one obstacle 110 may be another vehicle 112. In some embodiments, at least one obstacle 110 may be undetectable to the vehicle 112. In such embodiments, the presence of the obstacle 110 may be known to the vehicle 112 only by the virtual map 100. In this manner, a user may identify an area within the operating environment 104 that is otherwise undetectable (e.g., a restricted area 120 that is not set off with cones or markers, an undetectable surface imperfection, a show set 114 masked by fog or mist, etc.) of which the vehicle 112 will treat as an obstacle 110.

[0026] The ride vehicles 112 may be configured to move through the operating environment 104 as part of an attraction or ride. Ride vehicle as used herein may refer to a vehicle coupled to a track, a trackless vehicle, an AGV, or an FRV, without intent to limit. In embodiments, the ride vehicle 112 is a pilotless vehicle, such as a ground vehicle, an aerial vehicle, or other mobile platform. Depending on the application, the ride vehicle 112 may by piloted autonomously (e.g., via an onboard controller or a centralized controller, such as the centralized wayside computer) or manually via remote control. The ride vehicle 112 may be a people mover or a ride/attraction element (e.g., a show element) configured to move through the operating environment 104, although other configurations are contemplated. The vehicle 112 may be ridden by one or more riders, personnel, staff, etc., or the vehicle 112 may move through the operating environment 104 without riders (e.g., as part of an attraction or show element). In other embodiments, a vehicle may be an automated warehouse vehicle, automated trainyard vehicle, tow vehicles, automated delivery vehicle, aerial vehicle, suspended vehicle, submarine, boat, watercraft, and the like. As a result, the term ride vehicle is not characterized by any particular function, shape, type, or technology.

[0027] In embodiments, the vehicles 112 may all be similar to one another, or the vehicles 112 may include different configurations. For example, one vehicle 112 may be configured to move people through the attraction, whereas another vehicle 112 may be configured to move as part of the attraction itself (e.g., as part of a show set 114, to provide visual interest, etc.). Additionally, or alternatively, one vehicle 112 may be a ground vehicle, whereas another vehicle 112 may be an aerial vehicle or a boat, i.e., the term vehicle 112 is meant to encompass vehicles of all types and in different environments.

[0028] As shown, the vehicles 112 may move individually and/or as a group through the operating environment 104. For example, the vehicles 112 may travel individually along a first portion of the attraction, such as along the same or similar path. In some embodiments, multiple vehicles 112 can act as a group. For example, the vehicles 112 may group together along a second portion of the attraction, such is in a platoon 126. In such embodiments, the platoon 126 may move in coordination along at least a portion of the attraction, with the platooned vehicles 112 moving together but along individual (e.g., different) paths. In another example, a plurality of vehicles 112 may be grouped together to move along the loading/unloading area 116 in coordination, such as simultaneously or synchronously along the same path as a group.

[0029] Using the virtual map 100, the vehicles 112 may move through the operating environment 104 while avoiding the obstacles 110. For example, identification of the obstacles 110 in the virtual map 100 may define the path or trajectory of the vehicles 112 through the attraction. In embodiments, the virtual map 100 may be dynamic and continually updated (e.g., during attraction operation). For example, the number and position of obstacles 110 and vehicles 112 may be continually updated in the virtual map 100, whether by the vehicle 112, a centralized wayside computer, a program user, or the like. As a result, one or more travel paths may be updated accordingly, such as automatically. As a result, the need for pre-analysis of travel paths may be minimized, thereby increasing efficiency and reducing downtime caused by unforeseen circumstances.

[0030] Management of vehicle movement through the operating environment 104 may be accomplished in various ways. In embodiments, a position of a vehicle 112 may be compared to a position of an obstacle 110 in the operating environment 104 using the virtual map 100. Depending on the application, the vehicle 112 itself or a centralized processor may do the comparing. In embodiments, the position of the vehicle 112 may be known, such as by the vehicle 112 or a centralized processor, or the position may be determined. For example, an environmental feature of the operating environment 104 may be detected by the vehicle 112. In such embodiments, the position of the vehicle 112 may be determined based on the detected environmental feature. The environmental feature may be a known hazard, object, or structure within the operating environment 104, such as a fixed feature of, or a known marker in, the operating environment 104 that is detectable by the vehicle 112. In embodiments, the virtual map 100 may be validated based on the detected environmental feature. For example, presence of the detected environmental feature in the virtual map 100 may validate the virtual map 100, although other configurations are contemplated.

[0031] In embodiments, a trajectory of a vehicle 112 may be adjusted to avoid an obstacle 110. For example, as shown in FIG. 1, a vehicle 112 may approach a restricted area 120 or a pathway obstruction/danger 118. In such embodiments, the vehicle 112 may move around the restricted area 120 or the pathway obstruction/danger 118 based on a comparison of the vehicle's position to the position of the obstacle 110. Similarly, the vehicle 112 may operate around the show sets 114 and loading/unloading area 116, or any other obstacle 110 in the operating environment 104, based on a comparison of the vehicle's position to the position of the obstacle 110 in the virtual map 100. Depending on the application, the vehicle 112 itself or a centralized processor may adjust the vehicle's trajectory.

[0032] In embodiments, the position of the vehicle 112 in the operating environment 104 may be updated on the virtual map 100. For example, as the trajectory of the vehicle 112 is adjusted, or as the vehicle 112 progresses through the attraction, the position of the vehicle 112 may be updated accordingly. In embodiments, movement of the vehicle 112 may be coordinated with movement of another vehicle 112 through the operating environment 104. For example, multiple vehicles 112 may be platooned to act as a group through at least a portion of the attraction, as described above. In embodiments, the virtual map 100 may be updated with an additional obstacle 110 identified by the vehicle 112. For example, the vehicle 112 may encounter a new obstacle 110 while moving through the attraction, such as dropped personal belongings from the vehicle ahead, a malfunctioning element, a broken down vehicle, etc. In like manner, the position, size, or other characteristic of an obstacle 110 may change during operation of the attraction. In such embodiments, the virtual map 100 may be updated such that the trajectories of the vehicles 112 may be updated to avoid the new or changed obstacle 110. In like manner, an obstacle 110 that has been cleared from the operating environment 104 may be removed from the virtual map 100. In such embodiments, the trajectories of the vehicles 112 may adjust (e.g., automatically, such as through receiving control instructions from a central controller or onboard the vehicle itself) to account for the removal of the obstacle 110. Depending on the application, the vehicle 112 itself or a centralized processor may update the vehicle's position in the virtual map 100, coordinate movement of the vehicle 112 with another vehicle 112, and/or update the obstacles 110 in the virtual map 100.

[0033] Any of the features, components, and/or parts, including the arrangements and configurations thereof shown in FIG. 1 can be included, either alone or in any combination, in any of the other examples of devices, features, components, and parts shown in the other figures described herein. Likewise, any of the features, components, and/or parts, including the arrangements and configurations thereof shown and described with reference to the other figures can be included, either alone or in any combination, in the example of the devices, features, components, and parts shown in FIG. 1.

[0034] FIG. 2 illustrates a schematic view of an example minimum separation distance 204 for a vehicle 112. Vehicles 112 operating in close proximity may require a minimum amount of separation, such as to ensure rider and equipment protection. The minimum separation distance 204 may also apply while operating in close proximity to a detectable obstacle 206 (e.g., any one of the obstacles 110 discussed above) or one or more walls 208. The minimum separation distance 204 may be a function of one or more characteristics or factors, such as vehicle type, rider type, and attraction dynamics, among other things. For example, the minimum separation distance 204 may increase with increased vehicle speeds, increased rider reach capability (e.g., adult vs. child), or open cockpit configurations, among other factors. Conversely, the minimum separation distance 204 may decrease with decreased vehicle speeds, decreased rider reach capability (e.g., child vs. adult), or closed cockpit configurations, among other factors.

[0035] FIG. 3 illustrates an example point cloud 308 used to detect one or more objects near a vehicle 112. In embodiments, one or more sensors 322 may perform a scan of the operating environment 104, such as to generate the point cloud 308 illustrated in FIG. 3. The point cloud 308 is a discrete set of data points in space, with each data point representing a single spatial measurement on a detected object surface (e.g., walls, ride elements, obstacles, other vehicles, etc.). Taken together, the point cloud 308 represents the detected operating environment 104 of the vehicle 112. As shown, the point cloud 308 may be a segment point cloud of a limited space around the vehicle 112 (e.g., of a particular quadrant or segment around the vehicle 112, etc.), although other configurations are contemplated.

[0036] Although a point cloud is illustrated, other data may be used to detect the operating environment 104 of the vehicle 112. In embodiments, the data associated with the operating environment 104 (e.g., the point cloud 308) may be received from the sensor 322. For example, a processor of the vehicle 112 or a centralized wayside computer may receive the data for processing, as described below. The sensor 322 may be a camera, a LIDAR sensor, or any other imaging component configured to capture data of the operating environment 104, such as to identify objects in the operating environment 104.

[0037] The point cloud 308 or other data may be used to distinguish between objects in the virtual map 100 and objects that are not. In embodiments, points from the point cloud 308 that are known based on the virtual map 100 may be removed. For example, as shown, the point cloud 308 may include a first set of points 324 representing spatial measurements to known objects, such as the obstacle 206 and walls 208 illustrated in FIG. 2. In such embodiments, the first set of points 324 may be removed from the point cloud 308, leaving a second set of points 326 (i.e., remaining points of the point cloud 308) representing spatial measurements to one or more unknown objects.

[0038] FIG. 4 illustrates an example object recognition algorithm to identify an object in the operating environment 104 based on the point cloud 308. As shown, at least some of the second set of points 326 may be converted to a shape 404. For example, the second set of points 326 may be connected by one or more lines to define the shape 404, such as the L-shape as illustrated in FIG. 4. Such examples are illustrative only, and additional or different shapes may be identified by the second set of points 326.

[0039] In embodiments, the shape 404 may be analyzed based on an object database 408 to associate the shape 404 with an expected object 410. For example, the shape 404 may be analyzed by or otherwise ran through the object database 408 to determine whether the shape 404 can be associated with an expected object 410 (e.g., such as via a best fit algorithm, classification algorithm, or the like). In embodiments, the object database 408 may include a machine learning model or other algorithm configured to associate the shape 404 with one or more expected objects. In embodiments, the object database 408 may include a complete or partial 3D model of each expected object that allows the expected object to be detected or identified from any angle or vehicle, such as by matching the shape 404 to a portion of the 3D model. In embodiments, the object database 408 may compare the shape 404 to one or more objects in the virtual map 100 to determine whether the object is known. For example, the object database 408 may match the shape 404 to a portion of obstacle 110 or vehicle 112 in the virtual map 100. In this manner, the identified object may be classified based on an object recognition process, although other configurations are contemplated. In some embodiments, the expected object 410 may be a second vehicle operating near the vehicle 112.

[0040] FIG. 5 illustrates example clearance envelopes assigned to an object (e.g., the expected object 410) identified using the object recognition algorithm of FIG. 4. Based on the classification of the identified object 410, one or more clearance envelopes may be assigned to the identified object 410. For example, at least one of a vehicle protection envelope 514 or a rider reach envelope 516 may be assigned to the identified object 410, such as when the identified object 410 is a vehicle. In such embodiments, the vehicle 112 may maintain minimum distance requirements to the identified object, such as by not piercing the vehicle protection envelope 514 or the rider reach envelope 516.

[0041] The vehicle protection envelope 514 may be a protection based on observed and/or anticipated dynamics of the identified vehicle. For example, the vehicle protection envelope 514 may be shaped and adjusted based on the observed or anticipated speed, acceleration limits, and/or trajectory of the identified vehicle. In some embodiments, the vehicle protection envelope 514 may be shaped and adjusted based on vehicle and/or environmental anomalies or events, such as planned and unplanned scenarios and/or conditions. As shown, the vehicle protection envelope 514 may have an oblong shape with an area of protection that is greatest in the direction of travel of the identified vehicle. In embodiments, the vehicle protection envelope 514 may be based on stored characteristics or profiles of the identified vehicle that are analyzed to generate the output.

[0042] The rider reach envelope 516 may be a protection associated with the type of identified vehicle. For example, an open cockpit configuration may result in a larger rider reach envelope 516 as riders can reach out of the vehicle. Similarly, a closed cockpit configuration may result in a smaller or non-existent rider reach envelope 516 since riders cannot reach out of the vehicle.

[0043] As a result, the vehicle 112 may make decisions in real time or near real time regarding the need for minimum spacing from other vehicles and objects. Such embodiments may allow for quick changes of vehicle motion and effectively remove the need for a virtual or preplanned track, thereby allowing the vehicle 112 to operate autonomously and adjust to changing conditions. In addition, or alternatively, the minimum distance needed by the vehicle 112 may be minimized since the vehicle 112 can determine how to assign both vehicle and rider reach protection envelopes.

[0044] Any of the features, components, and/or parts, including the arrangements and configurations thereof shown in FIGS. 2-5 can be included, either alone or in any combination, in any of the other examples of devices, features, components, and parts shown in the other figures described herein. Likewise, any of the features, components, and/or parts, including the arrangements and configurations thereof shown and described with reference to the other figures can be included, either alone or in any combination, in the example of the devices, features, components, and parts shown in FIGS. 2-5.

[0045] FIG. 6 illustrates example clearance requirements for zones within an operating environment based on one vehicle behavior characteristic (e.g., vehicle speed) and several environmental and/or object conditions (e.g., wet, slippery, hot, and the like). Other vehicle behavior requirements that may be defined in a similar way include direction, lane changing, ability to stop, rate of speed change, entrance permission, and the like. Operation or positioning of a vehicle 112 in an attraction may be constrained or otherwise determined based on one or multiple conditions present in the operating environment 104. For example, minimum clearances from the vehicle 112 to environmental conditions or objects may be set by one or more standards. In embodiments, the minimum clearances may vary based on vehicle speed. For example, lower vehicle speeds may allow the vehicle 112 to be positioned closer to an environmental condition or object. Conversely, higher speeds may necessitate positioning of the vehicle 112 further from the environmental conditions or objects.

[0046] FIG. 6 illustrates example clearance standards, represented by clearance zones 610, 620, 630 and 640, for various environmental conditions or objects based on vehicle speed. Example environmental conditions or objects (e.g., Condition 1, Condition 2, etc. illustrated in FIG. 6) may include hot or sharp objects, animation, doors and handrails, grabbable objects, walls, precipitation, mist, or gas, among others. In embodiments, ranges of vehicle speeds may correspond to a particular clearance zone with respect to the environmental conditions or objects proximate to the vehicle's location. For example, a first range of vehicle speeds may correspond to a harmless zone 610 with respect to some environmental conditions or objects. Similarly, a second range of vehicle speeds may correspond to a benign zone 620, a third range of vehicle speeds may correspond to an inhospitable zone 630, and a fourth range of vehicle speeds may correspond to an uninhabitable zone 640 with respect to particular environmental conditions or objects. Such clearance zones are exemplary, and other clearance zones may be defined, as well as the ranges of each zone adjusted based as appropriate for a particular application.

[0047] The harmless zone 610 may represent a spatial zone in which the vehicle 112 is free to operate adjacent or near the environmental condition or object. For example, referring to FIG. 6, the vehicle 112 may operate in Condition 10 at any vehicle speed with minimal clearance envelope protections. Conversely, the uninhabitable zone 640 may represent a spatial zone corresponding to a large clearance envelope that prevents operation adjacent or near the environmental condition or object. For example, the vehicle 112 may be prohibited from operating in Condition 1 regardless of speed. Both the benign zone 620 and the inhospitable zone 630 may correspond to clearance envelopes of various size and shape in which the vehicle 112 is able to operate at certain speed ranges, with more caution given in the inhospitable zone 630. For example, some caution may be needed in the benign zone 620, with greater caution needed in the inhospitable zone 630, such as in Condition 8.

[0048] As shown, increasing vehicle speeds may elevate the clearance envelope requirements needed to operate the vehicle 112 with respect to an environmental condition or object. For example, with respect to Condition 8, speeds up to 30 feet per second (fps) may correspond to the benign zone 620, speeds from 30 fps to 60 fps may correspond to the inhospitable zone 630, and speeds greater than 60 fps may correspond to the uninhabitable zone 640 of operation. The change in operation zones may occur at different speeds and/or at different elevations of caution. For example, with respect to Condition 9, speeds up to a threshold (e.g., 60 fps for Condition 9) may correspond to the harmless zone 610, and speeds greater than the threshold may correspond to the uninhabitable zone 640 of operation, with no other zones between the harmless zone 610 and the uninhabitable zone 640.

[0049] FIG. 7 illustrates use of the virtual map 100 in defining a clearance envelope 706 (e.g., the rider reach envelope 516) for vehicle 112. Specifically, FIG. 7 is a partial view of the virtual map 100 illustrating the vehicle 112 and an object 708 in the operating environment 104. Here, the object 708 is a wall or surface (e.g., of a show set 114, of the loading/unloading area 116, a boundary, etc.); however, the object 708 may be any obstacle 110 or obstacle in the operating environment 104.

[0050] The virtual map 100 may include or define a characteristic 712 for the object 708. For example, the virtual map 100 may include a first characteristic 712A for the object 708. The first characteristic 712A may define a first condition (e.g., a first environmental condition) for the object 708. An example first characteristic 712A may include a surface characteristic for the object 708, such as a smooth wall condition, a show flat that is smooth condition, or any other surface condition, such as those listed in FIG. 6, for instance.

[0051] As discussed above with reference to FIG. 6, the first characteristic 712A may determine or define a first set of operation parameters of the vehicle 112 with respect to the object 708. For example, based on vehicle speed and the first characteristic 712A, a processor (e.g., onboard logic or a centralized wayside computer) may determine a first clearance envelope 706A needed, such as to prevent or limit contact with the object 708, for instance.

[0052] In embodiments, the virtual map 100 may also include or define a second characteristic 712B for the object 708. The second characteristic 712B may define a second condition (e.g., a second environmental condition) for the object 708. An example second characteristic 712B may include an additional surface characteristic for the object 708, such as an animation condition or any other surface condition, such as those listed in FIG. 6, for instance.

[0053] The second characteristic 712B may determine or define a second set of operation parameters of the vehicle 112 with respect to the object 708. For example, based on vehicle speed and the second characteristic 712B, a processor (e.g., onboard logic or a centralized wayside computer) may determine a second clearance envelope 706B needed, such as to prevent or limit contact with the object 708, for instance. In embodiments, the second characteristic 712B may necessitate a different treatment from the perspective of the vehicle 112 compared to the first characteristic 712A. For example, the second characteristic 712B may necessitate a more stringent operation of the vehicle 112 (e.g., reduced speeds) or a greater clearance envelope 706 compared to those associated with the first characteristic 712A, or vice versa. In such embodiments, the more limiting operational parameters or clearance envelope 706 may be followed or used.

[0054] The vehicle 112 may query the virtual map 100, such as continuously during operation. Querying the virtual map 100 may allow the vehicle 112 to understand its environment and how the vehicle needs to interact with its surroundings. For example, based on the characteristic(s) 112 for the object 708, the vehicle 112 may maintain the clearance envelope 706 with respect to the object 708. As a result, the vehicle 112 may programmatically enforce clearance rules based on boundary condition details in the virtual map 100.

[0055] As noted above, the virtual map 100 may be updated, such as dynamically during attraction operation. In such embodiments, the vehicle 112 may receive an updated characteristic for the object 708. For example, any one of the first characteristic 712A or the second characteristic 712B may be updated based on changing conditions. In such embodiments, the vehicle 112 may adjust the clearance envelope 706 based on the updated characteristic for the object 708.

[0056] In like manner, the clearance envelope 706 may be dynamically adjusted (e.g., by the vehicle 112) based on a characteristic of the vehicle 112 itself. In embodiments, the clearance envelope 706 may be adjusted based on a speed, an orientation, or a configuration of the vehicle 112. For example, increasing speeds may necessitate a larger clearance envelope 706, or vice versa. Similarly, an orientation of the vehicle 112 away from the object 708 may allow the clearance envelope 706 to reduce in size. As noted above, a closed cockpit configuration of the vehicle 112 may result in a smaller or non-existent clearance envelope 706 since riders cannot reach out of the vehicle 112, whereas an open cockpit configuration may result in a larger clearance envelope 706 as riders can reach out of the vehicle.

[0057] By setting or dynamically updating the clearance envelope 706 of the vehicle 112 using the virtual map 100, the need for verifying envelope compliance may be minimized. For example, an operator or user may need to only verify that the definitions of the virtual map 100 are accurate for the operating environment 104, leaning on the intelligence of the vehicle 112 itself to make sure that standoff distances are maintained. Such embodiments may support rapid path and profile changes in a given attraction as the vehicle 112 will protect itself (e.g., automatically) based on the definitions in the virtual map 100.

[0058] Any of the features, components, and/or parts, including the arrangements and configurations thereof shown in FIG. 7 can be included, either alone or in any combination, in any of the other examples of devices, features, components, and parts shown in the other figures described herein. Likewise, any of the features, components, and/or parts, including the arrangements and configurations thereof shown and described with reference to the other figures can be included, either alone or in any combination, in the example of the devices, features, components, and parts shown in FIG. 7.

[0059] FIG. 8 illustrates an example computing system 800 for implementing various examples of the present disclosure. For example, in various embodiments, components of the vehicle 100 or other systems described herein may be implemented by one or several computing systems 800. In embodiments, the computing system 800 may be a centralized wayside computer in communication with the ride vehicle 112, such as to implement the systems and methods described herein. This disclosure contemplates any suitable number of computing systems 800. For example, the computing system 800 may be a server, a desktop computing system, a mainframe, a mesh of computing systems, a laptop or notebook computing system, a tablet computing system, an embedded computer system, a system-on-chip, a single-board computing system, or a combination of two or more of these. Where appropriate, the computing system 800 may include one or more computing systems; be unitary or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in a cloud, which may include one or more cloud components in one or more networks.

[0060] As shown, the computing system 800 includes memory 802 (e.g., RAM), static storage 804 (e.g., ROM), dynamic storage 806 (e.g., magnetic or optical), a processor 808, a data interface 812, a communications interface 816 (e.g., modem, Ethernet card, a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network, a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network), an input/output (I/O) interface 820 (e.g., keyboard, keypad, mouse, microphone, display enabling communication between a user and the computing system 800), and a bus 810 (e.g., an address/data bus or other communication mechanism for communicating information and/or interconnecting subsystems and devices of the computing system 800), or any combination thereof. In embodiments, the computing system 800 may include one or more of any such components.

[0061] In embodiments, processor 808 includes one or more processing units for executing instructions, such as those making up a computer program. For example, the processor 808 may execute instructions for various components of the ride vehicle 100 or other systems described herein. Although described in the singular for convenience, the processor 808 may include multiple processors (e.g., distributed over a network, between various components of the ride vehicle 100, etc.). The processor 808 includes circuitry for performing various processing functions, such as executing specific software to perform the methods of managing an attraction or ride vehicle described herein. For example, the processor may compare a position of the ride vehicle 112 to a position of an obstacle 110 in the operating environment 104 using the virtual map 100, and instruct a trajectory of the ride vehicle 112 to avoid the obstacle 110, such as in a manner as described above. In embodiments, the processor may receive an updated position of the ride vehicle 112 in the operating environment 104, and update the position of the ride vehicle 112 on the virtual map 100, such as in a manner as described above. Relatedly, in embodiments, the processor may receive data associated with a detected environmental feature of the operating environment 104, and determine the position of the ride vehicle 112 based on the received data, such as in a manner as described above. In embodiments, the processor may coordinate movement of the ride vehicle 112 with movement of another ride vehicle through the operating environment 104, such as in a manner as described above. In embodiments, the processor may receive data associated with an additional obstacle 110 identified by the ride vehicle 112, and update the virtual map 100 with the additional obstacle 110, such as in a manner as described above.

[0062] In particular embodiments, the communications interface 816 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computing system 800 and one or more other computer systems or one or more networks. One or more memory buses (which may each include an address bus and a data bus) may couple processor 808 to memory 802. Bus 810 may include one or more memory buses, as described below. In particular embodiments, one or more memory management units (MMUs) reside between processor 808 and memory 802 and facilitate accesses to memory 802 requested by processor 808. In particular embodiments, bus 810 includes hardware, software, or both coupling components of computing system 800 to each other.

[0063] According to particular embodiments, computing system 800 performs specific operations by processor 808 executing one or more sequences of one or more instructions contained in memory 802. For example, instructions for the ride vehicle 100 or other systems described herein may be contained in memory 802 and may be executed by the processor 808. Such instructions may be read into memory 802 from another computer readable/usable medium, such as static storage 804 or dynamic storage 806. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, particular embodiments are not limited to any specific combination of hardware circuitry and/or software.

[0064] In embodiments, the term logic means any combination of software or hardware that is used to implement all or part of particular embodiments disclosed herein. The term computer readable medium or computer usable medium may refer to any medium that participates in providing instructions to processor 808 for execution. Such a medium may take many forms, including but not limited to, nonvolatile media and volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as static storage 804 or dynamic storage 806. Volatile media includes dynamic memory, such as memory 802.

[0065] Computing system 800 may transmit and receive messages, data, and instructions, including program, e.g., application code, through communications link 818 and communications interface 816. Received program code may be executed by processor 808 as it is received, and/or stored in static storage 804 or dynamic storage 806, or other storage for later execution. A database 814 may be used to store data accessible by the computing system 800 by way of data interface 812. In various examples, communications link 818 may communicate with the motion system 100 or other systems described herein.

[0066] Any of the features, components, and/or parts, including the arrangements and configurations thereof shown in FIG. 8 can be included, either alone or in any combination, in any of the other examples of devices, features, components, and parts shown in the other figures described herein. Likewise, any of the features, components, and/or parts, including the arrangements and configurations thereof shown and described with reference to the other figures can be included, either alone or in any combination, in the example of the devices, features, components, and parts shown in FIG. 8.

[0067] The embodiments illustrated in FIGS. 1-5 are non-limiting examples for managing an attraction or a ride vehicle. Thus, the description of certain embodiments included herein is merely exemplary in nature and is in no way intended to limit the scope of the disclosure or its applications or uses. In the included detailed description of embodiments of the present systems and methods, reference is made to the accompanying drawings which form a part hereof, and which are shown by way of illustration specific to embodiments in which the described systems and methods may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice presently disclosed systems and methods, and it is to be understood that other embodiments may be utilized, and that structural and logical changes may be made without departing from the spirit and scope of the disclosure. Moreover, for the purpose of clarity, detailed descriptions of certain features will not be discussed when they would be apparent to those with skill in the art so as not to obscure the description of embodiments of the disclosure. The included detailed description is therefore not to be taken in a limiting sense, and the scope of the disclosure is defined only by the appended claims.

[0068] From the foregoing it will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention.

[0069] The particulars shown herein are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of various embodiments of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for the fundamental understanding of the invention, the description taken with the drawings and/or examples making apparent to those skilled in the art how the several forms of the invention may be embodied in practice.

[0070] As used herein and unless otherwise indicated, the terms a and an are taken to mean one, at least one or one or more. Unless otherwise required by context, singular terms used herein shall include pluralities and plural terms shall include the singular.

[0071] Unless the context clearly requires otherwise, throughout the description and the claims, the words comprise, comprising, and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in the sense of including, but not limited to. Words using the singular or plural number also include the plural and singular number, respectively. Additionally, the words herein, above, and below and words of similar import, when used in this application, shall refer to this application as a whole and not to any particular portions of the application.

[0072] Of course, it is to be appreciated that any one of the examples, embodiments or processes described herein may be combined with one or more other examples, embodiments and/or processes or be separated and/or performed amongst separate devices or device portions in accordance with the present systems, devices and methods.

[0073] Finally, the above discussion is intended to be merely illustrative of the present system and should not be construed as limiting the appended claims to any particular embodiment or group of embodiments. Thus, while the present system has been described in particular detail with reference to exemplary embodiments, it should also be appreciated that numerous modifications and alternative embodiments may be devised by those having ordinary skill in the art without departing from the broader and intended spirit and scope of the present system as set forth in the claims that follow. Accordingly, the specification and drawings are to be regarded in an illustrative manner and are not intended to limit the scope of the appended claims.