Industrial and military robots come in all shapes and sizes, tethered and untethered, autonomous or human operated, and designed for many different environments. But no matter how advanced robots are today, we’re still a long way from having a humanoid robot from science fiction.   


Where do you start in assembling a practical military (or industrial) robot? As with any engineering task, we need a set of objectives and a mission, which in turn defines the capabilities that need to be part of the robot.  With this in mind, it’s instructive to consider some current military robots.


Most everyone has seen Explosive Ordnance Disposal (EOD) robots demonstrated many times during the last few years, but military robots have a punctuated long standing battlefield presence.  One of the earliest robots was used during World War II.




Goliath was a rudimentary, remote controlled, demolition robot – the first use of military robots. Today development of military robots is proceeding at a breakneck pace, fueled by recent international conflicts. The TALON type robot is typical of these land-based developments.




Despite the age difference between Goliath and base level TALON, both robots rely on tracks for propulsion. Looking at TALON, tracks have the advantage of simplicity and ruggedness. As with most wheeled or tracked vehicles, they are relatively simple mechanically while retaining ruggedness.  This compares with mechanically complex articulated walking platforms like Boston Dynamics BigDog.


Military and industrial robots have a wide variety of uses in many different environments. Considering land based robots only, there are a number of essential functional requirements:


  1. Communication
  2. Navigation
  3. Propulsion
  4. Sensing
  5. Effecting


Communication for robots began as a concept of operator-machine communications. Today modern battlefields, and industrial spaces, have adopted what is known in military circles as “network centric warfare.”  The name is somewhat misleading as the “network” in the title is not literally an electronic network but rather it describes the way modern militaries will organize and fight in the Information Age. Network Concentric Warfare (NCW) translates information superiority into combat power. This is achieved by effectively linking knowledgeable entities in the battlespace. The physical domain is where events take place and are perceived by sensors and individuals. Data emerging from the physical domain is transmitted through an information domain. Data is subsequently received and processed by a cognitive domain - where it is assessed and acted upon. Effectively, the NCW process reproduces the US Military "observe, orient, decide, act" loop.


The physical network can be implemented through libraries available from companies like Wind River Systems(1) and Green Hills Software(2). Wind River Platform for Industrial Automation combines together a Real Time Operating System (RTOS), network software, and other middleware that may be used to develop state-of-the-art applications, including robots. 


In addition to commercial product offerings, you can also employ Open Source libraries: depending on what protocol completeness you want to use – a thin client or full featured TCP. ENet's purpose is to provide a relatively thin, simple and robust network communication layer on top of UDP (User Datagram Protocol). The primary feature it provides is optional reliable, in-order delivery of packets. For full TCP one of the libraries is STLPlus .



One significant advantage to this specific Open Source library is the independence from other communications packages - it doesn’t require Windows message handling or threading to work. STLPlus is a licensed software package and uses a BSD-style license too. (Open Source licenses were covered in an earlier blog).


Military planners prefer peer-to-peer networking as part of NCW. There are numerous advantages to a peer-to-peer network including the elimination of a central server as a requirement for systems operation. From a military operations standpoint, elimination of a centralized server removes one critical failure mechanism that could disable many pieces of equipment. Operationally, peer-to-peer topologies permit sharing of resources between units and also provide a mechanism for improving system robustness. System robustness can be achieved through the use of virtualization<url> to virtualization blogs> techniques combined with certified Operating Systems  like those offered by Green Hills  and Wind River.


In an automotive blog I discussed GPS-based navigation from the retail automotive standpoint. But military systems have a greater requirement for reliability of autonomous operation. In the US Army Integrated Armed Robotic Vehicle-Assault, the Autonomous Navigation System is capable of controlling several other classes of manned and unmanned vehicles.  Where automotive navigation systems are fundamentally a convenience, military autonomous navigation is justified by the risk/rewards/cost assessment. An unmanned assault vehicle that can’t obtain its objective because it has become lost, may be more than simply one piece of lost equipment.  Such occurrences put the objective in jeopardy. There are important differences between domestic US automotive road navigation and military navigation. Where civilian navigation can rely on physical boundaries of a roadbed as part of the steering algorithm, military autonomous vehicles have limited hard boundaries. In many modern battlefields “roads” may be defined by expediencies including cross country navigation with no roads. For this reason, military robots need to be able to find their way via Global Navigation Satellite Systems (GNSS) combined with vision systems, and dead reckoning. GNSS is not available in parking garages, tunnels, areas with high rise building that eclipse satellite broadcasts. In addition, designers of military equipment must provide a mechanism for navigation. An Open Source project is underway to develop navigation systems. Perhaps the most recognized autonomous vehicle is Stanford University’s project Stanley which won the DARPA challenge.


Propulsion is largely a matter of the expected terrain to be encountered. Many military and industrial mobile robots use tracks because they are relatively simple and robust. But there are alternatives that have different tradeoffs. For example, research in self-balancing two wheeled robots has yielded a basic balancing robot. Tracks and wheels have problems with obstacles that are too high, but are of no consequence for people. Walking robots provide a unique alternative.  A four legged walker is much heavier than tracked or wheeled versions.  Walking robot platforms are remarkable, but use significant power to move. There seems to be no end to biologic- motivated developments - recent research from Boston Dynamics has also yielded wheeled robots that can jump.


Sensing and effecting have a wide variety of alternatives. Sensors can use visible spectrum cameras, LIDAR, RADAR, magnetic sensors, and more. Effectors are mechanical interfaces to physical objects. Pincers, grippers, articulated appendages, rotators, and trigger pulls are just a few of the effectors. Bio-models have a critical role to play in future developments. Boston Dynamics offers Digital Biomechanics. It is the world's first simulation tool aimed at permitting engineers to evaluate the effects of equipment, clothing, and tasks on human soldiers. Boston Dynamics has also used the tool to model advanced robotic systems such as BigDog, PETMAN and others.


All of these hardware alternatives have a mechanism used to define the hardware actions in MARIE, a heterogeneous modeling system. The primary goal of MARIE is to enable quick reuse of mechanical systems that may apply to robot design. This type of tool is critical for robot development. As much as novel mechanical structures are essential to developing a practical robot, the interaction of software components is critical to success. Many of the robots reported in the literature employ high end microcontrollers as expedient processors, but they lack the processing power needed to build commercially viable robots.





The SPARTICUS social interaction robot is mobile and can parse human input using three 1.6GHz processors to perform its tasks. Today, those same Pentium® class processors can be easily replaced by a multicore ATOM™ processor.


Considering the complexity of this simple social interaction robot, how will you design your next robot?



1. Wind River Systems is an Associate Member of the Intel Embedded Alliance

2. Green Hills Software is an Affiliate Member of the Intel Embedded Allaince



Henry Davis
Roving Reporter (Intel Contractor)
Intel(r) Embedded Alliance