The contents of this paper are © 2012 Jeffrey Thomas Chipman

November 27, 2012


PRECIS:  The robot maintains a running table of the position of its systems. When a Trigger is acquired, the running table is temporarily frozen, and a baseline between the robot and the Trigger is generated. The Lock is a mathematical progression from the baseline. The robot performs a check down of its systems to determine which systems are out of position to achieve the Lock by comparing the baseline with the Lock. The mathematics are applied to bring the systems into compliance with the Lock. A Simulation is run. If the Simulation is successful the behavior, or Model, is executed.











(2) A Map is a grid which can represent a real space, such as a city, or an imaginary space. The grid consists of intersections of lines which are horizontal, vertical, and front to back; i.e., a three dimensional grid. The distance between intersections can be as narrow or as wide as desired, depending upon the application. Any intersection can be used for measurement within a Lock [see (6)] and a resulting Model [see (6)] because every intersection has a unique address. It is at these grid intersections that a Trigger [see (6)] is detected. Once the robot is initialized into the Map, it is properly oriented. One method to do that is to use a landmark, which could be anything stationary. The Map is a file which is run at a selectable speed, but does not have to be run at the same speed everywhere within the Map. Flags [see (5)] or Triggers [see (6)] can be set to control speed if necessary. A robot may have more than one Map in its data banks.

(3) A digital photograph with the same perspective as the Map is overlaid onto the Map. All lines within the digital photograph correspond to coordinates in the Map. Therefore, all lines become a mathematical construct or a form. For example, a Mailbox in the digital photograph when overlaid onto the Map has a precise measurement and address that distinguishes it from other objects in the environment or Map, as do any signs or legends contained by it. Robotic activity of any kind can be programmed to take place at that Mailbox [see (6)]. Digital photographs can employ Zoom features as long as the resulting perspective of the Map and the digital photograph is the same. Depending upon the use for the robot, programs are loaded into the robot’s data banks which represent the desired object in all of its geometrical facets, i.e., rendering programs that produce a 3D image. Thus a Mailbox may be recognized at a distance by making a match in a rendering program. Even at a distance the Mailbox still has a distinct shape and aspect. It can thus be rendered potentially in a rendering program. The digital photographs are taken in rapid succession. The interval between photographs is when the photograph is scanned. The photograph is scanned, and the mathematical constructs or forms are passed to the rendering programs. This method also makes it possible for the robot to easily detect motion that is too minute to be detected by the human eye simply by comparing frames when it is indicated that the frames be compared [see (6)]. The interval between photographs is very small, so that the process seems continuous. These mathematical constructs or forms are actually strings of coordinates, and the rendering program merely has to come up with a relative match [see (7)]. For example, if a construct or form contains 100 coordinates, and 60 coordinates are matched in the rendering program, that is considered a 60% match. The pattern for scanning can begin anywhere. Beginning in the center and radiating out is one pattern. Coordinates can contain information such as color. A coordinate which is a border can be part of a mathematical construct or form in more than one object.

(4) A construct or form may be excluded as an action which constitutes a Trigger [see (6)] by two methods: the first method is that the construct or form has no match in the loaded rendering programs and is wiped after failing to make a match; the second is that all constructs or forms are first fed into programs which determine if the form or construct should be released to a rendering program. For example, the sky which has no practical upper limit, and therefore cannot be delineated, or a construct or form which has dimensions indicating it has no usefulness to the robot’s mission, as in a door, which is taller than it is wide, can be excluded from further processing. However, the sky may be useful in a mission in which color is vital. The appearance of color can vary with conditions in the sky, so that the sky which is characterized by no practical upper limit nonetheless can be relevant to the robot’s performance. Forms or constructs which are contained by the sky or the door can also be excluded from further processing because they are contained, or there may be constructs or forms within such constructs or forms that are relevant, such as a gun barrel. It is not necessary to tell the robot what constructs or forms within an excluded construct or form are relevant; it simply allows that processing by loading rendering programs. Constructs and forms may be considered as a hierarchy by the robot. What constructs or forms are excluded depends upon what tasks are assigned to the robot in that specific instance or mission. Often it is the coupling of two or more constructs or forms which are important. For example, the color of a policeman’s uniform coupled with motion of his hands can be a signal to turn, whereas neither considered singly are important. Construction worker orange, or the appearance of blockage in a path, or some other indicator that the robot must turn, are also significant. The context of action is also important: the robot might make a turn in civilian setting, whereas the same coupling would be ignored in a combat situation. Also, seemingly innocuous objects may be important: this robot does not require lasers to navigate, it can use the distance between itself and a street curb to progress normally down a street.

(5) The use of constructs or forms doesn’t preclude using other technologies in conjunction with the above described processing. The robot requires a Trigger [see (6)], but that Trigger may also use other technologies. For instance, thermal imaging which is identified as emanating from an address in the Map can be taken into account in the linked Lock [see (6)]. Enemy weapons which have a heat signature, or whatever other sensory data that is now or may be developed, such as infrared technologies which provide sensory data at night, is deemed relevant and can be a gateway to a Lock and resulting Model [see (6)]. Also, because the robot operates off a Map that can be an imaginary space, a flag may take the place of a Trigger [see (6)]. The flag is pre-programmed to cause a behavior at some intersection in the Map even though there is no conventional Trigger there. In fact, there may be nothing visible there which would Trigger the robot to engage in a behavior, but it will execute the pre-determined behavior linked to the flag at that precise point anyway.

(6) The components of the robot’s world consists of these: A Trigger is a construct or form that has a match in a 3D rendering program (much like a “Computer Aided Design,” or CAD program), and may have other sensory data associated with it. The Trigger is associated by the robot’s support team with a Lock. Any construct or form that is a Trigger may be linked to a Lock. Triggers may be active or de-mobilized. When a qualifying Trigger is detected by the robot, a baseline is generated, which is a straight (though not necessarily level) line from the robot to the Trigger. Since the robot’s world is a Map, the straight line is easily mathematically quantified, and will include variables such as distance. A Lock is any three dimensional geometric progression from the baseline, a field of robotic activity which cannot be disrupted unless over-ridden by another higher prioritized Trigger. (An example of a higher prioritized Trigger is in a combat robot which needs to discern who is the enemy and who are our troops and allies. Our troops and allies would have a chip sewn into their uniforms which tell the robot that it should not target them.) The association of a Lock with a Trigger is at the discretion of the support team. For instance, a Trigger which is an AK47 barrel can be the gateway to a Lock which requires the deployment of a heavy action machine gun fired at a certain angle to the AK47. But the support team can decide the appropriate response is a grenade launcher. The advantage to this system is that the Lock can take into account the distance from the robot to the Trigger, and what may be appropriate at 20 yards might not be appropriate at 60 yards. The hardware complement of the robot is a factor. Any system in the robot is a potential element in a Model. A Sliding Lock is a Lock which has multiple tasks within a field, such as 3 rounds from a machine gun and a grenade in a progression. What is in a Sliding Lock is also at the discretion of the support team. The robot always keeps a running table of the position of its systems and is programmed with the relative mathematical requirements of its systems. When the Lock is generated, if it requires the robot’s treads to move X amount of meters or a fraction thereof, then the physical composition of the treads could require, for example, two and one half revolutions. In other words, the robot knows where it is and where it has to be to achieve the Lock, so moving the systems is a matter of performing a check-down of its systems to determine which are out of position to achieve the Lock. The mathematics is applied to those out of position systems and those systems will then be moved into position. The mathematics will vary from situation to situation. A gun turret, for example, may have to move 20 degrees for optimum deployment at one time, and 35 degrees at another time. Although the support team can control the angle of deployment of a weapon, the robot will calculate the Lock automatically based upon when it recognizes the Trigger. The Lock, or field of robotic activity, uses measurement in the Map to control what happens in the Lock. If a Lock is generated to take out an enemy combatant who is leaning out a second floor window in a house, the position of the enemy combatant and what the support team considers to be the minimum effective deployment of the robot’s weapon are the primary determinants in the Lock. Treads will be activated, gun turrets rotated, raised or lowered—all required systems which must move to achieve the Lock use mathematical instructions that will be different in all cases, but are easily calculated. In order to create the Lock, the support team populates a three-dimensional field that is represented in software, which is loaded into the robot. However, before the robot will execute its behavior (the Model), it runs a Simulation. If the Simulation does not find a problem, the robot executes the completed assembled behavior which is called a Model, because it is a Model of behavior. The robot will not crash because a higher priority Trigger can over-ride the process. The Lock or Model it was working on can be stored and executed later. Also, in cases where there is an obstacle to achieving the Lock, such as a burned out vehicle, the robot will have to deal with that first, and if the obstacle cannot be blown out of the way or otherwise removed, it’s possible for the robot to poll other robots to see if they can remove the obstacle. Thus, when there is more than one robot operational, robots can communicate with one another, and if one robot cannot appropriately deal with a process, it can pass it to another robot, which will then apply the mathematics to execute the Model, if the Model is possible for that robot. Robots can communicate with one another over any distance and communications links by transmitting Models. All robotic activity can be saved and analyzed to aid the support team in setting up missions. This robot is not remotely controlled, but it is monitored. Should the robot for some reason malfunction, the support team can take control of it to retrieve it, and in extreme cases where the robot might be taken by the enemy, it can be remotely destroyed. Because the robot’s reflexes are much faster than a human’s, situations in which the robot might be taken by the enemy would be very rare. Using this technology, and if the requisite systems are on board, this robot can mimic the behavior of any dedicated robot, as when the movement of robotic appendages are part of a Lock. The process by which the robot moves from where it is to where it has to be is extrapolation. What is happening in this process is that the robot is separating space and object, where space = Map and object = deconstruction.

(7) Finally, I want to consider Artificial Intelligence (AI) capabilities of the robot. It should be noted that a 100% match in a rendering program will not always happen. The support team may decide that a 50% or 75% match is acceptable. That means that if a rendering program can match 50% or 75% of the object, then the process may continue. However, there are objects the exact equivalent of which the robot has not previously seen. Rendering programs may be set up to deal with the various characteristics of things, like the barrel of a firearm. A Colt Sporter and an AK47 are different weapons, but both have a barrel, trigger mechanism, sight, muzzle flash, etc. Flower pots can be big or small, and vary in color, and the type of foliage can vary from flowers to ferns, but they have a common relationship to the foliage they support. A gun barrel is not three feet in diameter. Therefore, when the robot scans certain objects, it can deposit those objects into a pending action file. Objects have a finite range of appearance. If enough objects are scanned to complete a profile, such as 50% or 75% of a weapon, that profile becomes a Trigger, and the robot can search for the most appropriate Lock to deal with it based upon how similar it is to objects already assigned to a Lock, again by comparison. Once the Simulation is run, and the Model executed, the robot can write the Model into its data banks and if it sees that weapon again it can deal with it as if it was something pre-programmed. At the end of the mission, these “exceptions” can be analyzed and the routines tweaked.

This capability also has applications in gathering intelligence. Because everything the robot encounters occupies a unique range or address within the Map, and thus has a mathematical description, it can be processed by the robot in many ways.  Because everything in the robot’s world is mathematically defined, therefore the relationships between things are also mathematically defined.

To amplify what I mean by “processing” in this specific sense it that the robot can deposit the deconstructed forms into various files.  The files can have their own processing protocols and hardware, and can feed other files which may link and process the forms again if necessary.  By any practical definition, that’s real AI.  All of this front-end processing has one purpose:  to feed the Bot a Trigger which will be linked to a Lock.

In this paper, I have primarily discussed a robot as a military weapon because military applications are demanding, fast-paced, and fluid. However, the same principles can be applied to operations such as garbage collection or mass transit systems which is possible due to the modularity of the robotics control program. This robot is not a concept because its behavior at every step is supported by mathematics. The robot does not require lasers or conventional object recognition, but those technologies, if capable, could be used to enhance performance if the application warrants it. The robot’s performance is tied to the ability of its support team to give it the information to perform at a given level. Its performance range is a function of the Triggers, rendering programs, and Locks that are activated at a given time, as well as the hardware complement of the robot. No machine is perfect, no matter how much technology is on board, but the performance of these robots will steadily improve as users better understand the robot’s capabilities.

The ordinary state of a robot, whether it’s Rest, Patrol Mode, Navigation, or some other activity, is controllable.

While this robotics control program sounds like a lot of code, there are many similarities between applications.  For example, much of the code in a combat robot and a waste hauling robot is the same.

To simplify the above, the flow of the robotics control program is:


(* The process of Extrapolation is the robot’s procedure to calculate how its systems must move to execute the model.  The process of Extrapolation is described in this paper, but it is useful in understanding the behavior of the robot to give the process a name.)

I have also described the robot as if it was a single engine in order to make clear its operation.  In actuality, functions would be segmented,with engines designed for the robot’s guidance, etc.


This Bot doesn’t use object recognition.  So how does it identify things?

Instead of object, I like the term “event.”  That stresses the dynamic as opposed to stasis.  The Bot de-constructs a digital photo by “drawing” lines around discrete structures which are boundaries of the structure.  A given boundary can be part of the boundary for multiple forms.

A simple example is a rectangle.  All boundaries are unique.  I’m going to use four coordinates to describe the rectangle:  A, B, C, & D.  A rectangle will have many more boundary coordinates than that, but four are enough here to illustrate the point.  And a rectangle can contain other structures.

All coordinates in the Bot’s world are assigned a specific address.  If the data structure is a rectangle bounded by A, B, C, D, then anything beyond A, B, C, & D cannot be part of the rectangle.  The data structure is fed into a CAD program.  The Bot’s map is constructed of addresses which have a set interval between them, so we can extract a relative structure while preserving the addresses of the structure.  This is important, because the Bot may encounter more than one structure of a type.  The bottom line is that any coordinate that is outside of the boundary of the structure cannot be a part of that structure.

We want it more sophisticated than that.  We want hierarchies of “events.”  This is useful when we program a Bot to use Artificial Intelligence.

There are a number of programs currently available which reduce a photo to a line drawing.  Those programs don’t do what I’m doing with Bots, but the tech for drawing lines is here now.

Most of what a Bot encounters is irrelevant to its performance.  There will be a navigation sub-system.  Most of the structures will not have a CAD program, and therefore will be wiped at some point.  Instead of a sequential read-out of the perceptual field, the Bot could wait until the entire field is enclosed by lines with their boundary and internal components.  The CAD programs would then scan the fields.  We’re dealing with strings of coordinates, but we don’t want strings filling in any part of a non-relevant field.  We don’t want strings dripping into CAD programs.  On each iteration there will be more fields wiped as irrelevant than there are matches with CAD programs.

Since boundary coordinates are different than other coordinates, other schemes for identifying “events” are possible.  A good approach is to pre-screen “events” using ratios, resulting in a two-stage scan process.  The ratios for “events” we want to further scan are in a table.



Bots use digital photography as their perceptual reality.

Once the structure (the border) is defined as an unbroken line, those coordinates that are the unbroken line are assigned a reference number. Bear in mind that the border will be a border for more than one structure, so borders will have more than one reference number depending upon direction. Since the “Map” or grid has uniform intervals, the number of coordinates within the lines can be calculated. The horizon or sky is the upper limit of the photograph, but a photograph can be taken from any angle.

If a Bot is correctly oriented at any point within the “Map,” then it is correctly oriented for the entire “Map.”  It’s very precise.

We want to take advantage of all of the information embedded in a digital photograph. Once the data structure is limited by the border coordinates, it is simple to attach information such as color to the coordinates that form the data structure.

The resulting complete data structure is fed to the 3D CAD programs to seek a match. Although the 3D CAD program is only concerned with the mathematical structure, nonetheless we want to preserve the addresses of the coordinates because there may be more than one structure of a type, such as two or more AK47s.

This sounds like a lot of processing, but with today’s super-chips acceleration may be applied.  Once the environment is reduced to data, that data can be fed into a CAD program, which is then linked to a Trigger, which is then linked to a Lock. Any technique used with digital photography, whether current or future, can provide input for the Bot.

Bots can be used as intelligent security cameras in hot spots around the world. The information they collect is invaluable—you don’t have to worry about lying informants. The information can be transmitted to other Security Bots or Bots higher up the food chain. It’s just a matter of every Bot having a file that contains information about every other Bot, such as available Systems and Capabilities like servo response times. That allows the much smaller Security Bot to emulate and communicate with another Bot. Everything a Bot does can be read into monitoring programs at HQ, allowing Bot handlers to evaluate the performance of the Bot and make adjustments if necessary.

Unlike a Security Bot, which can be placed anywhere for gathering intelligence, Combat Bots are for Urban Warfare, where everything is moving very rapidly and there are lots of reference points.  It’s not meant as an open-field weapon.  It can be used that way, depending upon the situation, but it’s primarily for Urban Warfare.  In an open-field situation there are other alternatives.

A Security Bot in a military setting is a clandestine device.  It has information and functions that can’t be known beyond its handlers.  If the details of the program are leaked, people may die as a result.  The program will survive because the software and Comm Links can encrypted with another algorithm, but considering where Security Bots will be deployed, making them public would be a very serious breach.

I understand the concern of the public over surveillance.  Deploying Security Bots within the United States is an issue politicians have to address.  But if the Security Bot is part of an operation during a conflict, or to keep a lid on unfriendlies, that’s a different story.

This technology does not use GPS or Google Maps.  If a flying Bot like a Transport Bot is needed, Security Bots or Combat Bots will guide it in and send it back.  GPS and Google Maps are not secure.  If Bots are tracked by GPS, the system might be hacked.  Some countries have corps of hackers.  That doesn’t mean these Bots can’t use satellite communication.  GPS can still be used from a central, secure installation to gather intelligence which is fed to Bots via the Bot’s “Map.”  But Google Maps and GPS were what I didn’t want when I came up with my system.  My system is far more secure.

This system can also be used for driverless cars and doesn’t require lasers to operate.



With today’s technology, transforming smaller objects such as automobiles into giant robots is impossible.  We don’t have the required materials, to say nothing of the integrity and performance of the resulting structure.

While giant robots such as the robots in the “Transformers” films are decades away, nonetheless smaller robots can be combined within a “Map” structure to create a functional “Transformer;” i.e., a team of robots that populate a “Map” which has uniform intervals to simulate a much larger machine—even larger than the movie “Transformers.” These teams and “Maps,” and how the robots behave, can be assembled and disassembled by HQ support. The combination of these elements are employed to create an automated battlefield.  Since any one machine is not the whole machine, there is no practical defense against it.

If our theater of conflict is a foreign capital, the first task is to create a 3D “Map” with uniform intervals.  The intervals may be any mathematical distance from one another, but in practice should be based upon the precision of the robot’s systems and the necessity for accuracy.

Next, we must consider the number and capabilities of the robots required to adequately cover the area.  If, for example, the area is 2 square miles, the area should be “salted” with enough Security robots— relatively simple robots whose task it is to collect Intelligence— to completely cover the area.  There are factors in the decision of how many Security robots are needed, such as the density of buildings.  Now that we have an idea of how many Security robots will be deployed and where they will be deployed, we can look at how many Combat robots and Transportation and supply robots we need to serve the area.

It is the function of the Security robots to provide Intelligence to other robots.  All of this activity is monitored by HQ.  Since the “reflexes” and perceptual capabilities of robots are superior to humans, we want to take advantage of that and let the robots perform their functions with minimal intervention by HQ.

Let’s look at an example:

Troops are called in to deal with X number of  infiltrating insurgents.  There’s a firefight, in the course of which a troop is shot in the leg.  The troop is now immobile and needs to be transported to the rear.

In order to protect our troops from being targeted by our robots, a small microchip has been implanted in the troop’s uniform.  The chip has basic information about the troop: name, rank, serial number, specialty, military unit, anything that’s useful.  When the troop is shot, either himself or another troop activates the chip, which emits light or sound indicating a wounded troop.  That signal is picked up by a nearby Security robot but is inaudible to a human or is a light frequency that a human can’t detect.  The address of the troop is broadcasted, and after going through two other Security robots is picked up by a Combat robot, who now has the exact location of the wounded troop and the Intelligence from those Security robots.  The Combat robot calculates where its systems have to be to protect the troop and what armament is required.  Because the firefight is heavy, the Combat robot will use its grenade launcher and a heavy action machine gun.  In the case of a wounded troop, the Combat robot’s responsibility is to lay down covering fire.  A Transport robot, like a drone helicopter, is dispatched to the wounded troop, who is loaded onto a carrying rack, and the drone takes the troop to a field medical facility.

It sounds like Isaac Asimov, but it’s reality.  All of this activity takes place within a 3D “Map” where everything has an address.  The intervals in the “Map” are uniform, a mm apart or a cm apart.  Using digital photography, anything in the “Map” can be described as a mathematical quantity in a specific location—including the wounded troop. Although the Transport robot looks like it’s just flying through the air, it isn’t.  It’s navigating a “Map,” going from Point A to Point B.  It knows where it started by using a table of the position of its systems, and it knows where to go.

There are three key elements that prove this application is sound:

a.  Each robot keeps a running table of the position its systems.  When a Trigger or Flag is acquired (and not all Triggers and Flags are loaded on every Bot), the table is “frozen,” and becomes the basis for extrapolation (see below). For example, a Combat robot’s gun turret is at 90 degrees when the Trigger or Flag is acquired and its table is “frozen.”  The Lock requires the gun turret to be at 270 degrees.  Therefore, the distance from where the gun turret is to where it must be is 180 degrees.  Since the gun turret operates off a servo-mechanism, the movement of the gun turret can be Extrapolated using an appropriate value X, so that movement of the gun turret 180 degrees is so much X to bring the gun turret into compliance with the Lock.  Bear in mind that the “track” over that 180 degrees are intersections of a “Map” or grid, and the Lock can determine the speed at which the gun turret must move in order to be in compliance.  Think of this movement as “Intersections Per Second.”  Like the movement of the second hand on a watch, except that a gun turret can move clockwise or counter-clockwise.

b.  Each robot keeps a file of the capabilities and systems of all other robots.  When a Trigger or Flag is acquired, any robot can calculate the behavior of any other robot. For example, if the behavior belongs to a robot with a different capability than the robot which acquired the Trigger or Flag, the behavior might be calculated up to Simulation level by the robot which acquired the Trigger or Flag and communicated to the appropriate robot.  Thus communication between the various types of robots is simplified.  In essence, the robots can emulate one another. This allows any robot to put together routines or any part of a routine associated with any other robot on the field, and transmit that data, saving time when a few minutes or even seconds can determine the difference between a successful mission and casualties.

c.  The robot’s perceptual engine is driven by digital photography, although the robot doesn’t require the photo to be something a human can see.  The photo has all of the borders between the elements in the photo reduced to lines.  Everything contained within the lines becomes a data structure described by coordinates.  The “Map” or grid sends the coordinates for analysis by 3D Computer Aided Design (CAD) software. Coordinates contain information such as color and the total number of coordinates that comprise everything contained within the lines.  A flower pot has more coordinates than a doorknob, so even if there are 3D CAD images loaded for flower pots and doorknobs, one will not be mistaken for the other.  Only Triggers which have matches with CAD images will be processed into a Lock.  Any number of 3D CAD images may be loaded into the robot. There’s a lot of information in a digital photograph, and we want take full advantage of it.

All of the robots use the same fundamental software flow:


What we have are smaller machines which when working together form a much larger machine.  That may be more useful than a movie “Transformer.”  These robots will save lives, materiel, time, and billions of dollars.  While there are clandestine elements here, much of the topology would be applicable to civilian robotics systems like Mass Transit and Garbage Collection.


In order to communicate with a Bot, it is not necessary to have a Comm Link or Internet access.  Flags may be set within a Map which tell the Bot to do something or to evaluate its situation or position, and to respond appropriately on its own.

In some situations, limited communication might be possible.  For example, a flag might be a Morse code flasher which is activated remotely and programmed with a message.  If HQ has intel, the support team can insert the Morse code flag into the Bot’s Map, which is really just altering the file for the Bot’s Map and download the modified file to the Bot.  It’s low-tech, but could be useful.

If the Bot has an active Comm Link, it can, and on its own if required, directly communicate with a support group, HQ, or another Bot or group of Bots.  That allows a Bot to change its programming “on the fly” or with a download from HQ.  HQ can have a super-computer that is a resource for the Bot, consisting of Models or parts of Models, or any other software clusters like Triggers and Locks.  If the Bot is in combat, HQ will want to communicate with the Bot in a secure manner using encryption.

In a civilian setting, Internet access by Bots opens up unlimited possibilities.

A Bot’s software architecture may include nodes, which consist of processors, files, and protocols.  The nodes can prompt a Bot to seek more information from the Internet in response to an Encounter and the resulting information can be used by the Bot in many ways.

Obviously today’s Search Engines are not designed for Bots.  In addition to a new interface, a Bot’s searches should be scheduled, automated, ranked in priority, etc., or be communicated to another Bot or groups of Bots.  So while popular Search Engines (Bing, Google, and Yahoo) cannot survive intact, nonetheless there is tremendous opportunity for Search Engines.

It is anticipated that within a few years after introduction, Bots will be the main source of Internet traffic.  The Internet as it stands today cannot handle that traffic.  Improving the Internet for Bot traffic will require significant investment and engineering. However, it is an investment that will have a major impact on the world economy.

All of this is front-end processing is to feed the Bot the right Trigger and Lock.  In this scenario, the Triggers and Locks in and of themselves don’t have to generate a Simulation and Model, but can generate other Triggers and Locks to generate a Simulation and Model.

Bear in mind that the Bot’s interface with the world—digital photographs—are not the photos you pick up at Walgreens.  Adequate 3D digital photography and CAD/CAM software is available now.  The digital photograph, after image sensors have picked it up (macro, micro, telephoto, infrared, thermal imaging, etc., or in conjunction with other data like audio cues), but before synthesis , has a wealth of information embedded within it.  The Bot will leverage all of that information, and can, if necessary, share it appropriately.

What I want to emphasize to the reader is that the system I have developed is modular and very flexible. Software modules can interact with one another within the engine in myriad logical sequences.  As long as the


program flow is respected, activity at any one of those points can be quite complex. Respecting this program flow makes robotic interaction relatively simple.

There’s no technological reason why my Bots cannot be manufactured today.  There are people doing very dangerous work who need this technology.

July 4, 2013


This is my text from which the above article is derived:

There are four levels of Bots, all of which share elements of the same algorithms:  WarBot, BotBox, Android, and Terminator.


Advances in thermal imaging and other imaging technology can be integrated into this software at any point.


The following describes a Bot system for real-world deployment.  I’ve named the product “BotBox.”  It will use an ordinary Internet connection for consumer civilian use.  The way this technology is employed for military use is different.  The explanation that follows is for the general reader, although the principles of operation of the Bot are clearly elucidated.  The Bot only requires hardware to be operational; the software is mathematically foolproof.

A real robot is a machine which is capable of operating without human remote control and is capable of stringing together unpredictable sequences of behavior by reacting to stimuli.  This article describes the software used to drive the Bot.  Mechanical and electronic systems are the responsibility of defense contractors and hardware manufacturers, in the same way that a Windows PC isn’t completely the product of Microsoft.  I’m not involved in machinery.  The Bot is only limited by its physical design and resident systems.

The Bots will respond to Voice Rec, or a combination of Voice Rec and object recognition.

I want to start off with a simple diagram which is crude, but illustrates the principles upon which the Bot is built.  It will aid in understanding the discussion that follows.  This isn’t a pie-in-the-sky product.  It’s all logic and math.

What we have here is a WarBot in patrol mode.  It acquires a CUE, which could be a terrorist with an AK47.  The WarBot actually targets the weapon rather than the terrorist.  The WarBot can store, if necessary, a thousand CUES or more to recognize that AK47.  The BASELINE is generated, which is just a straight line between the Bot and the terrorist.  The BASELINE will become the basis for all subsequent calculations.  HQ has programmed the Bot to respond to this cue with a heavy action machine gun.  But they don’t want the machine gun discharged at this angle—it isn’t the optimum angle to discharge the weapon.  So a LOCK is generated from the BASELINE.  The LOCK is where HQ wants the weapon discharged.  The LOCK is just a mathematical progression.  It gives us the basis for measurement.    Every system on the Bot is treated as though it could be an element in a behavioral sequence.  What do we have to do to go from where the Bot is to the LOCK position?  Getting to the LOCK is just logic.  The discrepancy between where the Bot is and where it  has to be triggers the loading of the tread systems.  The machine gun has to be deployed at a certain angle, and so forth.  The LOCK itself creates discrepancies which trigger loading of systems.  We have to move the treads and maneuver so the Bot can discharge the machine gun.  The Bot calculates what it has to do, and applies the math to each required system, which is the EXTRAPOLATION.  The BOT runs a SIMULATION to verify that the behavior will in fact achieve the LOCK, and then executes the actual behavior, which I call a MODEL.  It happens very fast.  The LOCK doesn’t have to be a straight line.  You could have what I call a SLIDING LOCK, which a sequence of weapons discharge at various points within a LOCK, in which case you have a sequence of mini-locks.

Once you understand what a LOCK is, a LOCK could be any mathematical structure, and anything can happen within it.  Ordinarily, achieving the LOCK would be based upon the most direct path and fewest movements of systems, which means it will be fast.  In a military situation the Bot might have to deal with obstacles which would be a CUE in themselves before it moves on.  A Bot could store a large number of CUES, although not all of them would have to be active.  What makes the LOCK possible is that the Bot operates on MODELS.  Once a LOCK is generated, the Bot does a check-down of the discrepancies (what systems aren’t in position to achieve the LOCK), loads the systems, and applies the math.  It’s not a real complicated logical procedure, but you can see that the Bot’s behavior can be extremely complex.  The Bot simply subtracts the position in which it acquires the CUE from the designated position of deployment to derive the LOCK.


As far as the CUE is concerned, to recognize objects, depending upon the sensors, if necessary a “zoom” could verify the CUE.  All of the action will happen so fast a “zoom” procedure wouldn’t eat up crucial time.

In the discussion that follows, you might think the military version is more sophisticated than the civilian version.  Actually, that’s not true.  The military version has a “lock,” while the civilian model has an “image.”  The “lock” is an “image,” but the software allows the military to program the “lock.”  What the military wants isn’t something that thinks on its own—they want a machine that does what it’s told.  Those orders can change day to day, or hour to hour.  It has to behave predictably, because it’s a tactical weapon.  When it’s inserted into a combat zone, they want to know what it’s going to do, so that it can work with the strategy they’ve devised.  A machine that’s just a berserker is useless.  The point here is that for a War Bot, the “lock” is subjective.  It’s whatever the military wants it to be.  The “lock” is a field populated with activity.  This isn’t Artificial Intelligence, no matter how fluid the behavior of the War Bot looks.  It’s a machine under total control by its programmers.  Unlike the civilian version this software, the War Bot doesn’t learn anything.  The people who program it learn as they use it.  They don’t have to worry about the War Bot doing something unpredictable.  All of the intelligence is derived from the people who program it.

So what is a “lock” or an “image”?

It’s a projection, or future event.  In a military Bot, when the cue is acquired, a straight line or baseline is generated.  The straight line doesn’t have to be a flat line.  It could be a triangle.  Right?  That straight line is used to generate the “lock,” which can denote a sphere of activity on either side of the baseline.  This “lock” isn’t a lock like in a weapons guidance system.  It’s a mathematical sphere of activity in which many things can happen.

In the case of the “lock,” that projection is programmed the way the military wants it, using a series of menus.

What really drives behavior?  Is it money, power, sex… what?

That’s what I want to get into for the civilian Bot.  I want a different way of interacting with a computer.  The civilian Bot runs on “models” just like the military Bot, but how are those “models” activated in the civilian Bot?  They’re activated by the “image.”

An “image” isn’t just what we can see.  An “image” can be completely unconscious.  What makes a string of ants meander down a sidewalk?  Where are they going?  What is instinct?  Instinct is a projection.  The ants have an “image” of where they want to go and they go there.  They don’t know exactly where “there” is, but they know it when they see it.  When geese fly south for the winter, they’re responding to an image.  Flying south for the winter is part of being a goose.  Animals aren’t as smart as we are, but on some level, our minds work the same way.  It’s DNA.  Some animals are very protective of their offspring, and some aren’t.  Some animals leave their young to fend for themselves, with instinct as their only guide.  But perhaps even higher order mammals, like lions, don’t really teach their offspring anything:  they just activate “images;” their behavior stimulates an “image” in the cub.

So what really drives behavior?  Behavior is driven by the “image.”  And that “image” is largely unconscious.

So what we need here is an “image” language.  We need a programming language that can translate the “image” into action; that is, generate a model.  But since the “image,” like the “lock,” is a projection, all we need are the elements of the projection.  What a projection is can be quantified, we can take that projection and make something happen.  We can make the Bot achieve the projection, by assembling “models,” or asking questions to create a “model.”  The Bot isn’t an android like Commander Data; all of the intelligence comes from human interaction, but we can create a very complex machine.

So the language we’ll use de-constructs the projection into elements the Bot can use to generate the “model.”  And to ask questions if it needs more information.

When I was thinking about how I wanted my Bot to interact with the Emulator boards, I realized that the Universal System Resource Interface wasn’t exactly what was needed.  There has to be electrical connections to the cards, and we can’t have Emulator boards crashing or overloading the system.  That has to be managed.  But do we really need to isolate Emulator boards from the rest of the system, on a subsidiary bus?

Instead of isolating Emulator boards on a subsidiary bus, we’ll assign them an “image.”  That “image,” when called for, will load the manufacturer’s proprietary operating system onto an Emulator board that has its own processor.  We’ll prevent collisions by having Emulators feed instructions into a queue operated by the main processor so that the main processor still sees all Emulators as one device.  We don’t need a separate bus.  The main processor will run a check-down to verify that the Emulator can run, but in most instances it doesn’t need to communicate with the processor on the Emulator board.

As far as the Voice Rec of the system, it will use whatever is the best technology of the day.  Voice Rec is now being used in Smart Phones, and it’s getting better all the time.  Using Voice Rec for say, word processing, still has a way to go.  I’ve seen the text generated by Voice Rec, and it’s not there yet.


Your next computer could be a Bot.

When I designed the BotBox, I didn’t want a conventional operating system tied to a churn cycle (a churn cycle is the period between the introduction of a product and its eventual replacement).  I wanted something that could continually grow and improve.  So the BotBox doesn’t have an operating system.  It’s really a Bot.  When the consumer buys a BotBox, the Bot will already have been taught the routines equivalent to a conventional operating system.  For instance, the consumer won’t have to teach the Bot how to bring files into active memory, or how they appear visually to the user—the Bot has already “learned” that at the factory.  The Bot will have the BIOS of the processor it’s running on.  Because of its tremendous flexibility, there will be a plethora of options, and the user can program the Bot to fit their needs.

The Bot uses a principle called Extrapolation, which mimics low-order human thought.  I became interested in how this technology could be applied in a military situation, to have a real Bot capable of independent action—without a human operating it.  The War Bot is designed for urban warfare, to give troops a tactical advantage on the ground.  It can go on patrol, soften up an enemy position, or flush the enemy into a position where our troops have the advantage, without exposing humans to danger.  It’s a strategic tool for the USA and its allies.

What would a simple War Bot mission look like?  The War Bot is programmed by HQ.  HQ also monitors the performance of the War Bot, but doesn’t operate it, because the War Bot’s reflexes are much faster than a human’s.  The War Bot can carry a full complement of armament.  The War Bot is brought to the insertion point on a flatbed vehicle.  HQ activates the War Bot.  It performs whatever mission HQ programmed it to do.  In the process, the War Bot sends video and audio back to HQ and to the ground troops, who can monitor its progress via a Tablet PC.  If there’s more than one War Bot operating, the Tablet PC will have multiple panes.  Both HQ and ground forces have a very good idea of what’s happening.  At some point, HQ tells the ground troops to “move out,” and they execute their orders.  Hopefully all of the ground troops make it back to camp in one piece.  HQ can evaluate the mission and decide if adjustments are called for.

In a military situation, the Bot uses a process called Extrapolation By Context.  That means the Bot’s behavior is triggered by cues that are derived from the environment, rather than a spoken or typed command.  The Bot can be programmed to recognize as many cues as are required, but not all of them have to be active.  The triggers assigned to cues are also programmable.

To accomplish this, Military Bots will have sensors and guidance systems (the sensors and guidance systems are the province of defense contractors).  As a military Bot moves through an urban neighborhood that’s held by the enemy, if it spots something it’s been programmed to recognize (a cue), it’s software triggers a routine appropriate to that cue, which will calculate a “lock” position; that is, the position at which it’s been programmed to deploy the weapon or complete a task.  If the weapon is a grenade launcher or small rocket, the routine will generate a “single lock.”  If it’s a machine gun programmed for a spray pattern, then the routine generates a “sliding lock.”  A “sliding lock” is a “lock” which has a pre-programmed progression.

How is the “lock” achieved?  By using a process similar to generating a geometric progression from where the Bot is when it recognizes the cue, which is derived from a running table of its processes, to where it should be as determined by its programming.  The table isn’t absolute positions, it’s just values which can be used in computation.  If it’s tread rotation, you could reset the value to Zero.  If it’s a grenade launcher on an appendage, it’s a matter of degrees and aspect; aspect being up or down position of the grenade launcher.

It’s math, and it’s all programmable.  A grenade can be launched from various angles to take out the enemy, so it’s up to the military to program what they want the “lock” to be.  The “lock” will be what the military considers the optimum deployment of the weapon, and of course that depends on what armament the Bot is equipped with.  Since the Bot maintains a running table of the position of all of its systems, whether motive, like wheels or tread, or offensive, like weapons systems, achieving the “lock” is a matter of mathematics.

For instance, if the cue is acquired at 50 degrees, but HQ has set the lock at 60 degrees, the Bot has to move into a position of 60 degrees to deploy the weapon.  If HQ has programmed a “sliding lock” to cover 60 to 90 degrees, then at the designated points the Bot deploys the weapon or weapons in sequence, which could be machine gun fire at 60 to 70 degrees, a rocket propelled grenade at 75 degrees, and more machine gun fire from 80 to 90 degrees, etc.  If the cue is acquired at any point within the programmed lock, then the Bot will deploy the weapon or weapons immediately by simply moving the weapon into position rather than physically moving itself.  In actual practice, the permissible lock, depending upon where the Bot is, could begin at, for instance, 60 to 110 degrees.

The Bot uses a procedure I call Extrapolation to generate the behavior necessary to achieve the “lock.”  Whether the Bot is military or civilian, it operates on “models.”  A “model” is a sequence of behavior that the Bot executes to accomplish something.  Once the “lock” has been generated, the Bot constructs the sequence of movements necessary to fulfill its mission.  So what has to happen?  Obviously, to move from one position to another, the wheels or tread have to be activated.  The weapon has to target the enemy.  Since the Bot knows where it is from its running table, and knows where it has to go by the “lock,” getting to the “lock” is just a matter of applying accurate math to the sequence of behavior.  Right?  That’s the Extrapolation.  The Bot will run a simulation to confirm the accuracy of its calculations, and then execute the “model,” which is the completed behavior, consisting of the sequence of events to which has been applied the specific mathematical calculations to achieve this objective.  A Bot can execute one model after another indefinitely.

This is the algorithm:


But is that possible?  Absolutely.  All systems on the Bot can be measured with mathematics.  Extrapolation is simply so many revolutions of a wheel and the rotation of a gun turret.  Lasers emanating from the Bot can calculate its distance from objects.  A practical War Bot will actually be running multiple models at the same time, so don’t think of it as a strictly linear process.  If the Bot recognizes another cue while it’s engaged in constructing a “model,” depending on the complexity of the machine, there’s no reason it couldn’t handle two triggers at the same time, put one trigger in cue, or pass a trigger to another Bot via a communications link.  So a “model” is just a sequence of available systems activations put together with the correct math applied.  That’s a real Bot—it doesn’t require a human to control it.  Available systems are movement via tread, various weapons systems, etc.  All of it is machinery controlled by motors which are activated by the programming of the Bot, and which move in accordance with mathematical precision applied to the specific situation.  Each system on the Bot can be part of a sequence of behavior.  For instance, if you want the Bot to move to the left, the left tread will be stationary or slower than the right tread.  Each tread is a system which can become part of a “model.”  The treads move or don’t move according to the requirements of the “lock.”

A trigger isn’t just recognition  of an object—it’s also the context in which the object appears.  It’s not appropriate to fire a rocket at a terrorist standing 20 yards away.  Once the weapon is discharged, the Bot goes into Patrol Mode.  It’s an extremely flexible system. Triggers don’t have to be sent into weapons deployment routines.  It could be removal of an object in the way.  It could be to take out a communications satellite dish.

The better the sensors, guidance system, and cue detection, the more effective the Bot.  If you can generate an accurate image of where the Bot has to be, which is the “lock,” this Bot will perform as claimed.  Is it a real robot?  If your definition is a robot like Bender in the animated series “Futurama,” the answer is No.  If your definition of a robot is a machine which can operate independently of human control and execute complex sequences of behavior on its own, then it is a real robot.  It’s all math and logic.  Conceivably you could program a machine to act like Bender, but it’s still a machine.  It has no consciousness, it doesn’t reflect on the meaning of life, it just does what it’s told.  The effectiveness of this Bot depends upon its ability to see the cue that triggers the software routine.  If the machine can accurately pick up the cue, everything else is merely mathematics.

Even if the Bot found itself already positioned for parts of the sequence, in many cases some movement of the weapons system would be required.

Because Artificial Intelligence at this point is crude, to prevent the Bot from attacking our troops, our troops can have chips sewn into their uniforms that identify them.  The Bot can be shut down or recalled at any time.  Software options (including the “lock”) can be changed remotely via a communications link to HQ if conditions require it.  Cue recognitions can be added or deleted.  A Bot can be programmed to recognize as many cues as necessary, and associated triggers can be changed.  That’s the software.

The military application is interesting because it’s so complex.  If a Bot can serve a military purpose, it can perform well in other environments, such as public service Bots like street sweepers and garbage trucks.

It’s patterned on low-order human thinking.  For instance, I want to go to Best Buy to purchase a CD.  I already know how to drive a car and I understand traffic signals.  The piece of information I’m missing is the location of Best Buy.  So I call and get directions.  I then drive to Best Buy.  That’s Extrapolation.  I’ve added something to a routine I already know.  Along the way I’ll encounter Stop Signs.  That’s a cue.  When I see a Stop Sign, I put on the brakes, slow down, and come to a stop.  The Stop Sign triggered that behavior, and the behavior is the executed “model.”  It’s thinking so basic that we never look at it.

The goal here is to save lives.  The new kinds of conflicts we’re involved in are increasingly urban, and that’s what this Bot is designed to deal with.  The War Bot would be a devastating weapon against drug cartels in certain countries—defeating those cartels would have huge benefits.

We want to get in and get out as fast as possible with as few casualties as possible.  Like the “Shock And Awe” bombing campaign that started the war in Iraq, we want to frighten the enemy and demoralize them in to believing that they can’t win.  Hopefully, the result is a political solution, which is what everyone wants.


I want the BotBox (the civilian commercial variant of the Bot) to be like something out of the first (original version) Star Wars Episode IV movie.  Something that would have been in Luke Skywalker’s home, what he would have used.  Star Wars was all about distributed processing, that kind of practical tech.  The limitless possibilities of technology.  That Universe was futuristic, but there was also something familiar about it.  Viewers didn’t watch the movie, they were in the movie.

Windows is a tremendous technical achievement, involving a huge amount of code.  But it’s still a personal computer operating system, and that kind of technology is rapidly changing form factors.  Companies that manufacture PCs must be concerned that the kind of machines they build are nearing the end of consumer acceptance.

The answer is to move into a new technology, a technology that can’t be implemented in a small form factor, that requires a constantly expanding technology.  One of the things I’ve come up with is the Emulator board, which utlilizes an electrical connection and software system together known as a Universal System Resource Interface (USRI).  The USRI allows the deployment of products as diverse as videogames and home and office automation systems by letting manufacturers load their proprietary operating systems and then use the electronic components of the BotBox to replicate their product.  These products can be downloaded off the Internet or installed via optical disk or flash memory—a dedicated network isn’t necessary to create a new industrial platform of digital emulation.  The main processor sees the USRI as one application, so it doesn’t have to communicate directly with processors running on Emulator boards.  It’s not necessary to have a secondary bus for the USRI.  Commands issued by individual Emulators, whether sharing a board or occupying an entire board, will be clocked and fed into a queue operated by the main processor, which will translate and execute the commands.  It manages the I/O processes for the Emulator boards.  The Emulator boards are the key to making affordable, sophisticated home and office automation a reality.

A BotBox isn’t a personal computer and doesn’t compete with Tablet PCs or Smart Phones, although it can communicate with those devices and make use of their capabilities.  The architecture of the BotBox will allow easy installation and upgrade of cards, which consumers will use to make the BotBox something that works for their specific needs.  The goal is constant development of new cards.

The BotBox isn’t a conventional Graphical User Interface mated to an underlying operating system.  When the user interacts with the Bot, they are communicating directly with the machine itself.  When the consumer gets their BotBox, the initial setup will already have been performed by the manufacturer—pre-loaded “models” which appear to the user like a conventional operating system.  Much like “Apps” for Smart Phones and Tablet PCs, there will be “models” available for consumers to download or read into the machine.  There are a lot of advantages to doing it this way.  As the tech matures, the core of the Bot can be replaced—it’s backward compatible.  So our Bot will always be cutting edge.

Although a BotBox can be taught to recognize cues that trigger behavior, and will be by some users, the more ordinary way a user will interact with the Bot is by teaching it what you want it to do with voice commands or some other input.  I call this Extrapolation By Command.

The data flow is this:


1.  Enter problem.  This can be through text entry or Voice Rec.  Create an “image” of the problem.  The “image” is the translation of the user’s words into something the Bot can understand, what the user wants, built from data structures the computer uses, action/object elements.  The “image” generates the “lock.”.

2.  Scan data files.  Has it seen this “model,” or any part of it, before?

3.  Extrapolate.  What if any, additional information is needed?   The gap between what the Bot knows and what it needs to know is the extrapolation, so the extrapolation is the logical sequence of actions necessary to accomplish the task.  The gap may have to be filled in with additional information, or it may have all it needs by putting together action functions derived from other “models.”  The action functions that comprise the “model” can be generated into other “models.”  Every time a new “model” is actualized, the parts that comprise it are stored to be referenced for further use.  Even if the “model” isn’t actualized, if there are any parts that are successful, those will be stored for further use.

If the Bot has all it needs, it jumps to Step 6. “Run Simulation.”

4.  Question the user.  Get whatever additional information it needs.

5.  Extrapolate.

6.  Run simulation.  This is in the background.  The user doesn’t see it.

7.  If simulation matches problem, notify user.  User says:  “Execute.”

8.  If simulation fails, analyze what parts of simulation that contain useful data structures should be retained and written into data files.  Return to Step 3.

Bear in mind that an average user isn’t going to have to teach the Bot very much.  That’s because “models” can be pre-built and loaded into the system via an optical disk or flash drive or over the network.  Within a very short  period of time, this system will have a lot of “models” to work with.  If you look at the proliferation of “apps” in the cell phone market, you’ll see what I mean.  Most of the time a user will just find the “model” somewhere and load it into the Bot.  This is a system of tremendous flexibility.  Ordinarily, after the Bot understands the “model,” it will scan its files for the elements of the “model,” create the extrapolation, and then execute the “model.”

One of the goals for the BotBox is to get away from the Windows desktop, and allow independent development of Graphical User Interfaces (GUI) tailored to the need of various user demographics.

The Bot can’t exceed its ability to deploy a solution, and if that happens, it will notify the user, and give the user options.  As the system evolves, users will increasingly take advantage of the Bot’s capabilities.

It can be as simple or as complex as you want it to be, but higher order functions are best left to gateway programs that can feed this robot.  For instance, if the robot is stuck in an extrapolation, it can refer the problem to a higher order program that will attempt to solve the problem on its own by using context (to be stuck in an extrapolation doesn’t mean the robot is permanently stuck—when another trigger presents itself, it will move on to the next model and write the defective extrapolation into a file for later analysis).  “Context” is the environment broken down into data structures, and that includes movement.  The robot would refer to its over-arching “meta.”  A “meta” is a purpose expressed as action.  It would scan its data banks for similar models, substitute elements derived from the context, run simulations, and assemble a model that best serves the “meta.”

Of course, this explanation is simplified, but nonetheless contain the operational specifics of the Bot.

The BotBox will use today’s Internet and can launch any browser from the Bot.  As the Internet as a medium improves, the BotBox can handle it.

Most of the time, we aren’t teaching the Bot a complete sequence of behavior; rather, it’s programmed to put together elements of sequences of behaviors that already exist in its data banks, and apply those sequences to execute “models” that accomplish something.  While theoretically a user could program the Bot to do anything feasible, most users will simply load “models” that have already been created.  For the civilian user, a “model” is like a macro, but it is stored in a data structures so that any part of the “model” can contribute to the creation of another “model”  during the process of Extrapolation.  The ultimate smallest segment of a “model” could correspond to instructions in machine code, or as elements of a programming language, but most users won’t use the Bot at that level.

The civilian Bot is designed for the home and office where it will become the center of the electrical grid.  The upgrade path is limitless as new cards and Emulator boards hit the market.  Affordable, sophisticated automation will be one of its primary applications.

An Android is not a more evolved Bot.  It uses the same software ancestor, but is a different machine.  The key to the Android is spatial recognition.  An Android must use the shape of space.  The shape of space is a cue, which can be used to generate a “lock.”  The shape of space is that which is not an object.  Object cues within space guide the Android on its mission.

The algorithm for an Android, which is more complex than a Bot, is this:


The Android is a more complex machine because we expect more of it.  It doesn’t necessarily look humanoid, like the Commander Data unit in “Star Trek: The Next Generation,” but it will perform tasks that humans can perform, but which are too dangerous for humans.  Mining disasters, firefighting, certain military missions, search and rescue are examples.  Even though the Android uses space, while a Bot is object oriented, an Android is still a machine.  It has to be programmed to recognize cues, whether they are spatial or object cues.  We can use cues more creatively with an Android, and build a machine which acts in humanoid fashion.

So for an Android there is space, and then, for instance there is a sidewalk, which is an object.  But we’ll have two ways of viewing space—we’ll have a rolling construct of space, in which there are programmable addresses, and we”ll have a “lock,” and objects.  The rolling construct of space is just to get the Android to where we want it to go, and the “lock” and object isn’t difficult.  GPS isn’t going to get it done, because this machine is a precision instrument.

Things move through space, but space can also be propulsion.  The “Rolling Construct of Space” isn’t something the Android looks at, it’s what makes it move.  For an Android, it’s a movie in its “brain.”  Once you do that, then the same tech as used in a Bot can be applied, albeit with more complexity, to an Android, because everything is measurable, and therefore, can be controlled.  There’s an old Chinese saying:  “The river does not flow, the bridge flows.”  We’re going to play a movie, but we’re going to let the Android be the actor in the movie, and how it does that depends upon conditions.  Separating space from object allows the Android to pre-play space.

Is that possible?  Yes, you could put the entire planet into a data bank.  It doesn’t have to be resident in the Android, just available over a com link, downloaded into active memory.  You set a task or mission for the Android, but how it gets there can vary depending upon conditions.

One micro-application for an Android is fire fighting.  It’s very dangerous—every year fire fighters are killed or seriously injured.  If there was a spacial “map” of a building, whether it’s a high rise or a home, you could send in an Android.  If it had low velocity ordnance, it could create an escape route, or vent smoke, and distribute flame resistant blankets, etc., using cues in the environment.  The Android can send video and audio back to the fire fighters.  For instance:  the fire fighters download a spatial “map” of a home that’s on fire.  When they run the “map,” the Android enters the zone.  If necessary, the fire fighters can direct the Android to a specific room by touching a plan of the home on a Tablet PC, while the Android reacts to cues in the environment.  The Tablet PC is referencing an address in the home.

When the Android is inserted into a fire, it goes into a “stall,” takes measurements, and initializes the “map;” that is, orients itself to where it is within the “map,” and then the “map” is run, and as it’s run, it’s moving the Android.  The “map” isn’t a pre-determined route, it’s the construct of reality for the Android, its world, the shape of space for that world.  The cues it acquires may be a shout for help, but there’s no direct line of sight to that person.  This is why an Android is not a Bot.  In fact, for an Android, there doesn’t even have to be a cue where activity takes place.

But you could have a “map” which covers ten city blocks, set the task for the end of the “map,” run the “map,” and the Android should perform.  The Android will react to “cues” within the “map,” such as traffic lights, but it’s still something that you programmed.   As the “map” rolls, it’s sending data which causes the Android to move—the “map” and the Android’s movements are synced.  The Android’s systems are treated like the Bot’s.  Running a “map” is sort of like running a video or audio file on your PC.  You can store “maps” in files.  When the Android acquires a “cue,” the “map” is interrupted, and the same sort of software the Bot uses is activated.

The Android will have some kind of locater tech to initialize the “map” and bring it back into the “map” if it is somehow knocked out of the “map,” but that’s for the engineers.  It’s not my province.

If you think about it, the world for an Android is an abstraction.  So you can create a “map.”  It doesn’t really have to be, well… real.  The Android will move around in it.  So if an Android is working in space, like on a space station, it doesn’t have to deal with the infinity of space, it just works with the reality or “map” you give it.  A “map” is a set of reference points, not longitude or latitude.  A construct of space which can be represented in 2D or 3D.  As long as the Android is oriented in the “map,” it will move within it whether it represents a real space or not.

Although Androids seem futuristic, this Android could be built now.  It isn’t a simple machine, but it’s not beyond our engineering capability.

Feeding the Android’s behavior into a “meta” program that analyzes its behavior might help improve Android performance.  I see no point in trying to give a machine “consciousness.”  Whether it can reflect upon its own behavior and modify it is another matter.  But with both Bots and Androids, some processing chores can be handled at HQ using state-of-the-art computers if necessary.  We may as well use com links to our advantage.

Space is something that we can quantify, so there’s no mathematical reason why an Android cannot be built, as long as we begin with the use of space, and progress from there.  We treat space and objects separately in terms of programming to create a machine that functions in very complex ways.

The quest for Artificial Intelligence (AI) is based upon our bias to anthropomorphize machines; that is, make them function like humans.  Human intelligence is many things:  daydreaming, the capacity to think beyond the present situation, imagination, interpretation, and intuition.  This sort of mentation is beyond the capability of machines.  The spark of whatever life is isn’t something we can put into a bottle.

When we perceive reality, what we see and hear are lines of demarcation, that is, the outlines that separate things and sounds.  So in order to simulate intelligence in a machine, the first thing to do is to give it the ability to break down what it sees and hears into discrete components.  Colors, shapes, sounds, everything, and isolate all of it into data structures.  That’s DECONSTRUCTION.  Because much of our thinking is a stream of consciousness, the next task is to give our machine the capacity for ASSOCIATION; that is, what those data structures mean.  What they mean is what we tell the machine they mean, that when these elements are found together, they mean THIS.  The success of this method relies on our skill in isolating perception into data structures.  When a human sees a cop directing traffic, they see his uniform, which they associate with cops, they see his hand signals which they associate with movement, and they see the direction of his hands, which they associate with going in that direction.  That’s pretty basic thinking.  Maybe we can use this technique to help a machine “interpret” its environment and take the correct action.  And the astute reader will understand that when a machine can break down “reality,” it can also create its own data structures.

So the algorithm is:


When the machine sees the color of the cop’s uniform, it sends an interrupt which means “do this.”  The various hand signals are in the machine’s data banks, so if the cop signals “stop,” that’s what the machine does, or it goes in the direction the cop wants it to go.

By CLUSTER I am not referring to a relational database, but rather to the fact that there are things that are demarcated which of themselves have no meaning.  By reducing the machine’s world to something we can work with, it’s not necessary for the machine to render a complete picture, just what to which we can attach meaning.  For instance, if a cop is directing traffic, it doesn’t matter what his purpose is:  the traffic lights may be out or there is an accident.  The machine only needs to follow the cop’s instructions.  All we need here is the meaning that the cop has “authority” and the direction in which his hands are telling the machine to go.  We don’t need to deal with the sleeves which connect the cop’s hands.  “Authority” and “direction” are the CLUSTER.  “Authority” is what gives meaning to the “direction.”  What the machine has to deal with is a world which is dynamic, but birds flying overhead isn’t something either we or a machine have to factor into what we do.  It isn’t necessary to work with everything, but we do need to break everything down before we can assign values.  The values vary:  some indicate connectedness, and others do not.  The world consists of lines, and things that are within lines, and things that emanate from within lines.

What the machine is doing is scanning the deconstructed reality for things that have associations or meaning, which is what humans do without thinking about it.  If a cop is leaning against his squad car on the side of the road while munching on a burger, that has no meaning and will be ignored.

The still shots are overlaid on the “map” or grid to produce a deconstructed reality that’s reduced to data fields.  The Bot can be initialized using a landmark (which could be anything).

Let’s look at the Bot’s file system. When the the data field the Bot has picked up has cleared the “Ignore List,” it’s written into a “Temporary Action” file with its original coordinates.  But because we have a map or grid which is a mathematical construct, the Bot knows the relative dimensions of the object.  THAT is what is fed into the rendering stage of the software.  If there’s a hit, the original object with the actual coordinates is sent from the “Temporary Action” file to the “Lock” software and the “Temporary Action” file can be cleared—OR, if the Bot is in the midst of generating the “Lock,” that can be stored or passed electronically with the actual coordinates to another Bot.  Don’t make the mistake of doing everything the same way—take advantage of the math.  Don’t make it harder than it really is.  Think of ways to give this Bot what it wants—input it can work with.

This may be as close to AI as a machine can get.  It’s a higher order of machine intelligence, but the real intelligence comes from the humans who program it.  It’s a start in a new direction of quasi-AI.  What interests me is that machines can have huge collections of CUES and TRIGGERS and we should use that.  Higher orders of machine intelligence than this will not be modeled on human mentation.  ASSOCIATION isn’t higher-order thinking.  Like EXTRAPOLATION it’s so basic we are not conscious of it.  We should not put off solving problems that are solvable while waiting for AI that’s only a concept in a screenplay.  When you deconstruct “reality,” a problem that looks as though it’s many years from solution could be solved with ASSOCIATION and PRIORITIZATION.  We build on that, because the building blocks of these machines are basically the same—we don’t have to solve the same problems over and over again.

Then we give our Social Machine the ability to make COMPARISONS.  How do we do that?  By identifying the characteristics of a class of things, so that this machine can generate its own meanings from the environment.  In addition to telling the machine what things means, we can create files which are characteristics of classes of things that help the machine to recognize things which we have not explicitly programmed it to recognize.  This is possible due to the technique of DECONSTRUCTION.  Once there are COMPARISIONS, then those things become part of the programming of this machine, even though the machine generated this programming itself.

For instance, when we look at the class of flower pots, the main function is to grow flowers, even though the pots in which flowers grow can be of many sizes and shapes.  A weapon which is fired may not be in the programming, but it is of a class of weapons.  So once the weapon is fired, its DECONSTRUCTION and meaning is written into a file to join the rest of the class of weapons.  The flower and the pot are a CLUSTER, and the weapon and its discharge are a CLUSTER.  Most of what comprises the machine’s environment is irrelevant to its performance and will be valued accordingly.

In the beginning, the technology may not exist to accurately put a sound together with a weapon, but there are other ways to identify weapons (such as muzzle flash), and as technology improves, the performance of the machine will improve.

You think it’s impossible, but it isn’t, when you use the appropriate data structures.  I’ll use the term “rendering,” not in the sense of making a data structure visible, but rather a “representation” of it in the machine’s data banks which makes the object in its various facets understandable by the machine.  If we saw it on a screen, we would see the machine size and angle the object, but it won’t be on a screen.  I’m not interested in the specific program, which is of a sort of program used in engineering and drafting, but to use this type of program in this application, to analyze data this way.

To give an idea of the software required to DECONSTRUCT the environment, take a look at programs which translate a photograph into a line drawing.  In the case of this machine, the lines and what they enclose are data structures.  It is not necessary to have a seamless “film” of the environment, just super-hi-speed shots in sync with the algorithm.  In any event, it will look as though it’s smooth.  Shots will be held in a buffer so that movement can be accurately determined.

Some people would call this a Terminator class machine, after the popular movie series—and they wouldn’t be far wrong.  Once we DECONSTRUCT the environment, a lot of modes of robotic intelligence become possible.


Here’s how Artificial Intelligence works with my Terminator class Bot:

The Bot takes a series of still “shots”, synced with a scan module.  Those “shots” are Deconstructed; that is, the lines around the various things in the environment are considered data structures.  The scan module scans those data structures for those which have an association or meaning.  Most of the data structures are irrelevant to the Bot.

If the Bot is able to identify something which it has not specifically seen before, like a new design for a grenade launcher, by comparing it with a class of things that define grenade launchers, it will store that object and search for a LOCK which has been assigned to a grenade launcher.  When it finds that LOCK, the new grenade launcher, which is the CUE, is linked to that LOCK and filed in storage.  The next time the Bot sees that grenade launcher, it has learned what to do.

This only works because of the underlying MODEL algorithm.

You can use this procedure with Bots in any environment.

How does Deconstruction work?  This is a picture of a can of worms.

This is the same picture using a program called FotoSketcher.  I’m showing it in B&W to maximize the contrast.

The lines which enclose a worm are data structures—the Deconstruction.  The data structures are scanned.  The Bot doesn’t have to scan everything in the environment. That’s because the programmers have given a neutral or ignore rating to most things the Bot “sees,” so we’re not going to waste time by scanning them—but what is ignored is up to the programmers.  This B&W drawing would be but one in a series of “shots.”

Everything enclosed by lines are data structures, or fields.  Field comparisons are important, and will be relatively simple because all fields have a mathematical representation.  Every subsequent data structure can be compared to its previous “image.”

Maybe the Bot’s job is to gather worms for a fishing trip.  The can itself is ignored.  So how does the Bot identify a worm?  The color and shape of the worm isn’t enough.  Yeah, it will trigger the Bot to store the structure into an Activity file, but it needs more data to identify this object as a worm.

Since worms move, the key here is motion.  So as the “shots” are stored into temporary memory, and the color has been identified as important, when the worms move, that’s called a Cluster.  In and of themselves, color and movement are meaningless, but when put together, that Cluster is a complete Association, and the LOCK is established.  In this instance, the LOCK is to scoop up the worms.

When I use the term “programmer” here, I’m not talking about the people who write the code for the program.  I’m talking about the people who have been trained to use the software and are making up a task for the Bot, which can be done on a mission by mission basis.

In the case of a WarBot seeing a make of grenade launcher it hasn’t seen before, we use the same procedure, but what attracts the Bot’s attention may not be at first the grenade launcher itself, but perhaps muzzle flash.  Even with a WarBot, combat is dangerous, and the WarBot’s ability to spot new weapons and respond appropriately will save lives.

I’ve made the bold claim that my Terminator Perceptual Engine is Artificial Intelligence (AI).  But is that true?

Yeah, it is.

The Terminator works this way:  it’s constantly taking still shots of the environment.  Then it deconstructs those stills into data structures and scans the structures for meaning, a process I call Association.  Almost all of those data structures will be ignored because they have no relevance to the Bot’s performance.  How will they be ignored?  You don’t actually code a data structure “Ignore.”  The data structure passes through the rendering programs and is wiped if it doesn’t hit a match.  So creating a mission for a Bot is just a matter of loading the correct rendering programs, isn’t it?  Everything irrelevant to that specific mission will be wiped.

Some objects will already be in the Bot’s data banks, and will generate the “Lock” for that object.

But what if the Bot hasn’t seen an object or action before?

Let’s say an enemy combatant with a weapon the Bot hasn’t seen before is leaning out a second story window.  All objects have characteristics.  Rifles have barrels, they generate muzzle flash, the combatant’s hands are on the weapon, etc.  Is it a weapon, or is it a kid poking a stick out the window?  Is that sudden flash of light muzzle flash or is it some sort of reflection?

The characteristics of classes of objects are stored in the Bot’s data banks.  If the Bot finds something that might be a weapon, it stores that image into a temporary Action file.  If it picks up a second characteristic, then it’s a Cluster (or you could set the Cluster threshold at three characteristics).  The weapon’s barrel could be a stick, and the muzzle flash could be a reflection, but when you put the two things together, then you have a weapon.  The Bot then searches its data banks for the closest match to this weapon. It’s kind of like a search engine.  The Bot finds the closest relevant match, and assigns a “Lock” to it from the “Lock” used by the most relevant match.  The weapon is written into a permanent file so when the Bot sees it again, it’s like any other “Cue,” and it uses the routine it’s already put together.

That’s a simple form of AI using the Terminator Perceptual Engine.  However, we can do more than that.  We want the Bot to create its own “Locks” out of elements of “Locks” already in its data banks.  Since the “Lock” is itself modular; that is, all of the systems in the Bot are potential elements of a model.  The Bot deconstructs the environment and will use logic to create a “Lock.”

Let’s say a child fell out a window, and the Bot is in the area.  It knows what a child is, and it knows what falling is.  One of the characteristics of a child is that it’s soft.  One of the characteristics of a street is that it’s hard.  When you put hard and soft and falling together, you’ve got a problem.  The appropriate response is to try to catch the child.  The Bot generates a “Lock” to move it into position to catch the falling child.

If the Bot knows what a child is, what the characteristics of a child are (such as “short”), and what the street is, and what the characteristics of a street are, and that “Soft + Hard + Falling = end of the line for the child,” or, put another way, that a soft object moving at speed toward a hard object means the soft object will be destroyed, the Bot can execute a “Model” based upon a “Lock” it devised on its own.  The key is “destroyed.”  That’s what really causes the Bot to move.  “Destroyed” doesn’t really have any meaning for the Bot.  The combination of these three things initiate the routine to generate a “Lock,” so “Destroyed” is implied.  It’s going to have to calculate on its own the mathematical progression to intercept the child.  One of the things it has to do is to calculate the distance to the intercept point, and where its appendages have to be to catch the child.  And in addition to calculating distance it also has to calculate the trajectory of the child.  Distance + Trajectory = Intercept Point.  The Intercept Point isn’t the “Lock,” because the Bot also has to calculate how long it will take it to get to Intercept.  “Destroyed” isn’t necessarily bad.  If it’s an enemy position, “Destroyed” is what we want.  But when you put “Destroyed” together with child and street and falling, “Destroyed” is bad.

That’s complex AI, but it only works because of the “Model” system.  Of course, all of the elements have to be in the Bot’s data banks.  If it sees something for which it has no reference, it won’t react to it.  Considering the large amount of data modern digital memory can store, you can have a lot of information in the Bot’s data banks.  What we’re doing here is using Association and Comparison to build a Bot that can act independently and solve some problems on its own.  As time goes on, the performance of the Bot will improve.  All of the software the Bot uses will be developed on advanced computers and then fed to the Bot.

If you think about it, a Terminator class Bot is an extremely sophisticated machine which can mimic a lot of human behavior.  But when a human sits down and listens to music or reads a book, those things have no meaning to a machine.  Humans are humans, and Bots are Bots.

What I want people to see here is that these Bots aren’t just a concept, they are mathematically sound.  The WarBot would have Deconstruction with better resolution than FotoSketcher, but the principle is the same.

We give our machine the outlines of that which is seen and heard, and fill those outlines with what is there, and then tell it what those things mean in context.  Since we know what they mean, trying to make the machine think on its own seems a waste of time and probably functionally impossible.  Instead of building machines that act like humans, we should build machines that can use human intelligence.

There’s over 50 million lines of code in Windows 7.  That’s a lot of code.  Of course, Microsoft doesn’t totally re-write Windows with every iteration.  The “kernel”—the underlying Operating System—was adapted from Windows NT.  I mention this to show that completely coding the control programs of the machines described here is within our technological capability.

And in the event that any of these machines find themselves in a situation they don’t understand, since they will be equipped with real-time video and audio, HQ (whether a military or civilian operation) can download instructions to extricate the machines from the situation.

These four things are the basis of the robotics control programs:  LOGIC, EXTRAPOLATION, ASSOCIATION, and COMPARISON.  Using these four forms of mentation, we can build an extremely sophisticated machine that isn’t the stuff of fantasy.


If you’ve read my paper on modern Bots, you might be confused about how I use the term “Lock.”  It’s not the same as when a missile guidance system locks onto a target.  My robotics control programs only activate the missile guidance system.

So what is a “Lock” as I use it?

A “Lock” is a sequence of robotic behavior.  Let’s say a military Bot detects a trigger, like a terrorist attempting to shoulder a grenade launcher.  By comparing frames of digital photographs, the Bot can detect very small movements, movement that would be undetectable by a human.  How does the Bot detect the trigger?  By using a Zoom function in the digital “camera.”

Now we have the trigger.  That trigger is a gateway to a software routine.  Who determines what gateway the trigger uses?  In this case, the software support team.  Any trigger can go anywhere, but the software support team sets the routine they want.

So they gateway the trigger to a certain routine.

There are a couple of factors here.  One of them is the distance the Bot is from the terrorist.  If the terrorist is within the range of a machine gun, then that’s the weapon that will be deployed.  If not, then the Bot will launch its own grenade.  That’s just math.  The military knows what the range of a given weapon is.

The “Locks” are set up using software that is a sequence of menus.  One great advantage to these Bots is their flexibility, which is derived from the basic flow of TRIGGER>LOCK>RUN SIMULATION>EXECUTE MODEL (completed sequence of behavior).

If you’re setting the software up, the first thing is you’re going to set up a trigger.  That trigger is really a rendering program, a program that is the mathematical representation of, for example, an AK47, a very common and cheap weapon often used in these situations, in every “view” of it.  Most of the environment isn’t going to trigger a “Lock,” because most of the environment has no relevance to the Bot’s performance, and will be wiped.

Once you’ve set up the trigger, then you want to link it to a routine.  You set up a “Lock,” which is the routine.  The AK47 isn’t a very good weapon, and you know its range, so that will figure in, and you know the range of weapons you have, so you select a weapon or weapons that you want to deploy in response to the terrorist’s AK47.  If the terrorist is 50 yards away, the Bot’s machine gun will be activated, but if the terrorist is 150 yards away, the Bot uses its grenade launcher.  It depends on what you want to do.  If there’s a burning pickup truck in the way, the Bot must deal with that first, so the Bot can blow it out of the street, or look for an alternative route before executing the deployment of the weapon, or deploy another weapon.  Kind of like, “If not A, then B, then A.”

The effectiveness of the Bot depends upon the skill of the support team.  The activities of the Bot can be saved back at HQ, and if things didn’t go as well as you wanted, you can look at what the Bot did and tweak the software.

What I’m saying is very logical.  It all works because of the basic flow that’s the core of the system.  One I came up with that, the rest of it fell into place.  I focussed primarily on a military Bot, because it’s such a demanding high stress environment.  If the Bot can handle that, it can handle other environments.

Because the Bot’s environment is a mathematical grid, the “Locks” conform to the relative notation of the grid.  They don’t have to conform to the actual addresses in the grid, just be able to plug into that grid.  The mathematical dimensions of the actual grid are the relative dimensions of the “Lock.”  The digital photographs will have the same perspective as the grid.  Most of the time, the “Locks” will be a “Sliding Lock;” that is, multiple deployments of weapons, like:  machine gun at “aa” to “ag,” and grenade at “ap.”  Something like that.  The distance between “aa” and “ag” is the same in the software as it will be in the actual grid.  It’s just that when you set up the software, you’re using relative notation rather than the actual addresses in the grid.  So when a “Lock” is triggered, the Bot does what you want it to do.  The grid is 3D, so one of my Bots, depending upon its hardware complement, should be able to mimic the behavior of any Bot now commercially available.  When the Bot hits a “Lock,” it just does a check down of its systems and then applies the math to move itself into position.  So you can see that the same “Lock” could require different movements of the Bot in different situations, and that’s accomplished by referencing the running table of the current position of the Bot’s systems against the “Lock.”  In a combat zone, effective deployment of weaponry will be the most important factor, and how far the Bot has to move to do that will vary.

The “Lock” has a specific relationship to the trigger, so any “Lock” is automatically achieved when  the Bot performs the check down of its systems.  It isn’t necessary for the Bot to reason that “I’m here, and the ‘Lock’ is at 45 degrees , so I have to subtract X.”  The Bot only has to know what the “Lock” is in mathematical terms, and then move itself into position.  The Bot ignores that which has no trigger; it just falls through the system and is wiped.

But you need people who know what they’re doing to set up the Bot, and it’s going to be a lot of work, but once it’s set up, then any Bot can use that set up.

Due to the depictions of robots in books, TV, and movies, we tend to make Bots “human.”  But they aren’t.  They live in the world of abstractions, and nothing means anything to them unless a human applies some skill to their behavior.  So this notion of “Skynet” going wacko and wiping out the human race is a figment of the writer’s imagination.  Good entertainment, bad robotics.

In my paper I take the reader through the various stages from a simple “object recognition” War Bot to a combination Android Control program with a Terminator Perceptual Engine, which will be the Bot actually manufactured.  Most of the time, military Bots will be used at night, after the initial bombing campaign if aircraft are involved.

I hope this explanation answers any questions readers might have.  Bots are a good thing.  And this is a perfect mathematical construct of a Bot.



Instructions to establish inter-communications within large networks of robots to create a very large device that acts as one device, which can be configured and re-configured upon demand.

Terrorists are able to infiltrate by blending into the environment.  Robots can use the same tactic to stop them.

How do we do that?

You take a bunch of smaller Bots and make them work together to form a much larger machine. Kind of like a “Transformer” from the movies.

You install these big Bots in areas infested with terrorists.

Every Bot in the “Transformer,” regardless of type, has a file with the capabilities of every other Bot.  What makes it work is that all Bots in the system have access via Comm links to the running table of the position of systems of every other Bot.  If you temporarily freeze a Bot’s systems table, you control the Bot.  Thus any Bot can do the calculations for any other Bot.  It isn’t emulation.  In essence, Bots communicate by becoming the Bot with which they want to communicate.  It also gives any Bot access to the knowledge of any other Bot.  In a “Transformer” some of the Bots are mobile and some are stationary—whatever mix is called for by the application.

These smaller Bots create a functional much larger Bot.  You can put these “Transformers” together and morph them as the requirements change.  There’s no defense against a “Transformer.”  If you do manage to knock out one part of it, it can be reconfigured.  And you don’t need an actual Trigger all the time.  You can plant Flags, too.  Thermal Imaging is a great technology and the “Transformer” will make use of it, along with any other tech that’s suitable, such as drones.

We take digital photos, overlay a grid onto the photo, and process the photo—when the Trigger is acquired, the Bot’s running table of the position of its systems is temporarily frozen, which generates a baseline, which is the anchor for subsequent calculations.  All of the mathematical information you need is already in the digital photo.  Most of what’s in the photo will be irrelevant to the Bot’s performance.  You can overlay Thermal Imaging, etc., so the Bot can use any kind of tech, and it’s all front-end processing to give the Bot the correct Trigger.  The Bot can use any kind of photographic technique such as Macro, Micro, and Telephoto.

If you’re asking:  are today’s processors capable of handling that much processing in so short an interval?  Yes, they are.

As I’ve remarked in other columns, Triggers can be assigned a priority rating.  A terrorist with a grenade launcher would usually carry a higher priority than a terrorist with an AK47, and the priority of Triggers can be weighed in context.

The Bot targets weapons, not people.  When a Bot takes a shot, it’s knocking out the weapon. Ordinarily, the individual with the weapon will be killed or rendered incapable of fighting.  The Bot can detect motion that human’s can’t.  If a Bot and a terrorist draw on each other, the terrorist is going to lose.

Our troops will have a ID Chip in their uniforms that tells the Bots not to shoot at them.  ID Chips and robotic communications will be heavily encrypted.

Assassination drones work, but we need a way to deal with terrorists at street level.  Thus far we don’t have an effective response.  This system was created from the ground up to be modular.  The elements can be combined in infinite ways.  Lessons learned from military Bots can be applied to civilian applications like automated mass transit or medical response services.

NOTE:  Artificial Intelligence is built into my system.  It uses a network of files and protocols and can write its own files, so it doesn’t need to license someone else’s tech. My system doesn’t need lasers to navigate.  It uses digital photography and a Map, so licensing someone else’s laser tech is unnecessary.  However, lasers can be used within my system to perform other useful functions.


I’m very interested in the ecology of humans and machinery.  How machinery can become part of the environment and benefit humans.

The American public doesn’t want more expensive invasions into foreign nations. One of the reasons is that the invasions are inconclusive.  They drag on for years, chewing up troops and materiel, and we have little to show for it.  In fact, the people we want to help want to distance themselves from us.  We need to get in and get out, get the warring parties into peace talks where they can hammer out a solution to live with one another.  All wars end with talking, and the faster we get to that point the better it is for everyone.

I was thinking about the ecology of humans and machines.  I call it a “Transformer.”  A virtual machine that acts like a Hollywood giant robot, but is made up of a lot of smaller robots.

Robots must communicate, but how?

Every Bot that is part of a “Transformer” has a file with the capabilities of every other Bot.  And every Bot can open a Comm link with every other Bot and access that Bot’s running table of the position of its systems.  That’s how Bots communicate.  Once a Bot accesses that table, it can be that Bot, even if it’s a Sentry Bot the size of a basketball controlling a 20 foot high Combat Bot. And any Bot can “see” what any other Bot “sees.”

These “Transformers,” or aggregations of Bots, can be assembled and disassembled at will.  What works one day or in one situation may not work the next day or for the next situation.

So in a way, while not as dramatic as a Hollywood “Transformer,” these giant virtual machines are actually better.  There’s no defense against a “Transformer,” because it’s distributed processing.  If one Bot is knocked out, you can insert a replacement.  It will be very difficult to knock out a Bot, because they can look like anything.

So how would such a machine work in a real world application?

One application is in guaranteeing the integrity of a border.  Preventing infiltration.  Deflecting terrorists.

Terrorists are quite effective.  They’re skilled at undermining the peace.  But they all have one problem:  they’re corporeal.  They exist in time and space.  They cannot materialize and dematerialize like ghosts.  It just seems that they can.

So, to start with, you take an area known to be infested with terrorists and you install as many “Transformers” as you need for adequate coverage.  The Bots can use Thermal Imaging, infrared, any technique now or in the future.  Thermal Imaging is a great tool—it tracked down the B0ston Marathon bomber.  Drones using Thermal Imaging could be part of a “Transformer.” So that’s defense One.

And then you build a defense line of “Transformers” to secure the borders.  That’s defense Two.  To deal with any terrorists who manage to slip through defense One.  For border defense we want to set up a “buffer zone” with flags, so that the Bots won’t act beyond certain coordinates.  Borders aren’t a straight line.  The flags allow the defenses to follow the shape of the border.  Flags can consist strings of values or a range of values.  You don’t have to input on a one-to-one basis every value from one point to another.  You can input:  “29xa4–55yz20.”  Like that.

The response to infiltration isn’t necessarily shooting.  Bots are not berserkers. Ordinarily entering the United States from Mexico is just a misdemeanor.  We don’t want to shoot the offenders, but we do want to notify the nearest Border Patrol personnel. The use of maps will tell the Border Patrol where the breach took place and can track where the offenders are going.  Border Patrol officers will then decide how they want to handle the situation.  While no system can be perfect, the use of Bots should greatly reduce illegal immigration.

In addition to the United States/Mexico border, there are two other border problems where “Transformers” might have a real impact:  The Israeli border with Arab neighbors; and Pakistan’s border with Afghanistan.  If Israel was satisfied that its borders were secure and its citizens safe, it might lead to flexibility in returning land taken in the Yom Kippur War.  That would help stabilize the region.  Pakistan’s border with Afghanistan is a corridor for drugs and weapons.  Pakistan feels American operations in the sector make them look inept, so they’re pissed off at us.

In order to use the map Bots must be correctly aligned with the map.  One way is to use landmarks to orient the Bot, but you could also use stars or GPS.  No specific mathematical notation is required, just unique notation for each coordinate.  Because numbers are infinite, theoretically there’s no limit to the size of the map.

No matter how much these machines cost, it’s going to be a lot less than inserting thousands of humans into an Action Zone.  And because the machines react faster and can detect things humans can’t, the machines are more effective.  We save lives and money.

Eventually the F-35 fighter will get its problems sorted out, but we own the skies anyway.  The problem is on the ground, at street level, in Kabul and Baghdad, or some other city.  We need to own the streets, too, and encourage combatants into peace talks, and we want to do that as fast as possible.  Bots bring sophisticated technology to somewhere’s Main Street.

Bots are a different bag than an F-35.  The F-35 will streak overhead for a few hours or days, while Bots will be deployed for longer periods.  And that’s OK.  Long enough so that we can secure the peace.  That’s where we’re running into difficulty—securing the peace.  If we can’t do that, the people will have no confidence in us.  One obvious customer for Bots is NATO.

So all Bots are one Bot, and every Bot is all Bots.  All for one and one for all.

It’s not a concept.  A concept is:  Wouldn’t it be great if machines could protect people?  This is a real-world way to do it, based upon solid logic and mathematics.


How can you use a Transformer Class Bot to create a Safe Zone or Safe Border?

You can block Combat Bots from firing in certain directions, like toward the rear of the installation. Create a DMZ to the front, limit the “hot zone” to a certain distance, and drop warning leaflets. If needed, open and shutdown a section of the border or zone on command to allow access to the rear.

Sections of borders and zones are opened and closed by toggling flags.

Transformer Class Bots Safe Zones can make a huge difference in war torn areas to protect refugees from depredations of paramilitary forces. It can secure the borders of countries facing a threat from their neighbors.

Safe Zones, in conjunction with other Bot tech, could deflect suicide bombers. Reversing a Safe Zone is a Containment Zone.

We want Safe Borders and Safe Zones, but we don’t want proliferation of weapons of mass destruction. Bots meet that challenge.

I call this virtual machine a Transformer Class Bot because every Bot is the entire machine, and the machine can be assembled and disassembled, and morphed into another machine, on command. Even though it isn’t a 10 story tall morphing movie robot, it can actually out-perform a 10 story tall morphing movie robot. Transformer Class Bots are almost impossible to defend against because the separate parts of the whole can look like anything. While in the real world a hot dog cart can’t morph into a giant robot, nonetheless a hot dog cart could be part of a giant robot. In a terrorist infested theatre, that’s what you want.

What’s happening is that when a Sentry Bot acquires a Trigger, it recognizes the type of Bot required to execute the appropriate behavior (Lock) for that Trigger, and then polls the field for the nearest Bot of that type. The Sentry Bot takes control of the Running Table of the Position of Systems for that Bot, and sees what that Bot sees, so that the Sentry Bot really is the other Bot. In other words, the Sentry Bot acquires the Trigger and generates the necessary behavior (Lock) using a file with the capabilities of every other Bot. The Sentry Bot’s position is the baseline for the other Bot’s Running Table to execute the behavior. Once the transmission is complete; that is, the other Bot is executing the behavior, the Sentry Bot can release the other Bot.

So it works like this: Trigger>Lock>Poll>Control of Running Table>Extrapolation>Run Simulation>Execute Behavior (Model)>Release

Bots can be anything. A Bot could be an armed drone. A non-mobile weapons installation. A medical evacuation drone. What you have is a 3D grid which mathematically could encompass the known Universe.

It all depends upon what you need from the Transformer Class Bot. Sentry Bots can be run just for Intel, in which case the Intel will be transmitted without further action. But in another implementation, a Sentry Bot could control a short range missile installation and fire the missile.

An example of a border that should be controlled for the benefit of everyone is the Pakistan/Afghanistan border, which is a swiss cheese corridor for terrorists, weapons, and drugs. It isn’t necessary to obtain permission from Pakistan to install the Safe Border because it can be erected on the Afghan side.

You can install Transformer Class Bots in some shit hole, and create a more effective violence free zone with a DMZ, at a fraction of the cost of a conventional military presence. Drop leaflets telling warlords and other undesirables that if they enter the DMZ with a weapon, they will be shot. That’s a message warlords and pirates will respect. And it allows relief agencies to get help to refugees without fear some thug will steal it because it’s dropped into the Safe Zone.

Warfare has changed. Shooting as many of the bad guys as possible isn’t a winning strategy. The goal in the new warfare is to set up Safe Zones, and keep setting them up so that the enemy is contained. You will have to shoot as many bad guys as you must to establish the Safe Zones. When the populace sees that they can live without fear, they will have confidence in us. That’s what will win the war. You’re dealing with a specified area. We fight for a piece of turf, and then turn it into a Safe Zone. And we keep doing that until the enemy has nowhere left to go. You need a DMZ that everyone must respect. But you don’t need thousands upon thousands of troops to do it.

Using the Afghan conflict as an example, instead of fighting the Taliban across Afghanistan, we kick the Taliban out of a certain area, and set up a Safe Zone. That protects the inhabitants of the Safe Zone, and limits the area of operations for the Taliban. If we continue to do that, and secure the Pakistan/Afghanistan border as a Safe Border, eventually we’ll win the war, with fewer casualties on both sides. There are ways of allowing some traffic in and out of a Safe Zone without compromising security. When you know what the in and out points are, you can deal with it.

Transformer Class Bots aren’t a concept. It’s real technology. Transformer Class Bots level the playing field.


In a previous column I discussed how a Transformer class Bot could deal with rockets lobbed into its territory. I was thinking primarily of Israel, but it applies to any country facing a problem like that, or even within war zones like Syria, to foil rockets carrying chemical weapons.

So how does it work?

The first line of defense in a Transformer class Bot are Sentry Bots. Sentry Bots constantly scan an area for Triggers. That area theoretically has no limit—at least not mathematically. In practical terms, the Sentry Bot is only as good as its sensors (whatever those are), but you can have as many Sentry Bots as you want. When you think of what we can do with telescopic equipment these days, the tech is really limitless.

Bots work off digital photography, but the photographs are so fast, it looks like continual motion to a human. When the Sentry Bot picks up a rocket, it begins to compare frames. That frame comparison gives the Sentry Bot the trajectory of the rocket. Once the trajectory is established, the Sentry Bot takes control of the nearest missile bank—which is also a Bot—and the counter measure is launched. It’s math.

I’m not concerned here with the actual guidance system of the counter-strike missile, how the missile gets from Point A to Point B. That’s the job of the weapon’s guidance system. I just want to tell the missile what Point B is, and do the correct math. Point B is where the incoming rocket will be. Once we take into account all of the variables, we can determine the Point B of this application. But don’t we have missiles that can shoot down rockets right now? Kinda sorta. Recently some rockets were fired into Israeli territory, and the rockets all made it to the ground, but there was nothing there to hit.

How many frames you need to compare to compute the right trajectory is variable. Maybe 15 frames. You set that value in the software. 30 frames might be better. Other factors are the response time at the missile bank. Maybe it’s 20 seconds to launch. Because the software is modular, if response time improves to 5 seconds, the software can easily be adjusted for that. Just a matter of changing a setting in a menu. That changes how long it will take the missile to intercept the rocket. That will depend upon the missile.

Everything in this system works from one logical component to another. There is no “If we knew how to do this….” We know how to do all of it. We just aren’t doing it.

If we had a Safe Zone in Syria, the government would be very stupid to launch chemical weapons. The weapon would be shot down long before it reached its intended target, and the weapon could contaminate the government’s own territory. As a practical matter chemical weapons would not be launched because the weapon might kill those who launched it.

Here’s another stupid thing that illustrates the same principle: let’s say a Combat Bot is moving down a terrorist infested street in Country A. A terrorist launches a grenade against the Bot. The Bot fires a counter-strike and destroys the grenade. Unfortunately for the people who launched the grenade, they perish in the resulting explosion, caused by the two grenades meeting.

This system could make a huge difference in places like South Sudan—which isn’t of strategic importance to the United States—by erecting Safe Zones.

One of the things we need to do is have better sensors to pick up IEDs. I’m not worried about rocket-propelled grenades. I think dogs could be a lot of help, because we can train the dog to bark in a certain way when it finds a bomb, and then use an Analog to Digital Converter to make that bark meaningful to the Bot. A Bot could literally have a file of hundreds of barks, and run the dog’s bark through it to find the matching bark, and then use that bark as a Trigger for some robotic activity.

This Bot is designed to work with any kind of input. Advances in inputs can be easily incorporated into this technology.

What we don’t want is the “Paint Yourself Into A Corner” approach like Windows and Mac. The world moves too fast for that. There’s no churn cycle on the ground in Iraq and Afghanistan. The bad guys won’t wait to shoot at you while a new OS is developed. This is a robotics control program designed to operate any Bot.

Is this technology perfect? No. But it represents a quantum leap over what we’re doing now. It isn’t a concept—it’s an exact description of how it works. This digital world created for Bots is actually a parallel universe that intersects with ours. If you watch a Bot perform a task, you’d think it’s doing it in our world—but it isn’t.

This is a logical and mathematical entity that exists independently of a programming language or computer hardware. Menus, tables, and files, etc., are not proprietary. What I’m doing here with these elements is my intellectual property. In other words, we may have data structures which are not themselves proprietary, but what is done with them is. For instance, Microsoft Windows uses folders, menus, text entry, and files—just like any other OS—but the way in which these common elements are used forms the intellectual property that is Windows.


My robotics control programs don’t need any existing programming language or Operating System. It is a robotic Operating System.  I call it “The Grid.” It’s not a concept. I’ll explain how it works.

The Grid is a 3d network of intersections. Those intersections are the mathematical points of reference for the entire Universe.

So what’s different about that?

This: there are two main data types in The Grid: “Intro” and “Outro.” Any intersection can be labelled “Intro” or “Outro” or both. “Intro” and “Outro” are flags. They trigger a robotic response. “Intro” is processing by the Bot itself. “Outro” is Intelligent Universe processing. Certain things are going on in the Universe which must be dealt with by the Universe’s brain, like maybe a Solar flare. So the Universe can relay information about that Solar flare to other data beings. The Universe is as intelligent as the phenomena we can detect. Where does the “Outro” processing take place? Could be in a Bot or on an Earth Station or the International Space Station or some spacecraft that’s leaving the Solar System altogether. The Earth itself could be “Outro.” Obviously this isn’t Windows or any other present Operating System.

I think you can see how that would work. We need a Bigger World. You don’t need a machine at every intersection, you just have to be able to detect and process that intersection.  The Universe is very intelligent.

The Bot can utilize 3D photography, and synthesize 3D from 2D.


1. Using a drone, map an area.

2. Analyze map. Insert flags.

3. Correctly orient Bot within map. Activate Bot.

Flags are artificial Triggers. The flags define an action which the Bot is to perform at a designated point in a map, even though the Bot hasn’t actually “seen” anything. The Bot measures distance, speed, and position by referencing the running table of the position of its systems.

The sequence is:


This method is useful when deploying inexpensive Bots for a pre-determined purpose within a small area. Like “Shock And Awe” bombing that minimizes civilian casualties. Instead of dropping bombs, drop “smart” bombs that are actually Bots.  Use drones to drop “smart” bombs.  Taken to its logical conclusion, aircraft with human pilots would be unnecessary.

What I’m saying is that theoretically, if you have an accurate map, and you have inserted flags into the map correctly, a Bot could operate without sensors. A given spot in the map could have multiple flags, arranged in order of priority.

These comments are intended to refute the argument that a Bot’s behavior is “obvious” because it is merely mimicking human behavior.

A flag doesn’t have to initiate a sequence of behavior—it can also initiate a functional sequence in AI applications.

%d bloggers like this: