Exercise 1 – Programming Basics
The first task was to connect the motors to the AEV and test the functionality of it. After hooking the AEV and motor together, we ran the coding for scenario one (glossary below that includes brief description of each code). After testing the scenario multiple times, we learned a a few new things. It was determined the propellers did not spin at low power (<15%). The motors needed to be about 20% or more in order to get both propellers to spin. There was also a noticeable difference in when both propellers started to spin. One propeller would start to spin right before the other one began to spin in less than a second. This indicates that the two motors have different initial energy levels to spin the propellers. During this exercise, the AEV ran smoothly without error; the motors behaved as expected when the Arduino code was established. After this exercise, we felt that the group is on track and another meeting was needed soon to go over the website and project details.
Glossary
celerate(m,p1,p2,t); – accelerates or decelerates the motor(s) in a specific time
motorSpeed(m,p); – tells the motor what power to perform at initially
goFor(t); – tells motors how long to run at a preset speed
brake(m); – cuts power to the motors and stops them from running
reverse(m); – reverses the spin orientation of the motors
Exercise 2 – Reflectance Sensors
The second task was to test the external sensors and check if the sensors worked for the command “goToAbsolutePosition” and “goToRelativePosition”. As we were installing the reflectance sensor, we knew that the connection needed to be install with the white wire facing the Arduino mini-USB connection, or it might not work properly. As we were testing the sensor, we found that they kept track of the position for AEV by counting the “marks” on the wheel. Each sensor recorded 4 marks (2 black and 2 white) for a wheel revolution. Since there were two sensors, there were 8 marks in a wheel revolution. As we were coding the command for reflectance sensors, we figured out that the units which AEV used was mark (0.4875 inches/mark). After the lab, we learned that using the commands of “goToAbsolutePosition” or “goToRelativePosition” were essentially the same if we manipulated them. The absolute position is the distance from the origin to the mark in the command, while the relative positive is the distance from the AEV itself. In addition, we realized that the coding would get the AEV to move a specific distance we wanted, but the coding to make it stop after reaching that distance would allow the AEV to move slightly past the desired distance. When the “brake(m);” command is used, the AEV will not stop right away. The motors will stop receiving power, but the momentum of the AEV keeps it moving along the track until friction and air resistance slows it down. After this exercise, we fully understood the importance of the reflectance sensors and were able to control the sensors versatility by the command codes. The sensors will allow us to move the AEV a certain distance, which is crucial to the MCR for picking up the loading block and stopping before a gate.
Exercise 3 – Creative Design Thinking
Each member drafted a potential design for the AEV and specified the benefits to it.
Tim’s design was made to be simple with only a T-shape in the bottom, and a L-shape arm on the top to hold body. With a simple body, the AEV is going to move faster while using less power. The weight are leaning forward, so the motor can just push the weight forward instead of being drag by the weight. The cost of this AEV is going to be approximately 150 dollars which is not too bad, and the weight is going to be less than 150 gram.
Grant’s design was made to be aerodynamic, stable, and light. This design uses the minimum amount of parts and is aligned downward to add to the overall stability of the vehicle and to eliminate much of the side-to-side wobbling motion that can be observed in wide models such as the sample. The overall cost was also considered in this design as it is composed of a very small number of parts.
Tysir’s design was made to be aerodynamic with a slanted front, back, and side. This can allow the AEV to move at faster speeds with less power and go uphill more efficiently if the AEV moves the way it was designed to. The design should not be too expensive or too heavy for the mission.
Ben’s design was made to be compact, stable and energy efficient. The design allows for the AEV to move at high speed while reducing wobble due to weighting and spacing issues. The design stays cost effective by utilizing all space on the main platform while raising the motors to allow the propellers no hindrance when attempting to move air around. This design is also front heavy, helping guide the AEV uphills as to not weigh it down meaning the most weight will reach the top of the hill first. Cost, efficiency and reliability were the major factors in determining this design.
Exercise 4 – Design Analysis Tool
In the fourth exercise, we ran a code for the AEV and plotted the figures for “Power vs. Time” and “Power vs. Distance”. From the plot of “Power vs. Time”, we saw that the propellers would not spin when the motors had low power, which meant that the AEV would not move until the motors achieve a certain level of power. If there was not enough power for the motors to move the AEV, the variable power would keep increasing until the AEV began to move. After there was enough power, distance would also start to increase in the figure of “Power vs. Distance”. However, it was different in the figure of “Power vs. Time”, because as power was increasing, time was also increasing. As the speed of AEV was changing due to the “celebrate(…)” command, there was a constant slope going up/down on the figure of “Power vs. Time”. However, if the speed was constant, there would be a horizontal line on both figures. An upward peak on the figures meant there was a command code “reverse(m)” being used on the AEV. If there was a line with a slope of 1, then it meant that there was a command code “brake(m)” being used on the AEV. During this exercise, we were able to do some extra coding, which was to reduce the stopping distance since the brake command does not instantly stop the AEV. We coded the the AEV to stop at certain position and then to reverse the motors and give it some power to push back the AEV. This would allow the AEV to not slide as much after shutting down the power with the codes. We tried to give a motor speed of 10% and go for 0.8s which almost made the AEV stop at what we planned. However, we would still do more testing on the AEV to make stop closer to the desired position. With the exercise’s code, we were able to learn what would happened during the phases of each figure with different command codes.
Exercise 5 – Concept Screening & Scoring
In exercise 5, we ran some more random trials with the AEV we had built previously. This allowed us to become more familiar with the response to coding and functionality of the AEV unit. We took into consideration several qualities about this sample AEV. First, there was a delay of about a second between pressing the start button and the motors initiating on the vehicle. Then, the AEV took about a second to start moving after the motors were on and the propellers were spinning. Also, the AEV was leaning to one side, so the weight should be redistributed in our design, like move the Arduino, to counteract the uneven weight of each side. This gave us a better idea of how to compare each of our design to this sample one for the concept screening. After evaluating our designs, we filled out the concept screening chart. This allowed us to fill out the concept scoring chart to compare our AEV designs together.
