Hard Tradeoffs and how to make Week 6 Decisions Easy

Leave a comment

In various design processes, several steps, done in many different ways, generally aim for one goal: Prioritize tasks to more efficiently delegate resources. In a nutshell, here’s my thoughts on that and how I do it.

The first formal design process I’ve looked at is JVN’s process, the one 148 uses. After the problem is defined, specifications are generated and then ranked. This is universally true for nearly any design process, but rather underrated in its performance. In particular, I think this needs to be the most spelled out and black and white part of the process. If these decisions are firmly made early, it saves time arguing and debating later, as long as everyone agrees to stand behind them.

In the context of robotic competition, I find it’s best to start with a very general strategy overview and setting your game objectives in a firm priority list. This list needs to be absolute and followed; if there is any conflict, resources go to the more important game objective. From there, you can break the game objectives down by subsystem and make a Want-Preferred-Demand chart for individual features and criteria. I find this slight tweak to the design process a lot easier and more relevant in competition robotics; that way you don’t need to list all of the requisite features of a subsystem under “demand” with other criteria like “robot must drive around well”. Once you get this firm list and agree to it, you can work on the design details, formally incorporating things from the Manual in there. One should have read the full manual by now to know if everything sought after is legal, but this is when you spell it out in your requirements.

Here’s an example for the Vex game my IED team is working on. We never wrote this down, so I’m somewhat making this up, but it’s a good example.

  1. Robot must be able to drive over the stairs. The starting area and the part of the field with every single scoring opportunity besides autonomous is separated by a set of stairs. If we don’t climb the stairs, our robot is worthless. Your first priority should always be your drivetrain requirements.
  2. Arm must reach 14 inches in the air and pick up / touch objects on a shelf 6 inches deep. The highest value game pieces are behind an unlatched door with a doorknob about 12 inches in the air. Many game pieces are on a shelf as well.
  3. Gripper must hold soda cans, juice boxes, and cereal boxes. These game pieces have the highest point value and are also the easiest to grip.
  4. Robot must complete Autonomous Mode. It’s worth 2 soda cans, but is not required to play the game.
  5. Gripper must grab plastic bowl and utensils. Difficult to grip and only 5 points, so not as high a priority as the other objects.
  6. Robot must stow as many objects as possible inside itself. We can ferry items 1 by 1 to the human player so this isn’t required, but if we can add it in we will.

Pretty simple list outlining all of the tasks the robot can do in this game in a ranked order. This has led to some very interesting (in my opinion) design tradeoffs.

We removed all drive encoders from our drivetrain. This is pretty important for autonomous mode, so why was that done? The encoders were too big and would be pretty difficult to mount in a manner that didn’t interfere with climbing the stairs. Instead of spending a week working out a custom mount in CAD and stress testing, we just left them off the robot, and as a result we more quickly climbed the stairs. (Bump sensors are used to detect when to stop now. Not pretty but it works.)

How many times has your team had this problem? 2791 spent two weeks arguing about whether or not to keep working on a hanger. About 2/3rds of our team was working on that. Only one team member was working on a ball magnet. Just one person. If we stuck to this, someone would have stepped up and said “we don’t have ball control done, thus all work on the hanger needs to be dropped”, we could have been more competitive.

Vex IED Final Project: Week 3

Leave a comment

So as you may remember from my previous post, my Intro to Engineering Design team is competing in a Vex competition in early December. We’ve made a bit of progress since last time.

This doesn't look generic or anything.


Previously, the team wished to use a four bar linkage arm with a Vexplorer claw to grab game pieces and dump them in an arbitrarily sized basket. Since then, we have done a bit more development and thinking. There was some concern that building a four bar linkage with crossing links would be very difficult. Others expressed concern over the uncertainty of the linkage once it passed the “cross point”, a very valid concern. Ultimately, a much more conventional looking robot arm was decided on. The claw is mounted to a wrist powered by a single motor geared 7:1, and the shoulder joint will be powered by a single motor geared approximately 25:1. It looks like any arm bot you’ve ever seen. The arm will start “folded up” into the basket and then expand after the match begins running “behind” the robot for most of its use. This lets us reach over shelves, up to doors, etc. while still fitting in the sizing box.

I thought up that little cantilevered first stage right as we were building it 🙂

Calculations were made to ensure the arm could lift the heaviest load (full soda can) in “worst case” scenarios; with this we arrived at our gearing choices. We didn’t assume any counterweight or balancing on the arms, figuring that Vex gears have enough backlash to stop significant backdriving and as long as we can move the load it’s fine. We may add some latex later, we’ll see… but even the 7:1 reduction stopped the Vexplorer claw from backdriving with a soda can in the gripper.


Simple wins.

We learned a few things quickly with our tests. First, with an increase in tank tread traction the treads can negotiate the “first step” of the stairs on their own, eliminating the required in chassis “foot” assisting device we had planned. Which is great, since the second thing we learned is that the small Vex chain is truly not designed for the loads of a drivetrain, at all. We drove it into the first step of the stairs and in under half a second, both properly tensioned chains failed completely. We were using a design that mounted the motors internally, “within” the tracks, using chain to connect the motors to the tread sprockets. This ended quickly.

It would have looked super cool though.

One team member proposed using bike tires as tread material. I’m not sure if he was joking, but we tried it and our thrown together prototyped worked GREAT for what it was. It ran up the stairs once, then repeatedly failed because the rubber bands holding the tread on would jam up. Our plan was to fix this with a more permanent mounting solution, but then we discovered that since the tread “expands” around the corner of a sprocket, the tread could not be held in place with any kind of rigid attachment method. We really didn’t want to go with the foot, so we decided to try another idea…

Arm AND Drive!

We assembled the arm and then quickly tested it and found that the 25:1 shoulder reduction was a lot of torque for a relatively light arm (less weight than expected). Perhaps one crazy idea might just work…

Well damn.

With proper coordination the arm lifted the chassis off the ground easily. It even pulled the chassis forward onto the first step. With a little play it could pull the chassis further up the first step and nearly onto the second one. This was without any tank treads on the robot; with a drive base to move the bot forward during this operation we could easily get up the stairs. This saves us considerable time making custom treads, weight with a bogey wheel, and many other headaches in general.

When I first proposed this idea on Friday it was the “ah-ha!” moment in our design process. We combined two complex parts into one simple and light part with dual functionality, and all we have to do to have a “mechanically complete” robot is to get the high strength motors on order from Vex and install them in our drivetrain.