SciBorg Work

Part 1: Making Functions

A function allows programmers to use code without having to rewrite the code

In Figure 1.0, the function of each command has been listed on each line of code.

The above-shown program was used to make a LED flash the Morse code for SOS (dot dot dot dash dash dash dot dot dot). The main aim of this program was to understand the ways in which a program function works. Writing a code directly and making sure a given command occurs continuously can be quite repetitive. The use of a function prevents a user from having to rewrite the code and thus increases programming efficiently. Furthermore, a function can help make one’s code more readable and more easily understood. The main principle of a programming function was used in all parts of the SciBorg tasks.

Part 3: Working with your SciBorg

In Figure 2.0, the function of each command has been listed on each line of code.

The above shown “Single Motor” program only operates one motor of the Sciborg. Therefore, only one pair of front and back wheels is in operation. This causes the SciBorg to move in a circulatory manner as shown in the video below.

Essentially, this “Single Motor” program causes the cart to move forward at a speed of 75 for one second followed by a speed of 255 for one second. Therefore, when the speeds are compared to one another, the cart moves forward slowly then fast.

Following the forward driving commands, the cart is made to move backwards at a speed of -75 (the negative sign denotes the backwards direction in which the cart moves) for one second and then -255 for another second. Similar to the forward driving commands, the cart moves backwards slowly and then fast. Overall, the identical commands and movement of the SciBorg backwards negates its forward commands, bringing the SciBorg back to its initial position.

Using the serial monitor we were able to analyze the movements of the Sciborg to better understand the commands of the program. At first, however, we had issues reading the serial monitor, as the serial console was not set to 115200 baud. Once properly set, we were able to easily track the Sciborg’s movements— a valuable lesson learned.

Running Both Motors:

Next step of the process was to get both motors to operate in order to allow the sciborg to move forward. Hence, we manipulated the single motor code as shown below.

In Figure 3.0, the function of each command has been listed on each line of code.

In order to get both motors to operate, motor 2 had to be defined within the program. Therefore, as shown through the highlighted red boxes, we added identical motor 1 commands now defined for motor 2.

This program allows our sciborg to operate at a minimum speed of 75 units and a maximum speed of 255 units. However, we noticed that although the motors were defined to operate at the same speeds within the program, they did not function at the same rate when the sciborg was allow the move on the floor. Uncontrollable variables will be contributing towards the varying motor speeds. This brought up concerns of real world operation versus theoretical concepts.

In a perfect world, theory would be synonymous with that of real world functionality, however the introduction of energy losses through factors such as friction can cause improper performances. Thus, when approaching projects from an engineering perspective one must account for non ideal conditions in the real world.

Making a hard turn versus gentle turn:

In Figure 4.0, the function of each command has been listed on each line of code.

When approaching this problem we chose to think of how a car moves when turning and the various commands enacted by the driver. A hard turn would be to turn at a 90-degree angle. To get the sciborg to do this, both motors would have to initially travel straight and then divert commands. One motor would have to be programmed to continue travelling straight, while the other would have to “reverse” (change direction of wheel rotation).

Shown through the blue highlighted boxes above, both motors would start by travelling straight for a fixed period of time. Following this interval, motor 1 would reverse at a rate of -255 while motor 2 continues operating at positive speed of 255 (highlighted by the red boxes above). These commands would last for the same amount of time to allow the car to turn.

Following the hard turn, we attempted to make our sciborg make a gentler turn (i.e. a turn at a larger angle). Having successfully accomplished a hard turn, creating this function was relatively easier. Through simply reducing the rate of motor 1 (highlighted in red), still allowing it to travel in a positive direction, the sciborg is able to make a gentler turn.

Such a set up allows motor 2’s faster rate of forward motion to drive the sciborg sideways, allowing it to make a gentler turn over time. The reduced rate of motor 1 enables the sciborg to continue moving forward while it turns, unlike in the previous program.

Travelling 10 feet:

Part of our next challenge was to get our sciborg to drive 10 feet and then stop. To express this command we used the delay function of the program.

It took our sciborg around 18 seconds, at a speed of 255, to drive 10 feet. Hence, using the delay function, we had our sciborg drive for 18 seconds at a speed of 255 and then stop of 18 seconds.

Figure 5.0, delineates the function of each command within the program.

Part 4: Feedback with Sensors

Feedback and control is the ability of a mechanism to sense changes in their environment and accordingly make changes in their operation. Most feedback and control machines consist of a sensing, computation and actuation mechanism.

Standard example codes were run for the MotorEncoder and LightSensorNXT programs.

Motor encoder:

Why doesn’t the motor position go back to zero if it goes forward for 1 sec and back for another? When “asked” to stop by the program, the wheels have momentum and therefore have to travel additional length ‘x’ to slow down. Therefore when they travel backwards at the same rate, the car doesn’t come back to its original position of 0.

If you let the motors run for a while, how much do they vary if at all? Maximum 73, minimum 1, average 50. Variation of position is non linear. Therefore the car comes close to its original position of 0, but never reaches it.

Light Sensor:

What range do you see? (In terms of scaled values) Red= 75, yellow= 95, black= 0, white= 93, brown cardboard= 60

Does turning in the LED light hep or hurt your sensitivity? (In terms of scaled values) Black = 0, White= 93, Red= 47, yellow= 96, brown cardboard= 0. Hence, turning on the LED decrease the sensitivity.

What distance from the surface works best? The closer the light sensor is to the surface the better its sensitivity.

Part 5: Drive Straight

This challenge made use of bang- bang control, an example of close loop control. Bang-bang control makes use of the all or nothing principle. It is a type of feedback control that alternates between on and off.

As can be seen through the program above, we chose a fixed driving speed of 230. Motor 1 was set to drive at this speed and motor 2’s speed was allowed to alternate depending on motor 1’s speed.

Ideally, motor 1’s speed should be constant, however when considering the frication of various surfaces and other real world problems, the rate of motor 1 will vary over time. Hence, using an ‘if’ command, when the speed of motor 1 is higher than that of motor 2, motor 2’s speed was programmed to function at 250 as to catch up to motor 1’s speed. Similarly, when the speed of motor 2 is higher than that of motor 1, motor 2’s speed was programmed to function at 230 as to slow down to motor 1’s actual speed. However, if motor 1 was travelling at a constant speed of 230, then motor 2 was programmed to travel at 230.

Through these series of command, each action of motor 2 would match that of motor 1 to ensure that both motors travel at the same rate. In theory, if both motor travel at the same rate the sciborg should drive relatively straight.

On a surface of high friction, the sciborg did not perform too well. Its motion was jerky and snake like. Such control would be non ideal to implements in a device for daily use. Under such control, the sciborg only performed best with low friction surfaces.

Part 6: Drive Straighter

This challenge required the use proportional control, another example of closed loop control. Proportional control takes into consideration the errors of a mechanism. The error is calculated by the difference between the target output value and the present state value. The ideal output value is reached using the following equation, where Kp represents the proportional gain coefficient: desired output value ± (Kp x error)

The programmer sets the proportional gain coefficient Kp. Too big a coefficient and one might overshoot the desired output, and visa versa.

In our model, we decided to vary motor 2’s speed and set a Kp value of 1. A speed output value of 230 was set for motor 1. Using an ‘if’ statement we programmed the following commands: if the error (the difference between speeds between motor and the other) is larger than 0, then motor 2 will drive at a rate denoted by 230 + (Kp x error). Similarly, if the error was below 0 then motor 2 will drive at a rate denoted by 230 – (Kp x error). However, if the error is 0, then motor 2 will drive at 230.

Proportional control allows the sciborg to drive straighter as it is able to account for a larger range of error values. Therefore, when tested on various surfaces and across different conditions our sciborg was able to travel more straight than it did under bang bang control. When compared to bang bang control, the sciborg was able to perform far better on high friction surfaces under proportional control. Although, it didn’t travel completely straight, it was able to maintain a smooth motion and transition between motor speeds.

Part 8: Line Follow (Bang-Bang Control)

The following challenge had us take advantage of the Light Sensor to make the Sciborg follow a white line.

We used the MotorEncoder program as a scaffold and primarily edited the “void loop” function to ask the SciBorg to include and act upon the light sensor readings. The light sensor reading for white is valued at 93; therefore in the “if” statement, we programmed the Sciborg to drive straight provided the light sensor readings were 93. If and when the light readings are not 93, we programmed the SciBorg to turn counterclockwise until a light reading value of 93 was achieved.

Upon evaluating the Sciborg’s performance, it followed the white line relatively well. However, using bang- bang control to do so was not the most productive method, leading to staggered and interrupted motion. Hence, in the following challenge we integrated proportional control in the MotorEncoder program to allow the SciBorg to follow the white line more smoothly.

Part 9: Line Follow (Proportional Control)

To achieve proportional line follow control, we one again manipulated the void loop. We created integers for the light sensor, set a ‘kp’ value of 1, and calculated the error by the difference between 93 (light sensor scaled value for white) and the measured light value. Similar to the Part 6: Drive Straighter program, we used an ‘if’ statement to program the following commands: if the error is larger than 0, then motor 2 will drive at a rate of 230 + (Kp x error). However, if the error was below 0 then motor 2 will drive at a rate of 230 – (Kp x error). If the error is 0, then motor 2 will drive at 230.

 

Overall, I enjoyed learning more about the ways in which SciBorgs function and the contexts in which bang- bang and proportional control is most appropriate. I found working with the various sensors challenging, but enjoyable, as I was able to get a better grasp of the C++ language. I look forward to integrating the knowledge gained from the series of SciBorg exercises in my final project.