Patent Grant
10188958
The present application is related to U.S. Utility application Ser. No. 13/963,638 for “Integration of a Robotic System with One or More Mobile Computing Devices”, filed on Aug. 9, 2013 and issued as U.S. Pat. No. 8,882,560 on Nov. 11, 2014, which claimed priority from U.S. Provisional Patent Application No. 61/693,687, filed on Aug. 27, 2012.
All of the above-mentioned applications are incorporated herein by reference.
The present disclosure relates to mobile agents operating in an environment including modular track segments.
Many electronic toys are controlled by a human operator. Such examples include radio and remote controlled cars and model trains that are controlled through a handheld device.
These kinds of toys have little or no ability to sense and interact intelligently and flexibly with their environment. Also, they do not generally have the ability to adjust their behavior in response to the actions of other toys. Further, many toys are physically constrained to slot or track systems and are therefore restricted in their motion.
The above-described related U.S. Patent Applications describe, in part, systems and methods for providing a toy system that includes a drivable surface having a plurality of segments of various types. Each segment includes machine-readable codes that encode locations on the segment and that encode a location of the segment on the drivable surface. A mobile agent, such as a toy vehicle or other vehicle, includes at least one motor for imparting motive force to the mobile agent, an imaging system for taking images of the machine-readable codes, a mobile agent wireless transceiver, and a microcontroller. The microcontroller controls, via the motor of the mobile agent, detailed movement of the mobile agent on the drivable surface based on images taken of the machine-readable codes of the drivable surface by the imaging system. As described, the system also includes a host device, or basestation, able to determine (via wireless communication with each mobile agent's wireless transceiver) a current location of the mobile agent on the drivable surface. The controller can store a virtual representation of the drivable surface and can determine, based on said virtual representation and the current location of each mobile agent on the drivable surface, an action to be taken by the mobile agent. The controller sends signals to the mobile agents to cause them to take action, such as to move in a coordinated manner on the drivable surface, and the mobile agents act accordingly.
According to various embodiments, a drivable surface includes a plurality of segments that can be arranged according to any desired configuration. In order for a virtual representation of the drivable surface to be constructed and maintained, one or more mobile agents are configured to automatically explore the drivable surface so as to ascertain the positions, orientations, and/or configurations of the various segments, as well as how they are connected to one another. The information collected during such exploration can be transmitted to a host device, or basestation, or other location, where a virtual representation of the drivable surface can be constructed and/or updated based on the collected information.
In at least one embodiment, exploration is performed during normal operation of the system. Thus, while mobile agents are moving around the drivable surface in the course of normal operation (such as while users are playing with the system), they may also perform exploration functions. In at least one embodiment, this may involve exploring areas to which the mobile agent travels in normal operation; in another embodiment, the mobile agent(s) may be directed to make detours during normal operation, so as to explore previously unexplored areas.
In another embodiment, the exploration is performed as a preliminary step before normal operation of the system commences. Any suitable mechanism can be used for controlling the exploration of the drivable surface. In at least one embodiment, such exploration involves fully automated operation of the mobile agent(s); in another embodiment, a user can control the mobile agent(s) and thereby direct the progress and methodology of the exploration. In yet another embodiment, a combination of such approaches can be used, wherein a user has some control over where mobile agent(s) go, but the agent(s) also move in an automated manner, at least to some extent, so as to perform exploration functions in an efficient and effective manner.
In at least one embodiment, exploration involves detecting and reading machine-readable codes on segments of the drivable surface. Such machine-readable codes can specify shape, orientation, position, configuration, and/or any other aspects of the segments. As described in the above-referenced related applications, machine-readable codes can take any suitable form, such as for example, RFIDs, optical codes, magnetic codes, and/or the like; they may be visible or invisible to the human eye. In at least one embodiment, mobile agents read codes as they travel on the segments containing the codes; in another embodiment, mobile agents are capable of reading codes for nearby segments without necessarily driving on the segments containing the codes.
In at least one embodiment, mobile agents transmit information obtained from such machine-readable codes to a host device, thus enabling the host device to construct, update, or add to a virtual representation of the overall drivable surface. In at least one embodiment, such transmission takes place via any suitable wireless communication mechanism, such as via WiFi or Bluetooth.
The techniques described herein can be implemented using any form of drivable segments. Such drivable segments can be placed and oriented so that they form a track along which the mobile agents can drive. For example, the mobile agents may be toy vehicles, and the drivable segments can be configured to collectively form a race track along which the toy vehicles can race each other.
In at least one embodiment, the described system and method are capable of detecting changes to the configuration of the drivable surface that have taken place since the virtual environment was initially constructed. For example, a user may swap out one segment for another, either while the mobile agents are driving around, or during a break in play. The mobile agents can be configured to detect such a change by reading machine-readable codes on the newly placed segments, and send the updated information to the basestation, which adjusts the virtual environment accordingly. In this way, updates can take place seamlessly without interrupting the user experience.
In at least one embodiment, as described herein, the system is implemented as an application in entertainment, such as one in which toy race cars or other vehicles move around a track. However, one skilled in the art will recognize that other embodiments are possible, and that the techniques described herein are not limited to the particular embodiments involving toy vehicles and tracks.
In various embodiments, the mobile agents can operate autonomously, or under the direction or a user (or multiple users), or in response to commands from the host device (for example, in response to a determination by the host device that some portion of the drivable surface needs further exploration, or in some combination of autonomous and user-controlled operational modes.
The accompanying drawings illustrate several embodiments and, together with the description, serve to explain various principles according to the embodiments. One skilled in the art will recognize that the particular embodiments illustrated in the drawings are merely exemplary, and are not intended to limit scope.
For illustrative purposes, the system will be described herein primarily in the context of a toy car racing game in which the mobile agents under user control are physical vehicles or accessories related to gameplay, competing on a physical track. Further details regarding the implementation of such a system, and its mechanisms for integrating virtual and physical environments, are set forth in related U.S. Utility application Ser. No. 13/707,512 for “Distributed System of Autonomously Controlled Mobile Agents”, filed on Dec. 6, 2012 and issued as U.S. Pat. No. 8,747,182 on Jun. 10, 2014, and which is incorporated herein by reference. However, one skilled in the art will recognize that the techniques described herein can be implemented in other contexts and environments, and need not be limited to vehicles on a physical track. The term “vehicle” as used herein shall therefore be taken to extend to any mobile agent that is capable of being controlled and operated in the manner described herein, while also being represented in a virtual environment as described herein.
Although the system is described herein primarily in the context of an application in entertainment, one skilled in the art will recognize that the system can be implemented in many other contexts, including contexts that are not necessarily related to entertainment.
System Architecture
Referring now to
Any of a variety of different devices can serve as host device 108; examples include smartphones, tablet computers, laptop computers, desktop computers, video game consoles, and/or any other computing device capable of supporting the control software for the system. In at least one embodiment, such a device can use any suitable operating system, including for example and without limitation: iOS or MacOS, available from Apple Inc. of Cupertino, Calif.; Android, available from Google, Inc. of Mountain View, Calif.; or Windows, available from Microsoft Corporation of Redmond, Wash. In at least one embodiment, host device 108 is an iPhone or iPad, available from Apple Inc. of Cupertino, Calif., running a suitable software application (“app”). In at least one embodiment, software for controlling host device 108 may be provided via any suitable means, such as a down-loadable application (“app”) that includes the appropriate functionality and gameplay structure to operate mobile agents 104A through 104F in physical space and to plan, coordinate and execute gameplay according to rules, user-controlled actions, and/or artificial intelligence. In at least one embodiment, host device 108 maintains the state of agents 104, and sends and receives commands to and from mobile agents 104. Host device 108 may also include a suitable user interface for facilitating user interaction with the system.
In at least one embodiment, mobile agents 104 are vehicles, and may occasionally be referred to herein as such, although they may be other objects or components.
In at least one embodiment, host device 108 is the central node for all activity and control commands sent to agents 104 and/or other components such as accessories 105, 106, whether the commands originate from algorithms running on host device 108 or are routed through host device 108 but originate from control devices 101D through 101K controlled by users 109D through 109K who are physically present or remotely located. In other embodiments, a more distributed architecture may be implemented wherein host device 108 need not be the central node for all activity and control commands.
The example shown in
In the architecture of
As shown in
In the embodiment depicted in
In at least one embodiment, artificial intelligence software runs on host device 108 and issues commands (via wireless communication mechanisms or other mechanisms) to control one or more mobile agents 104J operating on track 601. In other embodiments, software for controlling mobile agents 104J may be located elsewhere, and/or may run on mobile agents 104J themselves.
In at least one embodiment, host device 108 can simultaneously serve as a control unit for a human user 109A controlling a mobile agent 104 (in the depicted example, human user 109A uses host device 108 to control mobile agent 104A). Such functionality can be provided on host device 108 while host device 108 also serves as a conduit and interpreter for control commands incoming from other devices 101D through 101K controlling other mobile agents 104B through 104F. In another embodiment, host device 108 does not serve as a control unit for a human user 109, but rather operates as a dedicated central control unit.
In at least one embodiment, mobile agents (such as mobile agents 104B through 104F) under user control do not need to be consistent in form or function. For example, users 109 may be given the opportunity to control objects or elements other than mobile agents (such as traffic lights, railway crossings, gun turrets, drawbridges, pedestrians, and/or the like).
Player controllers 101D through 101K may communicate directly with host device 108 or they may communicate via intermediary devices. For example, in
Accessory 106 is an example of a virtual accessory, which has no physical component other than a computing device (such as a smartphone or tablet computer or the like) with an appropriate output device (such as a display screen). Virtual accessory 106 can be physically placed at a particular location in the physical game environment to render the accessory appropriately in both appearance and state. Further descriptions of such virtual accessories can be found in the above-referenced related applications. In various embodiments, accessories 105, 106 need not rely on a human user for operation but can operate under the control of artificial intelligence software running on host device 108 and/or elsewhere.
It can be appreciated by one skilled in the art that as the number of users 109 and the number of AI-controlled opponents increases, the performance demands on host device 108 likewise increases. Depending on the number of agents 104 and the capacity of host device 108, the increases in computational requirements, for example, can impact game performance. In at least one embodiment, the system is implemented in a distributed environment, wherein, for example, host device 108 has the capacity to distribute portions of its logic to any number of devices to which it is connected and which are capable of supporting execution of said logic. Examples of these include smartphones, tablet computers, laptops, game consoles, and/or the like, but can also be any suitable devices capable of providing the necessary support to run the logic assigned to it. In at least one embodiment, for example, some of the processing tasks associated with operating system 100 can be distributed to one or more controllers 101D through 101H.
It is not necessary that the distribution remain local; in at least one embodiment; logic can be distributed to, for instance, one or more remotely located servers. A modular design to the structure of host device 108 can lend itself to convenient distribution of logic, and the type of logic processes offloaded from host device 108 need not be of one particular type of function or process. In at least one embodiment, for example, the distribution of logic can be prioritized according to computational and memory demand, such that those most taxing of host device's 108 resources are the first to be allocated elsewhere.
It is not necessary that the wireless interface employed to communicate with and/or among controllers 101D through 101H be identical to that used to connect to agents 104A through 104F under the users' 109 control. For example, it is possible that host device 108 communicates with controllers 101D through 101H via Wi-Fi, while host device 108 communicates with agents 104A through 104F via Bluetooth. In such a case, host device 108 can serve as a bridge between a high-power protocol (such as Wi-Fi) and a low-power protocol (such as Bluetooth). The advantage of such an approach can be appreciated in instances in which mobile agents 104 controlled by users 109 via host device 108 or controlled directly by host device 108 (in the case of mobile agents 104J under AI control) have limited power budgets.
Another benefit afforded by the use of Bluetooth, in particular Bluetooth Low Energy (BTLE or BLE) or similarly capable wireless protocol, is that agents 104 can use the wireless protocol to communicate with similarly enabled BTLE/wireless devices. In one embodiment, for example, a user 109 wishing to assume control of a particular mobile agent 104 or active smart accessory 105 can bring the intended controller 101 (e.g., a BTLE-equipped smartphone) in proximity to the desired mobile agent 104. Leveraging BTLE's capability of determining relative distance or proximity to another BTLE-enabled device, a user 109 can bring two BTLE-equipped devices within a threshold range of distance. In at least one embodiment, this can prompt a data exchange between the smartphone (e.g., 101F) and mobile agent 104, presenting the user 109 with the option of selecting mobile agent 104 for play. The selection is subsequently relayed to host device 108 indicating the pairing between mobile agent 104 and the user's 109 smartphone 101, now designated as mobile agent's 104 control device.
In various embodiments, BTLE data exchanges among mobile agents 104 and/or similarly wirelessly-enabled agents can be used in other ways. For example, users or observers can receive information about the status of an agent 104 with respect to gameplay, overall lifetime usage, and/or historic achievements, and/or they can perform diagnostics or customize the unit.
As described above, controllers 101D through 101H can be implemented using any suitable devices. Again, less sophisticated controllers 101J, 101K can be used, such as wireless gamepads or joysticks. In instances in which a gamepad or joystick 101J, 101K is used which is not equipped with a wireless communication module supporting direct communication with host device 108, the connection to host device 108 can be achieved through a game console 101B or other intermediary, or through the use of a dongle (not shown) that plugs into an appropriate port on host device 108. Such a dongle links wirelessly to controller 101 and passes communications through the port into which it is plugged. Alternative embodiments of the dongle can include units that implement a bridge between a wireless protocol compatible with controller 101 and a wireless protocol compatible with host device 108.
Referring now also to
As described in the above-referenced related U.S. Utility Applications, drivable surface 601 is, in at least one embodiment, a physical model of one or more roads, and can include objects such as stop signs, traffic lights 105, railroad crossings, and/or the like. Mobile agents 104 may be vehicles, such as toy vehicles, capable of independent motion. Mobile agents 104 can be physically modeled after cars, trucks, ambulances, animals, or any other desired form. In at least one embodiment, each mobile agent includes one or more sensors 604 that can read information from drivable surface 601 and a communication module (not shown) that can send and receive commands and/or other information to/from host device 108, for example via wireless means.
Mobile Agents 104
Referring now to
In various embodiments, each mobile agent 104 can be fully controlled by host device 108, or through hybrid control between a user via a controller 101 and host device 108. If a user controls a mobile agent 104, he or she can choose to have the mobile agent 104 and/or host device 108 handle low level controls such as steering, staying within lanes, and/or the like, allowing the user to interact with the system at a higher level through commands such as changing speed, turning directions, honking, and/or the like.
One skilled in the art will recognize that the architecture of mobile agent 104 as described and depicted herein is merely exemplary. In at least one embodiment, mobile agent 104 includes several components, such as the following:
As shown in
In at least one embodiment, individual segments 602 of drivable surface 601 can contain machine-readable codes to allow mobile agents 104 to ascertain their position as well as to determine the placement, orientation, and configuration of segments 602. Mobile agents 104 identify their respective positions on drivable surface 601 by using sensors 604 to read such codes on segments 602 as mobile agents 104 drive over them.
Any suitable codes can be used, whether visible or invisible to the human eye. Referring now to
For illustrative purposes, codes 301 are shown herein in black on white background for readability and easier understanding. However, codes 301 can be made invisible to the human eye if desired. For example, in various embodiments, codes 301 may be visible only in the near infrared spectrum (NIR), in the IR (infrared) spectrum, or in the UV (ultra violet) spectrum, and may be completely invisible to the human eye. In at least one embodiment, this can be achieved using a combination of IR, NIR, and/or UV blocking ink and a matching IR, NIR, and/or UV light source.
For example, codes 301 can be printed with an ink or dye that absorbs NIR light. The peak absorption frequency is approximately the same wavelength as that at which the LED light source 1007 of imaging system 1005 on mobile agent 104 emits light, such as for example 790 nm. A code 301 would therefore appear black to imaging system 1005 on mobile agent 104, while an area of surface 601 that does not contain a code 301 would appear white. Referring now to
The mentioned wavelengths are of course only examples, and any CMOS sensor/LED/ink combination in the NIR/IR spectrum or even UV spectrum would work essentially the same way, and a variety of inks/dyes are available from numerous manufacturers like EPOLIN, MaxMax, and the like.
Referring now to
In general, codes 301 that are invisible to the human eye are desired so that drivable surface segments 602 can be made to have an appearance that more closely matches that of real roads. However, without changes in the hardware, the system can be implemented using visible ink (such as black), allowing users to print their own segments 602 on a standard printer without having to buy special cartridges.
Codes 301 can encode information such as the identity of segment 602 (e.g., straight, intersection, etc.), unique locations on segment 602, machine-readable codes 301A, and/or the like. In the example shown in
The codes 301 depicted in
In at least one embodiment, a type code 301 identifies a type of segment 602. Also included may be a location code 301 that encodes a unique location on that particular segment 602.
Referring now to
In at least one embodiment, some of the information encoded in codes 301 can be interpreted directly by mobile agent 104, while other information may be relayed back to host device 108. Host device 108 interprets codes 301 parsed by mobile agent 104, and has an internal (virtual) representation of drivable surface 601 and the various segments 602 therein. This allows host device 108 to identify positions of mobile agents 104 on drivable surface 601, and to consider this position and the positions of other mobile agents 104 (and other features or objects) on drivable surface 601 in its commanded behaviors of mobile agent 104. This also allows future expansion or custom-built segments 602 with only small software updates to host device 108 rather than having to also update each mobile agent 104.
Referring now to
Referring now to
Codes 301 serve several purposes. First, codes 301 allow mobile agents 104 to identify the segment 602 type that they are on during exploration, as described in more detail below. Furthermore, codes 301 allow the encoding of various parameters, such as the curvature direction of a segment 602 upon entering a new segment 602, thus enabling mobile agents 104 to better handle control-related challenges. Additionally, codes 301 provide position estimates at sufficiently fine resolutions to allow host device 108 to create high-level plans and interactive behaviors for mobile agents 104. Finally, each mobile agent 104 is able to accurately maintain a heading within a lane using a center-line code such as code 301A, and to estimate its speed and acceleration using the periods of time for which codes 301 are visible or not visible since the precise lengths of the bars and spaces between them are known.
Referring now to
In at least one embodiment, each segment 602 contains a transition bar 1301 at each entry and exit point. Transition bar 1301 is a particular machine-readable code 301 that indicates, to mobile agents 104, that they are entering or exiting a segment 602.
In at least one embodiment, some segments 602 may contain codes 301 representing obstacles or other features. Host device 108 can interpret such codes 301 as appropriate to the virtual environment. In response to a mobile agent 104 driving on such an obstacle or feature, a particular effect may be applied, for example to change the way mobile agent 104 behaves. For example, code 301 may represent an oil slick that adversely affects steering; therefore, after driving over code 301, mobile agent 104 may behave in such a manner that simulates impaired steering. Other codes 301 can provide a speed boost, or a maneuverability boost, or may act to impair movement in some manner. In at least one embodiment, such codes 301 may be pre-printed on segments 602, or they may be applied as a decal, sticker, or marking.
For some features, codes 301 are provided that can be read by mobile agent 104 regardless of current lane position. Such codes 301 can be reliably read and interpreted even when mobile agent 104 is not centered on a lane. In at least one embodiment, the following encoding patterns can be used to accomplish this goal (each containing five lines):
In at least one embodiment, multiple patterns can be used on the same segment 602, to encode additional information.
Referring now to
In at least one embodiment, when a mobile agent 104 encounters an intersection segment 602N, 602P, the mobile agent 104 can either turn or go straight. The decision may be automated, or up to user control. For example, in at least one embodiment, if mobile agent 104 is in the right hand lane when entering the intersection, it turns right; alternatively, it turns right if the user (or host device 108) commands it to.
In at least one embodiment, other types of intersections can be implemented, such as, for example, a T-intersection (not shown). In at least one embodiment, upon encountering a T-intersection, the mobile agent 104 can turn in one direction or the other (or go straight if traveling on the straight part of the T), depending on which lane it is in or depending on explicit commands from the user or from host device 108.
Another example is a Y-intersection (not shown), wherein one side veers to the right and the other veers to the left. In at least one embodiment, upon encountering a T-intersection, the mobile agent 104 can veer in one direction or the other, depending on which lane it is in or depending on explicit commands from the user or from host device 108.
Referring now to
Of course a mobile agent 104 may react in any suitable manner up reading jump code 301C. For example, game logic or commands from host device 108 may indicate that mobile agent 104 should not accelerate in response to reading jump code 301C, for example if one of the following game logic conditions is true:
The action to be taken in response to a jump code 301C can also be defined freely. For example, in response, mobile agent 104 might:
Other actions are possible.
In at least one embodiment, the system can detect statistics and elements about the jump, and inform/penalize/reward the user accordingly. For example, the system can detect any or all of the following:
Referring now to
In at least one embodiment, one side of turnaround segment 602S, 602T has a slightly different code offset than the other. This informs mobile agent 104 which half of the segment 602 the mobile agent 104 is driving on, and which direction it should turn to remain on segment 602. In other words, it tells mobile agent 104 whether to make a U-turn to the right or the left, depending on mobile agent's 104 current horizontal position (lane position). In at least one embodiment, codes 301 on turnaround segment 602S, 602T are also designed so that when parsed in reverse (on the way back out after turning), the code 301 appears different so it will not be misinterpreted to cause mobile agent 104 to turn around again.
One skilled in the art will recognize that many other types of segments 602 can be provided, in any modular fashion to operate in connection with one another and/or with the above-listed segments 602. Examples include a vertical looping segment 602 or corkscrew segment 602, containing a code 301 that tells mobile agent 104 to speed up so as to gain sufficient speed to complete the loop or corkscrew. As with the jump segment 602Q, 602R, statistics can be collected about the mobile agent's 104 performance on the loop or corkscrew. Another example is a half-pipe segment, that allows a mobile agent 104 to travel up a curved wall and back down again while traversing the segment 602, in a manner similar to a half-pipe snowboard or ski event.
Virtual Environment
As described in the above-referenced related U.S. Utility Applications, in at least one embodiment, basestation software, running on host device 108, operates a virtual version of the physical game that continuously maintains parity with events in the physical environment by updating stored information relating to mobile agent 104 position, direction, velocity, and other aspects characterizing game events. In at least one embodiment, host device 108 ensures that, at any point in time, the game states in the physical environment and the virtual environment are identical (or substantially identical), or at least that the game state in the virtual environment is a representation of the physical state to at least a sufficient degree of accuracy for gameplay purposes. Information provided by mobile agents 104 during exploration of drivable surface 601 can be used to generate and/or update the virtual environment.
For example, in at least one embodiment, if a user moves a segment 602 from one location to another, or otherwise reconfigures drivable surface 601, a mobile agent 104 that discovers the change (for example, by encountering a segment 602 in an unexpected location where previously there was a different segment 602 or no segment) transmits a signal describing the change to host device 108. Host device 108 can then update its virtual environment to reflect the change to the physical configuration of drivable surface 601. Such changes can therefore be detected by mobile agents 104 during normal game play, and not just during a separate exploration phase.
Exploration by Mobile Agents 104
It is desirable for host device 108 to know the exact structure of drivable surface 601. Since a user is free to reconfigure segments 602 at any time, there are a variety of techniques that enable host device 108 to identify the structure of drivable surface 601. In at least one embodiment, host device 108 determines the particular physical layout of segments 602 that currently make up the drivable surface 601 based on exploration of the physical layout of drivable surface 601 by one or more mobile agents 104. In performing such exploration, mobile agents 104 can act autonomously, or under the control of host device 108, according to various techniques described below. In at least one embodiment, mobile agents 104 operate in a coordinated manner to perform such exploration; in another embodiment, they operate independently. Mobile agents 104 may communicate information regarding the physical layout of the drivable surface to host device 108 using any suitable communications means, such as by wireless communication.
In other embodiments, host device 108 may obtain information about the physical layout of drivable surface 601 by other means, such as for example: a definition file accessible to host device 108; or a bus system of drivable surface 601 including a plurality of segments 602, wherein each segment 602 includes a bus segment (not shown) and a microcontroller (not shown) that communicates with host device 108 and with the microcontroller of each adjacent connected segment 602 via the bus segment.
The following description provides additional details for an embodiment wherein host device 108 discovers the layout of drivable surface 601 based on exploration by mobile agents 104. Referring now to
As mobile agent 104 drives from one segment 602 to another, it identifies each segment's 602 type, position, and orientation by reading codes 301 using its sensor(s) 604. From the information received from mobile agents 104, host device 108 can generate and/or update its virtual representation of drivable surface 601.
In at least one embodiment, one or more mobile agent(s) 104 explore drivable surface 601 by systematically traveling to previously unexplored segments 602. This can take place autonomously, or under the direction of host device 108. In at least one embodiment, mobile agent(s) 104 perform this exploration by repeatedly planning and traversing paths through the closest unexplored exit until no unexplored exits remain.
In
In
In
Referring now to
The method begins 1700. One or more mobile agents 104 travel 1701 along drivable surface segments 602 in a systematic fashion, as described in more detail below. As they travel 1701, they gather 1702 data describing the drivable surface segments 602 and transmit 1703 the gathered data to host device 108. At host device 108, a representation of an “AggregatedCodeEntryList” is generated 1704, as described in more detail below. Then, the representation of the AggregatedCodeEntryList is incrementally augmented to generate 1705 a coherent map of drivable surface 601, using additional data received from mobile agent(s) 104. In step 1706, a determination is made as to whether the generated map is consistent with AggregatedCodeEntryList. If not, the method returns to step 1702. If the map is consistent, the method ends 1799.
Each of the steps depicted in
Referring now to
Accordingly, each CodeEntry is an internal representation of a drivable surface segment 602, and each CodeEntryList is an internal representation of a section of the overall drivable surface 601 (i.e., the map).
Referring now also to
Referring now to
In at least one embodiment, the method begins by initializing 1901 an empty AggregatedCodeEntryList. A random CodeEntryList is loaded 1902 and compared 1903 with the AggregatedCodeEntryList. The comparison 1903 involves determining whether there is any overlap between the sections of the loaded CodeEntryList and the current AggregatedCodeEntryList. In at least one embodiment, comparison 1903 is performed using a metric (referred to as a MatchQuality metric) to determine a degree of similarity and reliability of the match. Any suitable metric can be used, such as for example a determination as to how many CodeEntries in the CodeEntryList match those of the current AggregatedCodeEntryList, as compared with how many CodeEntries would be a mismatch if the CodeEntryList were merged with the current AggregatedCodeEntryList.
If, based on the comparison step 1903, an overlap is found 1904 (with a sufficient MatchQuality metric), the rest of the CodeEntryList that is not already in the AggregatedCodeEntryList is merged 1905 into the AggregatedCodeEntryList. Any mismatch between the CodeEntryList and the AggregatedCodeEntryList is resolved 1906, for example, by holding multiple hypotheses for the element. In at least one embodiment, this means that at a given time, each element in the AggregatedCodeEntryList can be one of many different CodeEntries.
While merging the CodeEntryList into the AggregatedCodeEntryList, a determination is made 1907 as to whether each CodeEntry already exists in the corresponding entry in the AggregatedCodeEntryList. If so, then a counter for that CodeEntry is incremented 1908, indicating that a particular drivable surface segment 602 has been seen more than once. The counter thus indicates relative reliability of observed data.
If, in step 1904, there are no overlapping sections, the system uses 1910 the longest CodeEntryList that satisfies a confidence metric as the AggregatedEntryList. One such metric is the ratio of unknown/missing data to number of CodeEntries being below a threshold. In at least one embodiment, all other CodeEntryLists are retained for the next time step 1704 (generate representation of AggregatedEntryList) is performed.
Once the AggregatedCodeEntryList is generated 1909 (for example, if all CodeEntryLists have been processed), the method ends 1999. As described above, if in step 1706, no map is consistent with the generated AggregatedCodeEntryList, the method returns to step 1702 to gather more data.
Referring again to
Referring now to
First, a set of possible map candidates (represented as CodeEntryLists) is generated 2001, by generating all combinations of different hypotheses for all AggregatedCodeEntryLists 2302 having more than one hypothesis. In at least one embodiment, this is a combinatorial approach.
The various map candidates are evaluated 2002, based on a set of criteria. Such criteria can include, for example:
A map candidate is selected 2003 based on the evaluation. The method then ends 2099.
Referring now to
If a fork is encountered with different branches, the current loop is explored first 2101. This may mean, for example, instructing mobile agent 104 to continue driving forward until it has either hit a dead-end, or returned to its starting position. The return to starting position can be detected because the AggregatedCodeEntryList would generate a map with a closed loop.
Then, the next time a mobile agent 104 enters a drivable surface segment 602 containing a fork, it is instructed to choose 2102 a different branch than was previously traversed. This leads mobile agent 104 to a different loop, which it then explores.
The mobile agent 104 that explores the new loop in step 2102 may be, but need not be, the same mobile agent 104 that explores the current loop in step 2101. For example, two (or more) different mobile agents 104 can concurrently explore different loops concurrently, thus increasing the efficiency of overall exploration of drivable surface 601.
If any more branches are encountered 2103, the method returns to step 2102.
Once all branches have been explored, the various loops are stitched together 2104. In at least one embodiment, this is done by examining the possible branch points (Piece A in this case) and matching the CodeEntries related to the branch point. In this case, we know how CodeEntriesLists 2401A and 2401B are related to each other from the CodeEntries of Piece A and the system's understanding of the structure of piece A. In at least one embodiment, this results in a set of AggregatedCodeEntryLists that are related to one another.
Referring now to
The other mobile agent 104 (Agent 2), explores loop 2401B, and generates the following CodeEntryList 2301B based on information collected from drivable surface segments 602 along loop 2401B:
From this information, a set of AggregatedCodeEntryLists 2303E is generated, containing stitched information from the two CodeEntryLists 2301A, 2301B as shown.
In at least one embodiment, the system is able to begin operation, with mobile agents 104 traveling on drivable surface 601, even before the full map has been generated. For example, in some situations, the above-described method, including generating 1705 a coherent map, may result in a map that has missing information in one or more AggregatedCodeEntryLists 2303. A particular element of an AggregatedCodeEntryList 2303 might have no valid entries from any of the CodeEntryLists 2301, and may therefore be an unknown drivable surface segment 602.
In at least one embodiment, where appropriate, the system attempts to make intelligent guesses about such unknown elements of an AggregatedCodeEntryList 2303. For example, the system may try all possible shapes for the missing drivable surface segment 602 (such as left turn, right turn, straight, and/or the like) to see which one would best satisfy map requirements. If the number of unknown elements is below a defined threshold, and the system is sufficiently confident of the intelligent guesses, the map can be deemed complete, and main operation (gameplay) can begin. In at least one embodiment, the drivable surface segments 602 for which there is uncertainty can be marked as such; during main operation, additional information can be collected from mobile agents 104 to reinforce the guess or to make corrections when the guess is found to be inaccurate.
Referring now to
In at least one embodiment, mobile agent(s) 104 continue to collect 2201 information about surface segments 602 after normal operation (gameplay) has begun; this information may take the form of new CodeEntries that describe configuration of one or more surface segments 602. Upon collecting 2201 such CodeEntries, mobile agent 104 transmits 2202 the CodeEntries to host device 108, which records them and generates 2203 a new CodeEntryList (or more than one new CodeEntryList) from the CodeEntries. The new CodeEntryList is then merged 2204 into the AggregatedCodeEntryList, so as to update the AggregatedCodeEntryList with the newest available information. In this manner, “holes” in the map can be filled, and updates can be made to ensure that the map properly reflects any changes made to the drivable surface 601.
In at least one embodiment, the validity and trustworthiness of previously generated CodeEntryLists are configured to diminish over time; in other words, newly generated CodeEntryLists are trusted more than older ones. As a result, if the user reconfigures drivable surface 601 on-the-fly (for example by moving, removing, or adding surface segments 602), so that the system starts to generate CodeEntryLists that drastically differ from previous ones, the newer CodeEntryLists will be trusted more than the previous ones. More particularly, any hypotheses corresponding to the old configuration will stop getting new observations, while the hypotheses corresponding to the new configuration will receive more new observations and will therefore be scored more highly. As a result, the maps will reliably transition to the newer configuration, as the old configuration's likelihood score continues to drop and the newer configuration's likelihood score increases. At a certain point, the new version of the map will have a higher likelihood score than the older version, and it will be considered to be correct.
In at least one embodiment, multiple mobile agents 104 can explore simultaneously. Using multiple mobile agents 104 allows for quicker identification of the configuration of drivable surface 601. In at least one embodiment, the system takes into account any uncertainty in the respective locations of agents 104, in order to prevent collisions. For example, two intersection segments 602 in the system may have the same type, so mobile agents 104 ensure that if there is uncertainty about which segment 602 they are on, they are performing actions that under any possible scenario will not cause them to collide during exploration.
The above description and referenced drawings set forth particular details with respect to possible embodiments. Those of skill in the art will appreciate that other embodiments are possible. First, the particular naming of the components, capitalization of terms, the attributes, data structures, or any other programming or structural aspect is not mandatory or significant, and the mechanisms described herein may have different names, formats, or protocols. Further, the system may be implemented via a combination of hardware and software, or entirely in hardware elements, or entirely in software elements. Also, the particular division of functionality between the various system components described herein is merely exemplary, and not mandatory; functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead be performed by a single component.
Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one embodiment. The appearances of the phrases “in one embodiment” or “in at least one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
Some embodiments may include a system or a method for performing the above-described techniques, either singly or in any combination. Other embodiments may include a computer program product comprising a non-transitory computer-readable storage medium and computer program code, encoded on the medium, for causing a processor in a computing device or other electronic device to perform the above-described techniques.
Some portions of the above are presented in terms of algorithms and symbolic representations of operations on data bits within a memory of a computing device. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps (instructions) leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic or optical signals capable of being stored, transferred, combined, compared and otherwise manipulated. It is convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. Furthermore, it is also convenient at times, to refer to certain arrangements of steps requiring physical manipulations of physical quantities as modules or code devices, without loss of generality.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “displaying” or “determining” or the like, refer to the action and processes of a computer system, or similar electronic computing module and/or device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.
Certain aspects include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions can be embodied in software, firmware and/or hardware, and when embodied in software, can be downloaded to reside on and be operated from different platforms used by a variety of operating systems.
Some embodiments relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computing device selectively activated or reconfigured by a computer program stored in the computing device. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, DVD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, flash memory, solid state drives, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Further, the computing devices referred to herein may include a single processor or may be architectures employing multiple processor designs for increased computing capability.
The algorithms and displays presented herein are not inherently related to any particular computing device, virtualized system, or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will be apparent from the description provided herein. In addition, the system and method set forth herein are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings described herein, and any references above to specific languages are provided for illustrative purposes only.
Accordingly, various embodiments may include software, hardware, and/or other elements for controlling a computer system, computing device, or other electronic device, or any combination or plurality thereof. Such an electronic device can include, for example, a processor, an input device (such as a keyboard, mouse, touchpad, track pad, joystick, trackball, microphone, and/or any combination thereof), an output device (such as a screen, speaker, and/or the like), memory, long-term storage (such as magnetic storage, optical storage, and/or the like), and/or network connectivity, according to techniques that are well known in the art. Such an electronic device may be portable or non-portable. Examples of electronic devices that may be used include: a mobile phone, personal digital assistant, smartphone, kiosk, server computer, enterprise computing device, desktop computer, laptop computer, tablet computer, consumer electronic device, or the like. An electronic device for implementing the system or method described herein may use any operating system such as, for example and without limitation: Linux; Microsoft Windows, available from Microsoft Corporation of Redmond, Wash.; Mac OS X, available from Apple Inc. of Cupertino, Calif.; iOS, available from Apple Inc. of Cupertino, Calif.; Android, available from Google, Inc. of Mountain View, Calif.; and/or any other operating system that is adapted for use on the device.
While a limited number of embodiments has been described herein, those skilled in the art, having benefit of the above description, will appreciate that other embodiments may be devised which do not depart from the scope of the claims. In addition, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, this disclosure is intended to be illustrative, but not limiting.
The present application claims priority as a continuation-in-part of U.S. Utility application Ser. No. 14/964,438 for “Distributed System of Autonomously Controlled Mobile Agents”, filed on Dec. 9, 2015. U.S. Utility application Ser. No. 14/964,438 claimed priority as a continuation of U.S. Utility application Ser. No. 14/574,135 for “Distributed System of Autonomously Controlled Mobile Agents”, filed on Dec. 17, 2014, which claimed priority as a continuation of the following applications: U.S. Utility application Ser. No. 14/265,092 for “Distributed System of Autonomously Controlled Toy Vehicles”, filed on Apr. 29, 2014 and issued as U.S. Pat. No. 8,951,092 on Feb. 10, 2015, which claimed priority as a continuation of U.S. Utility application Ser. No. 13/707,512 for “Distributed System of Autonomously Controlled Toy Vehicles”, filed on Dec. 6, 2012 and issued as U.S. Pat. No. 8,747,182 on Jun. 10, 2014; andU.S. Utility application Ser. No. 14/265,093 for “Distributed System of Autonomously Controlled Toy Vehicles”, filed on Apr. 29, 2014 and issued as U.S. Pat. No. 8,951,093 on Feb. 10, 2015, which claimed priority as a continuation of U.S. Utility application Ser. No. 13/707,512 for “Distributed System of Autonomously Controlled Toy Vehicles”, filed on Dec. 6, 2012 and issued as U.S. Pat. No. 8,747,182 on Jun. 10, 2014. U.S. Utility application Ser. No. 13/707,512 claimed priority as a continuation of U.S. Utility application Ser. No. 12/788,605 for “Distributed System of Autonomously Controlled Toy Vehicles”, filed on May 27, 2010 and issued as U.S. Pat. No. 8,353,737 on Jan. 15, 2013, which claimed priority from U.S. Provisional Patent Application Nos. 61/181,719, filed on May 28, 2009, and 61/261,023, filed on Nov. 13, 2009.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4307791 | De Bruine | Dec 1981 | A |
| 4658928 | Seo | Apr 1987 | A |
| 5203733 | Patch et al. | Apr 1993 | A |
| 5452901 | Nakada et al. | Sep 1995 | A |
| 5697829 | Chainani et al. | Dec 1997 | A |
| 6012957 | Cyrus et al. | Jan 2000 | A |
| 6254478 | Namanny et al. | Jul 2001 | B1 |
| 6491566 | Peters et al. | Dec 2002 | B2 |
| 6780078 | Hageman | Aug 2004 | B2 |
| 6783425 | McKeefery | Aug 2004 | B2 |
| 7097532 | Rolicki et al. | Aug 2006 | B1 |
| 7753756 | McDermott et al. | Jul 2010 | B2 |
| 8013550 | Young | Sep 2011 | B1 |
| 8160994 | Ong et al. | Apr 2012 | B2 |
| 8287372 | Hong et al. | Oct 2012 | B2 |
| 20020102910 | Donahue et al. | Aug 2002 | A1 |
| 20020137427 | Peters et al. | Sep 2002 | A1 |
| 20030060287 | Nishiyama | Mar 2003 | A1 |
| 20030148698 | Koenig | Aug 2003 | A1 |
| 20030232649 | Gizis et al. | Dec 2003 | A1 |
| 20040068415 | Solomon | Apr 2004 | A1 |
| 20040134336 | Solomon | Jul 2004 | A1 |
| 20040134337 | Solomon | Jul 2004 | A1 |
| 20040162638 | Solomon | Aug 2004 | A1 |
| 20040210347 | Sawada et al. | Oct 2004 | A1 |
| 20040266506 | Herbrich et al. | Dec 2004 | A1 |
| 20050186884 | Evans | Aug 2005 | A1 |
| 20060073760 | Tremel et al. | Apr 2006 | A1 |
| 20060073761 | Weiss et al. | Apr 2006 | A1 |
| 20060223637 | Rosenberg et al. | Oct 2006 | A1 |
| 20070017984 | Mountz et al. | Jan 2007 | A1 |
| 20070021863 | Mountz et al. | Jan 2007 | A1 |
| 20070021864 | Mountz et al. | Jan 2007 | A1 |
| 20070173171 | Pal Benedek et al. | Jul 2007 | A1 |
| 20070173177 | Hirokawa et al. | Jul 2007 | A1 |
| 20070293124 | Smith et al. | Dec 2007 | A1 |
| 20080026671 | Smith et al. | Jan 2008 | A1 |
| 20080108277 | Nunez Serrano et al. | May 2008 | A1 |
| 20090004948 | Ando et al. | Jan 2009 | A1 |
| 20090076784 | Ong et al. | Mar 2009 | A1 |
| 20090111356 | Haass et al. | Apr 2009 | A1 |
| 20090138497 | Zavoli | May 2009 | A1 |
| 20090284553 | Seydoux | Nov 2009 | A1 |
| 20100093255 | Yamamoto | Apr 2010 | A1 |
| 20100099493 | Horovitz | Apr 2010 | A1 |
| 20100178966 | Seydoux | Jul 2010 | A1 |
| 20100203933 | Eyzaguirre et al. | Aug 2010 | A1 |
| 20100230198 | Frank et al. | Sep 2010 | A1 |
| 20100304640 | Sofman et al. | Dec 2010 | A1 |
| 20110047338 | Stahlin | Feb 2011 | A1 |
| 20130018575 | Birken | Jan 2013 | A1 |
| 20160089612 | Sofman et al. | Mar 2016 | A1 |
| Number | Date | Country |
|---|---|---|
| 19532540 | Mar 1997 | DE |
| 202004018425 | Apr 2006 | DE |
| 1103351 | May 2001 | EP |
| 2385238 | Aug 2003 | GB |
| 7016348 | Jan 1995 | JP |
| 2001022264 | Jan 2001 | JP |
| 2003346240 | Dec 2002 | JP |
| 2005185655 | Jul 2005 | JP |
| 100842566 | Jul 2008 | KR |
| 2008039934 | Apr 2008 | WO |
| 2009037677 | Mar 2009 | WO |
| Entry |
|---|
| Jadnckm, Jim's N Scale Train Layout, Mar. 29, 2009, https://www.youtube.com/watch?v=teDT55-O30g, p. 1. |
| Zlot, Robert et al., “Multi-Robot Exploration Controlled by a Market Economy”, 2009 IEEE, 9 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20160144288 A1 | May 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61181719 | May 2009 | US | |
| 61261023 | Nov 2009 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14574135 | Dec 2014 | US |
| Child | 14964438 | US | |
| Parent | 14265092 | Apr 2014 | US |
| Child | 14574135 | US | |
| Parent | 13707512 | Dec 2012 | US |
| Child | 14265092 | US | |
| Parent | 14265093 | Apr 2014 | US |
| Child | 14574135 | US | |
| Parent | 13707512 | Dec 2012 | US |
| Child | 14265093 | US | |
| Parent | 12788605 | May 2010 | US |
| Child | 13707512 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14964438 | Dec 2015 | US |
| Child | 15009697 | US |
