1 Encoder, 2 Jaguars

[kamocat]

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.

[jhersh]

Originally Posted by kamocat

The reason is, Tan Jaguars switch between 12v and open (coast) in their switching.
Black Jaguars switch between 12v and 0v (brake).

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

[kamocat]

The brake/coast jumper only controls when the motor has an output of 0.

[Ether]

Originally Posted by kamocat

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.

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:

http://www.chiefdelphi.com/forums/sh...5&postcount=70

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.

[kamocat]

Originally Posted by Ether

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.

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.

[Ether]

Originally Posted by kamocat

Assuming both Jaguars have the same PID coefficients, and the load is sufficiently large, the motors will share the load.

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.

[kamocat]

Originally Posted by Ether

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.

[Ether]

Originally Posted by kamocat

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)

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.

[kamocat]

Originally Posted by Ether

Would filtering be an option?

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.

[EricVanWyk]

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.

[Dave Bush]

Has anybody actually tried the Y cable solution for the encoder?

[Bryscus]

Originally Posted by Dave Bush

Has anybody actually tried the Y cable solution for the encoder?

I must say we have yet to do this, but it is planned in the near future. I will post our findings when I finally get to it. I think there is good potential that it can work in speed mode (and maybe position mode) with an I of 0. Adding the integrator could yield interesting results.

- Bryce

[otherguy]

Originally Posted by Dave Bush

Has anybody actually tried the Y cable solution for the encoder?

We tried it today. W/ our quadrature encoders (don't know the part number off the top of my head). All pins of the encoder were wired to one JAG then GND, A & B were jumppered over to the 2nd JAG. Implementing position control (implemented on only one jag - 2nd jag was not commanded) resulted in wild responses (motors continued spinning when they showed they had reached their destination). Removing the jumper to the 2nd JAG instantly resolved the problem. We didn't spend time trying to diagnose the problem, just moved on to the below. My uneducated guess is that these inputs need to be isolated. If anyone else is successful in wiring these, please share your solution.

EDIT: maybe this is our problem? http://www.chiefdelphi.com/forums/sh...9&postcount=16

We did however have good luck setting one jag up w/ PID position control (MASTER - wired to the encoder). The other JAG (SLAVE) was commanded using the %V bus mode. Inputs to the slave were the voltage output from the master controller. Sync groups were used to coordinate outputs. This seemed to work well in our tests. Our voltage output curves looked quite clean compared to some of the graphs which I had seen reported in other posts. We're going to continue this route as long as we don't start seeing any problems.

Tomorrow we'll move onto speed control.

[Mr. Lim]

otherguy,

I'm curious to see what your sync group code implementation looks like. Our team has just been directly setX'ing our slaves as quickly as possible in the Continuous loops.

I'm aware of the update sync group functionality in the API, but have not had a chance to see it, or try it.

If you are willing to share, I've love to see how you are updating your slave Jags using this feature.

[kamocat]

I'm familiar with the sync group feature, but I fail to see how it would significantly affect the control in a master-slave situation. As far as I can tell, it would simply force the slave Jagar to be one update cycle behind the master Jaguar.
What happens when you disable the sync update feature? (You can do this by setting the sync group to 0)

I'm glad you're getting good results in position mode. I have not tested in this mode; perhaps there is less oscilation.