Hoverbear

From ESE205 Wiki
Jump to: navigation, search

Useful Links

Link to our Log

Link to our Tutorial Page

File:Hoverbear Poster.pdf

Github

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 to hovercraft to autonomously avoid detected obstacles
  • 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 sensors attached to the arduino in order to avoid obstacles around it.

Circuitry:

  • 2 Ultrasonic Distance Sensors
  • Servo-Motor
  • Arduino


Setting 2: Line Following

In the Line Following setting, the Hoverbear will utilize photoresistors in order to follow a line of tape.

Circuitry:

  • 2 Photoresistors
  • Servo-Motor
  • Arduino

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.

Circuitry:

  • Servo-Motor
  • Arduino

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
Out of $150

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

HoverBearGanntChart.jpeg

Preliminary Group Presentation

https://docs.google.com/presentation/d/1LC5-bpy_PZ1Pp5c1MIzv8FixqiFnd0cE2mcwiCRTCIM/edit#slide=id.g4ecedb114a_0_0

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.

Hovercraft Diagram.png

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.

The first layer of the base of the Hovervear. The fan in the center is surrounded by the cockpit area, where the wiring and other circuitry is located.

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.


Battery Limitations

The Talencell 12V 3000mAh Battery is strong, with a power output of 36 Watts. The specifications of the battery claims that the battery can hold this power output consistently for 10 hours. However, using this battery for our hovercraft, it is clear that this power output decreases slightly over time.

multiple trials consistently show that the maximum weight capacity of the hovercraft decreases over time. After a few hours, the hovercraft is barely able to move, much less hover.

Assuming that LED outputs on the battery show two hours of charge on the battery, it can be calculated that, since the hoverbear loses flight when there is around 3 to four LED lights on, the hovercraft can remain in the air for roughly 3 to 4 hours with the talentcell completely charged.

Maximum Weight Capacity

These calculations are assumed with the talentcell battery at FULL CHARGE. The Maximum Weight Capacity is to be defined as the maximum weight that the hoverbear can carry on its base. The circuitry, the base, and other required parts of the hovercraft are to be excluded from this weight.

To determine the maximum weight capacity of the hovercraft, paperclips and nails will be attached to the base of the hovercraft until the hovercraft loses hovering capabilities. The experimental weight of the paperclips and nails that could be put onto the hovercraft before it losing hover capabilities was roughly 0.5 kg. Therefore, the maximum weight capacity is roughly 0.5 kg.

If the main parts of the hovercraft were to be added to the maximum weight capacity, then the weight capacity would be roughly 1.5kg. This implies that the hovercraft is able to carry almost half of its weight.

Cockpit Area

The Cockpit area of the Hoverbear serves two purposes. The first purpose is to provide a safe and secure area for the Arduino, the LiPo battery, and other relevant circuitry to be placed. The second purpose is to take some weight off the Hoverbear, increasing the Hoverbear's maximum weight capacity, and potentially allowing it to be propelled with more ease.

How to Make the Skirt

As stated previously, the skirt of the Hoverbear consists four "skirt tubes," hand made roles of Clear-Lay that outline the bottom base of the Hoverbear. In order to make the skirt tubes properly, the steps must followed:

  • Cut out a sheet of Clearlay, with a width longer than the width of the bottom base, and a length roughly equal to twice the diameter of however long one wishes each diameter of the skirt tube to be.
  • Roll the sheet into the desired diameter and push into two diameter-holders. In the image shown below, two rolls normally used for holding soldering and copper wire are easily used.
  • Line the skirt with hot glue or super glue to prevent the skirt from unfurling.
  • Cut the skirt tube to its desired length.
Skirt1.jpeg
Skirt2.jpeg

Circuit Problems

As shown, the circuit consists of two Ultrasonic Distance Sensors placed away from each other, which are utilized in the Hoverbear's 1st Setting. Centered in the middle are three photoresistors, which are utilized in the Hoverbear's 2nd Setting. Main problems with the circuit were a lot of wires. Much soldering is needed. The Air Chamber Fan and the Propelling Fan are connected in parallel to the Talentcell Battery in a completely separate circuit from the photoresistors and Ultrasonic Distance Sensor. A relay system or use of transistors could have allowed an integration of the two circuits, thus allowing the arduino to control the Propelling Fan.

Circuit 1 consists of the required sensors for all settings to be properly utilized.
Circuit 2 consists of the LiPo battery, the air chamber fan, and the propelling fan.

Rudder Design

The rudders for this hovercraft were replicated from a hovercraft shown on youtube. Using the STL file that the channel put in the description, the rudders from their hovercraft were 3-D Printed. However, because of the propelling fan used for the Hoverbear, the rudders had to be 3-D printed 1.5x larger than what the original size was. The original file came with additional parts that could be used to make a completely different hovercraft, but only the rudders were needed.

These are the parts that were 3D Printed at STS.

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.

https://www.dronezon.com/learn-about-drones-quadcopters/top-drones-with-obstacle-detection-collision-avoidance-sensors-explained/

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.

Results and Conclusions

The final design of the hovercraft was established on April 26th, 2019.

The hovercraft has a weight of roughly 1kg, and can carry around half of its weight in addition to its own. Compared to other larger hovercrafts, this is is fairly small ratio. Hovercrafts like the Hovertrek 4100L Have a weight of around 200kg and can carry roughly 4 people, or 450kg. That being said, the Hovertrek 4100L is traditionally used on surfaces that would benefit a hovercraft, like water, ice, or dense snow.

Out of the three settings established as goals for the group, one of these settings were successfully programmed. This was the obstacle avoidance setting. This setting wasn't overly complicated to code, but due to the fact that the hovercraft was not able to consistently move forwards until a couple of weeks after the code was ready to be implemented, the final adjustments were unable to be made until slightly before the deadline. As such, this left practically no time to implement either of the other modes we had wanted to implement, as we would have needed the time to code, wire, and test each of these modes while we had the much more pressing issue of getting the hovercraft to move properly on our hands.

The Obstacle Avoidance Setting worked as planned. The ultrasonic distance sensors were placed as close to each edge of the hovercraft as possible. The closer the ultrasonic distance sensors were to the edge of the hovercrafts, the more accurately they would be able to give information to the arduino pertaining to if the hovercraft would hit an incoming obstacle. That being said, the arduino was also told to delay switching the rudders from turning position to straight position to be certain that the hovercraft wouldn't hit these obstacles. The intelligence of the obstacle avoidance setting was overshadowed, however, by the propelling fan's inability to overpower forces on the hovercraft that will be discussed later.

The Line Following Setting was unfortunately never applied to the hovercraft, although simple circuitry was established and several examples utilizing three photo resistors were available for implementation. The weight of three photo-resistors would be well below the Hoverbear's Maximum Weight Capacity. Therefore, it is not implausible that, given time, the Hoverbear's final design could have easily implemented the three photo-resistors and show the intelligence needed to follow a line. Like the Obstacle Avoidance Setting, however, it is likely the theoretical success of the Line Following Setting would be overshadowed by the practicality the propelling fan's moving capabilities.

Many arduino vehicles have some sort of Manual Input Setting, and it is unfortunate that time prevented further research for this setting. Considering that this setting only needed an arduino, which is already part of the base weight of the hovercraft, no changes to the final design of the hovercraft would have been required. Just like the first two settings, all that was required was more time, proper coding, and a change in the propelling fan.


The final physical design of the hovercraft had a few differences from our initial design. Initially, the servo motor would directly change the direction of the propelling fan. After some time, it was decided that this would be too cumbersome, and rudders were 3D printed. The servo motor then used a lever attached to the rudder to rotate its positioning. Trials with the rudders before the 26th revealed that the rudders had the ability to change the direction of the the hovercraft, but its directional turning seemed to be overpowered by another force that seemed to be continuously making the hovercraft rotate in a clockwise fashion. After some testing, it was clear that this continuous rotation was not a problem with weight imbalance. Quite simply, it was concluded that this continuous rotation was a result of a uniform torque acting on the hovercraft. Specifically, the blades of the air chamber fan were creating a torque that acted on the hovercraft. With more time, any of these solutions could have been applied to account for this torque:

  • Getting a more powerful propelling fan would be the most obvious solution. As one of the TA's most famously said to the group, "None of your problems here can't be solved with more thrust."
  • The first solution is likely given, considering it would solve multiple problems. However, it wouldn't constantly or directly account for the torque. A more direct solution, as found on This Physics Forum Page would be to utilize two air chamber fans, with "identical but contra-rotating propellors." The logic here is that by splitting one large torque into two equal but opposing torques, the net torque on the hovercraft would be zero while still outputting the same pressure into the air chamber.

It's also noteworthy that most research of hovercrafts do not appear to discuss the blade's torque effect on hovercrafts. The group concluded that this is because initial research on how hovercrafts work was limited to larger scale hovercrafts with a large Maximum Weight Capacity, especially considering the base weight of the hovercraft. It is reasonable to assume that the torque effect on these hovercrafts was nearly negligible due to the inertia of these hovercrafts. This hypothesis was supported by finding other hovercraft designs with less weight that also suffered the torque effect from the blades of the air chamber fan. Therefore, by making changes to the design that would increase the maximum weight capacity and putting more weight onto the hovercraft, the torque effect could be decreased.

There were many setbacks that came about, preventing time for in-lab work.

One such setback was a limited budget that prevented a larger amount of fans to be experimented with. Not wishing to wait for shipping, and with the micro-center a $20 uber drive away, there was very little that could done about this. Given more time, the group believes that the most suitable propelling fan would be another delta fan of the same model as the air chamber fan.

Another way this project could be improved with more time is to 3D print the base of the hovercraft. Styrofoam allowed multiple designs to be experimented with. However, styrofoam is not always airtight, and the aesthetic of styrofoam is not always pleasing 3D printing is much more compact than the styrofoam, and it can be colored as well to add to its aesthetic.

Finally, the skirt tubes, although they worked well, were odd in that most hovercrafts do not utilize tube skirts. A quick search on google will show that many hovercraft designs utilize a bag of some sort to create a skirt. A bag was not utilized because of the aesthetics and it simply did not work as well as the skirt tubes. Looking back, this may have been a problem with the positioning of the skirt. Perhaps with more time, a more traditional bag skirt could have been utilized. That being said, the skirt tubes were a unique solution to expanding the air chamber without adding too much weight.

Rather than focusing on the skirt, however, it would have been interesting to focus on the air chamber itself. Specifically, Research shows that by directing the air flow of the air-chamber fan with a "wall curtain," air is less likely to escape the air-chamber. This is important because air pressure is the only thing keeping the hovercraft afloat.