We actually used these for 2021 (they make them a bit wider too) and they functionally worked great (especially when you put ferrules on the ends of the wires first before putting them in, helps prevent them from ripping out). Only reason I’m looking around for other ideas is because they got a bit big/clunky when we used a handful of them all near the Rio. As a connector though I really liked them
In that case, you may want to look into some of the Playing With Fusion products. Like this one:
https://www.playingwithfusion.com/productview.php?pdid=103
A little pricey for what they are, but would solve your issue with clusters while being able to continue the “bus” layout.
1 Like
I know I’m late to this party, but here’s what Bearbotics (4068) did. We’ve taken this on as a electronics design challenge for a few years, and arrived at the designs here. The CAN boards are titled “BearCAN2” and “BabyBearCAN2”, and the board design files and parts are all provided. I’m a big fan of the CAN star/bus topology and we’ve used it successfully for 4 years using various generations of these boards. It’s cool to see all the different CAN attachment methods posted earlier in this thread. But the main technical issues we’re up against here are noise interference and parasitic capacitance – the original standards are designed to deal with these issues, and we can ignore and abuse those standards only so far before weird (bad) things start happening. The BearCAN boards were designed to use common trace routing and spacing to preserve common-mode noise rejection to reduce noise interference, and to use small conductor profiles and connectors to reduce parasitic capacitance. We have had over 20 CAN devices connected (keeping leads of any connected device less than 12" / 0.3m long, of course) on one robot with no observed problems, but we have not done in depth analysis of CAN bus electronic performance or error thresholds. Just some factors to keep in mind as you work through all the options.
5 Likes
These boards look awesome, thank you for sharing! From what I’m reading it looks like you guys do kind of a loop with prongs coming off of it for each of your devices then, right? (so the lengths in the loop part are as long as they need to be, but the prong parts max out at 12") I’d assume implementing this on an elevator then would mean running wires both up and down instead of terminating at the far end of the elevator, have you guys done it before?
Ooooh, I really like the “Bear Jack” boards. I’m always terrified when we have to run CAN wire up an umbilical on a moving part. Any damage to those two wires kills the bot. Using ethernet cable for longer runs feels stronger.
1 Like
Yes, you understand correctly. We accounted for that in our control system networking architecture with the BearJack device (also fully documented in that same publication), which allows you to send 4 wires of signals + power over a single Ethernet cable to to max electrical limits of the signal. Even better, due to the twisted-pairs in the Ethernet cable, common-mode noise rejection is maintained, so signal quality remains high. One pair would be used to send the CAN Bus to the remote node, and the other pair would bring the CAN Bus back. If you send your DC power over the BearJack as 12 volts and put your regulation to 5 volts on the far end, this set up will support at least 5 A current at the remote node – enough to do a lot of cool sensor and servo stuff with.
The next step for our control network architecture is to build a CAN Bridge; we have all the designs done but haven’t built and tested it yet. We’re also hoping a FRC vendor will build one, but no luck on that front yet that we know of. A CAN Bridge will allow us to build an electrically-isolated branch off the main bus, so we only need to send a 2-wire CAN extension to a remote node and can terminate it there. Will post to CD if and when we complete this mini-project, but it won’t be soon (days or weeks).
Another option is to not loop the CAN Bus and just extend it out the BearJack extension to the remote node, and terminate it there. It’s not required to terminate the CAN Bus at the PDP – it can be terminated elsewhere, and the BearJack2 board does have a space for a termination resistor on it. This structure does pose some risk of losing CAN Bus continuity; you’ll have to assess whether you can mitigate that risk. “Experiences may vary…”
4 Likes
Now that the season is over for us, I’ll report on how this worked out. We basically ran these REV CAN Extension wires around the robot and inserted the splitters anywhere we had a motor. Being able to just use the connectors that were already on the motor’s CAN wires was great and we didn’t notice any issues with the CAN network during competition. We’ll run our CAN wires this way again next year.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.