Sciborgs Part 3

Day 15 (3/15/16)

Our next assignment with the sciborgs was to do essentially the same tasks as before, except instead of using bang- bang control we had to use proportional control. Proportional control uses feedback to figure out how much power to supply to a mechanism based on how far off it is from the goal. We write the power in the form of:

Power = k * error

where k is the gain constant

and error = goal - reality

Task #9

The first task we had to do was to make the sciborg drive even straighter than when we used the bang-bang control. We did this by setting the constant k to 3 and the error to the difference in the positions of both of the motors. Here is what our code looked like:

By using the difference between the positions of the two motors we were able to devise a system so that one motor would speed up or slow down based on the position of the other motor. Unfortunately, we did not have enough time to test this code on different surfaces because it took us too long to devise the code and we needed to move on to the other tasks. I am guessing that the best results would be on the carpet because with the higher friction, the wheels are less likely to slip and so the motor encoder will be more accurate.

Task #10

The next task we worked on (and spent a lot of time on) was making the sciborg go 10 feet exactly and then stop. Once again, we used proportional control to make this happen. Here is what our code looked like:

We devised the original function so the sciborg could get close to the line. The sciborg, however did not make it all the way to the line, so we devised a nudge function to push the sciborg a little bit farther until it reached the line. Changing the gain changes the speed of the sciborg as it gets closer to the target. We determined that a smaller gain will get the sciborg the farthest because it will take longer to slow down.

This assignment gave us lots of problems and issues. We tried many things, and worked many hours just on this task, and we were not able to get it to perform perfectly the way we wanted.

Here is a video for the sciborg moving 10 feet using proportional control:

Task #11

The next task was to use the ultrasonic sensor to allow the sciborg to follow something using proportional control.

This task was a bit easier than the others because we had two different modules from the first two tasks to use. We used the same concepts from task 9 and 10 to control the sciborg using the sensor. This time however, instead of using the motor encoder, we were using the ultrasonic sensor to determine how far away the sciborg was from the target (the delrin board or another sciborg).

Using proportional control is a little more effective then bang-bang control because the speed is related to the distance and the sciborg is constantly taking in to account the distance from the target.

Here is the code we put together for the ultrasonic sensor proportional control:

Here is a video of the sciborg following a delrin board:

And here is a video of a few sciborgs following each other in a row:

Task #12

Our final task was to get the sciborg to follow the path (white strips of tape) using only proportional control. For this task, we were not able to get very far in the execution of this task. We were able to devise our first draft of the code which did not work at all. Here is what the first draft looked like:

If we had more time, I would use a different logic to come up with a proportional equation to make one wheel turn faster or slower than the other depending on the reading from the ultrasonic sensor. The target reading is around 90 for the sciborg following on the line. So, the error  would be 90 - the reading from the sensor. If the value is higher, the error will be negative so the wheel will move slower. If we use this equation for the speed of motor 2, this proportional equation would control the sciborg in the correct direction. If the value is lower, the error will be positive, wheel 2 will move faster and turn the sciborg in the other direction.

Feedback and Control Systems

A feedback and control system is a mechanism that uses a combination of sensing, computation, and actuation.

A sensor is something that measures or detects something. It can measure a digital or analog signal and acts as an input for the mechanism. Computation takes data from the sensor and does something with it. Actuators are things that move (mechanically or electrically), like a piston or a light going on.

For this assignment, we were tasked with identifying and analyzing four feedback and control systems. They are described below.

System #1:

The first feedback and control system I analyzed was the swipe locks on the outside of all of the college buildings. They look like this:

When you swipe your one-card, the door will either unlock or not, depending on your specific access. The sensor of this mechanism receives a signal by reading the magnetic strip on the one card. This is likely a digital signal because it will either open the lock or not. Certain people's one cards will either be coded with access or not for a specific door lock.

The computation piece of this feedback and control system will take the reading from the magnetic strip and either unlock the door or leave the door locked.

The actuators of this system is the lock itself. When the system receives the digital signal for unlock, the lock will open and the green led light will turn on. If the system receives the digital signal for don't unlock, the red led will turn on and the lock will not be opened. When the system receives no signal, the yellow led light will show.

System #2:

The second feedback and control system I analyzed was the water dispenser. These water dispensers are all over the sports center and in the science center. They look like this:

The sensor for this system is a digital sensor. The sensor is either on or off- there is either something in front of sensor and it is turned on, or it is off if there isn't anything in front of the sensor.

The computation part of this system tells the water to turn on when there is an object in front of the sensor or to keep it turned off.

The actuator part of this system turns the water on when it gets the signal for "on"or it leaves the water off when the signal is "off".

System #3:

The third feedback and control system I analyzed was the fire alarm and sprinkler. These are in all of the dorm rooms and they look like this:

The sensor on this system is an analog sensor because it takes readings on the air in a room. It measures the amount of smoke in the room and once it measures a certain amount of smoke the actuator will activate.

The computation part of this system is the system that determines if the sensor is detecting high amounts of smoke or not, and then telling the sprinkler to turn on or stay off.

The actuator part of this system is the sprinkler turning on or off depending on the signal that the sensor is getting.

System #4:

The fourth feedback and control system I analyzed was the motion sensing lights in the observatory. When the lights are on in the "project room," a specific room in the observatory, the lights will turn off automatically after a specific time if no motion is detected. They will also turn back on if they detect motion.

The sensors for this system are quite obviously the motion sensors. These are digital signals-- either they detect motion or they do not. These motion sensors, in this room particularly, are located in the front by the door and in the back.

The computation part of this system is what the system does with the signal. If it detects motion, it tells the lights to turn on, if it doesn't sense motion for a while, it tells the lights to turn off.

The actuator part of this system are the lights turning on or turning off. Depending on the signal and the computation piece, the lights will turn on or turn off.

Sciborgs Part 2

Day 13 (3/8/16)

Today we started to delve deeper to understand the functions and uses of different sensors and feedback and control systems, specifically related to our sciborg (which we recently named Creepy Crawly Jr.). Nanaki and I immediately got to work on our new tasks which are outlined below.


Task 1 - Motor Encoder:

Our first task was to learn about the motor encoder. First we downloaded the code from the class website and adjusted if for our needs. The original program looked like:

The original code depended on the time the program had been running. Since the loop was set up to adjust the "previousMillis" to the new time, the code wouldn't start back at time=0 so the position would be the total position the motor has moved. It wouldn't restart the position each time the loop ran, it would just add the positions each time. We changed the code to no longer depend on the time the program has been running and set the limits of the loop according to the motor position.

We ran tests of different versions of the code using different position limits on the motor to figure out what distance corresponds to the specific value for the motor position. We figured out that the sciborg will move 10 inches with the corresponding motor position of 1,000. We then did a calculation to determine what the motor encoder will read to correspond to 10 feet. This value ended up being about 12,000, so we set the motors to run at full power until the motor position read 12,000 and then stop. Here is what our code looked like:

After running this code several times, we determined that the sciborg was off by kind of a lot (almost a foot). This is likely due to the uncertainties in our measurements for the conversion from motor position to actual distance traveled. Also, every run with the sciborg is different and most don't go completely straight. Here is a video of our sciborg controlled by the motor encoder:

Task 2 - Touch Switch: 

Our next task was to control the sciborg using the touch switch at the front of the robot:

To do this, we downloaded the code given to us on the class website and then included the motors in to the code. It was set up so that if the switch was pushed in, the sciborg would stop and if it wasn't, the sciborg would move ahead at full speed. Here is what the code looked like:

We figured out that we could put a barrier 10 feet from the starting position and the sciborg would travel at full speed until it hit the barrier and would stop at 10ft.

Here's how the switch worked:

Task 3 - Light Sensor:

Our third task was to learn how to use the light sensor and figure out a way to make the sciborg move 10 feet using the sensor as the feedback in the feedback and control system.

First we once again downloaded the code and tested it out to see what it did. Before we included the motors in the code we did tests to determine how accurate the sensor is. The range of the scaled value of the sensor was from 0 to 98. We determined that the light sensor would be accurate enough that it could be of use to us for later tasks when it is a few centimeters from the ground.

One extra function that the light sensor had was a guide LED light. You could turn the LED on or off and this would change how the light sensor worked and measured its values. After testing the differences in values between the white tape and the brown board we determined that the light sensor was more accurate with the LED turned off. 

Here is what the code looked like for the light sensor:

To make our sciborg go the 10m and then stop using the light sensor, we determined that we could lay down a piece of tape 10m from where the sciborg started and set it up that the sciborg would run at full speed when the sensor was reading the values that correspond to the dark ground and once the sensor detected the smaller number of the white tape, the motors would stop.

Task 4 - Ultrasonic Sensor:

Our next task was to learn how the ultrasonic sensor. First we downloaded the code and set it up with the motors. We then ran tests to determine how accurate the sonar is and what distance the readings correspond to. We determined that with a sonic reading of 3, the sciborg will be about 10in from the barrier. Also we determined that the sensor was accurate with about an inch of error.

Here is our resulting code to control the motors:

We set up a barrier 10ft 10in from the starting point of the sciborg and set the motors to run until the sensor read a value of 3 and then turn the motors off. Here is how it worked:

Task 5 - Drive straight:

To accomplish this, Nanaki and I used the motor encoder code. What we did is when the position of the motor on the left was less than the position of the motor on the right, we would turn up the power of the left motor and turn down the right motor. This way, the sciborg would correct for the difference in motor position by turning. Here is what our code looked like:

And here is how the code worked:

Difficulties we faced:

Throughout this phase of the project, we faced many challenges. First off, the sensors are not completely accurate, so there will always be a margin of error when using sensors. Also, the sciborg doesn't travel the same during each run.

One of the biggest things we struggled with was the ball bearing catching on the ground and messing up the positioning and the timing of the sciborg. To fix this we removed the ball bearing and lubricated it to make it run smoother:

After all of these tasks, we came up with some good ideas to have the sciborg follow a path. I will discuss these ideas further in my next blog post.

Sciborgs Part 1

Day 12 (3/4/16)

Today we started out talking about robots and types of feedback and control.

Robots are not actually specifically defined, but they are mechanical devices that serves a purpose or purposes. The specific kind of robot we will be using for this project are called sciborgs. Sciborgs are robots made from lego pieces and motors and ours are controlled by an Arduino with a Bricktronics Shield. Ours looks like this:

Besides talking about robots and sciborgs, we also talked about different kinds of feedback and control. Feedback and control systems use a combination of sensing (measuring something), computation (taking the data and doing something), and actuation (something mechanical that moves). There are open loops that try to accomplish tasks but do not confirm or deny its completion, there are bang bang loops that either turn something on or off, and there are proportional integral derivative loops (PID) that have complicated feedback and control. Some examples of feedback and control systems are thermostats, automatic doors, and cars. Our sciborg will eventually become a feedback and control system that will be controlled by the Arduino.

After talking about sciborgs, Nanaki and I started practicing making functions in our code. The point of functions are so that you don't have to write the code directly each time. You can set up your code so that you only have to write it once and you can call the function elsewhere in your code to perform its task. We practiced with the LED and dot and dash functions to represent morse code. Here is what our functions looked like:

After we got comfortable using functions in the Arduino, we set up our sciborg by attaching the Arduino and Bricktronics Shield and plugging in the cables.

The first task we had to do with our sciborg was to make a single motor run. All we had to do was download the "single motor" example, learn what it did and run it. This part was simple. The motor was turned on at high power, then low power, then high power reverse and finally low power reverse and just repeated that pattern.

Task 1:

The trickier task was getting both motors to run at the same time. We ran in to issues with this portion. At first we thought that our code was wrong, but what I realized eventually was that the Bricktronics shield was not completely plugged in to the Arduino, so the connection was bad and the sciborg was not doing the tasks we wanted it to do. Ultimately, our original idea for the code was correct and we were able to get both motors moving. Here is what the code looked like:

And here is what the sciborg did as a result:

Task 2:

After we were able to get both motors moving at the same time and at the same speed, we were tasked with figuring out what the minimum speed was that allowed our sciborg to move. To do this, we used the "Both_Motors" code with just one section of the fixed drive commands for both motors. We used trial and error and plugged in different numbers until we got our results. It turns out that when you are holding the sciborg, the motors will spin the wheels (just barely) when the speed is set to 47. When the sciborg is on the table, it will move at a minimum speed of 66.

Task 3:

The next task was to have the sciborg make a sharp turn. This was done by setting one of the motors at full speed forward and the other motor full speed backwards. This causes the sciborg to turn around very tightly. Our code for this was essentially the same as our code for both motors with just the one section like we used to find the minimum speeds. This time, however, the speeds of each motor were different. Here is what the code looked like:

Here is what the sciborg did as a result of uploading this code to the Arduino:

Task 4: 

Our next task was to make the Arduino turn more gently. This time instead of setting both motors as complete opposites, we decided to set one motor to full power forward and one motor to medium power forward. Here is what our code looked like. As you can see it is almost identical to the code for the sharp turn:

Here is how our sciborg reacted with the specified directions:

Task 5:

Our final task was to see how long it took our sciborg to move 10 feet. We laid down two pieces of tape on the lab-room floor that were ten feet apart, set both motors to full power with no delay and timed it. Our sciborg took about 12 seconds to cross from one piece of tape to the other.

Our next job was then to program the sciborg to move at full speed for just 12 seconds and then stop. Here is what the code looked like for that:

Here is how the code worked when used by the sciborg:

Ultimately, the sciborg did not make it all the way to the tape in the 12 seconds that we thought it should. This is likely due to several reasons. First, when we timed the sciborg going from one piece of tape to the other, it is most likely that it did not take 12 seconds exactly. There is human inaccuracy when timing objects. Also, the sciborg did not travel in a straight line, and sometimes the motors would almost seem to catch. Each run was different, so there could be an error of +- 2 seconds for the time it takes the sciborg to make it 10 feet. There is no way we could make the sciborg stop exactly on the line when just using a time dependence (maybe using sensors?).

Arduino Introduction Part 2

Day 11 (3/1/16)

Today we continued to learn how to use Arduinos. We worked on a few more programming challenges that are shown in detail below:

Challenge #1: "Use the photocell to change something about the LED"

For our first challenge, we decided to change the speed of blinking based on the photocell. We set it up so that the Arduino would receive a certain numerical representation of the brightness of light and depending on the value, the LED would flash slower, faster, turn on completely, or turn off completely.

For our code, we took ideas from our previous programming challenges and combined those ideas. Here is what our code looked like:

Here is what our circuit looked like with the photocell and the LED set up:

Here is a video showing the change of flashing depending on the incident light:

Challenge #2: "Use the tiny tactile switch to turn the LED on and off"

Here is what the code looked like to control the LED light with a switch:

Here is what our resulting Arduino and circuit board looked like. There were simple connections between the switch, the LED, and the rest of the circuit:

Here is a video of the resulting function of the button:

Challenge #3: "Use sweep and knob to control your servo"

Sweep:

First I downloaded the code for the sweep function and figured out that the Servo needed to be connected to pin 9. The code told the servo to sweep between 0 and 180 degrees. Here is what the code looked like:

A tricky thing with the circuit is that the yellow wire on the servo needs to be connected to the appropriate pin number, the red wire on the servo needs to be connected to the power source, and the black wire on the servo needs to connect to the ground. Here is what the circuit looked like:

If we wanted to change the range of motion from 60 to 120 degrees, we would have to change line 15, 22 and 27 where it says 0 to 60. We would change lines 22 and 27 where it says 180 to 120. Here is a video of the servo sweeping out the angles:

Knob

The knob function uses the potentiometer and the servo to adjust the angle of the servo based on the position of the potentiometer. The initial code is set up so that the servo sweeps between 0 and 180 degrees:

To change the range of angles that the servo sweeps, you have to change line 23 from (val, 0, 1023, 0, 180) to (val, 0, 1023, 60, 120) and then the servo will move from 60 degrees to 120.

Here is a picture of the resulting circuit. Again, here it was important to make sure all of the connections were being made in the correct place:

Finally, here is a video of the potentiometer controlling the angle of the servo:

Arduino Introduction Part 1

Day 10 (2/26/16)

Today we were introduced to Arduinos. Arduinos are very cool micro-controllers that can be used for many different functions. They have many different components and they look like this:

After we set up the Arduino and downloaded the software on the the computer, we then had to complete several mini-challenges to learn how the Arduinos work and to learn the structure of the code. Luckily for me, I have prior experience coding, so I understand the thought process and the progression through the code. That experience helped me to understand where the code needed adjusting to accomplish a specific task. I also have experience using breadboards and putting together circuits, so that came in handy as well. The mini-challenges are documented below:

Challenge #1 "Blink with delay of 10"

Our first challenge involved only the Arduino, an LED light and the computer. We were tasked with programing the LED to blink with a "delay of 10" which in the code means 10 milliseconds. We accomplished this by opening up a preprogrammed sketch and then just adjusting one parameter, the delay. Our code looked like this:

Lines 26 and 28 are where we specify the delay time. For this situation, we changed the delay time to 10 milliseconds inside the parentheses. When you run this code, the light appears to be on continuously. Don't let that fool you though, it is really flashing in pulses of 10 milliseconds but that speed is not visible to the human eye.

Challenge #2 "Pattern with at least 3 LEDs of different colors using the delay() function"

Our next task was to adjust our code and set up our circuits to command three different color LED lights to turn on in a cool pattern. To do this Meba and I just copied and pasted the sections of our code for each individual LED light. We then renamed the pin to the corresponding pin number for each LED. Since the information was coded in a loop, the process would go through all of the individual blocks of code for each light and created a pattern of changing lights. Here is what our resulting code looked like:

In this code we initialize digital pins 11, 12, and 13 and then we run the loop with all three LED functions that specify different delay times for each. We played around a lot with the different delay times for each LED light and here is a video of one of our favorite patterns:

Challenge #3 "Use potentiometer to change the LED behavior based on the resistance"

For the third challenge, we had to set up the circuit so that the potentiometer would control some function of the LED light. We designed our code and our circuit to change blinking speeds based on the resistance of the potentiometer. In order to do this, we had to first define position of the two components, the potentiometer (Pin_pot) and the LED (Pin_LED). The potentiometer was connected to A0 so we defined the integer Pin_pot as A0 and the LED was connected to pin 12 so we defined the integer Pin_LED as 12. We then defined the potentiometer value to be an integer (Pot_Value). Next we went in to the setup function to initialize the program and defined the LED to be an output. Finally in our loop we set the integer Pot_Value to the analog value received by the Arduino from the potentiometer. This value will depend on the position of the potentiometer. Finally we added the code to make the LED turn on and off. Our resulting code looked like this:

We set up our circuit so that the LED was connected to pin 12 and the potentiometer was connected to pin A0, the power and ground. Our resulting circuit looked like this (ignore the other two LEDs connected, we did not set them up in our code so they wont do anything):

And here is a video of the speed of the flashing of the LED changing depending on the position of the potentiometer:

Challenge #4 "Pattern with 3 LEDs of different colors that does not use the delay() function"

Our fourth and final challenge was to create a pattern of three different LED lights that does not use the delay function as we did previously in challenge #2. This way, we could make a pattern where the program does not have to do only one function at a time. With this new function we can tell the program to turn on multiple lights at the same time or do different functions simultaneously.

For this new pattern, we set up the code so that the red and blue light would turn on when the green light turned off and vice versa. Here is what our code looked like:

The final pattern of the LED lights looked like this:

Overall, I have really enjoyed learning how to use the Arduino and learning the language. I think coding is a lot of fun and I am very excited to see what incredible things can be accomplished with the Arduino. It is such a useful tool that we, as students, are very lucky to have access to.