To: Professor Jolanta Janiszewska
From: Nick Kanel, Marcus Pereira, Matt Musso
Subject: AEV Lab 3: External Sensors
Date: February 10, 2016
Intro
This lab was designed to give teams the opportunity to finalize the Alternative Energy Vehicle and write code for the arduino that was placed onboard. Teams were asked to attack the counter senators to the wheels in order to count the number of wheel rotations so that the total distance traveled could be calculated. After the sensors had been attached, they were able to be connected to the Arduino block and read by a program loaded.
Teams were asked to write a program to accomplish a task that was starting the AEV motors and sending the AEV down the track for a certain number of wheel rotations.
Before this lab, teams had worked to construct their AEV from the parts that were provided by the university. Drawings were done and many different ideas were combined into one in order to create an AEV that may be more optimal than the individual designs. If lab groups are so inclined, they can create a 3D model of their own parts to house the AEV and perhaps make it more aerodynamic.
Discussion
- How did the AEV behave on the track? How far this the AEV travel. Did the AEV that was constructed survive this trip? What changes will you have to make to the design?
The AEV behaved smoothly on the track and didn’t slide around too much. It was able to go around the corner in the track without too much trouble or risk of falling off. The AEV was able to survive the trip because its center of mass was so low below the track that there was very little risk of tipping.
If this design were to be changed in some way, it would be to make the AEV more balanced from side to side. At this current point in time, the AEV tends to lean towards the side that the battery is laid on, which could either cause it to take a turn in a more positive way or a more negative way than if it were perfectly balanced. The only way to meet in the middle of these is to make sure that the AEV is completely balanced to allow for it to take corners in the most effective way possible.
- Explain how the team will utilize the knowledge gained in this lab to construct a preliminary code to complete the scenario stated in the Mission Concept Review (MCR)
The Mission Concept Review states a requirement for positional specificity concerning the code that is to be used in the AEV. Such commands require familiarity in the capabilities of the commands able to be used for the AEV, as well as knowledge concerning sensors carried thereby regarding the motion of the vehicle. Therefore the knowledge gathered in the lab conducted will have significant bearing on the final product that is to be created. The commands goToRelativePosition and goToAbsolutePosition will allow for the positional control of the AEV, and are made possible by the use of the reflective sensor positioned near each wheel. Either command could potentially be used in the AEV’s code, however for simplicity for the user, it may be more prudent to use the relative position command for a majority of the commands given as the distances are not compounded upon one another. This could also potentially minimize any error to arise from the sensors during a run of the AEV, as each individual command will be based off of itself and not the entirety of the absolute command.
Aside from becoming familiar with commands for control of the AEV, familiarity was also gained in troubleshooting the dysfunction of the sensors. The possible issues are extensive, but things such as improper connections and the distance from the sensor to the wheel are each considerable. These issues can be discovered by use of the command “reflectanceSensorTest,” and solved without significant issues arising.
Resolving Error
During this lab there were a couple problems that arose. The first of which was the sensor coding. The sensors didn’t work correctly after the first time verifying, uploading, and running the code. To try to fix this, the code was reentered, reuploaded, and rerun, with the second time around working correctly. The second issue was with the run at the end of class. When testing the AEV at the end of class, the vehicle moved and balanced smoothly, but it didn’t reverse like it was supposed to towards the end. Due to time constraints, this issue was not solved within lab time.
Recommendations
Some trouble was had when attempting to run the sensor test for the first time. After attempting the test, the sensors were checked and all was determined to be in working order with the proper connections having been made to the proper places with the Arduino. The sensors were unplugged, and plugged back into the Arduino in the same manner as they had been before and the issue resolved itself. One other occurrence that was unexpected was found during the test run of the AEV. As the vehicle approached the hill it reached a point of equilibrium, where its motion ceased. The AEV continued to run, which was later attributed to the fact that, because the AEV was no longer moving, no ticks were being counted. The AEV did not stop because of this, and it had to be taken from the rail and manually shut off.
Conclusion
This lab helped students gain experience with the AEV through three main ways. One way was with the external hardware components. The second way was through troubleshooting techniques. The third way was by programming function calls for the external sensors in the arduino. This was all done while allowing for students to try to run the AEV’s on the track for the first time and testing out their code to see if progress was made. For group E, it was seen that the coding worked well up until the ending. At that point, the vehicle should have reversed the motors and turned around, but that was not the case. In this case, the group should go over the code to make sure they find the mistake and correct the issue.