FRC 95 The Grasshoppers 2019 Build Thread


#141

Thanks for taking the time to test and respond!

We will see what we can do to fulfill the requests that you’ve outlined.


#142

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!


#143

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.


#144

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.


#145

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


#146

Mmm, extra misalignment.


Is this cylinder legal?
#147

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.


#148

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.


#149

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!


#150

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


#151

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


#152

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


#153

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


#154

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


#155

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.


#156

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.


#157

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

Matt - 5675


#158

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?


#159

That is correct.


#160

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