I designed a star CAN board in the offseason, and now that we’re coming to the time of wiring the robot, I’m trying to figure out if anyone has actually done it, and what their experiences with it were.
Not Star, but 3468 is planning on using a combination of two types of splicing tap connectors to create an actual bus configuration with easy disconnects instead of a chain.
2-pin T-Tap Connectors: https://www.amazon.com/dp/B07DFZ8CBV/
2-pin I-Tap Disconnects: https://www.amazon.com/dp/B081JG4KR5/
1 Like
We did it as an off-season project and it worked without issue. We are planning on executing it in a competition robot for this season.
Is it feasible and legal to do a hybrid star or bus system separating drivetrain from other mechanisms? We have always toyed with the idea and never really done it. Every year though, it seems tempting.
~Mr. R^2
1 Like
Any topology is legal as long as it works well enough for the inspector to see the PDP firmware on the driver station IIRC. Bus can be done, but it has limitations on stub length you should consider.
3 Likes
Our team has been using a custom-made PCB that runs CAN in star configuration for the past two seasons. So far there has been no problems with it. Here is a post we made last year on our PCB: 2019 CAN PCB Giveaway by 5338
3 Likes
On our 2019 robot we had a separate leg for everything on the carriage of our elevator (Talon SRX and PCM). We never ran into problems.
3 Likes
We ran our CAN in star configuration all through 2018 and 2019 and never had any CAN issues. Could anyone explain why the common advice is to avoid star config like the plague? To my understanding, at the scale of FRC robots star configured CAN isn’t an issue - it only becomes one with much longer wire lengths. IMHO, the star configuration is much easier to wire and track through the robot due to its modularity. Additionally, one bad connection won’t kill your whole CAN bus which is an issue with the standard daisy-chained configuration.
4 Likes
Totally agree about it being easier/more reliable, the reason I’m a little nervous about switching is that it’s not common and also not mentioned whatsoever in FIRST’s guide to setting up the control system. That said, given that people have had a positive experience with this in the past, I think we’ll go for it this year
2 Likes
When a bus is short enough, a daisy chain with acceptable stub lengths and a star look about the same.
5 Likes
Technical inertia is a very real thing. If something works, even if it’s silly, you have to have a reason to risk changing it.
Perceived risk is just as powerful as real risk.
That being said:
I think some could argue this, especially if you consider “CAN networks in general”, rather than FRC specific. The CAN bus specs are very specific on what topologies work and don’t, so in theory the frequency of usage shouldn’t matter - corner cases are indeed still cases.
IMO - FIRST chose one way that’s nearly impossible to screw up (let device manufacturers control the drop length), and purposefully didn’t mention that “Other ways will work too”.
4 Likes
Those are excellent points. The team I was on had been around for a decade when I joined so we were a little less hesitant to push the boundaries with the control system. That might seem quite daunting for a less experienced team though, especially with the lack of documentation for the method.
I think with the rising popularity of motors with integrated controllers, more teams will benefit from exploring alternative ways to wire their CAN bus. Even with a relatively bare CAN bus (~8 Talon SRX’s and the required control components) the star configuration is superior in my experience for the two reasons already listed - reliability and modularity.
I’m glad this discussion has gone the way it has. I remember a few years ago a thread just like this one had popped up and not a single person in it had built a robot with CAN in a star topology, but everyone was sure that it was not a good idea. This thread feels a lot more educational and supportive.
2 Likes
I started doing it after seeing your 2018 robot. And didn’t have problem last year with. Initially with wago 222s then with t-taps.
1 Like
Because it is not the recommended practice by the OEMs of the Talons or the authors of the CANbus standard (mostly automobile manufacturers). Can you do some sort of star bus? It probably will work in a FRC environment but you should test it thoroughly. In my professional opinion the advantages of a star topology are not worth the risk. In FRC the bus is so short using the 12"-ish allowed stubs make it resemble a star configuration anyways. Why tempt fate? The robot is already a complex environment. Who needs to introduce unknowns?
Many folks in FRC say they have experienced no CANbus errors wired in a star configuration. But have they searched their logs for problems? With respect I kinda doubt it. IMHO we’ll rely on the tens of millions spent by the auto manufacturers designing and testing CANbus and use the team’s time on other more productive subjects.
7 Likes
We’ve run competition bots for multiple years with a star configuration in the sense that all can wires run to a common point. Not just that but we run both sets of can wires to the speed controllers. why? because in the past we’ve fought can issues because of bad connections or in one case when we had a daisy chained 1 bad controller with bad internal soldering dropped out that speed controller and everything down the chain. That’s even higher risk if you daisy chain the spark max since they have removable plugs. a but of intense vibration or loose connection you may lost the majority of control of your robot and that sucks. We’ve been there so with this configuration if 1 controller goes out at least the remainder of the robot still works.
This is pretty much it. Using a star topology without end termination allows lots of signal reflections, which raises the noise floor. As mentioned previously, CAN busses in most FRC use cases are so short that you can probably get away with it, but why reduce your safety margin?
1 Like
If your team is making bad connections, you will still have problems with your control system. Did your team have problems with making PWM connections, power connections, pneumatic solenoid connections or sensor connections? A fundamental of good engineering practice is to fix the root cause, rather than applying a baind-aid as your team is doing.
There are millions of cars on the road with CAN bus networks running throughout the car in the daisy chain configuration, each running for years without problems. There are all sorts of industrial applications using the CAN bus networks in the daisy chain configuration. There are probably (10’s or 100’s of) thousands of these applications for every FRC robot in existence. They can do this because they have learned how to make good quality electrical connections. It’s not that hard.
As I have stated in past threads, if your CAN bus implementation has a problem with reflections that is not fatal, you will have a difficult time knowing that you have a problem because you are just under some threshold. The noise/reflection effects are nonlinear. If you then make some change in your system (swap a motor controller, re-route some CAN wiring) the reflections could start crossing the threshold and suddenly you have a problem. I am pretty certain that no one at an event (not even the FTA’s and CSA’s) will have an oscilloscope or bus analyzer to troubleshoot your CAN bus on hand.
2 Likes
Well I’ll take that as a challenge 
2 Likes
all good on paper but that’s not the reality we’ve run into over the years. I mean for fudge sake do you know how often a robot loses connection on the field? there is no amount of “fix it so you have a good connection” that will actually work. have you ever worked with the jag speed controllers? do you know that no matter what you do you can’t get a “good” can connection on those stupid things? For example we’ve had to resort to powering the radio over the barrel jack and completely covering in hotglue every point of contact in the chain in ADDITION to running POE to it as well. We’ve lost tournaments because of bad connections during a bad time during a critical game. We even go out of our way to NOT use quick disconnects or even screw block terminals since when we tried those during off season we had issues. We solder everything other than where we don’t have a choice (like those removable plugs on spark maxes) so we do everything we possibly can to mitigate issues and they still sometimes occur.
for those mag absolute encoders we’ve even had to resort to not using the connector and instead soldering wires directly to the pins as we’ve had issues on those connections as well even when we completely drenched them in hot glue and strain relieved them.
The next challenge is to find people who know how to use the scope properly so they don’t pick up spurious noise…
1 Like