CANLight - A CAN based LED strip controller

[deepak]

at mindsensors.com we have developed a CAN based LED strip controller for FRC robots,
Just showing off a robot with it.

here is a url to it's video: https://www.youtube.com/watch?v=jgv_hIwiyp0

http://www.mindsensors.com/frc/181-c...for-frc-robots

[Drakxii]

How does the programming work?

[frcguy]

Looks like an interesting concept. I'm a little confused by the CAN interface - to me it looks like it only has a CAN input. Does it then include the terminating resistor on-board? That would also mean you are forced to have the controller last in your CAN chain. Another question - is it available without the LED strip? Kind of expensive with everything included.

[nuclearnerd]

Following up on the CAN question, is it too late to have an extra 2 pins added for "CAN out". That would save having to put another terminal strip somewhere to daisy chain this to another CAN device.

[EmileH]

Although this does look like a cool way to get started with LEDs, what advantages - cost or functionality - does it provide over using an arduino Uno plus an individually addressable LED strip?

[deepak]

Originally Posted by Drakxii

How does the programming work?

For Java and C++ there will be API library that you will be able to import into your Eclipse. We will have instructions posted soon.
For LabVIEW, there will be palette icons that you can import into your environment.
For Python, there will be library to import into your program.

API's can control the On/Off state, colors, intensity of lights, etc.

[Andrew Schreiber]

I'd be curious how you determined what connectors to use. Truth - they seem kind of random.

That being said - How did you like working with the XT60s? I've been meaning to pick some up for a project?

The 2 prong CAN connection is an odd choice since none of the rest of the CAN bus cables use that style connector, was this a cost saving measure?

That being said, screw terminals seem like the perfect connector for the LED strips.


I'll also second an interest in potentially purchasing without the lights (i have a bunch of strips already).

I'd also like to ask about how they work - if I apply power to the controller and no CAN signal will they retain the previous state for the lights? IE - are these set and forget or do I need to set them each power up?

[frcguy]

Originally Posted by Andrew Schreiber

That being said - How did you like working with the XT60s? I've been meaning to pick some up for a project?

I just got some XT60s for a quadcopter build. While I haven't run power through them yet, my initial impressions have been pretty positive. Once you have them soldered, the connections seen quite solid. Retention is decent as well.

In terms of FRC robot applications, I still like PowerPoles better - especially because of the grouping and retention features.

[cbale2000]

Originally Posted by frcguy

Looks like an interesting concept. I'm a little confused by the CAN interface - to me it looks like it only has a CAN input. Does it then include the terminating resistor on-board? That would also mean you are forced to have the controller last in your CAN chain...

Unless you use a Star Topology.

We used a set of grounding strips as a central connection point for all of our CAN this past year, if we were to use one of these LED controllers we would simply drop in another set of CAN wires for it onto the strips and have it connect up without needing to rearrange anything.

[frcguy]

Originally Posted by cbale2000

Unless you use a Star Topology.

We used a set of grounding strips as a central connection point for all of our CAN this past year, if we were to use one of these LED controllers we would simply drop in another set of CAN wires for it onto the strips and have it connect up without needing to rearrange anything.

Huh - I've never seen that setup before. Have a photo and/or wiring diagram to show how you have it set up?

[cbale2000]

Originally Posted by frcguy

Huh - I've never seen that setup before. Have a photo and/or wiring diagram to show how you have it set up?

Looks something like this:

http://i.imgur.com/er8Aq4e.png

We figured out it was possible after realizing that the two pairs of wires coming out of Talon SRX's were electrically identical (literally soldered to the same spot), we hypothesized that because of this the actual point the connection is made should be irrelevant and after a bit of digging came across the Star Topology. The biggest issue was finding an adequate grounding bar to use, as most are not shielded and/or made for very large gauge wire. The grounding bars we ended up using were still a bit overkill (rated for like 400A DC) but worked very well once hooked up. The only problems we ran into were caused by poor crimps in the ring connectors we had attached to the CAN wires.

[jimbo493]

CAN is run in parallel, so you could easily just twist two wires together and insert them into the crimp or something like that. An inconvenience, but it still works as it should. the greens and the yellows are commoned on every device out there.

EDIT: Star topology is not recommended, discussed here, and here

Yes it may work, but you are more likely to run into signal quality issues, due to the loss of twisting and long runs, besides, I'm not sure I see the real benefit, you need a pair of wires for every device on the bot going back to a central location, rather than short links from device to device.

Basically, dont do star, and you can make it work, but id recommend the weidmueller connectors if they do a revision if the board, even if it adds to the cost.

That red cable looks like a Y cable to me, I wonder if thats what its for, however, I see an issue of the wrong colors for CAN wiring(required in the rules, usual disclaimer about 2017 being different...), and it doesn't look twisted

[pnitin]

EDIT: Star topology is not recommended, discussed here, and here

I think Long Can network wires can be problem but you have to understand what is "Long". CAN spec says 40 meters, does typical FRC robot have even 8 meter of CAN wire length?
CAN is differential signal so as long as you have twisted pair and proper termination resistor you are good for FRC use. if your network is in manufacturing shop floor then you are in totally different situation

[marshall]

Originally Posted by pnitin

I think Long Can network wires can be problem but you have to understand what is "Long". CAN spec says 40 meters, does typical FRC robot have even 8 meter of CAN wire length?
CAN is differential signal so as long as you have twisted pair and proper termination resistor you are good for FRC use. if your network is in manufacturing shop floor then you are in totally different situation

As a mentor on a team that has been running CAN for a long time, I'd advise against the star topology for FRC. It might work but why risk it? Why give yourself the headache of dealing with terminating resistors on all the components?

There is another upside to daisy-chaining with CAN. It's forced us to invest in reliable connections between components or soldering the wires, which is designing for success rather than designing for failure, which is what you're trying to do with a star topology. The star topology makes a base assumption that you are trying to avoid a failure with a single component taking down the entire system.

Just my thoughts but we've been doing this for a while. I won't claim we have gotten it 100% right yet but I think our experience has given us a lot of insight.

[cbale2000]

Originally Posted by jimbo493

CAN is run in parallel, so you could easily just twist two wires together and insert them into the crimp or something like that. An inconvenience, but it still works as it should. the greens and the yellows are commoned on every device out there.

EDIT: Star topology is not recommended, discussed here, and here

Yes it may work, but you are more likely to run into signal quality issues, due to the loss of twisting and long runs, besides, I'm not sure I see the real benefit, you need a pair of wires for every device on the bot going back to a central location, rather than short links from device to device.

Basically, dont do star, and you can make it work, but id recommend the weidmueller connectors if they do a revision if the board, even if it adds to the cost.

That red cable looks like a Y cable to me, I wonder if thats what its for, however, I see an issue of the wrong colors for CAN wiring(required in the rules, usual disclaimer about 2017 being different...), and it doesn't look twisted

I did see those threads previously but to be honest we never had any issues wiring our CAN using Star. Aside from some poor crimping early on the system ran flawlessly throughout the season this past year.

We opted for this method because we got tired of having a single loose link between two controllers or a dead/unpowered controller disable the entire robot for a match, while Star doesn't guarantee redundancy (as a connection loss at the controller will still disable everything), it's removes a LOT of points of failure and reduces the impact of most failures if/when they do occur. I would much rather loose one of my 6 drive motors for a match than the entire robot.

We didn't have any issues with cable lengths either, but we did keep most (though not all) of our CAN devices close to the central hub (made mounting easier anyways) so long wires weren't necessary. We also did not add any terminating resistors beyond what's already part of the RoboRIO and PDP.

There is also plenty of searchable documentation that supports Star Topology (as well as one called "Ring", which looked interesting) as an option for CAN systems (different environments, granted, but same architecture regardless).