FRC 95 The Grasshoppers 2019 Build Thread

It looked to me that the slippage occurred in part because one skid plate cleared the platform before the other, which is visible in the screenshot below. When only one of the skids is no longer contacting the platform wall, there is no horizontal normal force provided by that skid and the robot can rotate about its vertical axis and decrease the normal force on one of the rubber foot pads. I’d insert a complicated 3 dimensional free body diagram, but it’s hard to draw.

A more gradual transition off of the end of the skid pad might help alleviate this. Another option is to just lift a lot faster and the transition period over the one-skid-on-the-wall phase will be quicker. Since so much of this lift process requires traction of the rubber feet, I’d also suggest getting some HDPE sooner rather than later to test with.

Also, here is a prototype concept I was playing with earlier this year that is related to this one, but different.


I see exactly what you’re getting at, thanks for the insight!

It also looks like we’re coming off of any roller contact on the far side. This would require a superior frictional interface to try and overcome as @Akash_Rastogi suggested. I can also see how the tapered transition that @Nick.kremer suggested could also improve this situation.

Look at me learning things…

Thanks all!

We are planning on the following mechanism changes:

-Side plates from delrin instead of aluminum, increased compliance should improve impact tolerance
-Core of wood to improve critical buckling load
-Many extra fasteners to improve critical buckling load by reducing unsupported lengths of material
-Many more wheels to avoid non-roller contact with the HAB
-Slightly larger wheels (lets us reach further down and use fewer wheels) unfortunately there isn’t room to make a tapered sort of skid as suggested by @Nick.kremer
-Double-up on wheels in important locations to get a wider localized wheelbase
-Add swivel feet to the bottom of the jack legs
-HDPE sheets on order to more accurately represent the HAB friction surfaces

Side note: I’m lucky in that I do a lot of CFD and computer modeling in my job. It grants some free time through the day to dig into things like this.


Our design is very similar to this and the biggest problem we have found is that the feet slip backwards and rack our lifting structure. We ended up adding one long foot between the two contact points with higher grip material and this has helped us significantly from sliding backwards.

Figured we would share that success.


Did you ever figure out the cause of or solution to this issue? It sounds very similar to a problem we are currently experiencing.

@hamac2003 @brandn03
my team also has this problem

here is a link to two threads on it:


We’re making good use of our laser cutter to make a few last-minute parts.

New skid assemblies are put together. They’re on the robot now, but I don’t have a picture yet.

Cargo intake has been modified, as has the hatch ground loader. Camera is mounted and nominally working.

We spent some time (though much less than we could have, in hind-sight) diagnosing a CANBus short. We eventually found that a CAN wire pair had been sandwiched under the elevator winch bracket. Key observations were that all devices showed a lost CAN signal and the network registered at 1Ω resistance.

I got some questions about our toggle-lock skid mechanism, so I made a quick and dirty annotation of one of the layout sketches that I worked on. Hopefully this sheds a little more light onto how one creates this sort of linkage.

Right now we have (finally) reached ‘minimum viable robot control’ where we have enough sorted-out features in one code set to do everything we need to, but not everything that we want to. Today and tomorrow will be chock full of drive practice and fine-tuning of programming. A lot less drive time than we normally like to have, but it is what it is.

No, we still haven’t found a solution. It really seems to me that there is an issue with the new roboRio image, rather than the driver station laptop being at fault. Because I very much doubt that a lot of teams are just suddenly all having the same problem with their driver stations that have worked in seasons past.


We just wiped our driver station laptop and did a fresh, barebones install of windows. Will let you know of this fixes our issue.

1 Like

I’m going to take a wild guess. Go into the driver station log and check, and I’ll bet dollars to donuts that the drop out will be EXACTLY 2.5 seconds. Let me know if it is.

1 Like

Nope. The drops are only a fraction of a second.


I have the same issue as well and mine are only a fraction of a second as well. My issue is still unresolved as well…


After wiping the DS laptop and reinstalling a barebones version of windows (no Office, internet browser, antivirus ect.) with only VS code and necessary software for the robot, the issue seems to be better after a little testing. I will report back later this day after more testing.

Saturday during troubleshooting we were able to create the drop by opening different programs on the DS laptop. We are relatively confident that this was the issue. Not sure why it was suddenly an issue.


Wanted to thank you for doing this thread every year and the depth of details and knowledge you make public. Our team designed a center of hatch grabbing mechanism that used 2 cylinders. Your posts on the floating cylinder and set up were extremely helpful in reducing part count and packaging of our new set up.

1 Like

Awsome! Please feel free to post a picture or video of it. We’d love to see it in action.

Now we just had one that lasted right around 2.5 seconds. A purple line that says “Watch Dog” popped up on the DS.

That isn’t exactly what we see. Our robot spontaneously disables for 2.5 seconds. Exactly 2.5. No watchdog, no dropping. Packets, no code problems. And it’s totally random. Once a day or three times in an hour.

We are going to shelve our HAB 3 climbing efforts for now. We can’t quite get the right weight distribution and traction combination we need for a clean HAB 3 climb. Instead, we’re going to focus all of our efforts on cycling efficiency for now.

Along those lines we mocked up and tested moving our CG by shifting the battery to the back of the robot, which let the robot lift very nicely. However, the CG moved just behind the center axle, so we could no longer tip and drive onto the top of HAB 3.

Slapped-together battery mount:

Otherwise we’ve been working on a number of subtle things aside from drive practice.

First, we had an incident where the elevator winch line managed to shift completely off of the spool, bunch up, and fail the VP snap ring in axial tension!

The shaft slipped out until it disengaged from the last stage’s spline socket.

We added some additional rope guides on top of the winch cut-out to help prevent this in the future.

We added some muffin fans to cool the compressor. This helps keep the compressor, and the tubing it’s connected to, cool and happy.

Lastly, while installing a down-stop on our cargo collector wrist, one of the students had a brilliant idea: use a Rivnut gun to install the PEM nut. It worked perfectly. Easier than cinching it down with a bolt, and a lot faster than taking the part off and getting it into a press. My brain exploded.

1 Like

Just wanted to reconfirm this issue. Only over WiFi I’ll get intermittent no robot comms often for about ~2 seconds or very rapid ‘blinks’. This only happens every few hours and I can’t see an obvious root cause.

Sounds like a brown out to me, but I don’t know the whole story.