I was going over some notes from this past year and had a basic design and strategy question for anyone.
During the course of the finals it became very clear that the better robots used the ‘reverse curl’ method to hang during the finale (ie Team 33 and 148 are excellent examples).
My question is: How to you think of this?
I will admit that we missed this method entirely! Was there something that triggered the idea of was it just divine inspiration?
Thanks
A strategic analysis showed that hanging from the side bar was more versatile from hanging from the top bar. You can hang from the side bar from the floor in the near zone, while the top bar needed to be hung from the middle zone or the bump.
Once you determine the strategic advantage, you then start thinking of ways to elevate, when the single joint “curl up” seems the simplest as it takes few motors.
My team could not figure out a mechanism to hold ourselves up on the side bar, so we were going to go for the simpler top bar. We were ultimately inspired by 1625’s post ship video to make a hanging arm that grabs the bar from both sides and elevates using a single joint. You’ll see it at many North Atlantic off seasons.
I find a lot of this kind of thing comes with experience.
People like JVN and other veterans will be able to think of similar tasks from their years of experience. There is also the strength of your brainstorming strategy; as Chris said, brainstorming strategically seems to work the best. That being said, I found a lot of our best ideas came from complete rookies who weren’t locked into a particular way of thinking yet.
The more you see engineering challenges and ways of taking them on, the more you will be able to apply old ideas to new challenges. Which is one reason I can understand why a lot of old engineers get paid really good money in industry.
Ours was presented as a spark from me while I was in the process of yelling (disagreeing) with my Father and his idea of driving up on the bump turning sideways and driving on the platform…
Easiest way to guarantee an idea I view as ridiculous to not be used, (I drove for 4 years and didnt view that as easily doable in a fast paced game) was to present a better idea, and then it hit me.
It First Started with the idea to make a pneumatic climber, up a side pole, which is much easier to grab from the ground and doesn’t need a subsystem to deploy it. It then cam to the realization that a curl would be the easiest and most reliable way to accomplish that. Both because of distance that needed to be traveled and the elimination of many other outside variables, such as the way the robot hung an the worrying about catching on the tunnel, etc.
It seemed like the obvious solution, but we never did get around to figuring out how to do it.
Glad that you mention us.
We initially thought we should hang from the vertical bar because it was more versatile then the horizontal bar. We also determined it would be easier on the drivers because it required less precise line-up and they could just ram the robot into the tower to hang.
We then looked at ways to implement this, including a four-bar linkage and the reverse curl method. One was the easiest, lightest, smallest, etc. and so we used it. It is powered by a CIM motor, 805:1, through a DeWalt then a Toughbox, plus chain reduction, and requires no bungee.
We wanted to:
We noticed Day 1 that the GDC’s definition of the tower allowed for hanging from the vertical bar. We believed a vertical bar hanger would best fulfill the 3 goals above.
In 1999 several teams elevated their robots 6" using nothing but a vertical bar (148 and 217 included). Thinking back to those robots provided inspiration that “this is possible” and some base designs to start thinking about improving.
-John
Emphasis added.
Not divine. Just the sort of inspiration that drives winning design. 
I want to touch on this as it was a topic of discussion between Jim Zondag and myself a couple weeks back. Recalling 2004 how the Bees hung from the upper bar I asked him why they didn’t do that again, it would have been simpler. In fact, one of the things 397 talked about doing was using the method from 2004 (shoot the hook and winch it down) I even had one of the 2337 mentors search his garage for our old winch (long story). Jim said the main difference between 2004 and 2010 was how you could approach the bar. In 2004 you could put a hook at 9 - 10’ and then drive through under the bar. It would catch and you would be done. This year you could not do that due to the tunnel. This meant the driver would have to line up and hook on which was time consuming.
I think a key came with how you interpreted and defined the problem -
If you interprete “hang” - then you focused on grabbing the top and pulling yourself up.
If you interpreted “get the robot higher than the platform” - then that opened up a lot of different ideas.
I will confess that experience was a big contributing factor in our decision on this design element. Way back in 1999, we were faced with a similar problem of hanging from a vertical pipe or climbing on a platform. We chose to do both that year. We never thought of doing a ‘footless’ pipe grabber which could suspend from the pipe only until we saw Team 190’s latch that year. It was a very cool design, basically a snap action Pony clamp.
In 2002 we had to grab and tow a goal from a vertical pipe and many types of latches and grabbers were built by many teams.
In 2000 and 2004 we were faced with grabbing an overhead bar.
Our 2010 solution is a collection of ideas we have previously built or seen implemented successfully in the past.
Because we had actually built and developed solutions for all of these challenges in the past, we immediately saw the advantages of the vertical pipe grab:
Our functional target was to be able to drive from mouth of the goal to the tower, dock and hang in 10 seconds or less. These targets eliminated many tall arm designs. It also put the arm on the back of the machine so we would not have to waste time spinning around. All in all it was a cool device to build and it has been bullet proof through 6 tournaments so far. It is easy to make compact mechanisms robust, since the weight penalty for doing so is much less than it is for physically larger components.
Speed, simplicity, and versatility.
We wanted to be able to drive into the tower at full speed and have the robot be in the air in less than 2 seconds. Ultimately we didn’t achieve that 2 second mark due to design tradeoffs. We realized it would be much slower to raise an arm 9’ in the air, hook something onto the horizontal bar, and then winch/lift up a few feet.
The vertical poles allowed us to achieve our goal of “ram into it at full speed and have it latch on, even if misaligned”. It also allowed us 4 options of where to hang, instead of effectively 2 (we never would have attempted to hang from the side).
Our goal is always simplicity. When discussing horizontal bar hangers we wanted something that would passively extend, which we could then winch down to hang. This would have made self righting complicated, which we thought would be rarely needed, but invaluable when it was required. Alignment is also much more difficult since you are relying on depth perception.
Once deciding on a vertical bar hanger, we extensively debated whether to do a single pivot, 1114 style hang, or the design we ended with. We wanted to retain the ability to go through the tunnel, but came very close to sacrificing it in favor of the simplicity of the single pivot design. Unfortunately this also meant that due to the way we implemented our design we would be lifting the robot with only 2 CIM’s instead of the originally planned for 4 CIM’s. The original goal was to lift ourselves in a a little over a second. We ended up at about 2.5-3 seconds, which was more than fast enough.
The robot hung extremely well, but we were very worried for quite some time that we were spending too much effort on the hanging mechanism relative to the points it would earn us. It was EXTREMELY difficult to make everything work the way we wanted it to (and in the end we had to settle for a solution none of us really wanted). We spent at least a week figuring out how to deploy the arm and then how to hang, with as much automation as possible.
We wanted to deploy the arm passively, but as it turned out the pistons we were using to shift our PTO between neutral, engage, and lock just didn’t have the force to overcome the load of a compressed gas spring, and we could not release the arm. We broke multiple dogs when the sequencing of driving the arm up was not quite right. We rotated the robot too far into the bar and got it stuck almost permanently. We encountered a situation where we could get almost latched onto the bar, but not be able to lift ourselves up, or back away and get off the bar.
Basically my point here is that design really is iterative, as John has said so many times. We encountered a lot of problems and if we hadn’t gone through many iterations of our design we would have had to scrap it, or it would have been mediocre at best.
This was also a really good example of “better is the enemy of good enough”. As I said, none of us were happy that we were forced to stop for 2 seconds to deploy the arm, or that we could only hang with 2 CIM’s instead of 4, but we got it to a point where it worked reliably and fast enough. We could have saved another 2-3 seconds off the total process and achieved all of our design goals perfectly, but it would have taken another hundred plus hours of work to implement changes that would have made us 10% better at scoring 10-20% of our points in a given match. It just wasn’t worth it.
Ours was iteration. We always knew we wanted to be a tunnel robot so we could do everything. Our problem was one of packaging. Having a compact assembly that fit inside the robot then allowed us to hang was difficult. We went through probably 4 different designs before we were happy with one of them.
At the end of this video you’ll see a nice shot of us hanging simultaneously with Bees (at State Champs) and Rush doing the same with their hanger but running out of time.
Our system required a bit of finesse to latch on, and we were rarely as bad at latching as we were in this video. Chalk it up to first round jitters on the part of our driver 
.
You can see where the “slam into the bar” here saved time for the bees - it took us probably 2-4 seconds longer to get locked on. Unfortunately, we also made our robot too rear-end heavy. You can see the result as we’re a second or two slower to get up than they are.
In the end, as someone else said - once we had it down to hanging in under 8 seconds, we decided it wasn’t worth it to keep going. We had thought about connecting it up to our drive train, but simply didn’t have the “drive” (pardon the pun) to get it done in time for Atlanta.
This is exactly what I was going to suggest. To expand a little further, this all boils down to the first part of your design discussion which is “What should the robot do.” Emphasis here is what and not how… this is often times the hardest thing to overcome in a design discussion. As Chris pointed out, the what is “get the robot higher than the platform.”
Here is a great thread on the “reverse curl” without really saying so much:
We didn’t start working on this feature until the last week of the build season. As others have said, we weren’t sure it was worth it for just two points. Our base robot was pretty heavy (a very rugged frame) so we didn’t have much weight to allocate to the hanging mechanism. We considered grabbing one or two vertical poles and flipping up but didn’t think we could get the mechanism working in just a couple of days. The hanger we ended up with was pretty reliable, very lightweight and very easy to develop. We designed it to work on the side bumps for two reasons: we decided fewer robots would attempt to hang from the side and the distance we had to lift was much less. Our mechanism was not as fast as others but was still pretty fair. In one match, our driver was defending in the far zone, scored, crossed the far bump, climbed onto the near bump, moved into position and hung - all in the last 13 seconds. Not too bad for a very simple mechanism. The design had nothing to do with how the problem was interpreted - the design was the result of practical considerations.
For 1511, the concept had come up in the original brainstorming, but was not initially selected. After watching teams compete at our first regional and struggling to get a consistent hang with our designed mechanism, we scrapped the first design and spent the next week on the reverse curl retrofit.
At our second regional Thunderfoot underwent a dramatic transformation on Thursday. I’d say that we relied heavily on the success of other teams’ reverse curl engineering!