Esther's Water Bottle Parametric Modeling
In this project, I created water bottle parametric model that can be easily changed to fit different type of user in different environment. My base three configuration is for: Biker in San Francisco, Child in Ankorage, and Elderly in Dubai. The design model is adjastable for each user by implementing different parameter on: Mobility, Temparature, and Dryness. The mobility factor indicate how much the user is mobile. As the user is more active, the higher mobility factor need to be input. However, if the user has lower quality of movement such as child or elderly,the low mobility factor has to be applied. The temparature factor is for Thermostat. The bottle thickness will be increased depending on the cold temparature between 32F and -76F. The dryness factor is for dry location which requires a lot of water to quench a user. As the location is more dry, higher number has to be applied as a dryness factor so that the volume of the water bottle is increased, and the bottle opening gets bigger for really thirst user.
Description of design drivers / goals
* Goal 1 – create easy grippable water bottle for different user
* Goal 2 – Create stable design.
* Goal 3 - maintain good water quality
* Goal 4 - Quench the user in any environmant
Logic diagram
CAD models
Parametric variations: Images
Here are some examples of what happens when I vary the parameters….
Unexpected case 1
The opening(straw) goes to inside of cap.
Unexpected case 2
When the bottle height is too small, the curve make strange configuration.
Lessons learned
- Check its configuration at each step before setting the next constraint
- To have more flexibility, limit the number of constraint
- Each workbench has different functions
- Limited use of formula function (it is not an excel sheet)
- Flexible use of workbench
- Difficulty to find overlapped constraint(violet)
Discussion
Esther, take a look at the Syntax page to fins out more about how to format your page. More specifically you may want to use headers and the formatting syntax to control image size.
Nice work, I really like the fact that put in a cap to your bottles, it makes them look more real.
I agree with Fernando - great job! I like how sleek yet simple and usable your bottles are. I'm wondering, how were you able to have caps on some of the bottles and not on others? (Did you somehow make a parameter that the cap would “disappear” or did it flip and go down inside the bottle?)
It's pretty cool that even your unexpected cases are attractive bottles and could work for other certain demographics. For example, the second unexpected bottle reminds me of Christina's forty parameter of an “overflow reservoir” - maybe that bottle could be used on boats? :)
Very cool design. The biker's water bottle actually looks like a sleek and marketable squirt bottle, and with a few parameter changes it can change into that “unexpected case 2” thing. In that regard, I'd say your design was a success. I also like how you included the temperature as a parameter controlling the container thickness, so a picture of, say, the sketches of two different temperatures would have helped visualize this. Nonetheless a great project.
Well done! I especially appreciated that you clearly presents the design drivers and the set of goals. Also sharing unexpected cases as well as lessons learned provides us Swedish PhD-students with useful insights of what might go wrong.
// Erik.
Very nice presentation, Esther. I totally agree with the students who write the comment. Your bottles are really exact right model for each condition. Moreover, your diagram is so logical.
I am really impressed with the shapes and curves that your models produced. I also like that you thought about the actual sipping mechanism when building your design model since that is something that everyone else overlooked.
A better way to do the Bottle and the cap is to do then as separate Parts and then constrain them together in an Assembly (called Product in DP). If so you define your Driving parameters at Assembly level and then relate these to parameters at Part level to get a Product.
I also think it is cool that you ran into the case where your cap got inverted - this is one of the less obvious things to think about when constraining a design and so is a good lesson learned.