1. A lamp that turns brighter if it's brighter in the room or darker if it's darker
2. Robot that stays within a box and avoids touching anything
3. A clock that works through several gear chains
4. Mini-fridge
5. Recreate a primitive form of the Google Car
6. Light that turns off if there's no movement for a while
7. Robot that goes to retrieve something and toss it into the air
8. Surveillance robot that takes video footage but stops moving when it senses something moving
9. A handhold device that vibrates or chirps when the user shows it the end of a line in a book
10. A mini elevator
I would be most interested in visiting the ComputerPlace, Innovative Engineers, Math Moves, and Nanotechnology exhibits. If there is additional time, I will visit the To the Moon, Conserve @ Home, and Catching the Wind exhibits. By visiting these exhibits, I hope to find more inspiration for my final project in addition to understanding how the museum chooses to convey these concepts. Breaking down certain processes to a level that children can understand will provide me with a baseline to aim for when I design how my project will be taught to my targeted audience. Furthermore, since all of the exhibits have been created to be interactive, I will observe how people interact with the exhibits and what concepts are demonstrated. It is important to understand how and why the exhibits were created for their targeted audience. Although the concepts can be complex in nature, the exhibits have been created specifically for children and thus, choose certain concepts and designs over others. In order to understand these concepts, I will spend some time observing how children interact with the exhibits and consider possible reasons for their actions.
I would be interested in learning about Peter's past experiences with designing the exhibits. Specifically, if he has any experiences in which the exhibits did not perform as well as others and what he believes is the cause for those failures. I would also ask him about any successful exhibits that he has created and what made them so successful. It would also be worth asking him about the process he must take in order to create an exhibit and some of the questions that he asks himself when creating exhibits. Finally, I would ask him for any tips or stories that he may have regarding his work and creating exhibits for others to use.
Friday, March 14, 2014
Tuesday, March 4, 2014
SciBorg Day 2
C. Fixed Distance
We realized while testing the Sciborg that it consistently turned left if both wheels were on full power. This was due to the fact that wheel B was turning anywhere between 70-90 counts more than wheel B. To address this problem, we identified that 1 counta was equal to about 0.125 inches. As such, in order to reach 10 feet, we used that measurement to determine that it would take 960 counta-s. However, that only took the Sciborg 38.5 inches perhaps due to friction. With this new measurement, we then calculated it would take 2992 counta-s but this carried the robot 4 inches too short of the goal. At this point, the Sciborg had been turning slightly to the left and could possibly be the reason why it was stopping short of its goal. We decided to switch to countb which yielded a slightly straighter line and add 68 counts to let the robot achieve its goal for a total of 3060 countb-s. In order to make the robot travel straighter as well, we programmed the power of wheel B to turn down to 99% after it had traveled about a third of the distance. This was to allow wheel A to catch up to the other wheel.
I predict that if the robot showed signs of it skidding, it would travel slightly farther than when it was programmed to stop. To address this issue, I would have lowered the total number of counts to take this additional distance into consideration. I could also turn down the power of the Sciborg in order to reduce the amount of skidding. Our robot most likely showed signs of slipping since the calculated number of counts had to be adjusted three times to reach our total of 10ft with each time being too short despite what the calculations stated. To address that problem, we simply recalculated how much we needed to reach 10 feet and increased the number of counts.
Touch feedback:
We replaced the last command of stopping after having reached 3060 of countb with a touch command that stated it should stop if the touch sensor touched anything (sensor 1 = 0). Unfortunately the robot was not able to stop immediately when it touched the bin. This was due to the fact that the robot's momentum carried it forward after it was programmed to stop. However, the touch sensor had to be fully pressed before the robot would register that it had to stop and thus, resulted in this unavoidable result.
Ultrasonic sensor:
Again, we swapped out the sensor 1 command for the next sensor and reduced its sensitivity to be less than 1, the lowest sensitivity possible for our program and robot. Although the robot stopped a few inches away from the bin, it did not achieve its goal of stopping over the white line. However, it did achieve its overarching goal of stopping before it reached a solid object.
Line follower:
Personally, this was my favorite. I believe it's the most accurate of the three sensors. We had to turn the power of the robot down because we found that if it was on 100% power, it would still register that it had read the white line and adjust accordingly once it did not read the white line anymore. However, because the robot was moving too fast, the momentum would carry it forward and the robot was unable to adjust in time. This resulted in it traveling over the line completely and setting it off into the brown cardboard attempting to find the white line it had just crossed over.
Drive Straight:
This task proved to surprisingly be the most difficult. We determined that our robot would travel 10 ft using a mixture of the touch and light sensors. To adjust for the fact that Wheel B turned more times than Wheel A, we attempted to adjust a number of things to try to fix the problem. At first we tried setting the power of wheel A such that it was only 1% more than wheel B. That unfortunately made the Sciborg turn too much to the right. Next we tried to set a number of if-then statements. We specified if either of the counts became unequal, the robot should turn the power down on the wheel that is turning too many times so that the other wheel can catch up. The result was a robot that traveled 10 feet continued to veer slightly to the right. Throughout testing the robot, we realized that pushing the white button on the right side of the robot added a slight amount of friction to it and may have caused an initial turning point. Thus, we programmed it such that the touch sensor had to be activated first before the robot would move.
We realized while testing the Sciborg that it consistently turned left if both wheels were on full power. This was due to the fact that wheel B was turning anywhere between 70-90 counts more than wheel B. To address this problem, we identified that 1 counta was equal to about 0.125 inches. As such, in order to reach 10 feet, we used that measurement to determine that it would take 960 counta-s. However, that only took the Sciborg 38.5 inches perhaps due to friction. With this new measurement, we then calculated it would take 2992 counta-s but this carried the robot 4 inches too short of the goal. At this point, the Sciborg had been turning slightly to the left and could possibly be the reason why it was stopping short of its goal. We decided to switch to countb which yielded a slightly straighter line and add 68 counts to let the robot achieve its goal for a total of 3060 countb-s. In order to make the robot travel straighter as well, we programmed the power of wheel B to turn down to 99% after it had traveled about a third of the distance. This was to allow wheel A to catch up to the other wheel.
I predict that if the robot showed signs of it skidding, it would travel slightly farther than when it was programmed to stop. To address this issue, I would have lowered the total number of counts to take this additional distance into consideration. I could also turn down the power of the Sciborg in order to reduce the amount of skidding. Our robot most likely showed signs of slipping since the calculated number of counts had to be adjusted three times to reach our total of 10ft with each time being too short despite what the calculations stated. To address that problem, we simply recalculated how much we needed to reach 10 feet and increased the number of counts.
Touch feedback:
We replaced the last command of stopping after having reached 3060 of countb with a touch command that stated it should stop if the touch sensor touched anything (sensor 1 = 0). Unfortunately the robot was not able to stop immediately when it touched the bin. This was due to the fact that the robot's momentum carried it forward after it was programmed to stop. However, the touch sensor had to be fully pressed before the robot would register that it had to stop and thus, resulted in this unavoidable result.
Again, we swapped out the sensor 1 command for the next sensor and reduced its sensitivity to be less than 1, the lowest sensitivity possible for our program and robot. Although the robot stopped a few inches away from the bin, it did not achieve its goal of stopping over the white line. However, it did achieve its overarching goal of stopping before it reached a solid object.
Line follower:
Personally, this was my favorite. I believe it's the most accurate of the three sensors. We had to turn the power of the robot down because we found that if it was on 100% power, it would still register that it had read the white line and adjust accordingly once it did not read the white line anymore. However, because the robot was moving too fast, the momentum would carry it forward and the robot was unable to adjust in time. This resulted in it traveling over the line completely and setting it off into the brown cardboard attempting to find the white line it had just crossed over.
This task proved to surprisingly be the most difficult. We determined that our robot would travel 10 ft using a mixture of the touch and light sensors. To adjust for the fact that Wheel B turned more times than Wheel A, we attempted to adjust a number of things to try to fix the problem. At first we tried setting the power of wheel A such that it was only 1% more than wheel B. That unfortunately made the Sciborg turn too much to the right. Next we tried to set a number of if-then statements. We specified if either of the counts became unequal, the robot should turn the power down on the wheel that is turning too many times so that the other wheel can catch up. The result was a robot that traveled 10 feet continued to veer slightly to the right. Throughout testing the robot, we realized that pushing the white button on the right side of the robot added a slight amount of friction to it and may have caused an initial turning point. Thus, we programmed it such that the touch sensor had to be activated first before the robot would move.
We tested this program on the lab floor, the carpet, and on the ramp. The robot continued to veer slightly to the right when it was on the floor. However, it continued to travel a distance of 10 feet. On the carpet, the robot traveled in a much straighter line but slower as well. It did achieve its final distance of 10 feet as well.
We encountered the most problems on the ramp. Because the robot had an affinity for turning slightly to the right, it was unable to make it up the 10ft ramp. We more often than not got it to travel about 3-5 feet before it fell off. We attempted to take this into account by programming the robot to turn off the wheel that was traveling too far so it would turn back to the other side. However, this was largely unsuccessful as well.
Traveling down the ramp increased the momentum of the robot which resulted in it moving at a much faster speed than what it was programmed to do. It essentially rolled down the plank and was barely able to react to the wheel counts because the robot was moving so quickly. As a result, when it reached the bottom of the plank, it was unable to read the line in time and could not stop in time. However, it did travel much straighter than when it was attempting to go up the plank and achieved its goal of 10 feet.
It would have been nice to have more time to perfect the robot so that it traveled straighter up the ramp. But in the end, testing out varying sensors and programming the robot to follow commands was an exciting experience. I was humored by the fact that I had to use my computer science skills to finish this lab but I thoroughly enjoyed finding a cross section between computer science and engineering since I find both so interesting.
Monday, March 3, 2014
Real-world Feedback/Control Systems
1. Human body in relation to hunger
The human body is constantly monitoring its current state of hunger by noting different levels of hormones throughout the blood. Put simply, when glucose levels drop, the body signals that it is requires food and consumes food until the glucose levels peak to optimal levels. The sensing mechanism would be the pancreas, the actuation mechanism would most likely be the hypothalamus which is the main organ that monitors the majority of hormones in the body, and the control computation would be the hypothalamus responding to the state of the pancreas. This system generally works well since glucose levels are essential for energy and bodily functions. However, there is a delay in the system. Food must be broken down to a certain extent to be converted to glucose before it can be absorbed by the body. Therefore, the delay in determining how much food needs to be consumed before glucose levels are at sufficient levels may cause people to overeat.
2. GPS system
GPS systems in the phone rely on the phone's ability to communicate with satellites to monitor its position and determine how it can reach its destination. There is a constant feedback loop between the phone sensing its current position and its needed route. The sensing mechanism would be the GPS locator on the phone that determines its location. The actuation mechanism would be the actual person moving in the physical world and following the directions of the system while the control computation would be the algorithms within the program that determine which route needs to be taken. These types of systems can be reliable and are incredibly useful. However, sometimes the routes the program chooses is not always the most efficient since it doesn't always take stopping at streets or speed limits into consideration. There may also be some roads that are undesirable due to safety or time issues.
3. Thermostat
The thermostat is the most common type of feedback and control systems. It relies on the sensing mechanism of the temperature sensitive pins which bend depending on the temperature. The actuation mechanism would be the magnets that change the system to be either on or off while the control computation system would be the chemistry in the strip that allow it to bend at such sensitive measures of temperature and mechanisms that turn the system on or off depending on the state of the bimetal strip.
4. Fluxx
Fluxx is a program on computers that changes the tint of the screen depending on the time of day. Blue light is a problem in many electronics because it can affect users ability to sleep at night and can strain their eyes during the day. Therefore, later at night, the program triggers the screen to show more pink or yellow to contrast with the blue light and prevent users from suffering from affected sleep cycles. The program asks for the user's zipcode to determine its position in the world and adjusts the screen depending on what time it is at that location. The sensing mechanism would be the program's understanding of what time it is at the location. The actuation mechanism would be the change in color on the screen while the control computation would be the program's algorithms to determine how blue, pink, and yellow the screen should be. The system in general works well since it also provides users with the ability to change how bright, pink or yellow the screen should be. However, sometimes the screen changes too abruptly between colors when it should be a more gradual fade.
The human body is constantly monitoring its current state of hunger by noting different levels of hormones throughout the blood. Put simply, when glucose levels drop, the body signals that it is requires food and consumes food until the glucose levels peak to optimal levels. The sensing mechanism would be the pancreas, the actuation mechanism would most likely be the hypothalamus which is the main organ that monitors the majority of hormones in the body, and the control computation would be the hypothalamus responding to the state of the pancreas. This system generally works well since glucose levels are essential for energy and bodily functions. However, there is a delay in the system. Food must be broken down to a certain extent to be converted to glucose before it can be absorbed by the body. Therefore, the delay in determining how much food needs to be consumed before glucose levels are at sufficient levels may cause people to overeat.
2. GPS system
GPS systems in the phone rely on the phone's ability to communicate with satellites to monitor its position and determine how it can reach its destination. There is a constant feedback loop between the phone sensing its current position and its needed route. The sensing mechanism would be the GPS locator on the phone that determines its location. The actuation mechanism would be the actual person moving in the physical world and following the directions of the system while the control computation would be the algorithms within the program that determine which route needs to be taken. These types of systems can be reliable and are incredibly useful. However, sometimes the routes the program chooses is not always the most efficient since it doesn't always take stopping at streets or speed limits into consideration. There may also be some roads that are undesirable due to safety or time issues.
3. Thermostat
The thermostat is the most common type of feedback and control systems. It relies on the sensing mechanism of the temperature sensitive pins which bend depending on the temperature. The actuation mechanism would be the magnets that change the system to be either on or off while the control computation system would be the chemistry in the strip that allow it to bend at such sensitive measures of temperature and mechanisms that turn the system on or off depending on the state of the bimetal strip.
4. Fluxx
Fluxx is a program on computers that changes the tint of the screen depending on the time of day. Blue light is a problem in many electronics because it can affect users ability to sleep at night and can strain their eyes during the day. Therefore, later at night, the program triggers the screen to show more pink or yellow to contrast with the blue light and prevent users from suffering from affected sleep cycles. The program asks for the user's zipcode to determine its position in the world and adjusts the screen depending on what time it is at that location. The sensing mechanism would be the program's understanding of what time it is at the location. The actuation mechanism would be the change in color on the screen while the control computation would be the program's algorithms to determine how blue, pink, and yellow the screen should be. The system in general works well since it also provides users with the ability to change how bright, pink or yellow the screen should be. However, sometimes the screen changes too abruptly between colors when it should be a more gradual fade.
Response to Control in an Information Rich World
A. Feedback is the information a machine or program receives from a sensor that describes its current state. For example, in a thermostat, the temperature sensing part of the device would be the feedback portion of the device.
B. Control is using the feedback information adjust its current state to achieve a preferred state. For the thermostat example, the magnets adjusting to change the heater on or off based on its current temperature would be control function of the thermostat.
C. I was personally intrigued by how interdisciplinary feedback and control was between varying fields such as Engineering, Computer Science, and Mathematics. I originally thought that feedback and control were largely Engineering concepts since it dealt with senors and changing the state of the robot. However, especially with this current assignment concerning the SciBorg, I have begun to realize that there is a considerable overlap between Engineering and Computer Science. The fact that Mathematics is also an important field should not be so surprising as well since it is needed to compare the current state of the device to its ideal state. It makes sense as well that more complicated systems would require more extensive and complicated algorithms from all of these fields to complete.
D. After reading this article, I would like to learn more specifically about what innovations are needed for the next generation of feedback and control. The article mentions several times about how there is a need for more advanced and innovative technology, but it never went into depth into a certain case study of it.
B. Control is using the feedback information adjust its current state to achieve a preferred state. For the thermostat example, the magnets adjusting to change the heater on or off based on its current temperature would be control function of the thermostat.
C. I was personally intrigued by how interdisciplinary feedback and control was between varying fields such as Engineering, Computer Science, and Mathematics. I originally thought that feedback and control were largely Engineering concepts since it dealt with senors and changing the state of the robot. However, especially with this current assignment concerning the SciBorg, I have begun to realize that there is a considerable overlap between Engineering and Computer Science. The fact that Mathematics is also an important field should not be so surprising as well since it is needed to compare the current state of the device to its ideal state. It makes sense as well that more complicated systems would require more extensive and complicated algorithms from all of these fields to complete.
D. After reading this article, I would like to learn more specifically about what innovations are needed for the next generation of feedback and control. The article mentions several times about how there is a need for more advanced and innovative technology, but it never went into depth into a certain case study of it.
Subscribe to:
Comments (Atom)