What should our discipline be called? Should it be called Robotics Science, or Robotics Engineering, or neither? Why?
Neither. It should be called Robotics.
We don’t say “Chemistry Engineering” or “Physics Science”. Robotics is not Robotics Engineering or Robotics Science. But the problem isn’t really one of nomenclature. The real problem is that Robotics doesn’t fit smoothly into these categories.
We could acknowledge the existing separations in the discipline between the hardware-centric researchers in Mechanical Engineering and the more theoretically oriented Computer Science groups, but the process that seems to be occurring is one of merging rather than separation.
The study of computing has effectively been separated into two disciplines: Computer Science for those interested in software and Computer Engineering for those interested in hardware. But that is, in some ways, an artificial distinction – both groups are solving problems with algorithms and patterns. We make a distinction between hardware designers who work on processors and bootloader programmers and language or operating system developers and application authors, but underlying all of those tasks is a fundamental problem associated with how you design entirely new sets of rules, and what those rules might lead to. It’s just that Computology, Computistry, and Computics all sound a little weird, and we don’t have a good name for something that bridges the gap between science and engineering.
Robotics already has a nice name, an excellent descriptor of what we do as researchers – just as Physics is the study of the rules that govern physical properties of the world and how objects with those properties interact, Robotics should be the study of the rules that govern effective robots (which is more of a philosophical question, appropriate to the sciences) and how to design robots that interact with the world in ways we want them to (which is the engineering side of the equation).
Engineering generally answers “how” questions, while the sciences focus more on “what” and “why” questions, on the causes of observed mechanisms rather than on the difficulties of designing new ones. But Robotics is doing both – it not only gives us lots of “how” questions to answer and gives us tools to answer “how” questions, but it also gives us lots of “what” and “why” questions. Not just “how do we learn?” but “why do we learn?” and “what should we learn?”. Robotics can even help answer questions in other scientific disciplines.
In Biology, there are often many hypotheses about what the rationale behind a given animal’s behavior might be. In at least two cases, researchers have been able to demonstrate that a specific behavior can be explained with simpler mechanisms than are usually attributed to it, by demonstrating that the simpler mechanism, implemented in a robot, is sufficient to drive the observed behavior. Robots are providing tools across the scientific disciplines in much the same way that improved sensors and new mathematical algorithms are good tools to support scientific research.
The primary difference between the engineering disciplines and the sciences is that the sciences have Philosophy as an underpinning. They have a philosophical component that is largely missing from the engineering disciplines. In Engineering, a solution that works is prized, regardless of whether it demonstrates some underlying truth, but in the sciences, solutions that lead to better descriptions of a perceived underlying truth are more highly prized.
Robotics can, I believe, do both. It is clearly a discipline that is concerned with functional solutions. Solutions that work are prized. But in that search for functional solutions, we are learning fundamental truths about ourselves, about other animals, and about complex systems. There are fundamental truths available through the exploration of Robotics that we will have difficulty finding in other ways. The fact that Robotics can take us to a better understanding of ourselves and other organisms in our world places it squarely in the sciences.
Robotics is more an engineering discipline than anything else (we are, after all, trying to build systems that work), but it is not only an engineering discipline. And it should reflect that by being called Robotics.
Signe, I agree: Robotics is a great name for the discipline, and there is no persuasive reason to search for a different one.
I should point out as a graduate of Missouri S&T: While there is no discipline called Chemistry Engineering, there most definitely is a discipline of Chemical Engineering. At MS&T Chemistry and Chemical Engineering are related but distinct disciplines, with Chemistry focusing more on scientific exploration and Chemical Engineering focusing more on the application of chemistry to large industrial settings.
The label "Physics" is indeed more universal, since there are e.g. no "Physics Engineering" or "Physical Engineering" curricula at most universities. However, in that case physics is so universally used in engineering that the particular type of engineering simply supersedes its use in the name, resulting in e.g. Electrical Engineering (applying the physics of electrons in diverse media), Mechanical Engineering (applying the physics of solids for the most part), Nuclear Engineering, and others.
The result of these further ruminations is: I'm not quite sure!
Here's an idea: Perhaps Robotics is the inverse of Physics, with Robotics defaulting to engineering, and Physics defaulting to Science.
That is, Physics by default refers to the exploration of a huge range of scientific sub-disciplines, each of which needs to be identified by name when talking its applied uses. So for example the application of electron physics is called Electrical Engineering.
By inverse symmetry, Robotics would refer by default to the huge range of _engineering_ sub-disciplines needed to build even a simple, working robot. It's hard to get around that, since pretty much by definition even a robot is a very eclectic entity!
But again by inverse symmetry, each of these sub-disciplines needs to be identified separately when talking about the _science_ that makes it possible. One obvious example would be Cognitive Science, the science of how to construct a brain smart enough to control a robot. One might invent a discipline of Collaborative Science, since in my mind that needs to be treated as a quite difficult research arena in its own right.
The symmetry is likely a bit broken by the fact that most robotic sub-disciplines will in time also acquire engineering names, as well as science names. E.g. Cognitive Engineering will I'm sure exist someday… but for right now, really? I just don't think we are that far along yet in that area. Ditto for many of the other aspects of Robotics, which has a habit of pushing its sub-disciplines so hard that they tend to hover at the level of still-doing-exploration science, rather than around the levels of standardization characteristic of engineering.
So: I think I've worked my way back to my original assertion: I agree with Robotics… but as the mirror image of Physics!
It actually probably ought to be Robotical Engineering, if we want it to be consistent, but that sounds even sillier than Robotosophy to me.
I actually came up with this question after noticing that all the undergraduate programs in Robotics tended to be called "Robotics Engineering," which seemed wrong to me, given the number of research groups based in Computer Science departments.
I like the idea of Robotics as the inverse of Physics. Engineering defined as applied Physics would define Science as theoretical Robotics? I think the scientists might have a problem with that…
I don't know about Collaborative Science, but there are definitely groups working in other interdisciplinary areas that have similar problems with large scale, highly complex systems – the smart grid people and the intelligent transportation networks people both have the same problems as the long duration multi-robot systems crowd. All of them have large numbers of distributed elements that all need to reach both local and global consensus about group actions that won't crash the system as a whole.