Categorizing Robots

      2 Comments on Categorizing Robots
ShareShare on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on RedditEmail this to someone

I’ve started working on an open source project that involves the design of a database schema to support the collection and searching of information related to robotics. I ran into a challenge that is fundamental to the database’s design and value: how to construct and populate categories for the robots. Naturally, I searched the web for relevant resources that could provide insight on these values. Although I am admittedly much more of an application designer than robot expert, I was not comfortable with the way information was organized in many cases.

Some examples of the items that confused me:

  • One prominent, robotics-focused website listed these values as “market segments” (or at least implied that categorization):
    Airborne, Education & Research, Engineering, Humanoid, Industrial, Manipulator, Maritime, Medical & Assistive, Mobile, Software. But I would argue that the values: Humanoid, Manipulator, Mobile, and Software do not really identify market segments (a group of individuals or companies that comprise a categorical market for your products and services).
  • I’ve also seen content that differentiated between tethered vs. autonomous robots. This differentiation seems to address the mobility of robots, but I think the “autonomous” term should be used to described how well a robot can “think and act on its own” regardless of whether or not it is tethered at all. And if I had a humanoid robot in my house that could walk around but required a very long tether for power and/or communication, I would consider that robot mobile.
  • Some terms like “field robotics” seem ubiquitous and important but I’m having trouble finding a structured home for them…

Rather than elaborate with more examples, I would like to (humbly and carefully) propose a categorization scheme that I believe would effectively support a user’s search for robots based on defining criteria. I am very much interested in getting feedback from others on this effort.

For starters, I am currently using these properties to categorize a robot:

  • Structure Type
  • Category
  • Market Segment
  • Applications
  • Features
  • Qualifiers

I’ll explain what each of these properties means and what the expected values would be.

Structure Type

  • This property defines the basic physical structure of the robot.
  • For ease of entry and searching, I will attempt to maintain structure types as a flat list without a hierarchy.
  • A robot in the robot database should be associated to exactly one structure type.
  • Proposed values for this property include:
    • Humanoid
    • Rover
    • UAV/Drone
    • Manipulator/Arm
    • Aquatic Submersible
    • Aquatic Surface Vessel
    • Exoskeleton
  • I know this categorization isn’t perfect. How do you classify a wheeled robot that has an articulated arm? I would classify it as a Rover, since that is the primary defining structure, with a feature of an arm (more on that when I cover features). How would you classify Baxter on a wheeled platform? I would classify it as a Manipulator/Arm with a mobile feature for similar reasons.


  • This property defines the general area or domain for the robot.
  • The category will be maintained as as a flat list without a hierarchy.
  • A robot in the robot database should be associated to exactly one category.
  • Proposed values for this property include:
    • Fields Robotics
    • Medical Assistive
    • Industrial
  • On a side note, when designing applications in general, I try to avoid or qualify properties with names like “type” or “category” because all of these properties are designed for typing and categorizing. However, I will use them when no better terms come to mind.

Market Segment

  • The market segment indicates the target group of persons or companies that would utilize the robot.
  • For ease of entry and searching, I will attempt to maintain market segment as a flat list without a hierarchy.
  • A robot in the robot database can be associated to many market segments.
    The proposed list of market segments includes:

    • Aerospace
    • Agriculture
    • Defense
    • Healthcare
    • Manufacturing
    • Private Consumer
    • Retail
    • Transportation

I expect I will find some reason to modify this list as I collect data.
Some examples related to these market segment values:

  • I would indicate that robots that automate warehouses belong in the Retail market segment (maybe others). I would include “Warehouse automation” as one of their applications, but more on applications later…
  • I would say that autonomous automobiles primarily apply to the Private Consumer and Transportation markets segments. Note that since market segments categorize the target market, the transportation market segment in this case would identify the likes of cab companies that might want an autonomous automobile. If we were discussing a robotic bus, I would argue that the transportation market would make sense but the private consumer would not since the average person is not in the market for a bus (as they may be for an automobile).


  • Applications will identify specific uses for a robot. These values will typically line up with market segments but the database will not link applications to market segments at this point — just to robots.
  • Applications will be managed as a flat list without a hierarchy.
  • A robot in the robot database can be associated to many applications.
  • I imagine the list of values could become extensive. Here is an abbreviated list of proposed values:
    • Aerial photography
    • Autonomous driving
    • Building construction
    • Bomb disposal
    • Caretaking
    • Electronic component production (IC, PCB, etc)
    • Education
    • Entertainment
    • Floor vacuuming
    • Fruit-picking
    • Home/business security
    • Lawn maintenance
    • Medical surgery support
    • Mining
    • Packaging
    • Painting
    • Personal mobility assistance
    • Personal service assistance
    • Research
    • Rescue support
    • Soldering
    • Surveillance
    • Telepresence
    • Transport/haulage
    • Warehouse automation
    • Welding
  • Note that with this approach “Agriculture” would not be a good application as it is too broad. The model prefers more specific values like “Weed control”, “Fruit-picking”, “Pest control”, and so forth.


  • Features will be used to identify certain characteristics of a robot.
  • These features will be geared to support valuable robotic searches; values like “Elegant” and “Plastic” are not appropriate values for this list.
  • A robot in the robot database can be associated to many features.
  • I imagine the list of values will also become extensive. Here is an abbreviated list of proposed values:
    • Articulated arm
    • Autonomous
    • Bipedal
    • Collaborative
    • Differential drive
    • Hexapod
    • Mobile
    • Quadruped
    • Swarm
    • Tethered
    • Treaded


  • An all-encompassing definition of what constitutes a robot seems to be elusive. There are however certain characteristics that exemplify what many will consider to be a robot. This property presents a predefined set of criteria to help determine how the individual robot measures against qualifications.
  • The database defines these qualifications to be evaluated per robot:
    • Has Sensors (does the machine have environmental sensors?)
    • Has Actuators (does the machine include motors and devices that move?)
    • Sensor/Actuator Controlled (does the machine include logic to drive actuators based on sensor input?)
    • Programmable (can the machine be programmed with instructions?)
    • Autonomous (does the machine employ algorithms to handle challenges without user-intervention?)
  • Every robot may be rated for each of these qualifications with one of these values:
    • Demonstrates
    • Partially demonstrates
    • Does not demonstrate
  • We can evaluate the robot-ness of machines using this scale. Take these examples:
    • Remote controlled car
      • Has Sensors : Partially demonstrates (has an RC receiver)
      • Has Actuators : Demonstrates (has motors that drive wheels)
      • Sensor/Actuator Controlled : Partially demonstrates (user sending RC signals drives motors)
      • Programmable : Does not demonstrate
      • Autonomous : Does not demonstrate
    • da Vinci Surgical System (best guesses…)
      • Has Sensors : Demonstrates
      • Has Actuators : Demonstrates
      • Sensor/Actuator Controlled :Partially demonstrates
      • Programmable : Does not demonstrate
      • Autonomous : Does not demonstrate
    • Mars Curiosity Rover
      • Has Sensors : Demonstrates
      • Has Actuators : Demonstrates
      • Sensor/Actuator Controlled : Demonstrates
      • Programmable : Demonstrates
      • Autonomous : Partially demonstrates

Finally, I plan on including some fields in the robot table that are commonly used to describe a robot including physical dimensions and weight and degrees of freedom.

Once again, the structuring and population of all the classification properties described above are intended to best support categorical searches for robots. I kept that goal in mind when writing this content. That being said, I am very interested in feedback from anybody, especially experts in robotics.



2 thoughts on “Categorizing Robots

  1. SJ Kim

    Dear iguanatronics,

    Your posting, which is “Simple tutorial on rosbridge and roslibjs”, is very helpful for me.
    I configured a simple node.js server and ran your html+js on it. Also I succeed running turtlesim by clicking the buttons.
    In addition, I posted about it on my github, and I am able to control my real turtle-bot via web interface!

    you may wanna check it out.

    Anyways, thank you so much for your posting!



Leave a Reply

Your email address will not be published.