Comments on: Question of the Week: Is robotics engineering different enough from embedded engineering to warrant being treated as a separate discipline?

By: D.W. @EM

D.W. @EM — Thu, 06 May 2010 00:19:01 +0000

A coda to my earlier comment. Autonomous robots differ from other mechatronics applications in that they require navigation in an environment. This is a whole additional area of applied physics to absorb.
.
To be more precise, what is required for a field robot is portage, as in navigation within a port rather than at sea. Navigation at sea has no landmarks, so you need either GPS, LORAN or a compass, a sextant and a very accurate clock. Ports have landmarks and obstacles. Navigation in-port requires locating landmarks and obstacles around you, and some of these change from day to day. The ship in that dock may not be there tomorrow; and the dock that is free today may be occupied tomorrow. And do not run into the ships that pass you.
.
What we want and need are autonomous field robots that can navigate in known but unpredictable, continuously changing environments. This is a key area of R&D. Many schemes have been used to identify landmarks, such as bar codes, flashing lights, radio beacons, etc. Of more interest are newer and improved means of machine vision for object recognition to give the range, bearing and pose (RBP) of objects surrounding the robot. If you know the RBP of all objects around the robot, you can write a program to navigate to and around them.
.
This additional problem of autonomous field robot navigation is what differentiates field robots from factory machine tool robots. It is not a derivative of embedded machine control, but an additional area of knowledge and expertise. It is the secret sauce of the next generation of robots, field robots.

By: T.G. @EM

T.G. @EM — Tue, 13 Apr 2010 20:52:33 +0000

It’s an interesting discussion. Typically there are differences between robotics curricula that focus on the system level and embedded curricula that deal with the microprocessor or lower level code. However, they both have many aspects that overlap and if students are armed with the proper tools and enough time, a combined curriculum is the way to go. We see this overlap happening in educational institutions across the globe, where professors and students have access to easy-to-use common programming language tools that help them collaborate across disciplines – from engineering to computer science – so that they receive a well-rounded understanding of robotics, mechatronics, embedded and more. All this meshing of curricula is necessary today in order to give students the skills needed to become “holistic engineers,” which will ensure their success no matter what field of engineering they ultimately pursue.

T. G.
Education Marketing
The MathWorks

By: A.P. @LI

A.P. @LI — Thu, 08 Apr 2010 20:15:10 +0000

No, we’re just batty.

Otherwise, we wouldn’t be in this business

By: R.A. @LI

R.A. @LI — Thu, 08 Apr 2010 19:24:54 +0000

“What about simulations of robots – are they robots?”

They are simulations of robots… unless of course we’re in the matrix, in which case they are simulations of simulations of robots, and we’re just batteries

By: T.D. @LI

T.D. @LI — Thu, 08 Apr 2010 11:15:27 +0000

Had a look at the answers.com definition of robotics...culled this:

"Recently, however, the industry's current working definition of a robot has come to be understood as any piece of equipment that has three or more degrees of movement or freedom"

The traditional definition of a robot was something like "artificial human".

The original definition is perhaps not applicable to current industry due to the early stage of development.

I prefer the term mechatronics for electromechanical systems.

By: R.S. @LI

R.S. @LI — Thu, 08 Apr 2010 09:59:52 +0000

Interesting.
R., Would you consider a “bot” a “virtual” robot? What about simulations of robots – are they robots?

By: R.A. @LI

R.A. @LI — Thu, 08 Apr 2010 05:54:27 +0000

“Robotics as a subject would I presume include internet agents…”Bots”. “

Absolutely not. Robots are, by definition, mechanical systems, that very often (but not always) controlled by software.

“I suppose there are two aspects to robotics: mind and body.”

Yes, and this is exactly why an Internet agent is definitely not a genuine robot.

I would refer you to the following link:

http://www.answers.com/topic/robotics

By: T.D. @LI

T.D. @LI — Thu, 08 Apr 2010 05:45:57 +0000

Robotics as a subject would I presume include internet agents..."Bots". These have purpose and intelligence but are not realtime or embedded.
Machine vision (and any similar conversion of sense data into higher forms of data) also would be a part of robotics technology, and again wouldn't necessarily be realtime or embedded.
But then motion control is realtime and embedded.
I suppose there are two aspects to robotics: mind and body. The physical aspects use realtime embedded as a platform.

With regard to "mind", in some cases decision-making might not be realtime...the robot might have to stop and think. And the intelligence might not be embedded, it could be running on a remote server given wireless communications.

By: R.A. @LI

R.A. @LI — Thu, 08 Apr 2010 05:00:46 +0000

"It seems there are many embedded subsystems, such as the braking systems or stability-control systems resident in many high-end automobiles, that fit the description of a robot—but we do not call them robots. Even my clothes-washing machine can sense and change its behavior based on how the cleaning cycle is or is not proceeding according to a predicted plan; the system can compensate for many anomalous behaviors."

I Think the confusion here may stem from the focus on software that the preceding paragraph seems to imply.

Robotics is a multi-disciplinary field, that certainly involves software, but also involves a possibly even more significant measure of mechanical engineering.

Typically, a software practitioner in the field of robotics has a skill set overlap in the area of robotic kinematic theory with a mechanical practitioner in the field. I believe that this skill set overlap is the defining characteristic of practitioners in the field (regardless of their source discipline).

From a practitioners point of view, I would be inclined to define robotics, not as a distinct practice, but rather as a specialized set of skills (i.e. a specialization) that differentiates a particular practitioner from other practitioners of a more general discipline.

I think that if one views the mechanical engineering discipline as the lead discipline in the multi-disciplinary field of robotics, then it becomes much easier to define the skill set that identifies a software engineer as a suitable practitioner for the field.

I think that if a separate discipline of "Robotics Engineering" were to be defined, that it would imply a course of study that would be something close to dual degrees in mechanical and software engineering.

I find (due in large part to the fact that the intersection of skills between the software and mechanical disciplines is relatively small in relation to the overall set of skills required in either of these more general course of studies) that the concept of identifying a stand alone discipline is a bit of a stretch.

I would largely concur with R. S.'s definition of robotics, and would refer to the following paragraph from the definition of robotics in the Sci-Tech Encyclopedia, which nicely identifies a set of attributes for a robot:

"Robots produce mechanical motion that, in most cases, results in manipulation or locomotion. Mechanical characteristics for robotic mechanisms include degrees of freedom of movement, size and shape of the operating space, stiffness and strength of the structure, lifting capacity, velocity, and acceleration under load. Performance measures include repeatability and accuracy of positioning, speed, and freedom from vibration."

By: A.P. @LI

A.P. @LI — Wed, 07 Apr 2010 22:11:40 +0000

I, too, like R. S.'s definition of robot but even then there are grey areas: a "pick-n-place" machine or warehouse stacker is certainly a robot under almost anyone's definition; a mail-sorting machine or conveyor system, maybe not so clearly a robot.

There is certainly a lot of overlap between robotics and some other forms of embedded system (I consider robotics a subset of embedded) but there's lots of domain-specific knowledge as well. For robotics, that seems to be largely related to motion control. When you slide into conveyor systems, there may be less motion control but the time domain may become a bigger issue.

Or not; now we probably have to start talking about specific applications.

I would consider robotics as a kind of specialization among embedded engineers, like being an internist is a specialization among doctors. As such, I'd probably want to have an emphasis on certain areas but I don't think there's enough difference to warrent a completely seperate curriculum. At least, not at the undergrad level.