# What happens from code to robotic action?

Starting in the code and through the hardware, what is the "path" that explains the robotic movement. Are there electrical signals involved? How they are initiated and formed and/or interpreted then by the "machine"/robot? Can you explain what happens from code to robotic action?

• Please specify what do you mean by code. The application program of an industrial robot? The source code of a robot controller? – 50k4 May 4 '17 at 19:38
• Welcome to Robotics, Octavarium. Could you please clarify what you're asking about? It sounds to me like you're asking about assembly language, but I can't tell the scope of your question from what you've written. Could you please expand it? – Chuck May 9 '17 at 10:17
• I am an amateur musician. I was not referring to assembly language specifically because, as far as I know, there are more languages in Robotics. Possibly binary is the "last" one regarding to what a "machine" understands. So "code" here in this question refers any applicable language to Robotics programming. My question is: what happens since the "effect" of the software. Many thanks. I am very curious. Sorry if I did not formulated well the question. Excellent answers were given, I did not upvote, just because I can not yet! Sorry about my English language (I need to study!). – Octavarium May 10 '17 at 14:53

what is the "path" that explains the robotic movement

Normally, a path refers to a path in the robot configuration space. Think of it like this. Suppose a robot has 6 joints. When you want to move the robot from pose A, at which the values of those motors -- a configuration -- are $q_A = [0, 0, 0, 0, 0, 0]$, to pose B, with $q_B = [1, 1, 1, 1, 1, 1]$. (Each of the numbers may be specified in radian, for example.) Roughly speaking, a path for that robot is a (continuous) vector-valued function $p$. It takes a time parameter $t$ as an input and outputs the configuration on the path at time $t$. So if the above motion takes $5$ seconds, $p(0) = q_A$ and $p(5) = q_B$.

But when one actually communicates with the robot (or rather with the robot controller), one does not tell the robot where it is supposed to be at every single time instant. Instead, one only gives the robot a set of waypoints -- points spread along the path $p$ that the robot needs to pass through. (Those waypoints are generally not too far from one another.) And then the controller then kind of guess what is between two waypoints and tells the robot to move accordingly.

Are there electrical signals involved?

Yes.

How they are initiated and formed and/or interpreted then by the "machine"/robot?

For industrial robots, we communicate with the robot through its controller. I will talk about the robots that we are using. (I think other robots should be more or less similar, though.)

The codes or commands that we want to execute (for example, in C++) are translated and sent to the controller through ethernet as packets. Something like 01 10 00 00 00 00 00 00 00 01 00 00 00 00 00 04 (numbers are in hexadecimal). Then the controller will tell the robot (I mean, the motors) what to do. But for the controller level, I don't know much.

The controller also communicates back to us the same way, i.e., sending packets, for example, when we ask it what the values of the motors are.

Rotot maker(s) make decisions, how to make robot and then they really build it physically. Also decisions about its behavior are made by the way and when all is clear, programming can start.

Programator (human) thinks about all different needed alogorithms and then write the code and compiles it (with some kind of compiler) to form usable by the robot (usually the code is written as program lines on some PC or so, which means electrical signals involved as anything elese done on PC).

Then the (compiled) program is uploaded to robots memory (again electrical signal all the way), which is othen part of the main microcontroler. Anything stored in memory is stored as electrical signals, of course.

When the robot is started, it usually means connecting it to electrical source (batteries), so electricity runs everywhere, where is needed (all logic circuits and a lot of motor, sensors etc.)

The controller (processor) of course runs by the means of electrical signals - simplest way is to send signal ot memory bus and then to control lines to obtain instruction from memory in form of electrical signals. The instruction is then decoded (a lot of circuits using electrical signals to inform each other, what is required to fullfill the instruction). The result is usually to set some variables (so more electrical signals) and/or to change state of some device (motor, servo, sensor), again lot of elecrical signals. If it is case of some motor (to drive robot forward maybe), usually the processor sends electrical signals to motor driver, which decode the signals and direct high electrical currents to the motor accordingly. the motor transfor the electrical current to magnetic field, which then is transformed to mechanical force to rotate the motor. Then usually came some gears and wheels and robot start to move forward.

In meantime the processor sends requests (a lot of electrical signals) to sensors, which process those commands similar way, as processor did with its program - so sending electrical signals between its (sensors) circuits until it is somehow transformed to another kind of energy (light, sound, and such), then the sensor is detecting returned signal by the way of changes in its internal electrical signals (like detecting arriving sound as electrical pulses in microphone and electrically comparing them to requeierd pattern and in case of match electrically computing the distance of obstacle.) Then the sensor sends a lot of electrical signals to processor as a form of message, what was sensed.

The processor by changing its internal electrical signals accordingly runs one instruction after another (requesting them from memory with appropriate electrical signals), until (at the athors intent) some criteria are met and the processor sends another group of electrical signals to motor driver to change speed/direction of motor.

And it goes again and again, until the battery dies or is disconnected. Even waiting contains a lot of electrical signals in processor to measure the time and ensure the waiting is prolonged to required time span or interrupted by other electrical signals as was decided.

So nearly everything in robot are electrical signals in some circuits, except the most final part of communicating with world(like moving, or sensing obstacles). Even communication can be done as sending electrical signals to antenae to use local wifi/xbee/another wireless protocol. Or to LEDs, where the signals are converted to light (which is kind of electrical, or electromagnetical signal itself too).

If you are interested, how are electrical signals treated by the processor, you can read the datasheets of any one. Its hundreds and hundreds pagges, how the electrical signals are used inside to initiate and run the processor. And it is usually covered on high level, so you can then study thousands of book, how exactly are the electrical signals managed by perticular logical gates, which are constructed from transistors, so you can find another thousands of books about transistors, how they treat electrical signals. And it is of course not the end, you can go even deeper and spend thousands life just studying all aspects of electrical signals in single robot on all possible levels. Depends only on you, how much you want to know.

(Not much robots are nowadays run on pure steam and mechanical gears, without any kind of electrical signals involved.)