FRC 95 The Grasshoppers 2019 Build Thread


Progress has been made on our toggle-lock skids for the HAB 3 climb. They will likely be a combination of plasma cut aluminum and laser cut delrin.

Only one is roughed into the robot model right now, but the snazzy mates in OnShape mean that it articulates as we intend it to!


Love the idea! Over-center 4-bars are tons of fun!

I assumed the 4 vertical cylinders were for getting onto the second level, so will you need them given you can use the same system to get you onto the second HAB level?

After getting my bearings with the onshape mate system, it’s really, really simple, and very powerful. It definitely takes some un-learning, and then re-learning to get everything to work correctly. I’m still often frustrated with, “Groups,” and how they prevent updates on the top level unless you suppress and unsuppress, but practice makes perfect. Also, I wish there was a way to align a mate without first creating a correctly aligned mate connector, but I understand why they do it the way they do.



The 4x vertical cylinders are brakes. They will help keep us from being pushed when we’re trying to score. We are likely only to wind up with 2x.

I have rarely needed to make my own mate connector. The ‘reorient secondary axis’ option, and alignment toggle, have solved 99% of the alignment issues I have had with mates.


The reorient function only works in 90 degree increments. The align secondary axis is what i was referring to by creating your own mate connector. That either precludes making the mate you want in the orientation you want, or you have to edit the created mate connectors after the fact. It’s just more clicks than I would prefer.


I got ya now.


I hope you’re not planning on using Chrome to display the camera stream to the drivers - it adds a noticeable delay as compared to Shuffleboard

The Ligerbots did a nice experiment to measure the differences in this thread:


Thanks Sam! We weren’t planning on using a browser for streaming, but your link really confirms that decision.


i have no link to back it up, but a former mentor of our team who is now with 4533, implemented a rasberry pi system that ran on a browser. idk how it worked, idk how any programming works. but i do know how to drive a robot real well and there was like zero delay.


Just have to say, just being able to look at your team’s CAD model helped our team see an easy way to solve one of the problems we needed to solve with our L3 lift system.


Awesome! Glad to hear it helped. Please feel free to post a picture or screen shot here if you’re so inclined.


CAD is nearing completion, although our electronics/pneumatics layout effort is wildly out of date.

Now to continue fabrication and assembly! We’re a little bit behind where we were last year, but with a clearer path forward. Hopefully we can pick up the pace and have a couple good weeks of drive practice.


So many gearboxes to assemble… here are two of the many we’ve been putting together.

Practice robot assembly has started.

After some additional research we found that the ‘star topology’ with which we had wired our CAN Bus is counter-indicated by CTRE. :persevere:

I take the blame for this arguably bad call. Although this topology worked flawlessly first try during the off-season it is likely not worth any risk for a competition robot. I stripped out the CAN block and started soldering all of the CAN leads together.

We’re struggling with a controller- or code-related issue at the moment, which is preventing us from driving. I anticipate some progress tonight with the presence of experienced programmers, which we didn’t have last night. When we attempt to command a drive throttle the apparent command value sent to the SRXs seems to fluctuate at random.

Edit: these are the errors that we’re seeing, presumably related to some of our Talons not being properly addressed (which we know). In the past this hasn’t caused any errors like we’re seeing now. I’m sure we’ll figure it out, eventually, but it’s not optimal for our timeline.

In better news we have ostensibly finished machining on our elevator rails, are continuing to machine our elevator bearing blocks, have found a new volunteer to make our practice field elements (our normal guy has changed jobs and is no longer available), and have our last few critical orders placed.

1 Like

Without going into a huge amount of detail, could you explain why the star topology is not good, other than it is “not robust”.

Edit: I went to the site, where we bought our splitters last year, and saw their guide to topology. It looks like CTRE lifted their graphics and just put a red X over them.

1 Like

I think you need to direct that inquiry to CTRE.


Me simple mechanical man.

But I’ll give it a shot.

My tentative understanding is that in a star topology the network can be quite sensitive to the lengths and types of wires used to construct the network. It can be executed, of course, but as more devices are added the network becomes more prone to instability/noise and failure.

With a ‘daisy chain’ (really Line/Bus) topology the 120Ω resistors in the Athena and PDB at each end of the CAN Bus rails keep ‘signal reflections’ and other errant signals to a minimum.

More discussion here: Mindsenors CAN Splitter

And yes, it looks like CTRE used the MindSensors figure directly.

The short story is: we had significant control systems issues, double-checked choices we had made, found one to be counter-indicated by the speed controller/electronics manufacturer, and decided to change it to avoid any possible issues related to that choice.

1 Like

Its all due to how CAN works. It needs to be terminated on both ends in order for reliable communications. Please have a look a this:

The high speed ISO 11898-2 CAN standard defines a single line structure network topology.
CAN bus does not support star or even a multi star topologies. The nodes are connected via
unterminated drop lines to the main bus. The bus line is terminated at both furthest ends with a
single termination resistor(characteristic line impedance)


We were seeing a similar issue when we were telling a motor controller to move that did not exist, this seems like a change from last year as I do not remember this happening previously.

I’m not sure that I like this change too much if it acts this way if a motor control that was instantiated properly goes out during a match and similar calls get made. It was also not incredibly easy to diagnose as the errors, in theory, should not have been able to affect other motor controller’s output.

I think that some more testing would be in order to see if this is the case and if so include some checks to make sure that a call is never made to a motor controller that does not exist.

1 Like

Thanks! @golf_cart_john It’s nice to know we’re not the only ones.


Do you stack your motor controllers? I can’t tell in your electronics layout photo. If so, have you seen any downsides to this - access to buttons, heat, etc? We’re always looking for more efficient layouts.


Is there a reason why you are using 2x 3:1’s and not one 9:1?