SparkMAX following loadless Talon

#1

Yes, before you say it, I know there are a lot of topics asking if the spark max can follow a Talon SRX. This is not one of those topics. The subject may not be clear enough, but reading through here I ran across the concept of using the complex built-in libraries of the TalonSRX, but having all the motors be NEOs instead of a heavier motor like a CIM and driven by SPARK maxes following the Talon. I recognize a few situations where this would be impractical:

The complex motion-profiling, etc. features of the talon are not necessary (probably any motor that does not need to be precisely controlled)
Using a Talon and brushed motor is just as useful (lighter, faster, cheaper) as a SPARK MAX and a brushless motor (because you likely already have Talons, in which case the use of the MAX would be to use a brushless motor)
You’re out of PDP slots. (remember, every motor controller needs one of the 16 slots, even if it doesn’t have a motor attached)

However, for a team whose programmers know lots about using the control features of the Talons, but whose mechanical design team wants to go brushless, for the physical advantages of NEOs over CIMs, this might seem like a good compromise.
The main problem would be if it turns out to not work at all, which is why I have been asked to research it. So I turn to this community:

Has anybody else experimented with slaving SPARK MAXES to a Talon without a motor attached, and if so, how was your experience with it?

#2

I can’t help but think that this is a pretty inefficient way of achieving whatever it is you’re trying to do. Without a motor attached, an SRX is basically a coprocessor that you have to treat like a motor controller with respect to wiring, PDP slots, etc. Why not write your own high-speed thread on the RIO to do that processing? You could potentially even use a separate coprocessor, such as a Raspberry Pi, to run all of your motors. Heck, since the SRX runs a dsPIC, you could probably figure out how to load the CTRE firmware onto your own dsPIC board, creating a “brain-in-a-jar Talon” that you wouldn’t have to count as a motor controller.

4 Likes
#3

At Detroit CTRE was showing off a new BLDC motor and controller that they hope to have legal for the upcoming season. They said the new motor controller will have the same programming features as the Talon SRX currently has. No official word on these new products yet, but if they do come to fruition that should all but solve your problem.

If this is not an option, I want to question this statement:

If the Talon isn’t controlling a motor, you can consider it part of a custom circuit. So you can power all of the sensor Talons from either a single PDP branch circuit or a VRM circuit.

#4

Personally I think it should be this way, but would that actually be legal?

I don’t see any leeway in there for motor controllers that aren’t actually being used to control motors.

#5

Electrically, a small load (1k resistor maybe?) is less potentially harmful to the controller.

If it is a standard H-Bridge using MOSFETs, a high-impedance load (open circuit) can allow for harmful (to the circuit) voltage spikes. Oh, there are ways to mitigate these things, but why risk it for a few milliwatts?

#6

Interesting. Yours definitely seems to be the correct interpretation of the definition of a custom circuit.

A CUSTOM CIRCUIT is any electrical COMPONENT of the ROBOT other than motors, pneumatic solenoids, roboRIO, PDP, PCM, VRM, RSL, 120A breaker, motor controllers, relay modules (per R36-B), wireless bridge, electrical solenoid actuators, or batteries.

(emphasis mine)

That being said, I’ve definitely seen custom circuits with VRMs and Spike relays inside. And per R40 COTS battery packs can be included in custom circuits to power computing devices. So I don’t really know.

#7

Back in 2017, when I needed a relay inside a custom circuit, I intentionally didn’t use a Spike for this reason. It would be nice to get some clarification on whether motor controllers and relays only count as such when being used to control actuators.

#8

Following a Talon with the SPARK MAX is currently not officially supported. You can read about details in the release notes under ‘Known Issues’ here. That discussion also includes details for a roboRIO side code workaround.

Anyone who is familiar with the common control features of the Talons shouldn’t have any issues using similar functions on the SPARK MAX. We have some good examples and API documentation that can help as well.

#9

CTRE refused to provide information to REV that would have enabled this functionality.

#10

CTRE’s CAN communication protocol is documented online (and can be reverse engineered using CAN reading programs) so I don’t know that this is necessarily the issue.

Edit: Apparently I was misremembering and this hasn’t been done yet. See below

#11

This is exactly what we did. We were able to successfully use velocity control and motion magic with a NEO that had a spark max follow a talon not connected to any motor. It worked flawlessly and very accurately and we didn’t use Spark Max’s built in following code. We did however use this for our Arm, but we think it could have very well worked with our drivetrain for motion profiling. If you want more info about how we did it:

Reason behind doing this:
The NEO was the only motor that would fit in our design, so programming team was tasked to get it working like a cim and talon. Neo’s motion magic equivalent was a horrible experience for us, so we ditched it.

2 Likes
#12

If I may suggest, please read the known issues linked prior to my post.

1 Like
#13

As Kunal said, we did the exact thing you are describing as the NEO was quite literally the only motor that would fit to power our arm. The method we used to follow the SRX I posted a while back here: REV SPARK MAX & NEO APIs & Info

The reason we did this was because at the time we were not very confident in the Spark MAX software and because we did not want to put any more workload on to our (admittedly weak) programming team than they already had.

#14

Are you sure? The “old” Talon CAN protocols (that I used here, and that can be found in code on the CTRE github) is no longer in use. Recent Pheonix releases use different, obfuscated packet formats that I haven’t yet succeeded in reverse engineering.

#15

The documentation I remember seeing must have been for the old protocols. I’m pretty sure I remember seeing someone on here had reverse engineered the new protocols, but I’m on mobile so I can’t go searching for it right now. I think in Detroit the Dilligent people were showing off one of their products that reads the CAN bus messages and they were explaining how the CTRE motor controller protocols work, but I could be mistaken on that.

#16

Would you mind providing a link to documentation listing the specific message ids and contents of each message for CTRE’s protocol? I may be wrong, but I have never seen such a document.

#17

I thought I remembered someone reverse engineering the new protocols but I can’t seem to find it. I’m starting to think I was just misremembering the documentation and reverse engineering of the old protocols, thinking they were for the new ones.

#18

Incidentally, if anyone else is also working on cracking the new protocols, I’m up for collaboration…

#19

I’d heard about this, but it was “maybe if enough people lobby the GDC they will clarify this.” I agree with CarlosGJ, I’m pretty sure a motor controller is a motor controller, regardless of whether it’s actually controlling a motor.

#20

So I’m getting mixed messages here. For some teams it seems to work fine, others say it’s totally not supported to follow a Talon with a MAX. Did some teams just do some hackery to get it to work?