Coding- Final Project

In order to build the eyes and eyelids, Christine and I needed the materials that Hande ordered. So, while we were waiting on materials, we started coding our eye movements in LabVIEW. However, in order to code our eye movements in LabVIEW, we needed to understand how the ultrasound sensors worked. So, we started there.

We tested the ultrasound sensors using some trivial code which said read the values of the sensor and print them out to the screen of the NXT until somebody physically stops the program.

Trivial code which reads the value of the sensor.
Lack of icons because the version of LabVIEW
on my computer is experimental, so I couldn't load the
NXT module. 

We found that the ultrasound sensors sensed pretty well. They printed out values between 0 and 255, where 0 is when you have your hand on the sensor and 255 is the maximum value. They were a bit sketchy when objects got too close (within a few centimeters of the sensor) and they would oscillate between the real value and the max value. However, we did not think that this would be a detriment to our project, since we would assume that nobody would walk within a few centimeters of our puppet. We also found that the sensors were extremely accurate and would pick up values when we waved our hands about half a meter in front of the sensors.

Ultrasound sensors configured to test values

So, after we tested our sensors, we started coding. However, minutes into our coding, we decided that it would be too complex to start with code. Rather, we decided to reason about our code on paper, and then translate that reasoning into LabVIEW.

An outline of our code

An outline of our design decisions:

•  Three sensors
•  5 angles for eyes based on which sensors are currently sensing somebody: -60, -30, 0, 30, 60.
•  The direction that the eyes move in depends on which angle the eyes are currently at and which sensors are currently sensing somebody
• For example: Wendy just woke up, so her eyes are at 0. However, Bob over to Wendy, and only is infront of the first and second sensors [sensors numbered in order]. So the eyes move to look at Bob, which means that the motor controlling the eyes goes backward until it registers -30 degrees. However, if Wendy hadn't just woke up and instead was watching Bob's friend Carol who was to the left of Bob, covering only the first sensor, the motor goes forward until it registers -30 degrees.

We spent a really long time iterating on our code for a variety of reasons.

• We originally planned on our range being only 90 degrees, instead of 120 degrees. However, this was not that noticeable for people who were just left or right of center. This was the easiest fix we made, as we just had to change our constants.
• In our first version of our code, we measured rotation every single time we wanted to use it. Now, this is absurdly inefficient. Measuring rotation is expensive, and doing it two to four times every single time around [I would assume] would make our eyes too jerky and not particularly creepy. So, instead of measuring rotation every single time we wanted to use it we just wired the value to every spot that we used it. I realized this strategy was too inefficient when we were not particularly far into it, so we never actually came close to completing or testing this code.

Second Iteration of our code

• So, the second (and the first for that matter) version of our code was coded under the assumption that only boolean values could be entered into case structures, an assumption based on experience with other programming languages and lack of experience with LabVIEW. So, these values were generated by comparing the rotation value to the our target values. We then made a really complicated case structure combined these booleans with other boolean values which asked is there somebody in front of my sensor to determine whether the motor for the eyes should go forward, backward, or brake. However convoluted this scheme was, we did not know a better way, until in class the next day, Chris suggested a new way.
• Our third version of the code entered the rotation value into the case structure. This way, we could make cases based on ranges, like 3-27 degrees instead of teasing out the ranges from a bunch of booleans. [Tip: the code will not compile if all cases are not covered. For True/False cases, it comes already preset. If you use numbers as input, like we did, you either need a case called "default" or cases that cover +/- infinity, by having one case that goes from ..-minVal and another case that goes from maxVal-.. . The ".." signifies and to infinity.] We still had nested case structures, to tease our which sensors were currently detecting something. We also changed the values of our rotations to be not the actual value, but the value mod 360, which made this value reflect the angle on the circle. When we ran our code after making this one change, our eyes kind of followed our hand, a great improvement from our previous iterations.

Third iteration of the code- this case is simpler than most

• The only differences between our third iteration and what we ended up at the end were minor.
• Instead of aiming for a singular target value, we aimed for a target range, from +/- 2 or 3 from the target value.
• We got rid of the shift registers. We tried to implement some proportional controls, and that made our code work even worse, so we gave up on ever implementing derivative controls.
• We noticed that sometimes the first value was not particularly accurate, so we decided to throw away the first reading.
• We also noticed that sometimes, when there was not a hard background behind her, that she would always register that somebody was in front of her, so I added a case structure that said if the value is greater than 180, that is if there is no close background, then just let 180 be the background. Else, let the measured background be the background value. This makes the code more modular, since it will work regardless if there is a close background or not.
• I also connected the pink wires into the case structure. This really didn't change anything, at least from observation, but it makes the code more logical, since the pink wires show sequence.

Final iteration of code broken up into two parts because
it did not entirely fit on one computer screen.
The other case structures control the brows and lids.

After exhausting all of my time on they eyes, I did not really have that much time to invest in creative coding for the eyebrows and eye lids. My first iteration was did the exact opposite of what I wanted (close eyelids when somebody was there, and open when nobody was). My second iteration worked. The code for the eyebrows and lids are almost the same. They are proportionally controlled and move only based on whether any sensor is sensing somebody or no sensor is sensing somebody. I should note that the code assumes that the eyelids start closed. We ran into issues here when we reset Wendy without resetting her eyelids. However, I cannot think of a good solution to fix this - the NXT automatically resets the rotation to zero whenever it is restarted. I could have assumed that the eyes start open, but this makes no sense.


Jaw:

So, I was in no means responsible for the jaw. However, I did help out in the coding. [Also, all of the sound recordings are my voice.] Hande coded all of the individual phrases, moving the jaw to mimic the motion that a human's jaw would. I helped her integrate all of the phrases into one file "mouthGo.vi". Here is the design process from after Hande coded all of the individual phrases until we finished:

• We needed to hook up the jaw some kind of sensor so her speech wouldn't be completely routine. Also, we could not use the three ultrasound sensors because each NXT device only has room for running 3 motors, and the NXT hooked up to the ultrasound sensors was also hooked up to 3 motors (eyes, eyelids, eyebrows). So, we decided to use a microphone. We wanted to have a different sensor and our options at the last minute were limited. It was also fun to try out a new sensor. We also could use this to have three states: "not present", "quiet but present" and "present and talking".
• "not present" -> do nothing
• "quiet but present" -> say "come closer"
• "present and talking" -> start a conversation
• Next we tested the microphone. We found that the microphone was extremely sensitive and the difference in background noise between different places made it impossible to have an absolute range for "quiet but present" and "present and talking". So, we used the difference between the current value and the background value for input, rather than just the current value. We also noticed that the variablity in any given place was about 20 units, so we set our "quiet but present" to be 15-30 above background, and anything above that to be "present and talking."
• Finally we combined everything into one big while loop. So, every time around, we measure current sound. Then we subtract off the background value and hook that number into a large case structure. We had 3 cases corresponding to the three states defined above.
• "Not present" was empty.
• In "quiet but present" we pasted in the code for "come closer."
• "Present and talking" had the largest amount of code. We had two case structures: one for the greeting and the other for the talking. However, we weren't sure what to put in the case structure. My first thought mod-ing a random number by 2. But, I couldn't find a random number so I used the sound, since this number was random enough. So, we hooked up this number mod two to the greeting block. If the number was equivalent to 0 mod 2, then she says "hi", else she says "hello." She then waits for awhile for the person to talk back to her. Then if the floor of the number divided by 2 was equivalent to 0 mod 2, then she says "hmm... interesting" else she says "tell me more."

First half of the final code

Second half of the final code

I've embedded some tips, but here are some more general tips.

• LabVIEW lets you label your code, so it makes it a lot more clear if you use that feature. I wasted hours and hours looking for a bug that probably could have been avoided if I had labeled everything.
• Before going intense bug hunting, first check that all of your ports are labeled correctly. Incorrectly or forgotten port labels were the majority of our bugs. Sometimes it is execution, not design.
• Notice, that the "clean-up" button does not always clean-up the same way. In addition, with our final version of the code, when you press that button repeatedly, it swaps all the elements around and sometimes makes the area larger or smaller. This makes it confusing to resume working exactly where you ended. So, be very careful right after you press that button, so you don't end up changing a large chunk of code. I did this. It took me hours to undo.
• It's easier to code things in chunks in different files and copy the contents of each of the different files into a new file. Hande did this with the code for the jaw, where each phrase was coded in a different file and combined in the final file. Christine and I did this in the eye code by coding up the brows and lids separate from the eyeballs and pasted them all together in a final file.

[As a side note, the coding part of this project reminded me of this comic: http://xkcd.com/844/. ]

Modeling - Final Project

So, after we decided that we were going to construct a Wendy head, we defined the scope of our project and split up the tasks. I will spend the majority of the rest of this blog detailing the parts that I was responsible for, the eyelids and eyebrows, and the parts that I played a major role in developing, namely the eyes. I will also touch upon the parts that I did not have a direct hand in, namely the jaw and the structure of Wendy, which Hande was responsible for.

A preliminary sketch of Wendy (sketched by Christine)
Note: this was sketched after Lyn walked by and
after we had scrapped our two-dimensional eye ideas, as modeled below.

So, first we thought about our particular parts individually.

The eyebrows were fairly straightforward because they are isolated from any other moving parts and my first idea of having them made out of delrin sheet plastic, but having a (tight fit) hole in the middle to put a rod connected to some connected gears, one of which would be hooked up to a rotating motor. This design would change as time progressed, but only slightly. These changes will be outlined later.

The eyelids were not as straightforward and their design completely depended on the design of the eyeballs. Christine's first idea for the eyeballs was to have them be two-dimensional. As you can see in the prototype below, the cornea of the eye would be a gear, perhaps covered in paper or something. Then the whites of the eye would be paper. The eyes would move when the gears moved across the track. The two-dimensionality of the eyeballs I tried to reflect in my design for the eyelid. I imagined them as an almost like the curtain in my dorm room which would roll in and out when she blinked her eyes. However, before I worked out all of the details, our professor walked by and suggested that we try to make the eyelids/eyeballs three-dimensional. This totally changed Christine's design, which turned into balls rotating on sticks. I decided to punt the design of the eyelids until after the design of the eyeballs, as to design the eyelids, I needed to know the constraints that the eyeballs would add. However, we needed to buy supplies (a task that Hande took on) and so I arbitrarily decided that the eyelids would be made out of ping-pong balls. However, I also knew that if ping-pong balls didn't work out, then I could try to work something out of materials scrounged out of the craft table in the lab. 

An early prototype of Wendy

Brainstorming - Final Project

After we chose partners, our first task was to brainstorm ideas for our final project. This project was left very open-ended; our only constraints were that it had to be a kid-appropriate puppet that used everything we learned this semester, or at least used pieces cut out from the laser cutter and some "smart" functions.

So, Christine, Hande, and I went back and forth with ideas. Here are our four main contenders and our reasoning for rejecting our three rejected ideas.

1.) "Wendy Wellesley" She would be a bust of a person. She would interact with whoever walked by her in her display case in many different ways; she would follow them with her eyes, make faces at them, offer words of condolences, and rotate her head 360 degrees. These actions would be triggered by her sensing her surroundings using a camera to sense where the people in front of her were, and a microphone to sense the words that people are saying. We considered trying to sense what people were saying, but we really don't have the expertise to do such sentiment analysis.

We ended up going with a version of this puppet. We heavily modified this plan and a description of what we ended up with will follow in future posts.

2.) Dancing Elephant. This elephant would have a repertoire of learned dances such as the Macarena, YMCA, shopping cart, Tunak Tunak Tan, etc... When a person called out a dance, he would dance that particular dance to music. Also, when he wasn't dancing, he would have some other reactions to people. Originally, we also thought that this elephant would have mannerisms similar to our professor, but our professor told us that it would be too creepy to do so.

This idea was the most popular with our classmates. However, after consulting with our professor, we were fairly certain that this idea was way out of reach. We then tried to modify this idea to make it more feasible (by turning the elephant into a marionette puppet and only having one dance, or perhaps instead of learning a particular dance, having one side of the marionette controlled by the user and the other side controlled by a program) but these ideas did not resonate the same way that the original did.

Sketch of dancing elephant - courtesy of Christine

3.) (Dancing?) Shadow Puppets. I love shadow puppets and thought it would be cool to make a shadow puppet. This puppet would consist of delrin sheet plastic connected by delrin rods on the pivot joints. The motors would control each of the limbs of our puppet directly (we were afraid of using string, because dealing with tangled string would be too much of a headache). All of the plastic would be in a box behind a sheet and a light would shine on the sheet, revealing only the shadow of the plastic. This puppet would execute a predetermined show. I thought it would be a little easier to execute, because we wouldn't have to cover the delrin plastic with anything and nothing would have to be three-dimensional. It would be tricky to hide the motors, but that would be one of the only concerns.

This puppet wasn't very popular with our class and therefore we abandoned it. We also thought that it would be too simple, because it did not use any complicated sensors; it just would use a simple touch sensor which would signal the start of the show, but that would be the extent of the interaction.

4.) Sock Puppets. This project was inspired my dad. I used to complain that I did not have a radio in my room and to compensate, he used to throw sock puppet shows to get me to bed, complete with songs and everything. So, for our project, we would have some puppets made of plastic controlled by some motors which would be covered by some socks. These puppets would interact with each other and the audience, which it would sense with a camera, and give an interactive show similar to the interactive shows that my dad use to throw. We also thought it might be fun to have them be male and female puppets where the male puppet would react to low voices and female puppet would react to high voices.

This puppet idea also wasn't popular with our class. We also did not have a really clear vision of exactly what kind of show we wanted to throw. For any given show idea, only 2 of the 3 members of the group agreed, so we did not have a clear direction. For the above reasons, our group decided to drop this idea.

Sketches of 1,3,4 - courtesy of Christine

Days 3-5 - Bird

The next few days we spend designing our bird in SolidWorks, printing out pieces using the laser cutter, and iterating this process until our design worked.

Our final working version of our bird

It looks more like a bird when covered in pink paper.

The assembly version of our bird.
The wings only move up and down without flapping since we could not figure out how to use gravity in Solidworks.

The important pieces of our bird in SolidWorks

We also added pianowire to secure our structure since the fits are too large and it is way too much plastic to be worth printing out everything out all again. (Before pianowire, the structure falls apart when dropped.

If we were to do this process again with infinite resources, we would iterate on this to get our structure perfect without any piano wire, but alas. In this infinite time/resources world, while we were reprinting out our structure, we would also file down all of our washers to make them all perfectly flat, which would cut down on the amount of friction, cutting down on the amount of effort to turn the crank.

An overview of our process after the sketch and model phases were complete:
1.) Design mechanism (no wings, no housing) on SolidWorks.
2.) Print out pieces in 1/8" Delrin plastic.
3.) Fit pieces together.
4.) Repeat 1-3 until mechanism works.
5.) Design wings.
6.) Print out wings and add to model.
7.) Design housing.
8.) Assemble total bird.
9.) Repeat 7 and 8 until works. (We just added piano wire when we were close.)

A few notes from this process:

Our working mechanism with wings.
My hands are where the structure should have been.
Note that our circle is not really a circle; it still works, so we haven't changed it.



Our wings' "house" which we envisioned would be held up with a delrin rod

• 

  Our device with foam housing
• Not making a Lego model really hurt us when we built the structure to house our wings. We built our original structure on the wrong plane, which was completely absurd after it was printed out in plastic.
• When making a SolidWorks assembly, insert your fixed piece first because SolidWorks fixes the first item. Make sure that this piece is the final version of it to save you lots of time and heartache later. Everytime you update a piece, you have to update all of the connections.
• Print out more washers then you think you will need. We ended up using twice as many as we had though we would need. However, it also took us quite awhile to find the perfect diameter for a washer as it is not .25" nor is it the same each time. Only print in multiples once you found the sweet spot for your laser cutter on your day on your piece of plastic. (Ours was more like .234".)
• Make the assembly before you print out your model, or even write down your measurements before you print out your model. Our initial measurements did not even make any sense. Our two rectangles were both about 3 inches long. Given that the backbone two our model had to be no more than 6 inches long, this makes no sense. Iterations based on absurd sizes do not make sense. After this point, the rest of our iterations were based on the size of the holes to fit delrin rods into, since the holes have to be just right, and there is variability based on factors outside of SolidWorks such as the laser cutter's precise allignment, where on the sheet of plastic the piece was placed, and the particular sheet of plastic printed on.
• Below are some of our initial SolidWorks designs which we printed out in plastic. Only the large circle did not change.

Our initial backbone. We designed this and decided to design the housing later. It seemed like a good idea at the time. On the up side, it allowed us to tinker to get the holes in the right places with the right diameters. On the down side, we had to make two assemblies and it took us longer than we could have expected to design housing.



The total possible movement for the birds wings depended on the distance between the two inner circles, so this was designed to maximize this distance.



The design was fine, except it was too long. Our next iteration is about half an inch shorter in length. We forgot to accommodate for the half circles at both ends.



You may not be able to see this clearly, but the difference between the long hole and the short holes is different on both ends. One bridge is too wide and the other is too small. As circles are hard to get precise in SolidWorks, we used a process similar to the process from my BottleOpener, placing guidelines to make sure that the bridges are even on both sides, the correct width, and in the correct place.                                                                                      

When we wirefitted the structure, we accidently wirefitted the wrong side. When we printed out the backbone, the bottom hole was too small so we had to drill press it larger. We only drill pressed out one side, so no rod could easily move around in the other side. To compensate for this, Hande sanded down the rod so it would fit. This made the washer on the crank side of the bird not fit, so I added paper on the inside of the washer to get a tight fit.



The wire fitting



The makeshift washer

Day 2 - Bird

Today we made physical mock-ups using legos, foam core, and lots of tape of our two primary contenders from last class.

First contender:
This model was based off of our super simple design which looked like an elegant, efficient design on paper. However, it did not reliably cause the wings to flap. We tried doing a similar model with two cams, which had even more problems. As it would have taken a lot more effort with unclear results and adding more parts to this design would compromise its appeal, notably its charming simplicity, we decided to scrap this idea.

Second contender:

Conveyor Belt

model with wing

This model was based off of a conveyor belt where a rod with an attached wing would mimic the flapping motion.  We were brainstorming this idea while trying to come up with a fifth sketch. We couldn't understand each other and were unable to communicate in pictures, so we decided skip to making a lego model. However, our instructor advised us against using this design based on the difficulty to execute properly in plastic.

The lack of usable ideas left Hande and I without a clear plan. However we became inspired by this model made by previous Wellesley engineers.

We decided to implement this design, adding wings connected with an axel at the top. We made a rough sketch and then proceeded to model our design in SolidWorks.

A rough sketch of our idea

Some of the highlights of our design decisions:

• We decided to make wings that resemble forks. We figured that we could cover them with paper so that they could resemble wings. This cuts down slightly on the weight of the wings, which would allow us to use slightly less durable housing.
• We decided to make our big circle 0.95 inches in diameter. We had to scale down the previously made model because the backbone was larger than 6 inches and that is a piece to fit in a base. We scaled down the circle less than the other pieces because the size of the circle limits the amount of movement possible.
• In the previous model, pieces were hitting each other when moved where they should not have. We wanted to fix this by making sure that all of our pieces were small enough to clear each other, albeit by a minuscule amount.

Day 1 - Bird

This next task is to design a device that converts the rotational energy of a crank into a flapping motion. Our design is to be made primarily of delrin plastic and no one piece is to be bigger than 6" in any dimension.
This first day was dedicated to brainstorming ideas and sketching those ideas. My partner, Hande, and I spent most of this day thinking about the flapping motion and came up with a number of ideas.

"Weighted from Top"

How it works: You turn a rod which rotates an uneven cam. This cam lifts up a small ledge which causes the entire vertical rod to move up and down. When the rod moves down, the middle wing ends move down, the wings pivot on the structure, moving the outer wing tips to move up.

Why it was not used: This design is overly dependent on the elements on the vertical rod to stay firmly attached to the rod, not so feasible. This is also assuming that the small rod which you turn stays perfectly horizontal, a bad assumption. Due to these reasons, we did not decide to move forward with this design.

"Wobbling bird"

How it works: You turn a vertical rod which has an uneven cam at the bottom. This cam hit a disk attached to a rod. The horizontal rod moves back and forth, depending on a rebound from the edge of the structure to move in the opposite direction from the cam. The movement of the horizontal rod causes disks to hit the end of a wing, which tip the wing, causing a flapping-like movement. However, the disks alternate which wing is flapping at any given time.

Why it was not used: There is so many issues with this design. The wings are "floating." The rod moving back and forth relies on a rebound effect, which means that the force going the first direction will be greater than the force going the opposite, so the wings are not only flapping at opposite times, but in uneven amounts.

"Simple, Elegent"

How it works: You turn a rod which turns two uneven cams. These cams push up on the middle ends of the wings, which cause the wings to pivot on the edge of the structure, moving the outer wing tips to move down.
Why it was used: We picked this model to build a lego model on based on its simplicity. It is also important to note that the wings on this model rely on their fish-like shape stay in place and they also never meet in the middle.

Model from previous Wellesley Engineers

This model inspired the next sketch.

Hinged wings

How it works: The wings are connected by a hinge. The wing tips are moved down from a weight pressing down right on the spot where the wings connect.

Why it was not used: This design has no really good place for a person to turn something.

Day 2 - Bottle Opener

Since my old partner missed today, I got paired with a new partner, Carrie. Her idea was to make a bottle opener inspired by an oar; she used to row crew and thought there would be a fairly large market on campus for a bottle opener that looked like an oar. She also wanted to make a bottle opener which was small enough to fit on a keychain so people could carry it around with them just in case.

Picture of an oar

Foam Mock-up of Carrie's oar design

Notice how this device uses a different mechanism to open bottles. Instead of using a hook, which is useless after it chips, this uses a 3cm long curved edge to open bottles, which can still possibly be used after some slight chipping. Also notice how the curves on the device are different on each side similar to the curves of an oar.

However, this device was not as easy to use as my ideas from Day 1. So, we decided to combine our ideas. We made a new device inspired by the robustness and oar design from Carrie's bottle opener and my easy-to-handle design from Day 1 and created a hybrid bottle opener.

Foam Mock-up of our hybrid bottle opener

How this bottle opener is meant to be gripped

Our bottle opener in action

Note: this is just a preliminary mock-up. The main change we are going to make is the location of the bumps because the current placement is really awkward.

The handle length was a compromise between my long handle and her short handle. The length of this hybrid was long enough to fit my large hands but small enough to where there was not any extra space at the end that stuck out. We also made the support on each side thicker than Carrie's original because we did not want our device to snap in half while opening a bottle. When we made our foam mock-up, Carrie diligently measured everything to be a nice measurement (an whole centimeter amount) which helped us when we eventually diagramed it in SolidWorks.

After making our foam mock-up, we started to design our bottle opener using a computer program, SolidWorks. We decided to make the top part symmetrical, a departure from the oar inspiration because with the bumps the device really did not resemble an oar. We started our handle by first drawing a rectangle of correct dimension in SolidWorks. {It should be noted that from this point forward on this project, I worked without a partner.} Then I added the bumps, and finally took out all of the extra lines. The bumps on the side took a long while to diagram in SolidWorks. To diagram them, first I measured the length from the top of one bump to the top of another bump using a previous design of an ergonomic handle which fit comfortably in multiple sizes of hands. Using this wavelength, I drew vertical centerlines of infinite length to use as a guide. Using these, I drew 8 consecutive 3-point arcs in alternating direction of the same radius. This made drawing consistent arcs of the same size more precise compared to freeform as once I created my first arc, the next would easily set to the same radius. Finally, I deleted the guidelines and then used auto-dimension to set everything in place.

Diagram of bottle opener with guidelines

Diagram of bottle opener after guidelines removed

Diagram of bumps with the guidelines

Diagram of bumps after guidelines removed

Alas, after I cut it out of 1/4" plastic, it was unable to open a bottle of pop. To be thin enough to open a bottle, the plastic needed to be thinner, but to be thick enough to withstand the pressure, the plastic could not be much thinner, a conundrum which renders this design in it's current state not particularly useful. I tried sanding it down, but after trying it on a bottle, my work was chipped away. However, I learned a lot about how to diagram ergonomic bumps in SolidWorks and will use this knowledge to move forward as I try to create my top design (the fourth one) from Day 1 in SolidWorks.

Unsuccessful bottle opener in plastic

The next design I tried used a hook mechanism to open a bottle.  I also continued to be inspired by things that are easy to hold. I was even more motivated to continue my quest for the perfect ergonomic bottle opener after googling "ergonomic bottle opener" and only finding super fancy bottle openers in the first few pages of results. Using my fourth design from the previous day, I continued on my journey.

The second SolidWorks diagram was much easier to make even though it was more involved and the foam mock-up off which it was based was not made with precise measurements. After editing it more, I made the bottom part too small and when I printed it out on the laser cutter, it bent under pressure and was unable to open a pop bottle.

Second bottle opener- plastic edition

For my third iteration I made the part that goes over the bottle thicker and added a small bump. This hopefully will be thick enough to withstand the pressure. I also smoothed out the corners around the ergonomic bumps because sharp corners are against the ergonomic philosophy. After my design was cut out of Delrin plastic, I had other handle this bottle opener and they all found it fairly comfortable in their hand. [The picture below is without the smart dimensions which are so thickly defined that you cannot see my design well with them.]

Third bottle opener diagrammed in SolidWorks

Third times a charm

How to hold the bottle opener

The bottle opener in use

This design opened a bottle!

If I were to continue working on this project, I would like to have tested it until it broke to figure out how reliable this design is and where the weak spots are. I would assume the major weak spot in my design is where the foam broke when I made my foam model, but I really do not know for sure. I would also would have like to have tested it with different length and depth of finger grooves. The ones on my design seemed fine, but there might be a better fit out there. I also might make different sized grooves for different sized fingers, because my current model has uniformly sized grooves.