Computer device support structure

Abstract

A frame for holding a set of hardware components for executing an interactive user experience is provided. The set of hardware components comprises a computing device. The frame comprises and input / output (I / O) face and a computing device access face. The I / O face provides access to a plurality of ports of the set of hardware components. The computing device access face providing access to the computing device. Physical connections, provided by physical electronic connectors, between a component of the set of components and an external component are provided via the I / O face only.

Description

[0001] Computer Device Support Structure

[0002] Technical Filed

[0003] The present disclosure relates to a frame for holding a set of hardware components and a system for implementing an interactive user experience.

[0004] Background

[0005] In immersive user experience, one or more pieces of computing equipment are required to implement the environment. For example, a server may be user to process user inputs and / or render images based on the user inputs.

[0006] It may be preferrable for the computing equipment to be contained in a structure which is held out of the way of participants of the immersive user experience. This prevents user obstruction of the computer equipment, so more reliably providing the experience, and ensuring the safety of the participants.

[0007] Summary

[0008] According to a first aspect of the present invention, there is provided a frame for holding a set of hardware components for executing an interactive user experience, the set of hardware components comprising a computing device, the frame comprising: an input / output, VO, face, wherein the I / O face provides access to a plurality of ports of the set of hardware components; and a computing device access face providing access to the computing device; wherein physical connections, provided by physical electronic connectors, between a component of the set of components and an external component are provided via the I / O face only.

[0009] By housing the hardware components in a frame with face through which all physical connections are passed and another face via which the hardware can be accessed and removed, ease of maintenance of the hardware is improved.

[0010] According to a second aspect, there is provided a system for implementing an interactive user experience comprising: the frame as set out above; and a set of hardware components comprising a computing device configured to execute a game engine for implementing at least a portion of the interactive user experience. Brief Description of the Figures

[0011] For a better understanding of some embodiments and to show how the same may be carried into effect, reference will now be made by way of example only to the accompanying drawings in which:

[0012] Figure 1 provides an interactive room;

[0013] Figures 2 and 3 provide a gameframe;

[0014] Figure 4 shows a schematic functional block diagram of a computer system incorporating lidar touchscreen functionality;

[0015] Figure 5 provides an example process for implementing actions in the interactive experience;

[0016] Figures 6, 6 A, and 6B illustrate lidar detection using a lidar scanner 102;

[0017] Figure 7 shows an example game which may be implemented on the game environment;

[0018] Figure 8 shows an example game rule database which may be used when providing the game environment; and

[0019] Figure 9 shows a schematic view of a computing device.

[0020] Detailed Description

[0021] Figure 1 shows an interactive room 100 comprising four walls, three of which are rendered interactive by way of appropriately-located lidar sensors 102-F, 102-L, 102-R (front, left, and right walls 104-F, 104-L, 104-R). In other implementations, one, some or all the walls of the room 200 (e.g. one, two, three, or four walls) may be interactive. The lidar sensors 102-F, 102-L, 102-R are used to detect a physical user interaction with one of the walls 104-F, 104- L, 104-R. An interactive environment is provided in the room 100. A user interacts with the interactive environment by way of touch inputs provided at the walls 104-F, 104-L, 104-R and corresponding to locations in the interactive environment.

[0022] Respective images are projected onto respective display areas 105-L, 105-F, 105-R of the three interactive walls 104-L, 104-F, 104-R using an arrangement of image projectors 108 positioned at or near the ceiling of the room 100. By placing the projectors 108 in this position, users of the lidar touchscreens 100 can move freely in the room without blocking, or colliding with, the projector 108.

[0023] The images provided to the interactive walls 104-L, 104-R, 104-F of the room 100 may correspond to the same interactive environment. For example, in a game environment using a gameboard, the gameboard may cover some or all of the three display screens 104 of the room 100. More generally, interactive game elements can be rendered on the interactive walls, and pass freely between the walls in a seamless manner (with the three images being adjacent portions of a single, larger game image that spans the three interactive walls 104-L,

[0024] 104-F, 104-R).

[0025] A fourth (back) wall 104-B is ‘passive’ in the present example. Each of the display areas

[0026] 105-L, 105-F, 105-R extends down to the floor 107. The front wall 104-F meets the left and right walls 104-L, 104-R at first and second outer edges 103-LF and 103-RF respectively, and the back wall 104-B meets the left and right walls 104-L, 104-R at third and fourth outer edges 103-LB and 103-RB respectively. The front display area 105-F extends between the first and second outer edges 103-RF, 103-LF thereof, and the left and right display areas 105- L, 105-R extend between the first and third outer edges 103-FL, 103-LB and second and fourth outer edges 103-RF, 103-RB respectively, in an edge-to-edge fashion, to provide a single and essentially continuous display area spanning the three interactive walls 104-L, 104-F, 104-F, all the way to the back wall 104-B.

[0027] To implement the interactive environment in the room 100, one or more computing devices are required, which process signals received from the lidar sensors 102-F, 102-L, 102-R and determine corresponding actions in the interactive environment. These computing devices are held in a gameframe 110 positioned at or near the ceiling of the room 100, and towards the back wall 104-B of the room 100. The gameframe 110 in some instances may be located centrally near the ceiling of the room 100.

[0028] The gameframe 110 may be held in place in the room 100 by securing it on a gantry with a safety tether or other suitable attachment means. In some embodiments, the gameframe 110 may alternatively be mounted on the rear wall 104-B, using angled brackets or French cleats, for example.

[0029] Figure 2 shows an example gameframe 110 from four different angles. The gameframe 110 is a structure for supporting computing equipment for enabling the immersive user experience. The gameframe 110 may be referred to as a frame or a chassis.

[0030] The gameframe 110 itself comprises 12 L-shaped metal strips, arranged to form the edges of a cuboid. The metal strips are connected together at the vertices, or corners, of the cuboid using releasable fastening. The L-shaped strip 218 providing the top and bottom edges of a shorter face of the gameframe 110 have endplates, such that the L-shaped strips 218 effectively provide a 3 -way angle at each end. Alternatively, the L-shaped strips meeting at a given comer may each be attached to a 3-way metal angle, thereby creating a comer connection.

[0031] The gameframe 110 also comprises two shelves 208, 210 onto which components held by, or within, the gameframe 110 are placed. A game server shelf 208 is located at a lower height within the gameframe 110 than a touch server shelf 210. This layout is to provide sufficient space for the corresponding server 202, 204 and other components held within the gameframe 110. Beams 210 are provided between lower and upper side strips 222 to provide both stability to the gameframe 110 and to provide connections for the shelves 208, 210.

[0032] Releasable fastenings are used to connect each element 208, 210, 218, 220, 222 of the gameframe 110. For example, the elements 208, 210, 218, 220, 222 may comprise holes through which bolts are placed to connect the required elements together, and nuts used to fix the elements 208, 210, 218, 220, 222 in place. Other releasable fastenings may be used and are known in the art. Using releasable fastenings allows elements of the gameframe 110 to be replaced if they become damaged or broken. The modular construction of the gameframe 110 allows for both easier manufacture and shipping. The gameframe 100 elements can be shipped when deconstructed, and constructed on-site, for example. Alternatively, the gameframe 110 may be constructed at a manufacturing site and shipped in its constructed state.

[0033] The gameframe 110 further comprises handles 216 attached to a top part of the L-shaped strip 218 providing the top edge of the shorter faces of the gameframe 110. The handles 216 provide means for easily handling the gameframe 110 by operators or installers.

[0034] The gameframe 110 is used to hold a game server 202, a touch server 204, a USB power distribution module 206, and a network switch 212. Power is provided to the components held in the gameframe 110 via an alternative current (AC) power distribution module 214, which is connected to the network switch 212. The game server 202 and the touch server 204 are connected to the network switch 212. The network switch 212 enables the game server 202 and the touch server 204 to communicate with one another by exchanging data packets.

[0035] The power distribution module 206, also referred to as a power distribution unit (PDU), allows for remote management of power to multiple devices, and thus providing means for load management as well as performing hard resets. Each of the components of held in the gameframe 110 is powered by the PDU 206. The PDU 206 may be an intelligent (IP) PDU.

[0036] Referring to the view of the gameframe 110 in the bottom left-hand comer of Figure 2, a long side of the gameframe 110 is shown. The game server shelf 208 is provided on the right-hand side of the gameframe 110 at a first height from the bottom of the gameframe 110 and with the game server 202 sitting on top of the game server shelf 208. The touch server shelf 210 is provided on the left-hand side at a second height from the bottom of the gameframe 110, the second height being larger than the first, and the touch server 204 is sat on the touch server shelf 210. The beam 220 connects both shelves 208, 210 to the top and bottom strips of the long side of the gameframe 110.

[0037] The network switch 212 is located below the touch server shelf 210 and above the AC power distribution module 214. The game server shelf 208 is located at a lower height that the touch server 210 to accommodate the different sizes of the servers 202, 204. This also provides flexibility since the gameframe 110 provides areas of different sizes, so if the hardware requirements change, there is still sufficient space within the gameframe 110 to accommodate the change in hardware. Changes may include the introduction of further hardware components or a change in size of the components already held within the gameframe 110.

[0038] Figure 3 provides further views of the gameframe 110. The gameframe further comprises an input / output (I / O) panel 302. The VO panel 302 is located at the short end of the gameframe 110 closest to the touch server 204 and the network switch 212. This face of the gameframe 110 is referred to as an I / O face.

[0039] The I / O panel 302 comprises a set of openings 304, 306, 308, 310, 312, 314, 316 in two rows. A top row comprises three USB-a power line openings 304, three USB-a data line openings 306, a USB-c connection opening 312, and an HDMI touch server connection opening 314. A bottom row comprises four XLR audio connection openings 308, four HDMI projector connection openings 310, a USB-a game server connection opening 316, and an HDMI game server connection opening 318. There is also a large pass through opening 320 at one end of the VO panel 302.

[0040] It can be seen that four types of connections are used for connecting to the components held in the gameframe 110: HDMI, USB-a, USB-c, and XLR. These connection types may vary depending on the components themselves, and therefore the connection types provided herein are provided by of example. The connections are between components held within the gameframe 110 and external components, such as the projectors 108, other computing devices, or power sources, for example.

[0041] Each of the openings 304, 306, 308, 310, 312, 314, 316, other than the pass through opening 320, of the VO panel 302 is the same size. This is to improve ease of manufacture. The size of the openings 304, 306, 308, 310, 312, 314, 316 is that as to allow the largest of a standard HDMI, USB-a, USB-c, and XLR cable to pass through. It will be appreciated that the openings 304, 306, 308, 310, 312, 314, 316 may have different sizes, with a minimum for each being such as to allow for their respective connection cable, or other physical connector, to pass through the opening. The cables passing through the openings of the I / O panel 302 provide physical connections to ports or connections of the components held within the gameframe 110. These ports may be I / O ports or power ports. The physical connections are physical electronic connections, that is for passing data or power by a wired connection.

[0042] The USB-a data line openings 306 and USB-a power line openings 304 allow data lines and power lines for providing power to the touch server 204 respectively to pass to the touch server 204. The lidar sensors 102-L, 102-F, 102-R are connected to the touch server 202 using cables which pass through the data line openings 306.

[0043] The projectors 108 are each connected to the game server 202 using cables which pass through the HDMI projector connection openings 310. The game server 202 provides images to the projectors 108 via these connections.

[0044] The layout of the components within the gameframe 110 provides space for the cables to run from the touch server 204 to the game server 202, thereby allowing communication between the two servers 202, 204.

[0045] Speakers (not shown) in the room 100 are connected to the game server 202 via cables passing through the XLR audio connection openings 308. In the implementation provided herein, there are four speakers provided in the room 100, one in each corner, and so there are four openings 308 for connecting them to the game server 202.

[0046] The USB-c connection opening 312 is used for to connect a camera. The camera may be a still image camera. The camera is a Participant Content Capture (PCC) device, which captures an image of the players at the end of a game session. At the end of the game session, a game session report may be displayed, or otherwise made available, to the players, which includes the captured image. The report may include statistics or other game data such as high scores, player rankings, etc. as determined by the game server 202.

[0047] The USB-a game server connection opening 316 allows a data line to be connected to the game server 202. This connection allows data such as game session data to be passed from a venue central server to the game server 202, and vice versa. This data line may also be used to update the game server 202, for example. The HDMI connections to the touch server 204 and game server 202 passing through openings 314, 318 respectively are used for servicing and repairing the servers 202, 204. Thus, in the event of a failure, there is a way to easily connect directly to the servers without having to unplug other hardware such as the projectors 108.

[0048] The pass through opening 320 allows for cables to run to the network switch 212 and the PDU 206. These cables may be, for example, power cables.

[0049] The layout of the openings of the I / O panel 302 has been chosen based on the layout of the components within the gameframe 110. The layout shown in Figure 3 reduces the cross-over of cables within the gameframe 100 when the components are arranged as shown with refence to Figures 2 and 3. It will be appreciated that other arrangements of components and openings are possible.

[0050] While reference to cables has been made above, any suitable physical electronic connector may be used to provide connections between devices.

[0051] The components held within the gameframe 110 are positioned such that their ports, where possible, face the I / O panel 302. For example, a face of the game server 202 comprising HDMI ports for connecting to the projectors faces the VO panel 302. “Faces” herein means closest to. This can be seen in the lower left-hand image of the gameframe 110 in Figure 3, for example. By orientating the components in this manner, the cables within the gameframe 110 are not required to circumvent the component they are connected to, and therefore can be arranged in a more organised way. This improves ease of maintenance.

[0052] In this way, all connections into and out of the gameframe 110 are limited to one end of the gameframe 110, the end with the I / O panel 302. This has the benefit of easier installation within a room 100 because all connecting elements connect at one face. Also, changing components within the gameframe 110 is easier since the location of connections does not change. That is, exposing the connections only on one end of the gameframe 110 improves maintenance support as it is easy for an engineer to see and disconnect and / or reconnect and / or add a temporary cable to test etc rather than having all connections concealed in the centre. The I / O panel 302 is fixed to the gameframe 110 with releasable fastenings, such as screws. The use of releasable fastenings mean that, if the required connections change, the I / O panel 302 can be redesigned and replaced without the need to replace the whole gameframe 110. For example, if more projectors are added into the room 100, the I / O panel 302 can be redesigned to increase the number of HDMI projector connection openings 310 in line with the increase in the number of projectors, and the I / O panel 302 replaced.

[0053] At the short face opposite the I / O panel, referred to as a computing device access face, the face is open. This provides easy access to the game server 202 so that the game server 202 can be removed and / or replaced if needed. For example, if there is a fault in the game server 202, the game server 202 can be “hot swapped” for another, working, game sever 202 without having to remove any other components form the gameframe 110. The fixed connection locations also result in an easier hot swap of servers 202.

[0054] By keeping the device access face open, the VO panel 302 does not need to be removed in order to access the components held in the gameframe 110. This improves ease of maintenance since both the I / O panel 302 does not need to be removed and any connections to other components passing through the I / O panel 302 can remain connected.

[0055] The shelves 208, 210 have fin-shaped holes in their base, i.e. the part of the shelf 208, 210 on which the server is positioned. These holes allow air to circulate closer to the servers 202, 204 and therefore provide passive cooling for the servers 202, 204.

[0056] At least some of the L-shaped strips forming the gameframe 110 comprise holes. These holes are used to connect elements of the gameframe 110 together, as described above. The holes are provided uniformly along the strips. By providing more holes than are necessary for the construction of the gameframe 110, the gameframe 110 can be easily modified on-site, without requiring additional holes to be cut for new elements to be connected thereto. That is, the holes provide flexibility to the gameframe 110 such that it can be modified as the components held within the gameframe 110 change.

[0057] The holes on both the L-shaped strips and the shelves also helps to reduce the overall weight of the gameframe 110. The gameframe 110 is similar to a modular 19” rack-mount chassis. This is a standard size of rack within the field of technology, and the measurement of 19” refers to the width of the front panel of the mountable module that slides into the rack. The gameframe 110 has a width in the region of 450mm and 550mm, may be between 483mm and 550mm, and preferably 516mm. The gameframe 110 has a height in the range of 250mm and 300mm, and preferably 278mm. The handles 216 may provide an additional height of around 48mm. The gameframe 110 has a length in the range of 825mm and 875mm, and preferably 855mm. . It will be appreciated that the gameframe 110 may be made to have different dimensions if so required by the components held within the gameframe 110.

[0058] As set out above, the elements of the gameframe 110 may be shipped in a deconstructed state and the gameframe 110 constructed on-site, i.e. at or near the location of the room 100.

[0059] In other embodiments, the gameframe 110 is constructed at a manufacturing site and shipped to the location of use, i.e. the room 100. The dimensions of the gameframe 110 are chosen, both to accommodate the hardware to be held by the gameframe 110, and to be suitable for shipping using standard shipping equipment, specifically pallets. In Europe, Euro pallets are used in shipping. These pallets have a size of 1200x800mm. The Euro pallet is smaller than the standard pallet used in the UK, at 1200x1000mm, and therefore the gameframe 110 can be shipped using both pallet sizes.

[0060] The computing hardware components are tested at the manufacturing site before being shipped to the location of use. This reduces the changes of the equipment being unsuitable for use on arrival, and reduces installation time as testing is not required on-site. The components are mounted into the gameframe 110 at the manufacturing site. The components are attached to the gameframe 110 using releasable fastenings. For example, cage nuts, or other nut-and- bolt combinations may be used to provide the releasable fastening.

[0061] The gameframe 110 provides standard mounting points for standard 19" rack mountable components. These components are measured in “U’s”, or “rack units”, which are a commonly used unit of measure in the art and measure 1.75 inches. The height of the gameframe 110 provides 4Us. The gameframe 110, once constructed and filled with the hardware equipment, is loaded onto a euro pallet. Three gameframes 110 are stacked on the pallet.

[0062] The gameframes 110 are stacked so that the bottom L-shaped strips 222 of the bottom gameframe 110 in the stack are flush to the pallet. For gameframes 110 higher in the stack, their bottom L-shaped strips 222 are flush to the top L-shaped strips 222 of the gameframe 110 below in the stack. This stacking removes any point loading, and therefore reduces shear forces in the gameframes 110 during transit.

[0063] The gameframes 110 are designed to carry the weight of the gameframe 110 and the components held inside when in use in the room 100. They are also designed to be able to carry the load of at least two gameframes 110 stacked above it and their components when in transit.

[0064] Within the gameframe 110, the game server 202 and touch server 204 provide different functionalities. The game server 202, for implementing a game engine as described below, is more likely to require updating, for example if game rules change, or if operational systems need updating for improvements to the games to be implemented. Alternatively, the game server 202 may be replaced with a different game server 202 if a different game is to be played in the same room 100 or if updates are needed. It is therefore beneficial to have two different servers, and for the game server 202 to be accessible without having to detach the gameframe 110 from the ceiling of the room 100, without having to remove any part of the gameframe 110 such as the I / O panel 302, or without having to remove any other components from the gameframe 110. The layout of the components held within the gameframe 110 contributes to this, with the game server 202 being located by the open device access face.

[0065] Power to the servers 202, 204 and other hardware components held within the gameframe 110, or hardware components connected thereto such as the projector 108, is controlled remotely. That is, the servers 202 , 204 etc. are tuned on and off without having to physically access the servers 202, 204, and in some instances can be turned on and off from outside the room 100. This removes the need to be able to easily access power switches of the devices, and therefore provides more flexibility for aligning the hardware devices within the gameframe 110 for improved maintenance. The constituent parts of the gameframe 110 are made of metal. Any suitable metal may be used, where a suitable metal is one which is strong enough to withstand the forces applied to it when in use. It will be apricated that other materials which provide suitable resistance to the forces applied may be used.

[0066] Figure 4 shows a schematic functional block diagram of a computer system incorporating lidar touchscreen functionality, which is described in detail below. For now, suffice it to say that the system comprises a touch data processor 1002 that received and processes lidar returns from the lidar sensor 102, and a game engine 1006 that receives and actions detected touch inputs from the touch data processor 1002 to deliver an interactive visual experience (a game in the examples below). The game engine 1006 acts as an image rendering component to render and update images containing interactive game elements, which are then provided to a display system 1004. The game engine may also determine sounds to be played in the room 100 corresponding to actions within the game based on user inputs. The game engine 1006 provides instructions to an audio system 1008 located in the room 100 (not shown), such as speakers, to emit the sound.

[0067] The computer system is implemented using the touch server 204 and the game server 202. The touch data processor 1002 is executed on the touch server 204, which the game server 202 is configured to execute the game engine 1006.

[0068] The game engine 1006 may receive game session data from a venue central server, which generates and maintains game session data for multiple game servers 202 across a venue. Game session data may include game rules and / or booking data. Booking data may include a name or booking reference, a time, a number of players, and / or a game refences identifying a game to be played. The game engine 1006 uses the game session data to execute the game. The game engine 1006 may pass data to the venue central server at the end of a game session, such as results (e.g. scores) of the game.

[0069] Figure 5 shows an example process for implementing actions in the interactive experience. Reference is made to Figures 6, 6A, and 6B. Figure 6, 6A, and 6B illustrate lidar detection using a lidar scanner 102. Lidar scanning is known in the art and therefore will not be described in detail herein. Figure 6 shows an arrangement referred to herein as a “lidar touchscreen” and is described in detail below.

[0070] At step S502, the user provides an input at a location on the display screen 104. This input is provided by way of user touch 608 or by some other objects, such as a stylus, touching the surface of the display screen 104 (or, more precisely, intersecting a detection plane 109 of the lidar scanner 102).

[0071] The lidar scanner 102 detects one or more returns from the user touch 608 (e.g. the user’s hand) at step S504. It will be appreciated that the lidar scanner 102 continuously scans the detection plane 109 in order to be able to detect a user touch at any time.

[0072] The lidar scanner 102 provides the lidar return corresponding to the user touch 608 at step S506. This return is provided to the touch data processor 1002 at the touch server 204, which transforms the lidar returns to a touch input for actioning by the game engine 1006. Whilst the following description refers to a single lidar return from an object (e.g. user’s hand), it will be appreciated that multiple returns may be detected and processed from the object, and aggregated to provide a single touch input when the multiple returns are determined to belong to the same object.

[0073] Whilst step S504 considers a return from a user touch 608, the lidar scanner 102 provides all lidar returns to the touch data processor 1002, i.e. all lidar returns irrespective of whether a user touch 608 is detected or not. However, not all lidar returns necessarily trigger a touch input. In the present example, individual lidar returns are converted to an (x,y) coordinate representation. For example, each lidar return could be transformed to the normalized coordinate system of the surface, although it is not necessary to transform the lidar returns to (x,y) surface coordinates for this purpose; blob detection would be applied in any (x,y) coordinate system (e.g. by simply converting the return time and return angle to (x,y) coordinates in units of distance, meaning the lidar points are represented in a non-normalized coordinate system, with the lidar sensor 102 at the origin). In this manner, individual lidar returns are transformed to (x,y) points (lidar points). In particular, lidar returns from the adjacent surfaces (walls, floor and / or ceiling) are ignored for the purpose of detecting touch input. The present techniques apply a form of “blob detection” to the (x,y) lidar points. Any two lidar points within some threshold distance of each other are determined to belong to a common object (or, more generally, lidar points are clustered into object groups using an appropriate clustering technique). Then, for each set of points determined to belong to a common object, a circle (or other predetermined shape) is fitted to those points. A touch input detection is triggered only if the radius of the circle is greater than a minimum radius, but less than a maximum radius. The minimum and maximum radius are examples of touch input conditions that may be tuned to approximately match the scale of a human hand. These limits provide robustness to ‘spurious’ detections that do not actually result from objects of the expected size (e.g. reflections caused by opening a door to the room). This same mechanism could be used to exclude lidar returns from the adjacent surfaces (as these would be grouped as much larger objects above the maximum radius), although such returns could also be excluded based on the known positions of those surfaces relative to the lidar scanner. That is to say, the touch data processor 1002 may additionally filter-out the lidar return from the adjacent walls and floor, so that touch input are only instigated by a lidar retum(s) from an object within the area defined by the adjacent walls and floors (object return). For example, the touch data processor 1002 may determine which, if any, of the lidar returns have a distance value less than that corresponding to the display screen boundary for the corresponding angle of the lidar return. Alternatively, the touch data processor 1002 may determine a location of all of the lidar returns on the display screen 104, and use the determined locations to isolate the location of the user touch 108.

[0074] If any object lidar returns are detected, the touch data processor 1002 determines (S508-510) a touch input comprising the location (x,y) of the user touch 108 on the display screen 104. As noted, this location is derived from knowledge of the position of the lidar sensor 102 relative to the wall 104. Figure 5 considers a multi-stage process, in which the return time and return angle of the lidar retum(s) is first converted to normalized cartesian coordinates on the wall 104 (S508), and then to pixel coordinates in the image (S510). However, the lidar coordinates can alternatively be converted to pixel coordinates directly. In some implementations, more than two coordinate system might be used. For example, blob detection could be applied in a non-normalized (x,y) coordinate system of the lidar sensor 102 (with the lidar sensor 102 at the origin) to locate a detected object(s) in that coordinate system. The location of any detected object(s) satisfying the touch input conditions(s) (e.g. the center point of a circle fitted to a cluster of object points) may then be transformed to normalized (or non-normalized) surface coordinates (e.g. with a comer or center point of the surface 104 as the origin), and the surface coordinates may then be transformed to (x,y) game coordinates.

[0075] Once the location of the user input 108 is known in game (x,y) coordinates, the game engine 1006, run on the game server 202, then determines the action to be triggered based on the location of the user input, of which steps S512 to S520 provide an example method.

[0076] At step S512, the game engine 1006 determines whether the (x,y) location of the touch input corresponds to a user selectable element. The interactive user environment comprises user selectable elements, such as game pieces in a game environment. However, the interactive user environment also provides areas which are not user selectable, such as empty spaces or “locked” elements, which the user may, for example, have to unlock through gameplay or by logging in to a user account.

[0077] If it is determined that the user input is not at the location of a user selectable element, no action is triggered, step S514.

[0078] If, however, the user input is associated with a user selectable element, a set of rules associated with the interactive user environment is accessed to determine a corresponding action, step S516.

[0079] At step S518, the determined action associated with the user input is triggered and the image updated accordingly. This updated image is displayed on the display screen 104 at step S520. The user can then provide a further input, S502, corresponding to the updated image.

[0080] Sounds to me emitted may also be determined, based on triggered actions, at step S518, which are then emitted by the audio system 1008 at step S520.

[0081] In some embodiments, sounds are also emitted if the player fails to interact with an interactable element. For example, a negative sounds may be played if the user touches an area of the display at which no elements are rendered. In this case, the game engine determines the sound and provides an instruction to emit the sound to the audio system 1008 at step S514. Figure 7 shows an example game which may be implemented on the game environment. Figure 8 shows an example game rule database 800 which may be used when providing the game environment of Figure 7. The game rule database is stored on the game server 202.

[0082] At step S702, an image is displayed on the display screen 104 with a number of cards, each card showing a shape. In the example for Figure 7, six cards are shown, with each card having either a star, a hexagon, or a cross. Two of the six cards have each of the three shapes.

[0083] At step S704, a new image is displayed on the display screen 104 in which the cards have been reversed such that the user can no longer see the shapes. The aim of the game is for the user to pair up matching cards from memory.

[0084] The user selects a first card by providing a user input at the location of the display screen 104 at which the first card is displayed.

[0085] The game engine 1006 accesses the game rules database 800 to determine the action to be triggered. Since the user has selected a first card, the triggered action is to turn over the selected card. The image is updated, by the game engine 1006 and passed to the display system 1004 for rendering to the user, to display the first card shape side up, showing a star, and the updated image is displayed on the display screen 104, step S706.

[0086] The user selects a second card by providing a user input at the location of the display screen 104 at which the second card is displayed. Again, the game engine 1006 accesses the game rules database 800 to determine the action to be triggered.

[0087] If the user has selected the card matching the first card, in this example the other card with a star, the triggered action is turning the second selected card over, changing the colour of both of the now selected cards to green, and removing the cards from the game environment.

[0088] The image is updated based on the triggered action and displayed on the display screen 104. In the example of Figure 7, the actions are triggered in two stages.

[0089] At the first stage, the second card is turned over and both cards are shown in green, step

[0090] S708. At the second stage, the cards are removed, step S710. It will be apricated that each of the actions associated with the selected element may be implemented in separate steps, in a single step, or in any combination of steps.

[0091] If, instead, the user has selected a card which does not match the first card, in this example a card with a cross, the triggered action is turning the second selected card over, changing the colour of both of the now selected cards to red, and turning both cards back over so that no shape is visible to the user.

[0092] The image is updated based on the triggered action and displayed on the display screen 104. In the example of Figure 7, the actions are triggered in two stages.

[0093] At the first stage, the second card is turned over and both cards are shown in red, step S712. At the second stage, the cards are turned back over, step S714.

[0094] The game rule database 800 also comprises a score associated with the selected element. During game play, a game score may be calculated by the game engine 1006 based on these scores. For example, when the user selects a first card, there is no change in score; if the user selects a matching card, the score increases by 10 points; and if the user selects a nonmatching card, the score decreases by 5 points.

[0095] The game engine 1006 updates the game score with each user selection.

[0096] Returning to Figures 6 and 6 A, a user selects a selectable element by way of a user touch 108 at a location of the selectable element on the display screen 104. That is, the user touches the location of the display screen 104 at which the selectable element is displayed (or, more precisely, causes their hand or another object to intersect the detection plane 109 at that location). In areas of the display screen 104 at which there is no user touch 108 provided, the laser beams 106a, 106b, 106c projected in those directions may be reflected by one or more of the outer edges 103A-C of the display screen 104, depending on the reflective properties of the adjacent surfaces. In the examples below, the walls of the room are light coloured and the floor is mainly dark coloured, resulting in strong returns from the adjacent walls extended outwardly from edges 103 A and 103B, but limited returns from the floor extending out from edge 104B. When a user touches the display screen 104, the laser beam(s) 106d which are projected from the lidar scanner 102 in the direction of the user touch 108 are reflected by the user touch 108, creating one or more lidar returns back to the lidar sensor 102 (object returns).

[0097] In this instance, the time taken for the light to return to the lidar scanner 102 is shorter than when no user touch 108 is provided (i.e. shorter than the return time to one of the adjacent walls or the floor, as applicable). The distance of the user touch 108 is determined based on the return time. Since the angle of the beam 106d is also known, the location of the user touch 108 relative to lidar scanner 102 can be determined. Lidar inherently denotes polar coordinates (d, 0), in a frame of reference with the lidar scanner at the origin. When the position of the lidar scanner 102 on the wall is known, those coordinates can be mapped to location within the image occupying the available display area, thus providing an actionable touch input for the image. The touch input is provided to the game engine 1006, which in turn is able to match the touch input to any touch-selectable input at that location. As noted, this may involve multiple transformations of the coordinates, to provide the coordinates of the touch inputs in a way that is interpretable to the game engine 1006.

[0098] Figure 4 shows a display system 1004, such as the arrangement of image projectors 108 in Figure 1, coupled to at least one lidar scanner 102. The touch data processor 1002 is shown coupled to the game engine 1006 and lidar scanner 102. The touch data processor 1002 can, by virtue of calibration not described herein, provide touch input to the game engine 1006 in (x,y) game coordinates for mapping onto interactive game elements that are also represented in (x,y) game coordinates. In addition, a motion capture system 170 is depicted, coupled to the game engine 1006 and one or more image capture devices 172 located in the room (not shown in Figure 1). To interact with the game, a combination of touch input and motion capture is used. To control certain game elements, users move within the room, and touch inputs are used to control other game elements.

[0099] Figure 9 shows a schematic view of a computing device 1100 which may be used for example as the game server 202 or the touch server 204 for implementing the game engine 1006 and touch data processor 1002 respectively. The computing device 1100 has a controller 1122. The controller 1122 may have one or more processors 1104 and one or more memories 1110. For example, a computer code of executing the interactive user experience on the computing device 1100 may be stored in the memory 1110, along with the rule databased 800 and / or session metadata generated during the interactive session. The controller 1122 is also shown as having a graphics controller 1106 and a sound controller 1112. It should be appreciated that one or other or both of the graphics controller 1106 and sound controller 1112 may be provided by the one or more processors 1104. Other functional blocks may also be implemented by suitable circuitry or computer code executed by the one or more processor 1104.

[0100] The graphics controller 1106 is configured to provide a video output 1108 to the image provider 1004. The sound controller 1112 is configured to provide an audio output 1114. The audio output 1114 may be provided to an audio device 1120 such as a speaker and / or earphones(s). The controller 1122 has a network interface 1116 allowing the device to be able to communicate with a network such as the Internet or other communication infrastructure.

[0101] The device 1100 may have an input device 1102. The input device 1102 can take any suitable format such as one or more of a keyboard, mouse, touch screen joystick or game controller, and includes the lidar scanner 102.

[0102] The blocks of the controller 1122 are configured to communicate with each other via an interconnect such as a bus or any other suitable interconnect and / or by point to point communication.

[0103] It should be appreciated that, in some embodiments, the controller 1122 may be implemented by one or more circuits, at least in part.

[0104] It should be appreciated that embodiments may be deployed in different system architectures. For example, the interactive user experience may be implemented as an interactive experience that is stored in the memory 1110 of the computing device 1100. However, when in an online mode, at least part of the interactive experience may be provided by an interactive experience server. By way of example only, a Java game applet may be provided to the computing device 1100 and the locally running Java applet will generate, for example, the graphics, sounds, and user interaction for the interactive experience on the computing device 1100. The Java applet can have sufficient information to allow offline usage when the computing device 1100 is no longer in communication with the interactive experience server, e.g. if connectivity is lost.

[0105] In some embodiments, the game may be implemented as a computer program that is stored in a memory system, for example the interactive experience server, and which runs on the processor of the interactive experience server. Data streams or updates are supplied to the computing device 1100 to allow the computing device 1100 to render and display graphics and sounds in a browser of the computing device 1100.

[0106] Figure 6 shows an arrangement referred to herein as a “lidar touchscreen” 600. The lidar touchscreen 600 comprises a lidar scanner 102 and a surface 104 that is used as a display screen. The lidar scanner 102 is positioned on the display screen 104 such that it can scan the surface of the display screen 104. A display area 105 is depicted which, in the present example, extends all the way to at least three out of four outer edges 103A-C of the display screen 104. In the examples below, the display screen 104 is a wall, with the display area 105 extending to both horizontal edges of the wall 103 A, 103B (where the wall meets the two adjacent walls) and the lower edge 104B (where the wall meets the floor), and the display area 105 is defined by an image projector as a region in which the image projector is capable of projecting a real image on the wall. However, it will be appreciated that the system can be implemented with other forms of display screen and display system. In general, a display screen refers to any surface and a display system refers to any system capable of rendering an image (real or virtual) on that surface.

[0107] More generally, the described techniques allow touchscreen functionality to be provided for any surface 104 - whether or not any image is displayed or otherwise rendered visible on the surface - by mapping lidar object detections to coordinates on the surface 104. To this end, the lidar sensor 102 is calibrated such that its position relative to the surface 104 is known, which in turn allows a location of a detected object to be determined in (x,y) cartesian coordinates on the surface 104. In the described examples, an object detection satisfying predetermined object size constraints (minimum and maximum) triggers a touch input at the location of the detected object. A multi-stage transformation is described, in which first (x,y) coordinates of the touch input are initially determined in a normalized coordinate system of the surface 104. The normalized coordinate system is a “scale invariant” coordinate system, e.g., with (0,0) representing a top-left corner of the surface, and (1,1) representing a bottom right corner of the surface, although it will be appreciated that a normalized surface coordinate system can be constructed in other ways. Object detections are transformed to the normalized coordinate system based on measured distances from the lidar scanner 102 to the three outer edges 103A-C and a measured orientation of the lidar scanner 104 relative to the outer edges 103A-C. Whilst convenient, normalized coordinates are not required; more generally, a known position of the lidar sensor 102 is used to locate lidar detections on the surface 104 (that is, in a coordinate system of the surface 104). The first (e.g. normalized) (x,y) coordinates are then transformed to an “interaction coordinate system” to provide second (x,y) coordinates of the touch input in the interaction coordinate system. The interaction coordinate system is a coordinate system used by an interactive application, such as a game (or component thereof, such as a game engine) to represent element(s) that the user can interact with via touch input. In other words, the interaction coordinate system is a coordinate system in which an interactive environment is represented by the application component (such as pixel coordinates, or any other coordinate system used to describe the interactive environment). The first and second coordinates may be referred to as surface coordinates and game coordinates respectively (although the description applies equally to other types of interactive application). When used in conjunction with an image projector, the multi-stage transformation can compensate for image distortion caused by angular misalignment of the image projector relative to the surface 104. However, the multi-stage transformation is not required in all contexts: for example, the interactive elements could be represented directly in terms of surface coordinates, in which case the second transformation is not required because coordinates on the surface 104 are directly interpretable by the interactive application. A surface, such as a wall, equipped with touch functionality in this manner may be referred to herein as an “interactive surface”.

[0108] Lidar scanners 102 are known in the art and therefore will not be described in extensive detail herein. During use, a laser of the lidar scanner 102 produces a laser beam 106a, 106b, 106c, 106d and measures the time for the reflected light to return to a receiver of the lidar scanner 102 (return time or “time-of-flight”). The time to return is then used to calculate a distance from the lidar scanner at which the light was reflected. The lidar scanner 102 may be equipped with a single or multiple scanning lasers, hence reference numerals 106a-106b may denote a single laser beam at different time instants, or multiple laser beams. Typically, a beam(s) 106a-d in the infrared or near-infrared spectrum would be used, such that the beam(s) 106a-d are non-visible to the human eye. Figure 6B shows a highly schematic block diagram of a typical lidar scanner, shown to comprise a laser 112 and a detector 114 coupled to signal processing logic 120. The signal processing logic 120 can be implemented at the hardware level in any suitable manner, e.g. as a DSP microcontroller, FPGA or in dedicated signal processing circuitry etc. The laser 112 is a pulse laser, which emits laser pulses at regular intervals and signals the emission of each pulse to the signal processing logic 120. The detector 114 is collocated with the laser 112 for detecting any reflection of the laser pulse from an object. Any such detection is signalled to the signal processing logic 120, allowing the latter to compute the return time as the difference between the time the emission was signalled by the laser 112 and the time the detection was signalled by the detector 114. In some contexts, this calculation may be referred to as a time-to-digital (TDC) conversion or, more generally, a time-of-flight calculation. Typically, the lidar sensor 102 actually provides a return angle “bucket” (angular range, e.g. of a few arc seconds). The term “return angle” is used in a broad sense, and could mean an angle bucket depending on the configuration of the lidar sensor 102.

[0109] The laser 112 and detector 114 are coupled to a rotatable section 115 of the lidar scanner 102, which, in use, is caused to rotate by a drive mechanism 116 of the lidar scanner 102. The lidar scanner 102 records and reports the relative angle at which each laser pulse was emitted (return angle). Therefore, for each laser beam 106a, 106b, 106c, 106d emitted from the lidar scanner 102 that is reflected back to the lidar scanner 102, a lidar return provides polar coordinates (d, 0) of the point of reflection, where d is the distance of the object on which the light is reflected that can be calculated from the return time based on the known speed of light, and 0 is the angle at which the laser beam was emitted.

[0110] The lidar scanner 102 depicted in Figure 1 is a 2D lidar scanner, which means the laser(s) scan is in a 2D plane (the detection plane) for detecting physical structure that intersect the detection plane. The lidar scanner 102 is arranged so that the detection plane lies adjacent and substantially parallel to the display screen 104.

[0111] Figure 6A shows a side view of the system 600, with the detection plane denoted by reference numeral 109. The floor is denoted by reference numeral 107, and the detection plane 109 extends from the lidar sensor 102 down to the floor 109. In the present example, 1 the display area 105 is located below the lidar sensor 102, and the aim is to provide touchscreen functionality within that region, thus only returns from below the lidar sensor 102 are considered (this may, however, vary dependent on the application). The detection plane 109 lies slightly in front of the display screen 104 and any object intersecting the display plane 109 within the display area 105 may result in the detection of a touch input (the object does not necessarily have to actually touch the display screen 104, although the gap between the detection plane 109 and the display screen 104 is typically chosen to be small enough that this is not readily apparent in use). Whilst the lidar scanner 102 is shown to be mounted on the display screen 104 in Figures 1 and 1A, the lidar scanner 102 can be otherwise located to position the display plane 109 in the depicted manner (e.g. it could be mounted on the ceiling, or located in a recess in the floor with the display area 105 and detection plane 109 located above the lidar sensor 102 in that event etc.).

[0112] The lidar scanner 102 is used to detect touch input at the display screen 104, based on return time and return angle, without the use of a frame. A return from an object within the display area 105 containing an image is used to generate to a touch input, by transforming the return time and return angle to cartesian coordinates within the display area 105, using knowledge of the position of the lidar scanner 102 relative to the display screen 104. The cartesian coordinates could be expressed, e.g., in units of distance (e.g. meters, centimetres, millimetres etc.), units of image pixels, in “normalized” coordinates (see below), or in any other way relative to some known reference point in the display area 105 or, more generally, on the display screen 104 (e.g. a center point or comer point of the display area 105 or display screen 104). As described in further detail below, in the present example, multiple transformations are applied between multiple cartesian (x,y) coordinate systems. In any event, the known position of the lidar scanner 102 allows a lidar return(s) from an object intersecting the detection plane to be mapped to a location within the image, which in turn allows any touch action associated with that image location to be instigated.

[0113] The display screen 104 is substantially flat so that the laser beams 106a, 106b, 106c, 106d can provide coverage of the entire display area 105, absent any obstructing object (such as a user’s hand).

[0114] During use, an image is displayed within the display area 105 of the display screen 104. The image is a touch-controlled moving image that provides an interactive user experience, and provides user selectable (or otherwise interactive) elements which, when selected (or otherwise interacted with) by a user via touch input, result in an action being triggered. In the examples below, the display screen 104 is a wall of an “interactive” cuboid room, and the image is projected onto the wall so as to occupy the available display area. As indicated, in this set-up, the available display area 105 extends to the two vertical edges 103 A, 103B and lower horizontal edge 104B of the wall 104, and images are also projected onto at least one of the adjacent walls equipped with the same touchscreen functionality. Each such wall is said to operate as a “lidar touchscreen”. The described set up allows images to be displayed “edge-to-edge”. In general, an “edge-to-edge” set up refers to two or more non-parallel display screens configured in the manner of Figures 6 and 6A , where a first of the display screens meets a second of the display screens, and the display area 105 of each of those display screen extends all the way to the edge at which it meets the other display screen to provide an essentially continuous, touch-controllable display area extending across the nonparallel display screens.

[0115] In the examples herein, the room is made interactive through a combination of touch input and motion capture that drives an interactive application (such as a game).

[0116] It will be appreciated that, while the gameframe is described in the context of delivering an interactive game to users, the gameframe described herein may be used in other environments in which a set of computing equipment is required to provide an experience.

[0117] Various methods and devices have been described. It should be appreciated that these methods may be implemented in apparatus or devices comprising any suitable circuitry. Some embodiments may be implemented by at least one memory and at least one processor. The memory is provided by memory circuitry and the processor is provided by processor circuitry. Some embodiments may be provided by a computer program running on the at least one processor. The computer program may comprise computer implemented instructions which are stored in the at least one memory and which may be run on the at least one processor. A computer program product may be provided which comprises computer program product comprising code embodied on a computer-readable medium which is configured to be executed on a processor of the computer or user device. In some embodiments, a non-transitory computer readable storage device may be provided to store program code instructions that, when executed by at least one processor causes any of the above described methods to be performed.

[0118] The examples described herein are to be understood as illustrative examples of embodiments of the invention. Further embodiments and examples are envisaged. Any feature described in relation to any one example or embodiment may be used alone or in combination with other features. In addition, any feature described in relation to any one example or embodiment may also be used in combination with one or more features of any other of the examples or embodiments, or any combination of any other of the examples or embodiments. Furthermore, equivalents and modifications not described herein may also be employed within the scope of the invention, which is defined in the claims.

Claims

Claims1. A frame for holding a set of hardware components for executing an interactive user experience, the set of hardware components comprising a computing device, the frame comprising: an input / output, I / O, face, wherein the I / O face provides access to a plurality of ports of the set of hardware components; and a computing device access face providing access to the computing device; wherein physical connections, provided by physical electronic connectors, between a component of the set of components and an external component are provided via the I / O face only.

2. The frame of claim 1, wherein the I / O face comprises an I / O panel comprising openings for physical electronic connectors to pass through to provide the physical connections.

3. The frame of claim 1 or claim 2, wherein the frame further comprises a first shelf adjacent to the computing device access face for supporting the computing device.

4. The frame of claim 3, wherein the frame further comprises a second shelf adjacent to the I / O face for supporting at least one component of the set of hardware components.

5. The frame of claim 3 and claim 4, wherein the first shelf is located at a first height above a base of the frame and the second shelf is located at a second height about the base of the frame, wherein the second height is greater than the first height.

6. The frame of any preceding claim, wherein the frame is modular.

7. The frame of any preceding claim, wherein the frame comprises 12 L-shaped strips, the 12 L-shaped strips being affixed to form a cuboid.

8. The frame of claim 7, wherein the L-shaped strips are metal.

9. The frame of claim 7 or claim 8, wherein at least one of the L-shaped strips comprises a set of holes spaced at regular intervals.

10. The frame of claim 3 or any claim dependent thereon, wherein the shelf comprises a set of holes located so as to provide air flow to components on or above the shelf.

11. The frame of claim 6, wherein two or more parts of the frame are connected using releasable fastenings, wherein the two or more parts comprise at least one of: an I / O panel; an L-shaped strip; and a shelf.

12. The frame of any preceding claim, wherein the I / O face and computing device access face are located at opposite faces of the frame.

13. The frame of any preceding claim, wherein the computing device access face has a width of 450-550mm.

14. A system for implementing an interactive user experience comprising: the frame of any preceding claim; and a set of hardware components comprising a computing device configured to execute a game engine for implementing at least a portion of the interactive user experience.

15. The system of claim 14, wherein the set of hardware components further comprises a network switch, wherein a set of I / O ports of the network switch are exposed at the I / O face.

16. The system of claim 15, when dependent on claim 2, wherein the set of I / O ports are aligned with at least one opening of the openings of the I / O panel.

17. The system of claim 14 when dependent on claim 2, wherein at least one component of the set of hardware components is electronically connected to an external component not held in the frame via a physical connection, wherein the physical connection is provided by a physical electronic connector passing through the I / O panel.

18. The system of any of claims 14 to 17 when dependent on claim 4, wherein the set of hardware components further comprises a second computing device configured to execute adetected user input and process the user input to determine a location of the user input, wherein the second computing device is position on the second shelf.

19. The system of claim 18, wherein the second computing device comprises a set of I / O ports, wherein the second computer device is positioned with the I / O ports facing the I / O panel.

Images