Our team is new to CAN, but would like to use the speed control function using encoders. The chassis team is thinking of using two toughboxes with two motors each, therefore requiring two jaguars each. But the problem is these toughboxes only have one encoder each. How should we wire or program so that each encoder is used by two jaguars?
What you don’t want to do is try to close the loop on speed with each of the two separate jags/motors controlling the same gearbox. This is not the right way to balance the load on the motors.
Instead, close the loop on speed with one Jag, read how much motor voltage (or current) that Jag is supplying, and feed the other motor the same voltage (or current).
**
Thank you, we will certainly try this out
Something along the lines of this . . .
Jag2.set(Jag1.getOutputVoltage() / Jag1.getBusVoltage()); //For voltage control mode
Jag2.set(Jag1.getOutputCurrent()); //For current control mode
TI told me that they would consider something to do this automatically for next year.
Just to put my two cents in, we’d definitely like to see this happen as well…
A “slave” Jaguar that automatically mimicks the outputs of a “master” Jaguar would be nice!
I was testing this today (driving the slave Jaguar with Vcomp mode), and had little success. The slave motor kept jumping all around. The ramp didn’t help.
I think the issue is inaccuracy in the voltage measurement of the Jaguar. The one situation where it worked well was at full power.
Another issue may be bugs in the Vcomp mode.
Perhaps the %Vbus mode will work better.
The %Vbus mode is the only one that I would try.
Why is that?
EDIT:
I just tried, but noticed no difference. It’s still very jerky on the secondary motors.
Now, understand that in my test, I am not actually putting both motors on the same gearbox. If I did that, I wouldn’t be able to see what each motor is actually doing. Instead, I have each motor on an identical gearbox.
Here’s an interesting graph:
It shows what my speed-mode Jaguars are reporting as their % voltage output, every 20ms.
This corresponds to what I see my secondary motors doing.
The important part here is that the speed mode Jaguars are, in actuality, driving the motors at a constant speed (approximately half of full-speed).
This leads me to believe there is an issue with how Jaguars report their output when they are in internal closed-loop control. They may be reporting what they are doing instantaneously, but that is not a useful value at 50hz.
If this is not remedied, my only option is to wire the quadrature encoder channels to both Jaguars.
Here’s a way to get around the issue of putting two motors on the same transmission:
Use only Tan Jaguars.
The reason is, Tan Jaguars switch between 12v and open (coast) in their switching.
Black Jaguars switch between 12v and 0v (brake).
Thus, if one motor is driving the other faster, they won’t conflict; the slower motor will simply coast along.
This means an encoder can be split off and wired to two Tan Jaguars for closed-loop control without issue.
Is that behavior not controllable via the brake / coast jumper? Or is that only controlling the behavior when the Jag is commanded to have 0 output?
-Joe
The brake/coast jumper only controls when the motor has an output of 0.
In the Tan Jags, during the “off” portion of the duty cycle, the circuit is not open in the direction that the current was flowing. The inductance current continues to flow through the Zener diodes as shown in the attached schematic. This inductance current continues to provide assisting motor torque during the off portion of the duty cycle.
In the Tan Jags, only the high side switches, and there is no current path for the back emf to provide reverse current (and resisting motor torque aka “braking”) in the event that the inductance current decays before the end of the “off” portion of the duty cycle. They would then be “coasting”.
Black Jaguars switch between 12v and 0v (brake).
Black Jags switch between 12V and motor shorted as shown in the attached schematic. During the “off” portion of the duty cycle, the current continues to flow (and provide assisting torque) due to the motor’s inductance. This inductance current decays rapidly, but unless there are large step changes in the command, it does not decay to zero before the end of the duty cycle. Thus there is no braking under these conditions. Unlike the Tan Jag however, if the inductance current ever did decay to zero (due to a large rapid command reduction), the back emf would have a path to force a reversal of the current (basically reversing the arrows of the red lines in the schematic), and provide substantial braking due to a reversal of the current.
See the attachments to this thread for analytical and numerical models of these effects:
Thus, if one motor is driving the other faster, they won’t conflict; the slower motor will simply coast along.
That’s exactly what you don’t want. You want the motors to share the load. If two motors are mechanically linked to the same gearbox, you don’t want separate closed-loop speed controls. This won’t guarantee load sharing.
This means an encoder can be split off and wired to two Tan Jaguars for closed-loop control without issue.
If the intent is for the motors to share the load, this is not a good approach.
**
Assuming both Jaguars have the same PID coefficients, and the load is sufficiently large, the motors will share the load.
I’m trying to avoid two Jaguars fighting with a small load, which can happen due to variances in motors.
Perhaps you can get away with it for the 2-minute FRC matches, I don’t know, never tried it.
Speaking from a control theory point of view, I can’t convince myself that the integrators will not diverge over time.
**
Isn’t the integral reset when the output is 0? I’m sure the robot will stop driving several times in a match. (picking up a tube off the ground, placing it on the rack)
EDIT:
To be sure, I’d like to match the motors by power. However, I tested it, and it’s just too unsteady. If I go this way, it will be hard on the secondary motor when the robot is moving slowly, because it will be jumping between 0 and half power at about 10hz. See my graph above.
Good point. If so, that would go a long way to mitigate any concerns.
EDIT:
To be sure, I’d like to match the motors by power. However, I tested it, and it’s just too unsteady. If I go this way, it will be hard on the secondary motor when the robot is moving slowly, because it will be jumping between 0 and half power at about 10hz.
Would filtering be an option?
See my graph above.
Off topic, but: many folks sort the posts so that the newest ones appear at the top of the page.
**
That’s true, I could. In order to get something approximately the right value, I think would have to filter out the zeros and do an average of the past five values.
At that point I have an extremely low update rate, which is not what I want for driving. (Also, this wouldn’t respond when we WANTED the robot to stop)
If I could do filtering on the Jaguar, that’d be great.
Has anyone tried matching the currents?
Per Kevin’s analysis, the current reported is reasonably well filtered.
Current balancing is torque balancing, assuming that both motor’s motor constants are equal. But, in the case that the constants aren’t equal, you will at least be sure that they are working together and not fighting.
PS: I’m at home with a head cold, I apologize if this doesn’t make any sense.