Because the motion imparted to a given joint depends on what’s going on in the other joints. Every motion of any joint imparts reaction forces and torques on all the others. If you want the system to follow a smooth trajectory from one state to another, you have to anticipate and counter those reactions.

In the world of rigid body motion, we call these reactions “cross-coupling” between axes. An industrial robot is a collection of (hopefully) rigid bodies, all connected together in complicated ways, so the cross couplings are very much more profound.

I don’t think it works that way, A.. Physically, the various parts of a robot can’t be treated in isolation. Newton’s laws dictate that for every force and torque on one body, there’s an equal and opposite force on the other. A controller has to take into account those reaction forces.

I think it’s probably possible to build a robot that doesn’t have (much) crosstalk between channels. You could have, for example, an x-y-z table, so the various degrees of freedom are all independent. You could make it a point to move along only one axis at a time.

You _COULD_ do that, but you won’t sell any of the robots. The customers want smooth motions from place to place, all axes working together.

I’m only being a little facetious here; industrial robots and UAV’s are a subset of embedded systems. In terms of actual embedded skills, I don’t think there is a lot of difference (and I have done both visibly moving robotic systems and “other” control systems).

But there is a whole level of anciliary skills which are needed for either system and they may vary quite a bit. As Jack said, if you have an industrial robot, you have moving masses and you really need to understand the physics of that motion. in an HVAC system, on the other hand, you don’t have much in moving parts (compressor and maybe some actuators) but you better understand the heat cycle you’re working with.

In short, the fundamental differences aren’t within the embedded side but rather with the hardware you are working with.

It’s also a controls issue, so one needs to be pretty thoroughly steeped in the concepts of modern control theory, stability, and all that.

Finally, as Scott suggests, this is a “hard real-time” problem. Things absolutely _MUST_ be done at a fixed rate, with low jitter.

Now, as for “other-than-robot” applications like differential braking on a car: The problem is much the same, except that the car is much harder and has more variables to control.