Part 1: the Control

This instructable is one part of a larger build. Please ensure you start at HDL Motor Speed Control, so you understand where the following fits in within the larger project.

Motor speed and direction control is one of the two main divisions in the photodetector robot, the other one is the photodetector or light detector division. While the photodetector division focuses on the robot's vision, the motor speed and direction control division focuses on the robot's movement. The motor speed and direction control processes data given from the photodetector division and gives a physical output in the form of motor movement.

Motor control is one of the blocks inside the motor speed and direction control division. Motor control is the brain the processes the input data from the photodetector division and then decides on how the robot should move.

This part will give a detailed information about the control block in the motor speed and direction control division of the photodetector robot.

This project uses VHDL language and is implemented on an FPGA board.

The control block in the motor speed and direction control division is, as the name suggests, the “brain” block, the control block of the division. The control block will be the first block in the division which receives information, which is the output of the light source detector division, process it, and decide on the robot’s speed and direction.

Although the control block played an important role as the “brain” of the division, the control block still couldn’t stand alone, since the motor’s speed and direction signal are still raw and need to be further processed before they are relayed to the PWM generator that generates the signal for the motor to start working physically.

Since the robot uses two motors. The control block generates speed and direction for both motors independently. So, there are two outputs regarding speed and direction coming from the control block, right motor goal speed and direction and left motor goal speed and direction (the goal speed and direction is in one output signal).

The control block also works together with the counter block, responsible for the movement delay procedure of the robot. The counter block will give a signal "Rotate" to indicate when the control block should stop the robot (giving 0 output) or rotate the robot.

The control block’s principle is similar to that of an RC controller. If you are familiar, an RC controller has two analogue inputs, one to make the device move forward and backward, and one to make the device turn left or right. When moving forward and backward, we want the same speed applied to both sides motors so the device will move in a straight line. When turning, we either want the front wheels to turn or to apply different speed on both sides’ motors. If we want to turn left, then the right motor speed should be faster than the left motor and if we want to turn right, then the left motor speed should be faster than the right motor.

Now our goal in the photodetector robot is to have the robot seeks or follows a light source. The control block will make it so that the robot will move forward when a light source is present but is too far from the robot, to move while turning when the light source is present but is not exactly in the center of the robot’s vision, to move backward when the robot is too near to the light source, and to rotate if the light source is in the robot’s blind spot (which means it can’t be detected at that time).

The picture above shows the full internal block diagram of the control block. The control block consists of 5 port signals (2 input, 3 output) and 6 internal signals.

Port Signals:

Input:

1. Position

2. Size

3. Ctrl_en (control block trigger from light source detector division)

4. Rotate (control block trigger from movement delay procedure)

Output:

1. Goal_Left (goal speed and direction left motor)

2. Goal_right (goal speed and direction of right motor)

Internal Signals:

1. A (integrated with input position)

2. B (integrated with input size)

3. TGL (temporary goal left, before limiter)

4. TGR (temporary goal right, before limiter)

5. TTGL (true temporary goal left, after limiter, integrated with goal_left)

6. TTGR (true temporary goal right, after limiter, integrated with goal_right)

Above is the truth/lookup table for the control block. In the control block there are five combinational function that requires a truth table, speed limiter and goal speed decision for both left and right motors and one for the light signal.

The control block’s internal block consists of five parts representing a function. Four of them represent function relevant for the goal speed and direction output, and one function relevant for the counter block. The block can be divided as shown above

The role of block 1 is to pinpoint the location of the centre point of the light source in the camera and the width of the lights source in one frame of the camera. Let’s start from the inputs, the input “position” from the light source detector division shows the position of the centre point of the light source in the camera.

We use a 640x480 pixel camera, assume that we calculate the pixel for each frame in an ascending order (0, 1, …, 636, 640), if the input “position” is, for example, 640, it means that the centre point of the light source is on the rightmost edge of the camera. If the input “position” is 0, it means that the centre point of the light source is on the leftmost edge of the camera. And if the input “position” is 320, means that the centre point of the light source is exactly at the middle of the camera.

In block 1, as shown in the picture above, the input “position” enters the upper block, connected to port “a” and gives output a-320. The number 320 represents the centre point of the camera as explained before. The process here is a subtraction so that we know in which side of the camera the centre point of the light source is. If the input “position” is 640 (supposed right side), 640-320 = 320. If the input “position” is 0 (supposed left side), 0-320 = -320. And if the input “position” is 320 (supposed middle), 320-320 = 0.

From these three calculations we can conclude that if the subtraction result is positive, it means that the centre point of the light source is on the right side of the camera. If the subtraction result is negative, it means that the centre point of the light source is on the left side of the camera. And if the subtraction result is 0, it means that the centre point of the light source is in the middle of the camera.

Using the control block, we want to make the robot turns until the centre point of the light source is in the middle of the camera.

Next is the input “size”. The process for the input “size” is similar to that of the input “position”. The difference is in size, we don’t care about the numbering order of the pixels in the frame. The input “size” simply informs that in a frame of 640 pixels, how many pixels are occupied by the light source. If the input “size” is 640, it means that the light source has filled the whole frame and might also means that the robot is too close to the light source. If the input “size” is 320, it means that half of the frame is occupied by the light source. And if the input “size” is 0, it means that no light source is present in the frame at that time.

As shown in the picture above, the input “size” enters the lower block, connected to port “b” and gives output 320-b. the number 320 represents the thresholding (maximum size) the light source can occupy the frame before the robot stops moving forward. It is a free variable and can be changed with any number we want.

The reason behind the processing of the input “size” is what we call perspective. We have all experienced that when we stand far from an object and start moving closer to it, we feel like the object is getting bigger and bigger, but actually, the object’s size doesn’t change at all. The same concept is applied to the robot’s vision.

Imagine if our eye is a frame of 640 pixels that is seeing a light source. When we are standing far from the light source, it might feel like the light source is only 1 pixel out of the 640 pixels of our eye. As we move closer to the light source (assume that the light source size doesn’t change), we feel like the light source is getting bigger, the light source’s pixel increases.

The process here is a subtraction so that we can determine whether the robot is too far, just enough, or too close to the light source. For example, if we set the size threshold to 320, if the input “size” is 640 (supposed too close), 320-640 = -320. If the input “size” is 320 (supposed just enough), 320-320 = 0. And if the input “size” is 1 (supposed too far), 320-1 = 329.

From these three calculations we can conclude that if the subtraction result is positive, it means that the robot is still too far from the light source and has to move forward, closer to the light source. If the subtraction result is negative, it means that the robot is too close to the light source and has to move backward, away from the light source. And if the subtraction result is 0, the robot has reached the threshold point and should stop moving. A special case is if the input “size” is 0 or there is no light source present, the robot should rotate in place, looking for a light source until it found one.

Using the control block, we want to make the robot moves until the light source size is equal to the threshold size we set.

The role of block 2 is to generate a temporary goal speed and direction for both left and right motors, represented by TGL for left motor and TGR for right motor. The input to block 2 is the output from block 1. The output from “position” or A-320 is connected to port “P”, so let’s just call it P, and the output from “size” or threshold value-B is connected to port “Z”, so let’s just call it Z.

The value of both TGL and TGR are result from processing “P” and “Z”. The process for both inputs is actually very simple, as you can already see from the block diagram above. After doing calculations, the value of TGL should be the result of Z+P and the value of TGR should be the result of Z-P. The formula is fixed for both motors and can’t be switched.

The formula satisfied the initial goal to turn the robot until the centre point of the light source is right in the middle of the camera and moving the robot forward or backward until it satisfies the threshold condition. Both movements, moving forward or backward an turning left or right, are performed at the same time, that’s why the two inputs are included in a single process. They are made so that the robot will stop moving once both conditions (size and position) are satisfied and will still move otherwise.

The role of block 3 is as the overflow prevention. This block works to solve the overflow problem coming from block 2. The process is quite simple. If the output from block 2 is an overflow of positive number (>511) , block 3 will give an output of 511, the highest positive value for a signed 10-bit data and if the output from block 2 is an overflow of negative number (<-511), block 3 will give an output of -511, the lowest negative value for a signed 10-bit data.

An unsigned 10-bit data has a maximum value of 1023. When turned into signed, the value ranges from -512 to 511, but for the overflow prevention I use -511 as the minimum value because the robot's motors can only read value up to 255. Later on in the coding explanation, I will explain the relationship between these two.

The overflow prevention was made one for each motor, so there are 2 overflow preventions left motor overflow prevention and right motor overflow prevention. We have to make one for each because both motors have different process at block 2 so the overflow criteria on both motors are different.

The role of block 4 is a selector which decides the final “goal speed” output for each motor based on the condition from block 5. The selector was made one for each motor so there will be two outputs, left motor goal speed and right motor goal speed. The only input to block 4 are only from their respective overflow prevention.

The role of block 5 is a combinational circuit that generates the output “light’ and as a condition for the selector block (block 4). Block 5 has 3 inputs: “Size”, “CTRL_EN”, and “ROTATE".

library IEEE;

use IEEE.STD_LOGIC_1164.ALL;

use IEEE.NUMERIC_STD.ALL;

use IEEE.STD_LOGIC_SIGNED.all;

entity Ctrl is

Port ( POSITION : in STD_LOGIC_VECTOR (9 downto 0);

SIZE : in STD_LOGIC_VECTOR (9 downto 0);

ROTATE : in STD_LOGIC;

CTRL_EN : in STD_LOGIC;

GOAL_LEFT : out STD_LOGIC_VECTOR (8 downto 0);

GOAL_RIGHT : out STD_LOGIC_VECTOR (8 downto 0)

);

end Ctrl;

architecture Control of Ctrl is

signal a, b: STD_LOGIC_VECTOR (9 downto 0);

signal TGL, TGR: STD_LOGIC_VECTOR (9 downto 0);

signal TTGL, TTGR: STD_LOGIC_VECTOR (9 downto 0);

begin

a <= POSITION - "0101000000"; --posisi - 320 (posisi tengah)

b <= "0101011110" - SIZE; --350 (threshold size) - size pada saat itu

TGR <= b - a;

TGL <= b + a;

process(a, b, TGR) --mencegah overflow goal right

begin

if (a(9) = '0' and b(9) = '1' and TGR(9) = '0') then

TTGR <= "1000000011"; --mentok ke -511

elsif (a(9) = '1' and b(9) = '0' and TGR(9) = '1') then

TTGR <= "0111111111"; --mentok ke 511

else

TTGR <= TGR; --kalo bener, langsung

end if;

end process;

process(a, b, TGL) --mencegah overflow goal left

begin

if (a(9) = '1' and b(9) = '1' and TGL(9) = '0') then

TTGL <= "1000000011"; --mentok ke -511

elsif (a(9) = '0' and b(9) = '0' and TGL(9) = '1') then

TTGL <= "0111111111"; --mentok ke 511

else

TTGL <= TGL; --kalo bener, langsung

end if;

end process;

process(SIZE, CTRL_EN, ROTATE, TTGL, TTGR) --selector goal speed

begin

if ((ROTATE = '0' AND SIZE < "0001100100") OR CTRL_EN = '0') then

GOAL_LEFT <= (others => '0');

GOAL_RIGHT <= (others => '0');

elsif (ROTATE = '1' AND CTRL_EN = '1' AND SIZE < "0001100100") then

GOAL_LEFT <= "001100100";

GOAL_RIGHT <= "110011100";

--elsif SIZE > "0000000000" then

else

GOAL_LEFT <= TTGL(9 downto 1);

GOAL_RIGHT <= TTGR(9 downto 1);

end if;

end process;

end Control;

This is the coding for the processes in block 1 as explained in block 1 above. a = position – 320 to find the middle point of the light and b = threshold – size to measure the size of the light source in the robot’s vision.

While the input size and position are in unsigned value, starting from this block, we are already calculating and giving outputs in signed value. The end goal of the control block is to determine the motor's movement. Using signed value, which has negative and positive value, makes it easier to determine the direction of the motor. If positive means clockwise, then negative means counterclockwise, and vice versa.

This is the coding for the processes in block 2 as explained in block 2 above. TGL and TGR are both temporary goal speed for the left motor and right motor, where TGR = b – a and TGL = b + a.

This is the coding for right motor speed limiter. The inputs to the right speed motor limiter are “a”, “b”, and “TGR”. According to prior calculations done, there are 2 conditions when the output “TGR” will be an overflow; when a(9) = 0, b(9) = 1 and TGR(9) = 0, it is a negative overflow (<-511) and when a(9) = 1, b(9) = 0 and TGR(9) = 1, it is a positive overflow (>511).

When TGR is negative overflow, the speed limiter will give output TTGR = -511. When TGR is positive overflow, the speed limiter will give output TTGR = 511. When TGR is not overflow, the speed limiter will give output TTGR = TGR.

This is the coding for left motor speed limiter. The inputs to the left speed motor limiter are “a”, “b”, and “TGL”. According to prior calculations done, there are 2 conditions when the output “TGL” will be an overflow; when a(9) = 1, b(9) = 1 and TGL(9) = 0, it is a negative overflow (<-511) and when a(9) = 0, b(9) = 0 and TGL(9) = 1, it is a positive overflow (>511).

When TGR is negative overflow, the speed limiter will give output TTGR = -511. When TGR is positive overflow, the speed limiter will give output TTGR = 511. When TGR is not overflow, the speed limiter will give output TTGR = TGR.

This is the coding for the combinational and selector. Selector will decide on the value of the goal speed for each left and right motor based on the conditions from the combinational block. These two block processes are based on the truth table given above, selector goal speed truth table (simple)

From there we can
see that there are 4 conditions that will result on 3 different outputs. The first one is when Rotate = 0 and size = 0, then no matter what the Ctrl_en is, the output goal speed for both motors will be 0 and the motors will stop rotating. The second one is when Rotate = 0, the no matter what the Rotate and size is, the output goal speed for motors will also be 0 and the motors will stop rotating.

The third one is when Ctrl_en = 1 and Rotate = 1 and size = 0, which indicates that there is no light source present in the robot’s vision, then the robot should rotate in place. For this to happen, the goal speed for the left motor and right motor should be of the same value, but in the opposite direction. In the coding, I give the value -511 for the left motor and 511 for the right motor.

Last one is when size = 1, or actually, when size > 0 which indicates that there is light source present in the robot’s vision, then the goal speed for each motor should be the output from their respective speed limiter. In this way, we won’t have to worry anymore about the overflow problem because it has been solved by the speed limiter.

Earlier in the block 3 explanation, I mentioned that the minimum value I used for the goal speed is -511 because the robot's motor can only read up to 255. If you see in the coding above, the goal speed for both motors are in a 9-bit signed data. In that 9-bit signed data, the 9th bit, or the most significant bit, determines the direction of the motor rotation and the rest 8-bit determines the motor speed.

The 10-bit signed data of value -511, when we take the last 9-bits and convert it into unsigned data would give a value of 255. but a 10-bit signed data of value -512, when we take the last 9-bits and convert it into unsigned data would give a value of 256 which is unreadable by the motor. That's why for the minimum value, I use the value -511 so that the unsigned value is still readable by the motor.

This is the end for the control block explanation. Control block is just one part of the motor speed and direction division. Being the first block in the division, we still have to further process the data such as to convert the data from the control block to be readable by the motor, making the motor move and making error adjustments.

To read the full details on the project, you can go to the link below. There are also explanation for the other parts in the motor speed and direction division.

Thank you so much for reading the explanation for the control block, I hope you can now understand better about the control block and how it works, and best of luck if you do try to make this project!

https://www.instructables.com/VHDL-Motor-Speed-Con...