FRC 95 The Grasshoppers 2019 Build Thread


Here is a link to our OnShape project. I have also updated the first post to include this link. Anyone can view/manipulate/interrogate the models we’re making, but you cannot copy/export/link to them. If anyone has need or want of our models we can work with you on an individual basis. We have done this in the past though, and are happy to do so again.

Delrin Blocks as elevator bearing replacement

If our OnShape workspace were a studio it would be filled with crumpled up pieces of paper. Lots of churn, but not as much visible progress as we’d be happy with. Still, this is part of the process, and we can’t expect tons of visible progress every day (as much as we hope and work for it).

Starting to package in the elevator carriage and hatch cover mechanism.

In what feels like 95 traditional design practice: the gripper uses a floating air cylinder to grip the inside of the hatch cover with two identical pieces used in different orientations.

We laser cut a copy last night and were quite pleased with the results. We’re going to refine it a few more times and then likely cut it from 1/4in polycarbonate or nylon.

Also working on a robust 3D printable Life Cam housing.


Looking good guys can’t wait to see the finished product!


Im assuming that you are going to have a way to push the Hatch or extend the gripper out over the bumpers to score on the rocket?


@EricLeifermann Yes.


How do the floating pneumatics work? I’ve always wondered whether it extended or retracted evenly to both sides. It seems like it would try to favor one side.


They can favor one side or another. In our uses it’s never been an issue. Typically the ‘favoring’ is so small that as soon as one side of a mechanism encounters a game piece, the other catches up. We’ve really liked them because they can dramatically simplify our mechanisms and/or improve packaging.

2018 cube gripper floating cylinder.

2017 gear placing mechanism. One side open, one side closed.

2015 Can gripper. Less obviously floating, but it still floated.


This is looking like a very robust and dependable design for hatch panel manipulation. Great job Grasshoppers with using a simple design that does not depend on the game piece to be in perfect condition and still being able to score it readily. These designs are really bringing me back to 2002 with your simple but effective ball intake and delivery mechanism that was a game changer.


James is doing a great job of explaining the mechanical parts of our robot design, and has asked me to share some of the software aspects as they come together.

This year, we have decided to try using a Raspberry Pi 3B as a vision coprocessor. With the WPI-provided disk image to help with coprocessing, this seems like a good thing to start trying. The instructions from WPI work great, with no surprises.

We made a discovery that makes testing and developing these algorithms much easier: it’s pretty easy to run code meant for the coprocessor on Windows. This isn’t too surprising, but it’s nice to see how easy it is.

You can find Team 95’s bleeding-edge example in our github repo. (Explanations farther below) If you want to run our example, follow these steps:

  1. In VSCode, say “open folder”, and open the “VisionCoprocessor” folder
  2. Download OpenCV 3.4.4 from (
  3. Run that .exe to self-extract
  4. Copy its opencv\build\java\x64\opencv_java344.dll into C:\Users\Public\frc2019\frccode\ (Or, if you’re on an x86 computer, you should use the x86 version)
  5. Click “debug” or “run without debugging” while is in the forefront in the editor

If you do this, you should see a pile of windows appear, with some annotations drawn on top of the test images. This is an algorithm we’ve decided not to use, so you may notice that it doesn’t work super well. (As of commit 671740ef9de1df072eea18a20af7392841dc0ef2)

The key to making this work is found in GripPipelineLinesFromTarget.main():

	public static void main(String[] args) {

		String[] filesToProcess = {
			"test_images/Floor line/CargoAngledLine48in.jpg",
			/// ... many files omitted ...
			"test_images/Unoccluded, two targets/RocketPanelAngleDark84in.jpg                       ",

		Scalar unfilteredLineColor = new Scalar(255, 0, 0);
		Scalar leftLineColor = new Scalar(0, 255, 0);
		Scalar rightLineColor = new Scalar(0, 0, 255);
		int lineWidth = 1;
		GripPipelineLinesFromTarget processor = new GripPipelineLinesFromTarget();
		for (String file : filesToProcess) {
			Mat img = Imgcodecs.imread(file);
			for(GripPipelineLinesFromTarget.Line line : processor.findLinesOutput()) {
				Imgproc.line(img, line.startPoint(), line.endPoint(), unfilteredLineColor, lineWidth);
			for(GripPipelineLinesFromTarget.Line line : processor.filterLines0Output()) {
				Imgproc.line(img, line.startPoint(), line.endPoint(), leftLineColor, lineWidth);
			for(GripPipelineLinesFromTarget.Line line : processor.filterLines1Output()) {
				Imgproc.line(img, line.startPoint(), line.endPoint(), rightLineColor, lineWidth);
			HighGui.imshow(file, img);
			System.out.println(file + " has " + processor.filterLines0Output().size() + " left side lines: " + processor.filterLines0Output());
			System.out.println(file + " has " + processor.filterLines1Output().size() + " right side lines: " + processor.filterLines1Output());

This main() method is not run by the code that runs on the Pi (see for that - we’re using the one from the Java example on the Pi image). This is code that is only executed when you say “Run” from VSCode. This way lets you run the VSCode debugger really easily too, which let me identify some errors in the GRIP-generated pipeline.


Feynman was a wonderful robot. Just like the physicist whose name he bears, Feynman was everyone’s favorite.

My rookie year robot. I did all of the pneumatic plumbing on Feynman. @JVN used to have a video of Feynman up on his youtube channel, but it doesn’t seem to exist anymore. I regret not downloading it when I had the chance!


We all regret not having that five second video. Maybe @JVN still has the clip. I remember standing sideline for one of the matches 95 was in, and to see that perfection up close was just jaw dropping. Zone Zeal is still in my top five games. What a beautiful and simple design Feynman was.



Is this the video you are looking for?


YES! Thank you very much!

Apparently it’s on a now-defunct 95 youtube account. I’ll have to see if we can still access it.


We can start to show how the ground load to elevator handoff is going to happen.

With the scoring mechanism retracted and closed, a ground-loaded hatch will swing right onto the gripper.

With the gripper engaged and extended, we can reach a small ways outside of our ‘bumper perimeter’.

But I think that we’ll want to tweak some things around to get a little more reach.

I know this build thread has been mostly CAD so far. The reason is that I have two kids now, and most of what I’ve been doing for the team this year is CAD from home. I hope to get some more pictures and video of prototypes tomorrow and Saturday.




No. I have a 2.5 y/o Alex and now a 6mo old Ana. Managing two is more than twice as hard as one, so I am spending more time at home to help my wife.


Hey @JamesCH95, How are you guys bending the sheet metal. We are having some difficulties and wanted to know if you guys are able to do it at home or send it out to someone. Any tips?


What material type are you using? 5052 Al is the aluminum that industry typically uses for bending. Also minimum bend radius is material thickness and even then usually good to go a bit bigger is able.


We have a pan and box brake and press brake in-house in addition to a sheet metal sponsor, Progressive Mfg who bends with CNC press brakes. Between the two of us we exclusively bend 5052 H32 in thicknesses from 0.030 to 0.100in for robot parts.

I could dive into a lot of the design stuff, but it sounds like you’re really after the more practical “how do I bend this metal?” sort of information.

Use 5052
6061, 7075, and other less-ductile aluminum alloys tend to crack if bent parallel to the rolling grain. If you must use alloys less ductile than 5052, align the bends to be perpendicular to the rolling grain and increase the bend’s inner radius.

Get a ditial angle finder
I have two of these angle finders in my shop at home and use them for bending gauging bends and many other things. Having a clear digital readout that you can zero to the angle your brake starts out at is REALLY helpful. I can’t even count the number of times a mechanical angle finder has given me a bad reading from paralax or static friction.

Ensure your brake is square and the fingers are even
It only takes a few minutes to check the finger position on a pan and box brake with a machinist scale or calipers, but it can save a lot of time. I will often use a scrap of the material I’m going to bend, plus a scrap of the bend radius (often the same thickness), to do gauge the finger positioning on a pan and box brake. Also ensure that the bending edges are straight. Sometimes these get bent if someone has abused them.

Bend in the middle of the brake
Most non-super-nice brakes deflect a noticeable amount when bending material. If you bend the part off to one side of the brake the center of the brake can bow, results in a tapered or skewed bend.

Make your own mandrel/die
I don’t have a good picture of this. But we have used this with great success in the past. Let’s say you’re bending 0.1in sheet with a 0.1in inside radius. Take a scrap of the 0.1in material and bend it around the fingers on your pan and box brake with a 0.0in radius (set the fingers to 0.1in back). This strip is basically a mandrel (it’s not exactly a mandrel, but I can’t think of a better term).

Move the fingers back to 0.2in, align for your real bend, then slip the mandrel back onto the fingers, clamp, and bend. This arrangement forces the part to a constant radius and results in more consistent bend geometry.

Hand tools can help a lot
Sometimes the parts will need a little manual tweaking. A nice heavy hammer with a clean edge to strike against (I’ve used anything from a block of wood to an anvil), sheet metal vice grips, a bench vise, and other such tools can ‘massage’ things into place.

Manage critical features
If possible, keep all critical features (holes, slots, whatever) in one face so that the bend position/angle isn’t critical to the parts’ function. Where that’s not possible, consider making these features after the flanges are bent. If you’re making angle brackets, bend the sheet metal blanks, clamp them to a jig, and drill the holes through the jig. With this approach the part will mount in place even if the bend isn’t square or if the radius is off a bit. There are MANY other ways to manage critical features in sheet metal that I don’t have time to go into.

Hope this helps. If you have more specific questions I’d be happy to answer them.


We’ve settled on a linear bearing arrangement to enabled a fore/aft hatch placing DoF.

We’re planning on using some very slim UHMWPE braided rope, which makes the spool remarkably smaller than 2018’s. This decision enables us to get the winch underneath the robot which in turn gets the winch nicely in-line with the first fixed pulley. Lots of small but important decisions are being made right now.

First big Vex order showed up on Friday. It’s a Vexmas miracle.

This proved to be the best way to get the Velc… hook and loop tape applied to our new hatches.

The WIP benches are starting to fill up, slowly.

We cut our first lift bearing block on Saturday. With the CNC programs and setups worked out we’ll be slamming through these starting on Monday. Also cut some 5mm thick hatch gripper prototypes.

The camera mounts, they are a-printing.

As soon as we start the fab phase of build things get crazy, I’m looking forward to it!