The Bulldogs Ri3D 2020

Hey everyone!

Kettering University’s Ri3D team, The Bulldogs, will be participating for our second year during Infinite Recharge. This year, we are approaching kickoff much more prepared to keep our progress tracked. Stay tuned for:

Status Updates

CAD and Code

Demonstrations, Recaps, and our Reveal

We’re looking forward to sharing what we put together and competing in the 2020 FIRST Alumni Collegiate Competition.

Thanks, and good luck this season!

The Bulldogs


Hi everyone!

We hope your season is off to a great start. We’re live streaming all day today and tomorrow on twitch.

Check out how our first day went here! We have another video uploading now explaining our overall strategy that will be out soon.

Let us know if you have any questions!

The Bulldogs

1 Like

We have a lot of insights to share after three long days of Infinite Recharge!

Our YouTube has been updated with daily recaps, up-close videos of our subsystems in action, and our Robot Reveal.

Our website has daily progress reports, links to our social media, and our CAD and Code we developed.

If you have any questions, feel free to ask them on this thread or email us at

As we look back on our robot for Infinite Recharge, here are some of our thoughts and insights that occurred during and after these three exciting, stressful, fun-filled days.

Game Strategy

Deciding on our “needs” and “wants” to meet our goals for the three days worked very well. We were able to effectively determine what was feasible for us to complete, what we would struggle to finish, and what was out of reach. This ensured we would not take on more than we could handle with our time, manpower, and resources.

What we would improve

The overall flow of the build could have been improved with the delegation of priorities. By the end of Day 2, we began delegating specific tasks to individuals, but starting the process on Day 1 would potentially have made for even smoother sailing.


Using 6" pneumatic wheels and 1.5" of clearance below the drivetrain had no problems traversing the field. The steel bars were easy to cross and did not cause any damage to the robot whatsoever at reasonable speeds.

What we would improve

A faster drivetrain would be a lot more advantageous for cross-field cycles. Our robot weighs in the ballpark of 100 pounds including a battery and bumpers, so a speedier drivetrain would be a lot more feasible than an average robot as well.


Powered by the same motor running our indexer/hopper, our intake ended up working fairly well, though it took several iterations.

What we would improve

We were limited to a closed frame and closed bumpers this year. Although our intake works pretty well, seeing how open bumpers or an open frame would have affected how Power Cells are collected would have been very helpful and may have changed our intake tremendously.


Powered by the same motor running our intake, our indexer worked fairly well in storing 3-4 Power Cells and delivering them from our intake to our shooter. In some situations where Power Cells are collected back to back, they will “jam” our indexer. The “stickiness” of Power Cells touching each other was a big problem, possibly one of the largest design challenges that teams will face this year.

What we would improve

In hindsight, prototyping more than one method of indexing Power Cells would have been extremely beneficial. We spent hours trying to fix our jamming issue. We ended up minimizing the problem, but it was never eliminated. If Power Cells are collected one immediately after another, they will get stuck. This is easily fixed by being careful driving, but having to limit your performance is never desired, especially once you reach higher levels of play.


With two PVC arms, a hook, and a winch, we could reliably enter the Rendezvous Point and climb in less than 10 seconds. The arms had potential energy stored in their surgical tubing and hook and loop tape keeping them constrained to the winch until it was run. They served very well for delivering the hook to the Rung without actually needing the strength to withstand the weight of the robot.

What we would improve

Our winch was able to hold us up with no power to the motor because of the large reduction of its VersaPlanetary gearbox (81:1) and small winch diameter (0.5"). This worked very well for getting 25-40 points alone. However, to reliably climb with a partner, a mechanism to linearly travel across the Rung to help level the generator switch would be very beneficial. To further optimize the climb, we could have used a lower reduction on the VersaPlanetary to give the climber less torque but more speed. A ratchet to stop us from falling with no power could take the place of the torque removed.


Starting out the three days, we were focused on building a robot that would complete the tasks we set out to solve. We had no guidelines for how we would complete them. The goal was “Get it working” and not “Follow these steps to get it working.” While this worked out in the end, there were many bumps in the road to get there. Many designs started out way more complicated than they needed to be, and we had to sacrifice time because of it.

Beyond this, in some of our designs, we were stuck in our ways trying to get specific methods to work. In the end, we figured out what was causing problems, but trying to bandage one design instead of creating a new design without those problems hurt us for time.

What we would improve

Keep it simple

The simpler your robot is, the more effective it has the chance to be. Our climber was a great example of this. We started out with two ideas for climber prototypes. One was a telescoping mechanism requiring two winches and a lot of mounting, and the other manipulated a tape measure, requiring a decent amount of mounting, heavy precision installing a motor, and a winch. By the end of Day 2, neither was working, and we began to wonder if we would be able to climb. At the beginning of Day 3, we started prototyping with several PVC pipes, and we created an effective method for delivering a hook with only a winch motor. Although this was less elegant and arguably less cool to look at, the method was simple and worked nearly 100% of the time, compared to 0% with more complicated approaches. This is no means of saying complicated devices will never work, but approaching problems with simple solutions will always have merit.

If you’re not moving forward, you’re wasting time

We tried numerous times to fix a design that was flawed. No matter how many fixes we tried to apply, we couldn’t get it working. When you’re stuck, the only way to get unstuck is to try something new. If you’re sinking in quicksand, and kicking your legs sinks you further, you should probably stop kicking your legs. Similarly, if your design isn’t working no matter what you try, it may be time to test a new solution. This doesn’t mean as soon as there’s a problem you should give up. This just means that if you can’t find success one way, don’t let it hold you back from finding success another way.

The Bulldogs


How well did your shooter work, and what design did you use?

We used the white andymark KoP wheels with 1 inch of compression and it is very consistent from all of our testing. if the sector line is below our robot we’re able to get the cells in the outer goal

What rpm did you run both wheels, and if the shooter had max rpm how far do you think it could shoot while remaining accurate?

Both shooter wheels were each ran with a MiniCIM with a 3:1 reduction, so a little under 2000 rpm on each side. With accuracy, we were able to make shots from about 15 feet.

That climber looks very familiar! :wink:

1 inch on each wheel (so 5 inches between) or 0.5 inch on each wheel (6 inches between)?

0.5 for each wheel so total of 6 inches between

How do you guys disengage the hook and loop tape to deploy the climbing arm?

There is a single ziptie holding it down which breaks when we run the climber winch. I’ll try to grab some up close footage next time I can.

On an unrelated note we were messing around with autons and were able to program a 5 ball autonomous that takes about 12 seconds to run. We will be using this at the FACC Ri3D competition on February 2nd. With a better intake (and encoders) a 6 ball auton would take no effort. The code has been pushed to github for anyone curious but trust me it’s nothing special

Edit: noticed our link to GitHub isn’t here

1 Like

How well does sucking the power cells over the bumper work? If it works it would cut down on complexity and wouldn’t require cutting a hole in your frame.

If we actually had chained our intake it would be even more effective. Currently it is running off of the surgical tubing which is the only reason It slows down when intaking.

it would also be more effective if we used a smaller gear reduction, it still manages to be quite
effective all things considered.

On the video you guys have some sort of wheels or spacers on the axel for the surgical tubing to stay in place. What are those and where can we get them?

I would highly recommend not copying what we did for the surgical tubing to be honest. The surgical tubing can on occasion get pulled out and into the mecanums. We have a piece of lexan that just free spins between the wheel and where the surgical tubing is to keep this from constantly happening (it spins around one of the vexpro belt pulleys). We had to work with what we had in the center which is why we used the surgical tubing the way we did but don’t feel it is a robust solution

What would be a good material for the conveyor?

We found that polycord was effective for delivery, but we had problems due to it only having contact with the ball on one side. We didn’t have access to the polycord-like belting (pic below) or time to try timing belts, but these were both options we would have liked to prototype with given more resources.



Awesome to see a similar analysis and basic design! See y’all at FACC!