paper: Killer Bees 2011 Robot CAD model

Thread created automatically to discuss a document in CD-Media.

Killer Bees 2011 Robot CAD model
by: Jim Zondag

STP model of Buzz16, Team #33’s 2011 Robot

Complete CAD Geometry of our winning robot design.
Last generation minibot and deployment are not included, as these parts were never integrated in the final model. (1.94 MB)
Dual Drive.pptx (390 KB)

Amazing robot as usual, i have a few questions.

what was the material you used for your roller, i heard someone say it was spray on rubber? if so could you say where you got it?

what precautions, if any did you take to prevent smoking the rs550 in the drive-train (or is it a 775)

what did the robot end up weighing?

where did you get the smaller cylinders for the gearboxes?

Polycord belts, laced through the polycarbonate roller in a double-helix pattern.

We didn’t end up putting the 550’s in the drivetrain, because we initially didn’t have the weight and later didn’t feel the need for them.

With the ramp minibot deployment, it was about 115.5 or so.

Here’s a loaded question…if you had to do it all over again, what would you have changed? (Given your success on the field this year, I wouldn’t be surprised if the answer is “nothing”)

Thanks for posting!

There was a lot of effort put into loading over the back from the feeder station. Turns out training your hp was more effective. There may be a couple minor compromises related to that.

In general we were very happy with the performance of this robot.
If I had to do it over again, what would we make differently?

My #1 item would be to try to reduce the amount of elevated mass on the elevator. Our design was very good, but there are a variety of design points in the Collector, Forearm assembly, and Elevator stages which could be lighter, and this would improve the dynamic performance of the robot in a number of ways.

This is only the second time in our history where we have done a direct drive powertrain. This has a number of advantages, but the disadvantage is that it makes final drive gearing changes more difficult if you do not have the ability to make custom gears quickly. Our initial ratio choices were good and very compeititive, but iteration would have been harder than I am used to if we had had to make any design changes on this detail. In the future, we will probably do something a little more flexible, or simply make a family of final drive gear sets when we make the initial parts.

There are a thousand small details that could be made better, but seriously we put a big priority on construction speed. How fast we can make it often trumps some of the desire to make things more precisely. A winning robot is not a winning robot unless you have winning drivers too. You need the time to develop both.


I regret not taking a closer look at your robot at champs. This thing is a work of art, very well done.

I’m wondering how it articulates though. It looks like there’s a slot to allow movement in the front/back direction, is that to keep the center to center distances the same on the chain run?

Edit: Never mind, I constrained it in Solidworks. Amazing stuff.

I’m going to use that line in my signature. :slight_smile:

Another great robot this year from the Bees…

Thanks Jim!

How do you get the drivers trained? Do you try to get a working drive train quickly, as within 2 weeks, and let them run with that while you build another drive train and the rest of the robot? Or do you try to get the complete robot done in 4 weeks, with 2 weeks for driver training and debugging?


Read the journal Jim posted in the white paper section, and I think you will find the answers you are looking for. Yes it is a long read, but it covers this topic very well.

Basically, we try to have a basic mobile platform with the intended drivetrain configuration (but perhaps not the correct gearing) within about 1 week from kickoff. We have a couple of prototype chassis platforms which make this easier to do, as often we have something very close right from the start.
Drivers and software teams can start work using this right away. We will spend about 30 days building the first robot, and have the 2nd one done in 40 days.

The three motor gearboxes show two CIMS, a FP through a P60, plus a FP through a Cimulator.

What motors did you actually use for the drivetrain?

I really like the drivetrain concept of articulating the rear wheels, very innovative.

With the speed of this year’s game, did the drivers find themselves switching much between the high/low on the two speed gearbox? Did they use the low gear for placing the tubes or only when in a pushing match?

I believe I can help.

We used only 4 CIMs on our drivetrain because we were very close on weight. Later when we did have the weight, we decided not to put them in simply because we didn’t feel we needed them and didn’t want to rip the gearboxes apart.

Thank you, we found it to have lots of benifits that were not really obvious to a spectators eye: straight tracking in auto, eliminating over-steering (our driver loved this), making ourselves very difficult to push, pushing through defense, being able to turn on a dime, and very low maintaince.

We shifted 13fps and 6fps. This sequence was automated along with the wheel articulation. Eventually, however, it was made so as to only shift up because on hard stops it would shift down and buck the robot forwards. I’m not sure if our driver hung tubes in low or high gear. However, I do know that there was a function which made the drivetrain a bit more “sloshy” when the elevator was raised all the way. This helped considerably with lining up to the pegs.

I’ll elaborate a little more:

We designed a custom 3 motor transmission in the first week. We made all the parts but did not have the Banebots transmission required for the 3rd motor when we wanted to assemble everything for the first drive tests.
So we built it up without these. In week 3, when we finally got some details on what a CIMulator actually was (no drawings or anything on BaneBots site), I did a little work to see if I could also fit 2 of these into the assembly instead of the P60 transmission, since this solution is slightly lighter.

We ended up very close on weight in week 6, and the robot with 4 motors was capable of meeting all of the performance objectives, (it is really not geared super high) so we decided not to put in the 3rd set of motors. Later when we got a little weight back, I did not make this a priority, since the robot can hang 9 tubes the way it is andthis game is mostly about auton and minibots. We spent most of our additional developement time on these areas.

Both of these motors options are suppressed in my Inventor Model, but it appears they get re-enabled during the STP file conversion process. This is why you see them both in the model. Our crate arrived from STL this afternoon. When we get a little time, we will probably put 2 of these in, but I haven’t decided which design yet.


I’m very impressed with your “Dual Drive” design. It strikes a nice balance between mobility (turning easily) and defense (raw pushing power and straight tracking) without too much added complexity.

Looking at the CAD model, it wasn’t clear to me how the chain on the articulating wheels are tensioned. I’m assuming the assembly pivots about the spacer that rests in the slot in the frame, but I don’t see where a cam could be used to slide the assembly over and tighten the chain. Or do you use another method with these wheels?

About the cams, how are they fixed in place? Is the center hole tapped? Do they ever work their way loose?

This may be a minor detail, but the wheel bearing flanges are mounted to the frame with 1/2" slots, and the shaft is the same diameter. Wouldn’t it rub?

On the arm pivot, is the split shaft collar welded to the side plate? Is this to facilitate assembly?

Is small green arm on the main arm pivot for counterbalancing purposes?

Once again, nice work, and thank you for sharing.

  1. The spacer that the articulating wheel pivots about sits in a milled block inside the tube. There are two bolts going from the end of the tube to the block, which has taped holes. To tension the chain, the two bolts are tightened.

  2. There is a bolt going through the tube (with a spacer in the tube) and the cams, with a nut on the cam side. We loosen the bolt attaching the cam, loosen the bolts on the bearing block, tension the cam, then tighten the bolts again. No, they didn’t work themselves loose.

  3. Yes, it has the possibility to rub, but it will wear a hole for itself.

  4. The collar is welded on one side to the side plate.

  5. Yes, it is for counterbalancing.

Sorry for reviving an old thread, but I was looking at your CAD and had a question about it. On the wheels, the hub that you use to attach the wheel to the axle is right up against the bearing blocks. How did you attach this hub to not need space for the head of a bolt to attach it to the wheel? Also, there doesn’t appear to be anything to prevent the sprockets from moving along the axles (in the axial direction). Is this accurate?

Thank you in advance for answering my questions and more importantly thank you for posting your CAD.

as usual great job once again!
Between that and what you shared from your 2010 drivetrain in tackling the large bump…they are both great works of art, and useful for us to see the design process you folks experienced and succeeded with.

They’re there, just not in the CAD.

The hubs are countersunk and we use flatheads, so there is not much to interfere. The bearing blocks are taped for a #10-24 bolt, and the bolt heads are on the other side (not the wheel side). We put in a single wave washer between the bearing block and the wheel hub.

On the sprocket side, we have a (lacking knowledge of the actual name of the part) press-on shaft collar.

Alex, The attached picture shows the sections view through the wheel and hub assembly. The inboard side is held in place by a pushnut. Outboard side uses a screw into the the counter bore in the axle. We counter sink the AM hub and the bearing mount to and use flat head 10-24 screws so we avoid any fastener collisions.


*Not sure why image does not show