Difference between revisions of "Hoverbear"
| Line 115: | Line 115: | ||
Each ultrasonic distance sensor is reading distances constantly, with whichever distance is shorter being used to determine how close the nearest obstacle in front of the hovercraft is. The code also checks to make sure that if there is nothing within range of the ultrasonic distance sensors, the servo motor will not react to the fairly arbitrary error values the ultrasonic distance sensors put out, not turning at all even if the values would indicate otherwise. From there, the hovercraft will then use the distance calculated earlier and tell the servo motor to turn the hovercraft away from whichever side had the obstacle closest to it. From there, the servo motor would remain in the turned position until there are no obstacles in its way, at which point the servo motor returns back to the starting position, and the cycle begins again. | Each ultrasonic distance sensor is reading distances constantly, with whichever distance is shorter being used to determine how close the nearest obstacle in front of the hovercraft is. The code also checks to make sure that if there is nothing within range of the ultrasonic distance sensors, the servo motor will not react to the fairly arbitrary error values the ultrasonic distance sensors put out, not turning at all even if the values would indicate otherwise. From there, the hovercraft will then use the distance calculated earlier and tell the servo motor to turn the hovercraft away from whichever side had the obstacle closest to it. From there, the servo motor would remain in the turned position until there are no obstacles in its way, at which point the servo motor returns back to the starting position, and the cycle begins again. | ||
| − | The code was originally developed long before we had access to any of the pieces to test with, and as a result the main way things like turn direction were defined were by arbitrary numbers that the code could use as a stand-in for the sensors. All of the error cases in turnCheck() caused the hovercraft to turn to the right, which was only intended as a placeholder. We also used 3 ultrasonic distance sensors: one for detecting the presence of an obstacle, with the remianing two used to determine which direction to turn. Then, we got our ultrasonic distance sensors and servo motor. After tinkering around for a bit, we realized that there was no need for obstacle detection ultrasonic distance sensor | + | The code was originally developed long before we had access to any of the pieces to test with, and as a result the main way things like turn direction were defined were by arbitrary numbers that the code could use as a stand-in for the sensors. All of the error cases in turnCheck() caused the hovercraft to turn to the right, which was only intended as a placeholder. We also used 3 ultrasonic distance sensors: one for detecting the presence of an obstacle, with the remianing two used to determine which direction to turn. Also, turning was permanent, with the only way to stop turning one way was to start turning the other way. Then, we got our ultrasonic distance sensors and servo motor. After tinkering around for a bit, we realized that there was no need for obstacle detection ultrasonic distance sensor since the two turning ultrasonic distance sensors could be used for that as well. We also then proceeded to make turning work in a more logical way, where it keeps turning only until there is nothing else in the way before returning to its initial position. From there, testing yielded a few bug fixes, from obvious ones such as how the program used to always turn right due to a greater than sign being used in place of a less than sign, or less obvious ones like how in the rare case of the ultrasonic distance sensors getting an error reading, the servo motor would turn to the right position because of a clause that had been there since the beginning that arbitrarily caused a right turn. |
| − | |||
===Physical Design=== | ===Physical Design=== | ||
Revision as of 02:45, 16 April 2019
Contents
Link to Log
Project Proposal
Overview
We are going to be constructing a hoverboard that would be able to hover a few centimeters off the ground. It will be able to move to a destination by means of a beacon or vectors, and contain some measure of intelligence.
Team Members
- Lucas Alcantara
- James Shaheen
- Michael Horwitz
- TA: Tony
Objectives
- To enable the hovercraft to autonomously detect obstacles
- To enable the hovercraft to autonomously travel to a beacon
- To enable the hovercraft to follow a predetermined trail / follow a trail marked out on the ground
Defining Smart
Our Hovercraft will have three settings.
Setting 1: Obstacle Avoidance
In the Obstacle Avoidance setting, the Hoverbear will utilize two ultrasonic distance sensors in order to avoid obstacles around it.
Setting 2: Line Following
In the Line Following setting, the Hoverbear will utilize three photoresistors in order to follow a line of tape.
Setting 3: Manual Input
In the Manual Input setting, the Hoverbear can be given a set of simple inputs that will allow the user to give the Hoverbear directions to follow.
List of Dated Goals
February 15, 2019: Present initial project proposal to the entire class. During this time, the goals of the project should be presented along with a condensed timeline for completion as well as anticipated challenges that have been or will be faced.
- Finish the night light in the first week or so (date TBD)
- Familiarize ourselves with the sensor and work on coding to make self sufficient (date TBD)
Week of March 31st: By this week, the group should have a final design of the hoverboard and built before the end of the week.
April 8th, 2019: By this day, a Final Proposal should be finalized and submitted to Professor Feher.
April 26, 2019: By this day, the hovercraft will be presentable and at its final design.
Challenges
- All group members have very busy schedules. Finding times to meet will be hard, and individuals might have to work on their own at some times.
- Not a whole lot of experience in automation. There will a be a learning curve for the group.
- Not everyone in the group is familiar with Arduino programming. Learning how to use an Arduino is likely to take time out of the building process of the project.
- It could be a challenge to learn how to utilize the ultrasonic distance sensor so we can be self dependent and navigate through obstacles. In addition, we will be trying to use more than one ultrasonic distance sensor. It may be hard to calibrate all distance sensors.
- The hoverbear will be a careful balance between power and weight: The heavier the craft is, the more power is required to keep it afloat. The heaviest machine part will either be the fans or the battery.
Videos
Budget
| Item | Quantity | Cost |
|---|---|---|
| Cardboard | 1 | $10.00 |
| Delta Fan | 2 | $25.99 |
| Ultrasonic Distance Sensor | 3 | $5.42 |
| Micro Servo Motor | 1 | $7.79 |
| Talentcell Battery | 1 | $23.99 |
| Remaining Budget | $39.98 | |
| Total Budget | $150.00 |
Materials
- Arduino Uno
- Foam Board (for the base)
- 12 V 3000mA Talentcell Battery
- Servo Motors
- Ultrasonic Distance Sensors
- One Delta Fan
- One slightly weaker fan
Gantt Chart
Preliminary Group Presentation
Design and Solutions
Programming and Hardware
Intelligent Turning
While being able to turn is nice and all, being able to turn intelligently is much more important. The way we did this was by implementing two ultrasonic distance sensors and a servo motor.
Each ultrasonic distance sensor is reading distances constantly, with whichever distance is shorter being used to determine how close the nearest obstacle in front of the hovercraft is. The code also checks to make sure that if there is nothing within range of the ultrasonic distance sensors, the servo motor will not react to the fairly arbitrary error values the ultrasonic distance sensors put out, not turning at all even if the values would indicate otherwise. From there, the hovercraft will then use the distance calculated earlier and tell the servo motor to turn the hovercraft away from whichever side had the obstacle closest to it. From there, the servo motor would remain in the turned position until there are no obstacles in its way, at which point the servo motor returns back to the starting position, and the cycle begins again.
The code was originally developed long before we had access to any of the pieces to test with, and as a result the main way things like turn direction were defined were by arbitrary numbers that the code could use as a stand-in for the sensors. All of the error cases in turnCheck() caused the hovercraft to turn to the right, which was only intended as a placeholder. We also used 3 ultrasonic distance sensors: one for detecting the presence of an obstacle, with the remianing two used to determine which direction to turn. Also, turning was permanent, with the only way to stop turning one way was to start turning the other way. Then, we got our ultrasonic distance sensors and servo motor. After tinkering around for a bit, we realized that there was no need for obstacle detection ultrasonic distance sensor since the two turning ultrasonic distance sensors could be used for that as well. We also then proceeded to make turning work in a more logical way, where it keeps turning only until there is nothing else in the way before returning to its initial position. From there, testing yielded a few bug fixes, from obvious ones such as how the program used to always turn right due to a greater than sign being used in place of a less than sign, or less obvious ones like how in the rare case of the ultrasonic distance sensors getting an error reading, the servo motor would turn to the right position because of a clause that had been there since the beginning that arbitrarily caused a right turn.
Physical Design
Getting the Hovercraft into the Air
In order to make a hovercraft, one must first decide which system to choose from: The first system is one fan, which divides work between the air chamber and air propulsion. Another option is to use two fans instead of one. One fan pushes air into the air chamber, the other fan propels the hovercraft. Our team decided that the latter option would be easier for our purposes. This is because the second system would make it easier to steer the hovercraft without having to worry about rudders. Instead, the propelling fan would just be moved by a servo motor.
In addition to the chamber and air propulsion, A skirt needed to be made. The skirt is what prevents pressure from depleting from the air chamber. A good skirt needs to have certain qualities. To name a few:
- Obviously, be able to contain the air cushion
- Some flexibility, so that it can return to its original shape after bumping into an obstacle, scraping into something, etc.
- Provide some stability for the hovercraft
Normal plastic was used for our first skirt. Although it was flexible, the skirt was not very durable, and broke easily. On top of that, the wrinkles in the plastic film degraded the hovercraft's overall aesthetic. The skirt we are using is made of Grafix Clear-Lay, a plastic film easily found at the Wash U Store at the Mallinckrodt Center. While its primary purpose is for overlays for protective coverings for stencil drawings, the Clear-Lay is flexible yet durable enough to make a good skirt for our hovercraft. In addition, it was easy to hot glue to the base, providing some stability for the hovercraft. There were also no wrinkles when bending the Clear-Lay into its desired form, upping the hovercraft's overall aesthetic compared to the light plastic film skirt.
Once a proper material for the skirt was found, the shape of the skirt needed to be properly designed. Initially, a simple skirt tightened around the edges of the hovercraft was designed, such as found here. It became clear, however, that this design did not maximize the carrying capacity of the hovercraft. It was hypothesized that the carrying capacity of the hovercraft could be increased if the air chamber was expanded. However, expanding the air chamber would in itself require adding more base layers, which would in turn add more weight. This dilemma was resolved by changing the design of the skirt. Rather than using a tightened skirt, four tubes of Clear Clay were created and lined the sides of the hovercraft. This skirt design allowed the air chamber to be expanded without the additional weight that more base layers would created. In addition, this tubed skirt design had the benefit of adding more space to the top of the hovercraft base, since the tightened skirt took space from the top base and four tubed design does not.
Circuit Problems
Helpful Links
https://makezine.com/projects/diy-r-c-hovercraft-from-cardboard-and-trash-bags/
This link was first sent by Feher as an idea of what to create for our project.
https://www.instructables.com/id/Hovercraft-with-Arduino-design/
This link was found by Lucas as a basic structure for the project.
This link was found by Lucas. It informs the reader on the basics of collision sensing in motorized machines.
https://www.instructables.com/id/Arduino-Ultimate-Obstacle-Avoiding-Robot/
This link was found by Lucas as an example of an Arduino showing obstacle avoiding capabilities.
http://www.delta-fan.com/Download/Spec/AFB1212GHE-TZR6.pdf
This is a pdf of the delta fan that will give the hovercraft lift. A separate fan will be used to move the hovercraft in different directions.
