Log in

View Full Version : CAN to PWM converter?


asid61
23-08-2016, 01:08
After reading the recent thread on motor controller selection, I realized that if a poor-ish team wanted to use CAN they would have to drop $40 more than a SPARK to buy a Talon SRX. Does anybody know how one could have a separate PCB that would act as a CAN device and relay commands to a Spark or Victor SP as PWM? I anybody could help me with it/answer case-by-case questions (like how CAN commands would be set up, how to set up a particular chip) I would be very grateful.

nickbrickmaster
23-08-2016, 02:14
IIRC, the CAN protocol used for FRC is pretty heavily modified and kept under wraps to prevent tampering.

If you do somehow figure out the protocol, you would need to use a microprocessor to a. spoof a talon SRX and b. translate the commands into PWM values.

I can't really help you with anything, sorry. If you wanted to try to reverse-engineer the protocol, I would start with the firmware files, or maybe see if it's on robotpy's github.

FrankJ
23-08-2016, 08:51
Current FRC rules would prohibit that anyway. R68 in 2016 rules. The usual caveat about future rules, but I don't see this changing. The device would be more than a simple convertor. It would have to read & respond to Canbus commands and the make a PWM output. Would still would not get the advantages of the additional modes in the native Canbus motor controler By the time you made that, you would have covered the gap to the Talon.

If you just want Canbus, a cheaper solution might be to find used Jaguars. They have a somewhat undeserved bad reputation.

Chris is me
23-08-2016, 09:15
I don't understand why someone would want to do this. Can you elaborate on the advantage?

ASD20
23-08-2016, 09:18
I don't understand why someone would want to do this. Can you elaborate on the advantage?

I'm guessing the main one is that a poorer team would not have to buy all new motor controllers if they wanted to connect everything with CAN

Chris is me
23-08-2016, 09:35
I'm guessing the main one is that a poorer team would not have to buy all new motor controllers if they wanted to connect everything with CAN

I mean, what is the advantage of using CAN on a motor controller that does not support it? You don't get any of the cool CAN-only features of the Talon that way. I'm not the most electrical / software guy so I think I'm missing something here.

nickbrickmaster
23-08-2016, 10:25
I mean, what is the advantage of using CAN on a motor controller that does not support it? You don't get any of the cool CAN-only features of the Talon that way. I'm not the most electrical / software guy so I think I'm missing something here.

The advantage I see is being able to connect all your devices in sequence.

marshall
23-08-2016, 10:44
IIRC, the CAN protocol used for FRC is pretty heavily modified and kept under wraps to prevent tampering.

If you do somehow figure out the protocol, you would need to use a microprocessor to a. spoof a talon SRX and b. translate the commands into PWM values.

I can't really help you with anything, sorry. If you wanted to try to reverse-engineer the protocol, I would start with the firmware files, or maybe see if it's on robotpy's github.

If by heavily modified and kept under wraps you mean CAN spec compliant and out in the open based on the manuals provided by CTRE then you are absolutely right!

http://www.ctr-electronics.com/Talon%20SRX%20Software%20Reference%20Manual.pdf
http://www.ctr-electronics.com/Talon%20SRX%20User's%20Guide.pdf
http://www.ctr-electronics.com/PCM%20User's%20Guide.pdf
http://www.ctr-electronics.com/PDP%20User's%20Guide.pdf

Being that CTRE's devices are the only CAN devices at the moment for FRC motor control (and power and pneumatic) and they offer non-FRC firmware and tons of example code, they are doing a terrible job of hiding any of this.

My smarty-pants response aside, the CAN devices available for FRC teams are pretty well documented and accessible.

Also relevant if you get into CAN jiggery pokery:

Cool device and software for making it a lot easier (CAN is integrated into the Linux Kernel these days though):
http://linklayer.github.io/cantact/

Good talk explaining how CAN works and how to use above device with software (I'm in the audience somewhere):
http://livestream.com/internetsociety2/hopeconf/videos/130605456

EDIT: Also, the irony of FRC specific CAN being an undocumented dark art while most of the automotive industry keeps it a closely guarded secret is amusing. Seriously, watch the talk.

notmattlythgoe
23-08-2016, 11:26
You must spread some Reputation around before giving it to marshall again.

asid61
23-08-2016, 14:31
I mean, what is the advantage of using CAN on a motor controller that does not support it? You don't get any of the cool CAN-only features of the Talon that way. I'm not the most electrical / software guy so I think I'm missing something here.

Mostly just the ease of wiring. Plus, if you already own PWM motor controllers, if one can make a CAN-PWM converter for $2 or $3, it's not a bad investment to purchase them instead of SRXs. Personally, if I wanted to do CAN control the next year, I would rather purchase a few converters before jumping on SRXs; SRXs could be used for the motion profiling, and the converters for less critical applications.

That being said, if I could get a converter working, then it's possible to increase the size of the microcontroller and add support for PID or something, although at that point we're getting into SRX territory anyway. :P Kind of unfortunate that the rules disallow it, although the rule makes sense.

nickbrickmaster
23-08-2016, 14:31
<snip>

My bad, sorry :|

Thanks for the info. Must have been the late night that caused me to miss those sections.

AdamHeard
23-08-2016, 14:37
Mostly just the ease of wiring. Plus, if you already own PWM motor controllers, if one can make a CAN-PWM converter for $2 or $3, it's not a bad investment to purchase them instead of SRXs. Personally, if I wanted to do CAN control the next year, I would rather purchase a few converters before jumping on SRXs; SRXs could be used for the motion profiling, and the converters for less critical applications.

That being said, if I could get a converter working, then it's possible to increase the size of the microcontroller and add support for PID or something, although at that point we're getting into SRX territory anyway. :P Kind of unfortunate that the rules disallow it, although the rule makes sense.

if it were a COTS converter for FRC it would likely be in the $20-30 range (if not more).

You also give up most of the usefulness of CAN while doubling your number of control system connections.

Chris is me
23-08-2016, 14:52
Mostly just the ease of wiring. Plus, if you already own PWM motor controllers, if one can make a CAN-PWM converter for $2 or $3, it's not a bad investment to purchase them instead of SRXs..

I don't think people actually invest in the SRXs simply because they prefer the wiring layout of a CAN system. If you're using SRXs and CAN, it's to take advantage of the features that require the CAN bus (e.g. PID). These features don't become a thing on other speed controllers just by converting PWM to CAN. It's not a good idea.

MichaelBick
23-08-2016, 14:53
Mostly just the ease of wiring

I'm going to agree with Adam here and add on. One of the bigger negatives of CAN is that if your first connection in the daisy chain fails, all of your motor controllers go down. Although CAN seems like the easier method of wiring motor controllers, it has its fair share of issues.

asid61
23-08-2016, 14:57
if it were a COTS converter for FRC it would likely be in the $20-30 range (if not more).

You also give up most of the usefulness of CAN while doubling your number of control system connections.

Forgive me, but I don't know enough about CAN to see where $20 to $30 came from. I was looking up general-purpose CAN controllers and microcontrollers and found options in the $1-3 range, and PCBs should only cost $1-2 tops. What would drive up the cost?

I don't think people actually invest in the SRXs simply because they prefer the wiring layout of a CAN system. If you're using SRXs and CAN, it's to take advantage of the features that require the CAN bus (e.g. PID). These features don't become a thing on other speed controllers just by converting PWM to CAN. It's not a good idea.

That's pretty fair. But if you could do it for cheap or wanted to try out CAN in general, a cheap converter would be useful. Plus, it would be easy to go from converter to SRX without changing much code.

AdamHeard
23-08-2016, 15:02
Forgive me, but I don't know enough about CAN to see where $20 to $30 came from. I was looking up general-purpose CAN controllers and microcontrollers and found options in the $1-3 range, and PCBs should only cost $1-2 tops. What would drive up the cost?



That's pretty fair. But if you could do it for cheap or wanted to try out CAN in general, a cheap converter would be useful. Plus, it would be easy to go from converter to SRX without changing much code.

Not all of the profit in the per item reference frame goes to the overall business profit... Most of it is eaten up by salaries of engineers, warehouse, quality control, support etc...

I know nothing about the COTS FRC Market, but I wouldn't be surprised if the per item cost on a Talon SRX is in the $20-40 range.They need to sell it at $90 to cover all the overhead and still make a profit.

Andrew Schreiber
23-08-2016, 16:11
Forgive me, but I don't know enough about CAN to see where $20 to $30 came from. I was looking up general-purpose CAN controllers and microcontrollers and found options in the $1-3 range, and PCBs should only cost $1-2 tops. What would drive up the cost?



That's pretty fair. But if you could do it for cheap or wanted to try out CAN in general, a cheap converter would be useful. Plus, it would be easy to go from converter to SRX without changing much code.

PCB fabrication is cheap, populating it? Less so. Add in a case, quality control, development costs... I've got a hunch COTS would be in that range if not a little higher.

FrankJ
24-08-2016, 08:56
Not to mention programing & design time. If you are doing it as a hobby or have students do as a project that might not be much of an issue. If you have to actually pay your programmers and engineers, it starts to add up. Quite expensive for a prototype or small production run. Obviously the per unit costs come down with the more you make.