On Secrecy and Team Egos

6 Comments

I was digging through some old photos on Facebook the other day and found an interesting conversation on a picture of one of my friend’s electrical boards. On it, some kid from another team made a comment about how complex their robot was for running 8 motors, when his team had only 3. I posted a comment basically asking why that was and if their robot was working alright, since it was just a few days before ship. He responded  by saying something to the effect of “yeah, it’s working just fine, if we added more we’d be overweight anyway”. Another friend offered to help make suggestions for weight reduction so that they had weight for a better drive, ball magnet, etc. and the kid responded with some comments about how their robot was just fine, it could kick and hang “just like 148 could”, and that he did not want to reveal any team secrets by showing the robot a few days before ship.

This team went on to lose more than two thirds of their matches, and they only got their fourth win at their third event.

I started thinking about those comments today and was wondering what was going through this team’s head. It seemed they had a bit of an inflated ego, and that this ego led them to decide that their robot needed zero improvement. Not only that, but even just a day or two before ship, revealing anything about the robot would give them a competitive disadvantage. The former is a bit of a problem (honest self analysis is difficult but immensely helpful in the design process) but it could be solved if it weren’t for the latter. What if the robot was posted to CD a week before ship? Looking at just their TBA picture I could point out where they could shave down at least 5 pounds (they had 80/20 brackets and 1/4″ plate on everything). What if it wasn’t even posted on CD, but just shared with some friendly teams or other people that need advice?

I’ve always thought that a secret philosophy with robot building is always hurtful. There are several different cases, and I think for each one there is benefit to being open, although this cuts off severely once you reach the very most competitive robots. This plateau is one that far too many teams think they are on, when they really aren’t there yet. As a rule of thumb, if you have to ask, you aren’t there yet.

  • Case 1: A young team without many resources or engineers. This team is very, very unlikely to come up with a World Champion robot. In terms of their competitive success, if they share their robot and solicit input throughout the build season, they could potentially get design critiques and improvements that would help them find on field competitive success. If the choose not to share, it’s unlikely that this team will gain anything. They are not very notable at all so no one would strategize against them with the “leaked” knowledge of their robot. They probably do not have a fantastic innovative mechanism that is only good because no one else has it. Overall, they personally have everything to gain from sharing a robot.
  • Case 2: A middle ground team with engineers, some friend teams, and some talent. This is where I would put Shaker Robotics. This team also has the same things to gain as the young team above. In addition, this team has the additional chance of inspiring other, younger teams with their designs and prototypes. Even older teams could stand to benefit from their design sharing. At least one team on Einstein this year asked for the exact part number of a gate latch I posted on CD (no word if it was used on their robot). This team gets a bit more notability and attention than they otherwise would, and that increase in attention alone can make up for any negligible loss in competitive advantage.
  • Case 3: A high resource team that has a very good robot. This team stands to lose from revealing the nuances of their design, however they have a lot to gain as well. They will garner attention well before their first regional, so even with some bad luck they will stay on the radar. Others will be inspired by their success, making more teams competitive and deepening the field of play. On the off chance this team made some mistakes, others can point out slight improvements they could make to be even more successful. The competitive drawback is mainly if their mechanism is something not many teams had thought of before; however by being the originators of the design and having worked on it for longer, as long as this team continuously improves they will always be “a step ahead” anyway.
  • Case 4: This is the case of team IFI, team 469, and the other top tier teams. These teams really have nothing to prove, will garner a lot of attention on their own, and will inspire others no matter what day they choose to reveal their robot. These teams are strong enough that they may have mechanisms that are so ridiculous they could win the World Championship. I’m not going to weigh the pros and cons of sharing designs for these teams, because it’s pretty obviously at their team’s detriment. I have been on a team that firmly believed that they were a Case 4 team.

Something to note is that often, teams feel they are in Case 3 and Case 4 when they are really a Case 2 team. Their mechanism is probably a design a lot of teams have already thought of, and have on their robots, so “revealing the secret” of their design probably won’t lead some team to beat them. Even on the off chance that these teams are at the very top of FIRST this season, the worst possible outcome is that another team gets inspired and does a little better than you, but when you factor in things like the entropy and luck of FRC, the inspired students on the other teams, and the opportunity benefit of getting design critiques or notoriety, is that slight risk really worth cutting your team off from everyone else?

Shaker Robotics will once again be posting “everything” in 2011. There is merit to not posting “everything” initially as it can take away from the learning process on other teams, but as we complete prototypes and head toward the final weeks of build you will be able to see all our results and designs. One of my favorite things about this team is that our ego isn’t yet big enough to think that we’re at the top. We’re pragmatic enough to know that we are not the top tier and that everyone stands to gain from us sharing parts of our design, especially ourselves.

I’d be interested to know what others thought about sharing and whether or not I made any sense. I mean, it is 8 AM.

Vex IED Final Project: Week 1

Leave a comment

For the latter two thirds of my Intro to Engineering Design class, teams of 6-8 students work together for about 10 weeks on a final project. Unlike the mini project, most of the challenges aren’t open-ended competitions, but rather specific problems that need to be solved in some way. However, one of the teams gets to compete with local high schoolers in a competition using a Vex robot and custom 1v0 game. Guess which one I’m in?

The rules are pretty open ended and the tasks are pretty simple, so there’s not much strategy to the game since each task basically leads to the next. Navigating through a tunnel autonomously gets bonus points. 10 points are made for getting halfway through the tunnel, and 20 points are scored for autonomously completing the tunnel (about 72 inches of driving with 2 turns). Once past the tunnel, a set of small stairs must be climbed to get to the main portion of the field. Once on the field, various objects must be retrieved from various places (behind a door, on a shelf) and brought to within arm’s reach of a sitting human player for additional points. 20 points for a soda can behind a door, 10 points for an accessible soda can or a plastic bowl, 5 points for a juice box or some utensils. Field photos will be around in a week or so.

For build constraints, you get to use $200 of Vex parts, a Starter kit, and whatnot basically. This is kind of flexible and donated parts don’t count (guess who gets to use their Cortex?) so as long as we don’t spend too much of RPI’s money they don’t seem to care.

In our analysis and prototyping so far, the game is deceptively difficult. The big challenge is the stair set. The stairs are 4 inches tall, 4 inches deep, and you have to step up two of them. This means that the diagonal is about as long as the wheelbase (you won’t touch the floor and flat top at the same time) so you can’t just hop over a single step or gap, but you have to really climb up the stairs. In addition, the size constraints make stuff like tri-wheels and PackBot-style treads very hard to use. Stairs are a “must solve” problem; if you can’t get over the stairs you can only score about 25% of the game’s points. Our first prototype was to see how well tank treads could climb the stairs.

It looked more successful than it was.

Unfortunately actually climbing up the side of a step is actually not really easy or fun, so we had to place it on the edge of the first step to start it climbing. From there, the robot could pull itself onto the second step and get oh so close to making it on top. We played around with various ideas for arms to assist the robot at various parts of the climb. We’ll see how that goes. Moving our manipulator around to play with the CG during the ascent could also help.

Can we just turn this in as our robot?

Luckily manipulator prototyping was a lot easier. We grabbed a Vexplorer robot from RPI’s stock and saw if the claw could grab everything. Indeed it can. The utensils were easily pinched, the soda can even more easily pinched, and the only thing that was even remotely difficult was the styrofoam bowl. We tried placing objects at different heights to see what angle the claw should be at for easiest pickup (parallel to the ground won), and we’ll place the arm on a very compact four bar linkage for compactness and ease of use.

After a few days of prototyping and learning what looks hard / is easy and what is hard / looks easy, we have a fairly concrete plan of action for the next few weeks. The manipulator should be nearly problem free as four bar link arms and claws are very easy to do, but the drivetrain will be a real challenge that we will have to refine over time to get right. We still can’t decide on a team name and theme, but one of the last ideas looks promising…

Team Robot Unicorn Attack?

Vex-based IED Mini Project

7 Comments

In addition to tons of FIRST stuff, I also go to college (surprise!). For RPI’s Intro to Engineering Design class, we start the first month of the semester by working on a “mini project”, where teams compete in an engineering challenge. My small team (3 people) competed in a marshmallow shooting competition.

For the marshmallow shooting competition, students were given 5 attempts to shoot one marshmallow a distance between 5 and 20 feet to be determined on competition day. In addition, teams had to display competency by firing a marshmallow over 20 feet. The primary design challenge essentially was consistently shooting a marshmallow a varying distance.

We followed a standard engineering design process fairly “to the T” for the project as we were being taught and graded on it. Stared off by figuring out our priorities and identifying the problem. Got all the fun technicalities out of the way (no, we couldn’t shoot more than one marshmallow per trial for a “shotgun approach”; the marshmallow had to remain intact, the firing mechanism could not leave the starting area except for random strings or whatever, etc etc). Then we went to our design specifications, pulling most from the manual and grading rubric and some “for fun”, though unfortunately we failed at making our project able to put on a laser light show. I quickly figured out that it’s pretty similar to what I’ve done in FIRST every year, which got me thinking of a concept.

Eventually it came time to prototype. Most teams basically drew on their past experiences and picked whichever design seemed simplest to them, but my team had a few different ambitious designs and the fallacious idea that we had a lot of time to complete the project. The first idea was similar to a lot of designs: Stored energy (in the form of a mousetrap) hitting the marshmallow and using the angle of launch to adjust the landing position. The second idea was one I drew on from FIRST: a flywheel shooter that used 1-2 high velocity wheels to throw a marshmallow super far. We decided thanks to my Vex kit that made building my prototype super fast and easy that we had time to build prototypes of both designs and go from there.

In about a day I whipped this little thing up together:

Vex Flywheel Shooter

Geared 1:25, nothing could go wrong!

It spun the wheels at about 2ooo RPM, which translated into about a 6-8 foot shot for a marshmallow. It didn’t fully work, but it was relatively consistent (all shots landed within 6 inches of each other) and the team was very attracted to the idea of varying PWM signals for pre set distances and ranges. Our plan to get the necessary range out of the thing was to set the machine’s angle to 45 degrees, raise it about a foot off the ground just within the size requirement, and to use the Vex High Strength Motors to get the machine spinning about 60% faster. With the success of the prototype above we chose this direction to go.

Unfortunately, the High Strength Vex Motors were on backorder, so we ultimately decided to see if it was at all possible to make do with the current Vex motors and just gear them even faster. Now, in retrospect overgearing a vex motor 35:1 sounds really, really stupid, but at the time… Nah, it was still stupid then too.

At least the structure was coming along nicely.

Anyway, the gearup was so severe that one motor was spinning significantly slower than the other. We tried changing out shafts, gears, and the motor itself until we came to the conclusion that it was acting that way because the weight of the gears was pressing down on the motor shaft on one side, and the other side did not have this problem. With any reasonable loading at all this difference is absolutely negligible, but not with a 35:1 overgear with Vex’s “slop-py” holes. Ultimately we quickly ended up going with a DC motor and AC-DC voltage regulator to power said motor. Since DC motors don’t really couple with Vex out of the box, we had to get creative…

Try and tell me this isn't cool.

Using some tube clamps, foam tape, plastic tubing, and some set screws, we made a custom mount and flex coupling for the motor that mated the pulley at the end of it to Vex shaft. With this major change, we were able to get the wheel spinning and shooting 20 feet. Of course, like all good engineering projects, it was completed the day before, at about 1:30 AM in my room.

A scene I knew far, far too well by the end of the night.

We ended up using only one shooter wheel and a backspin plate for more repeatability, and ultimately did alright in competition. We lost, but we also were the first people to ever attempt this project electrically. This didn’t make much sense to me, as our entire group was straight up mechanical. I guess approaching the project through gear ratios and varying motor speeds “seemed like a good idea at the time”. Ultimately we were beaten by a stupid simple project: A slingshot with two rubber bands and a peg board to adjust wind up distance. D’oh.

If you want, I can include my technical paper on this whole project if you’re interested in the design details and everything, but I don’t think it’s a particularly good paper so I don’t want to just post it in public if I don’t have to…