Due to a couple of consistent problems with checking CAN connections during the 2017 Power-Up season, our controls department has been looking for ways to simplify wiring to a central hub, so that only one central location has to be checked for any CAN related issues.
After some thought, I realized that since the order of connecting CAN devices together doesn’t matter, making a central board to manage the wiring should be a simple task.
To test the notion that centralizing CAN connections could work, I quickly whipped up a proto-board prototype, and to my surprise, it worked! (there will be pictures at the bottom of this post).
I tried changing the order of the CAN connections, and the RoboRIO web interface still recognized the motor controllers(victor spx & talon srx), and I was able to control the motors. After reading a bit more into the idea, a helpful mentor noted that CTRE apparently doesn’t recommend the hub, due to ‘star topology’. My main question is, why is connecting the CAN devices to a central hub regarded as “less stable”, and only recommended for test benches according to the talon manual(image below)? Additionally, doesn’t star topology actually benefit the reliability of the CAN connections, since if a cable fails, only one node will be brought down?
You are right in that making a central hub won’t deter from any bad crimps or joints, which are a major problem. However, the main objective of this project is to make diagnosing which connections are faulty much easier. Additionally, we inevitably have motor controllers in separate parts of our robot, meaning that the CAN loop is (sometimes unavoidably) hard to access. This *solution attempts to centralize the connection point in order to help fix CAN issues faster during competition.
At the speed CANbus operates (1 Mbps), you have to think of the twisted pairs as transmission lines. In order to avoid causing reflections, which can potentially interfere with subsequent signals, a transmission line has to be terminated with its characteristic impedance (~120 ohm, for 20ish AWG twisted pair). Now, this can be done in a star topology, by terminating each of the “arms” of the star. However, the more arms there are, the lower the net resistance between the two sides of your bus (resistors in parallel). With lower differential resistance, it becomes harder for the CAN transceivers to rapidly assert a dominant voltage on the bus. (When the bus is left to float, and the sides are at approximately the same voltage due to the resistors, it’s called a “recessive” state. When the sides are driven apart, one side high and the other side low, it’s a “dominant” state.)
While we don’t use it in FRC, it’s interesting to note that there’s a different standard, called low speed or fault-tolerant CAN, that allows bus, star, and pretty much arbitrary topologies, at the cost of much lower bandwidth.
It’s not usually a problem to use star topology, if you’re confident in your wiring. CAN is not only very robust, but also tells you when you get CAN errors, so it’s possible to pick up any blips.
That being said, using bus topology is one less thing to worry about when debugging CAN. If you’ve only got Talons on the E-plate of your robot, right next to the RoboRIO and PDP, star can work easily. But if you have a branch of CAN going 10ft to the top of your elevator, you might start seeing issues.
That article seems to say that you can basically use star topology as long as the branches are less than 1ft long. So if you have a compact control board, star should work. But I wouldn’t risk it. 548 always solders their CAN in a chain/bus topology and I don’t think we’ve had any issues in the last few years.
We have motor controllers all over the robot as well - placed in proximity to their motors as that is our convention typically. We route the CAN wires where they need to go since we have to run power to those locations anyway, data lines aren’t a big deal to run with them (blah blah, bad practice, shielding, blah blah… leave me alone EEs, this is HS robotics, not a defense missile system).
We SOLDER and then apply heat shrink to all of our CAN connections. This has served us well.
And yeah, we’ve tried it the other way. It did not work as well.
I do agree that having this sort of setup with a compact board does simplify a lot of wiring, you could just do a few simple things to keep your CAN manageable.
If your having trouble diagnosing CAN, an easy trick is to color code (and number) your motor controllers, and cables (also label them accordingly in silverlight). This allows for communication between the programmers and your electrical team to see where the problem is occurring.
Another easy thing to do, is keep your CAN wires as short as possible. It’s pretty hard to diagnose your robot when you’re staring into a bowl of yellow and green spaghetti. This also helps with keeping your CAN consistent.
Also, keep your motor controllers in one place. This is intrinsic to the last two anecdotes I made. This will allow short CAN paths between them, as well as make it easier to diagnose any CAN issues by viewing light codes on the motor controllers.
Lastly, our team had an issue our 2017 year with when the CAN went down on our turret, the rest of the robot went down. If you have this sort of issue, you can actually make a Y-split-CAN wire with a 120ohm resistor on it, to prevent a problem like that.
Hope this helps out, I know that CAN be a complicated beast to tackle, and I wish you luck with it.
Star topology networks almost always (perhaps always?) have an active device as the “star” to reduce (or in some cases eliminate) “packet collisions” where two or more nodes are trying to send data at the same time on the same piece of wire in the same bandwidth/channel, and which limits the amount of energy each node requires for transmission. A bus topology puts the nodes at a bit of a distance from each other, allowing collision mitigation, and, as Carlos notes, allows the ends of the bus to have an appropriate resistor to knock down reflections while not (significantly) increasing the power load requirement on each device as more are added.
CAN is quite robust and you’ll likely get away with this on most FRC robots - but you risk crossing that threshold and having to rebuild quickly at an inopportune time, and/or losing match(es) because your CAN is overloaded.
A bit of electrical background for those who might be viewing this thread and thinking “but it probably works right???”:
When frequencies are low, and wire lengths are short, you can make the assumption that electrical current and voltage travels instantaneously from one point on a wire to another, with no distortion in waveform.
As frequencies get higher and/or wire runs get longer, this assumption is no longer true. The effect is usually modeled with what’s called a Transmission Line.
1Mbps CAN on an FRC robot is just barely where this assumption flips to requiring having a transmission line in your model of the electrical signal.
A certain node on the bus will produce a waveform that is distorted in specific ways as it propagates down a wire. It gets rounded out (slower voltage slew rate as you switch between high and low voltage levels), and delayed. This can be bad, since CAN protocol relies on having all transmitters start talking at the same time, with some minimum low-to-high transition time. Devices & wiring schemes that cause these assumptions to be violated are no longer technically compliant with the standards for CAN, and all bets are off as to whether you can transfer data.
The ISO standards for CAN are set up to assume a transmission line in between each node, but not a transmission line from a common point to each CAN bus node device.
Again, for sufficiently short wire runs and CAN bus speeds, can you make it work? Maybe. Should you play with fire? I don’t think anyone will say “eeeh you’ll be fine”.
Are you plugging in both pairs of the CAN wires for each motor controller into your board or just one pair? If you plug both pairs into your board, the stub length is equal to the length of each pair of CAN wires. If you only plug in one of the two pairs, your stub length is roughly twice the length. This might cause greater signal distortion than if both pairs are plugged in. Please note that the length of each of the pairs of the CAN wires is 1 ft as delivered from the factory.
You can get the basic effect you are after (all connection points in one area) if you cut the solid wires running the length of the board to divide the connectors into pairs. You would plug one of the CAN wire pairs from a motor controller into one pair of connectors and the other CAN wire pair into a different pair of connectors. You may have to double the number of connectors you install on the board. This would change the star into a daisy chain. It would have the same effect as having a bunch of the CAN Connectors from AndyMark all on the same board.
The challenge with “getting away with it” is systems such as a CAN bus are nonlinear. Doubling the amount of noise or distortion may not lead to an degradation in system performance if the noise or distortion is small enough. Conversely, if the noise or distortion is just below the detection threshold, a small increase will cause a significant degradation in performance.
Teams I have worked with in the past coiled the excess length of the CAN wires and tied up the coil with a small zip tie. This prevents the “bowl of yellow and green spaghetti” and preserves the length of the wires so that the motor controller can be reused without having to possibly splice onto the CAN wires.
Thank you all so much for your help! Based on your advice, I don’t think we will pursue this idea, but it definitely gave our team a much better understanding of CAN. Also, the helpful tips on how to manage CAN wiring are greatly appreciated. Thanks!
Yeah, we are plugging both pairs of wires into the board at the same factory length that they arrived in. Jus tto clarify, are you suggesting that we plug one pair of CAN wires on one column of headers, and another pair on another column(both pairs being from the same motor controller)?
I think you are asking about my post 14. Please have a look at the attached drawing. A picture is worth a thousand words. If you are already plugging in both pairs of the CAN wires from each motor controller, you only need to cut out the wires betwen alternate pairs of connectors to get a daisy chain connection scheme.
Next time, click on the “quote” button that appears in the bottom right corner of each post to get the text from that post in your post.
It should be noted that both sets of green and yellow wires on a Talon a soldered to the exact same contact points inside the speed controller (IE both yellow wires are connected to the exact same spot) and are, consequently, electrically identical. This means you don’t actually need to use both pairs of wires if you’re using a “Bus” topology.
For the past 3 years, I’ve used CAN control systems in a “Bus” configuration with ZERO issues (with the exception of physical issues with the wires).
The past two years I’ve connected Anderson connectors to one set of CAN wires on each controller and used these 2-channel power distribution buses to connect them all. All the yellow wires connect to the red channel, and all the green wires connect to the black channel, the ends of the CAN terminate just like they would in a Daisy-Chain layout.
At some point I would like to replace the Anderson connectors with Weidmuller connectors and make a custom bus board to make the entire package smaller and lighter.
This is, in fact, a star topology, unless I misunderstand the layout. In the proper bus topology, the “stub length” is the distance (inside the Talon, etc.) from the PCB points that connect to the CAN bus to the CAN transceiver.
Star topology may “work” in FRC electronics, due to the short distances involved. However, by introducing a multi-arm topology, you’re eating into the safety margin provided by the CAN protocol physical layer. Unless absolutely unavoidable, I’d prefer to do correct CAN wiring and avoid invading the margin.
