FRC 95 The Grasshoppers 2019 Build Thread

Thanks @Jacob_C, we’ll see what we can do. Regarding #3 though, the motors pause for less than a quarter of a second at a time, so I don’t think we’re gonna be able to squeak a self-test in there.

My leading hypothesis is that what we’d originally attributed to CAN problems is actually something like the watchdog events you describe. The problems correlate with software delays, regardless of the CAN configuration. The pauses we’re seeing are extremely brief though - feels like 100-200ms. Could the watchdog events explain a shorter pause as well? It seems to fit. I suspect (but can’t prove) the bugs in our code (multiple instantiations of the PDP class) were causing the code to wait around too long for CAN messages to arrive, making it seem like CAN errors correlated with the motors pausing. But in reality, it seems more likely it was the timeline abuse that was causing the problem.

We’ll check for those watchdog events next time we get a chance. Thanks for filling us in, I had no idea that information was there!

1 Like

We are also having this issue in our code, very brief periods where in the riologs it will show that the robot disabled even through the driverstation still said enabled. I anyone has additional suggestions or if we find anything I’ll post here.

Our team has experienced similar issues, although we haven’t looked into it very much due to the fact that it only happened a few times. We use Labview, and occasionally when we are driving our robot in teleOp, the signal light will go solid, and we will lose the ability to control the robot for a second or so, then the signal light will start to blink again, and everything returns to normal. All the while, the driver station has some sort of error to do with a watchdog, although I don’t know what the message said verbatim.

It is worth noting that we did all of our debug testing while connected via ethernet or Wifi, not USB.

Mmm, extra misalignment.

So we’re seeing something similar where it looks like the robot is being disabled for 1-500ms at a time as well, which is evident by the robot getting very jerky, and it might be my imagination/poor memory but I’m almost 100% sure I’ve seen the DS flash to disabled then back to enabled but our robot code never sees this and when this happens and we also seem to see higher packet loss.

Now something to note, we don’t use the WPI lib/hal at all, and use the CTRE lib with Phoneix_No_WPI, and it happens with our PWM outputs as well so I don’t think this is a CTRE issue.
Also we only started to see this after updating our 3 prototyping robots/RIOs to the 2019 rio image, networking libs, and radio fw. We know there was a radio fw update recently which fixed an issue with the bw limit and I feel like that COULD be the issue we’re seeing but haven’t had time to flash and test. We also want to try reflashing the radio back to the 2018 image. Even with a default wpi sample loaded into the rio we see the pack loss count just go crazy sometimes on all 3 bots which have never had an issue before.

I don’t want to hijack your thread but I feel like this could be relevant information, so if anyone wants to PM me instead feel free.

1 Like

Improved hatch mechanism.

Special thanks to @Ty_Tremblay, 319’s public CAD, and their willingness to share.

You’re not hijacking, just a continuation of an interesting topic! We hope to respond to this topic in the future.


It seems like you might want to be able to extend that mechanism a bit more once you put bumpers on. I’m a really big fan of passive self alignment here. Great work!

1 Like

Which pillow blocks are you using for the extend/retract guide rails?

An acetal-based linear bearing from McMaster. The PN is in our OnShape workspace (see first post in the thread for a public link).

Does the hatch mechanism just freely pivot, or is it spring loaded to return to center at all?

Freely pivots. There is no spring return right now, but we may add some sort of centering springs in the future.

Check for autodesk updater running in the ds. Or really any process like that. Ideally nothing else is on your ds.

1 Like

Thanks for the build thread, really like being able to stay up to date with the team while I’m away. Best of luck this competition season I’m sure you guys do great with that beautiful robot.


Elevator support guy-wires are in.

Ground collector is mounted and beginning testing.

Hand-off geometry looks good.

We’re a little worried about ropes coming off their pulleys with our new routing scheme, so we’ve designed and starting printing these handy little guys.

We’ve also started printing these umbilical guide rings to manage the wire/hose run that will go the carriage.

The cargo loader assembly is… not going as smoothly as we’d like. Hopefully we’ll have that running by the end of the week.

We’re at 92.6lbs as it sits right now with all hatch mechanisms, but no cargo and no HAB 3 climber.


We printed 2 of your lifecam housings - they are beautiful! Thanks so much for sharing the CAD!

Matt - 5675


Nice guy wires!

Based on the cable routing for your elevator, it looks like it only lifts in the upward direction and relies on gravity to pull everything back down?

That is correct.

Thank you for sharing! The student who designed it is ecstatic!


Are the guy wires used to support the elevator as a replacement for metal structure? Is the only benefit weight savings?