Sync Two Jags

[Talguy]

How can I get two jaguars to sync together their PIDs when I only have one encoder. Should I have it that the one jag w/ encoder sens their voltage ramp to the jag without an encoder. How are other teams doing it?

[Joe Ross]

The following thread has some ideas, but no resolution. http://www.chiefdelphi.com/forums/showthread.php?t=89282 When you get it working, be sure to let people know how you did it.

[kamocat]

You can try using one in %Vbus, Vcomp, or Current mode, feeding it the value you've gotten from the controlling Jaguar.
For any of these options, you'll want to do some processing to the data to get something acceptable. The trouble is, for low speeds the Jaguars like to return lots of zeros. (though perhaps my PID is tuned a little too high) When you tell a Jaguar in %Vbus or Vcomp to go "0", it doesn't ramp down, it just stops. This leads to very jerky movement. Perhaps a running average of the last 5 samples would work, or perhaps you just want to ignore all the zeros.

In Current Mode, the main issue is simply lack of accuracy. It's +-2 Amps below 8A, and +-1A above. That means you better have a pretty big load in order to use it. However, large loads are usually where the double motor is necessary.

I'm planning on wiring the encoder to both motors, and having the PID independent. Because both Jaguars are subject to the same conditions, I'm hoping I won't get significant integral windup. (Also, the integral is reset when the Jaguar output is "0")

[Talguy]

You can try using one in %Vbus, Vcomp, or Current mode, feeding it the value you've gotten from the controlling Jaguar.
For any of these options, you'll want to do some processing to the data to get something acceptable. The trouble is, for low speeds the Jaguars like to return lots of zeros. (though perhaps my PID is tuned a little too high) When you tell a Jaguar in %Vbus or Vcomp to go "0", it doesn't ramp down, it just stops. This leads to very jerky movement. Perhaps a running average of the last 5 samples would work, or perhaps you just want to ignore all the zeros.

In Current Mode, the main issue is simply lack of accuracy. It's +-2 Amps below 8A, and +-1A above. That means you better have a pretty big load in order to use it. However, large loads are usually where the double motor is necessary.

I'm planning on wiring the encoder to both motors, and having the PID independent. Because both Jaguars are subject to the same conditions, I'm hoping I won't get significant integral windup. (Also, the integral is reset when the Jaguar output is "0")

Is it possible to wire one encoder to two jags?

[kamocat]

Yes, but you have to make a splitter for it.
Make sure to not wire the two 3v power supplies together, but connecting just their - terminal should be fine.

The way I was planning on doing it was taking a prototype board (5x3) and vertical 0.1" headers, and soldering across. That way, I could just take the encoder in its current configuration, plug it into the board, and have two adapter cables, one for each Jaguar.
It's also possible to have a board that plugs directly into one of the Jaguars, but that's a little harder to make.

[Talguy]

ok I could just use an old PWM splitter cable

[Alan Anderson]

ok I could just use an old PWM splitter cable

Not exactly. Quadrature encoders have more than three connections.

[Talguy]

Not exactly. Quadrature encoders have more than three connections.

yea our's has four connections but I can type them both to a common ground and 5v supply. The A&B channels will be split to the jags

[techhelpbb]

We split the encoder like this.

A to both.
B to both.
GND to both.
VSupply from only one.

Don't connect the supplies together unless you diode OR them and if you do that use germanium diodes for the low voltage drop across the junction.

We had a little discussion amongst ourselves about how this shouldn't work, but given we've driven the Victor 884s unmatched into CIM gear boxes with a mere gear dividing the 2 output shafts, and given there's reverse protection on both the Jaguars and Victors (in case something turns into a generator) the risks are low.

There is a chance that one Jaguar might drive more of the mechanism load than the other, as they are able to spin each other's armature like this. It shouldn't be too much of a problem and when the load on the mechanism increases they should both start to contribute. This will make tuning them interesting considering that effectively they are both in a state of semi-permanent runaway.

Only thing I will warn you about...we did this for a velocity set point...not position (haven't thought about it the other way) and I strongly advise you to have a single harness handy in case someone thinks the split harness is causing your issues.

[Mr. Lim]

Hook up your encoder to you "master" Jags only. Put your "slave" Jags into absolute Voltage mode.

In your TeleOp Continuous loop, do:

slaveJag.setX(masterJag.getVoltage());

[kamocat]

Mr. Lim, have you tried this?
I had little success in LabVIEW.
http://www.chiefdelphi.com/forums/showpost.php?p=1006215&postcount=10

[Mr. Lim]

Mr. Lim, have you tried this?
I had little success in LabVIEW.
http://www.chiefdelphi.com/forums/showpost.php?p=1006215&postcount=10

We have tried this, and anecdotally we are having success, in that we are able to get our robot to drive at the desired speeds, with what APPEAR to be balanced output from both. I haven't scoped, or otherwise recorded, or graphed the values, and our slave Jags appear to run in virtual lock-step with the master Jags.

We are using Java, and I'm wondering if there could be a difference in the implementation between languages, or the fact that we're passing the output voltage (i.e. -12V to 12V) from the master Jaguars to the slaves, and those output voltage values might be filtered to provide a meaningful value (i.e. not an instantaneous %Vbus).

[AustinSchuh]

I'm planning on wiring the encoder to both motors, and having the PID independent. Because both Jaguars are subject to the same conditions, I'm hoping I won't get significant integral windup. (Also, the integral is reset when the Jaguar output is "0")

Warning: I haven't tested this or tried to model it, but it should work in theory... Of course, the devil is in the details.

Try wrapping a control loop around the two control loops on the Jaguars to sync their voltages up. The pseudo code would be something like the following, and you can make it more complicated if the nieve implementation doesn't work. This is assuming that you are sampling the voltages of the two jaguars at the same time, and I'm not sure how much a difference in sample time between the two jaguars would effect things. Probably depends on how aggressive you are trying to sync the two.

v1 = jag1.getVoltage()
v2 = jag2.getVoltage()

error = (v1 - v2)

jag1.setX(goal - error * Kp)
jag2.setX(goal + error * Kp)

The basic idea is that you wrap a proportional loop around the two PID loops running on the jaguars in order to drive the voltage error between the two loops to 0. This should cause them to provide the same voltage to the two motors, and share the load nicely. It might also work if you try to drive the errors in the current that the two motors are drawing to 0, or something clever like that.

[kamocat]

Warning: I haven't tested this or tried to model it, but it should work in theory... Of course, the devil is in the details.

Try wrapping a control loop around the two control loops on the Jaguars to sync their voltages up. The pseudo code would be something like the following, and you can make it more complicated if the nieve implementation doesn't work. This is assuming that you are sampling the voltages of the two jaguars at the same time, and I'm not sure how much a difference in sample time between the two jaguars would effect things. Probably depends on how aggressive you are trying to sync the two.

v1 = jag1.getVoltage()
v2 = jag2.getVoltage()

error = (v1 - v2)

jag1.setX(goal - error * Kp)
jag2.setX(goal + error * Kp)

The basic idea is that you wrap a proportional loop around the two PID loops running on the jaguars in order to drive the voltage error between the two loops to 0. This should cause them to provide the same voltage to the two motors, and share the load nicely. It might also work if you try to drive the errors in the current that the two motors are drawing to 0, or something clever like that.
That's an interesting method of doing it. It would probably be best to get the %Output status, not the Vout status, because the voltage would have to be scaled down anyway.
Then again, I don't know what your "getVoltage" function does. Has it been modified to get the actual voltage, or does it return %Output?

I think it would make sense to monitor it first and see if any problems arise.

[AustinSchuh]

Then again, I don't know what your "getVoltage" function does.

My "getVoltage" function returns some indicator of how much voltage the Jaguar is trying to put out. It is probably easiest to get the % Output from the Jaguar (should be [-1, 1]) and use that, but theoretically, any indicator should work. The time constant should probably be pretty slow since you don't care too much if they aren't perfectly the same and just want the two to be pretty close.

[Hugh Meyer]

We split the encoder like this.

A to both.
B to both.
GND to both.
VSupply from only one.




If you connect the two GND wires together you can expect to have ground loop issues. This is only a problem with heavy loads where the motors are drawing significant current. We saw this issue last year in the CAN bus ground wire. We have an opto isolator in the circuit to prevent the ground loop.

So far the motors drive well. We see some unbalance, but not very much. We are still investigating if this unbalance is real, or inherit in our logging scheme.

Attached are two step response graphs from recent testing, one showing current and the other showing speed, both from the same run.

-Hugh

[techhelpbb]

If you connect the two GND wires together you can expect to have ground loop issues. This is only a problem with heavy loads where the motors are drawing significant current. We saw this issue last year in the CAN bus ground wire. We have an opto isolator in the circuit to prevent the ground loop.

So far the motors drive well. We see some unbalance, but not very much. We are still investigating if this unbalance is real, or inherit in our logging scheme.

Attached are two step response graphs from recent testing, one showing current and the other showing speed, both from the same run.

-Hugh

Interesting. We'll keep that in mind.

Thanks.

[Ether]

So far the motors drive well. We see some unbalance, but not very much. We are still investigating if this unbalance is real, or inherit in our logging scheme.

Attached are two step response graphs from recent testing, one showing current and the other showing speed, both from the same run.

I didn't see any previous posts in this thread from Team 1741. Could you please provide some context for your post? (What is your drivetrain; What feedback sensor are you using; How do you have it connected; etc) Thanks.

[kamocat]

I didn't see any previous posts in this thread from Team 1741. Could you please provide some context for your post? (What is your drivetrain; What feedback sensor are you using; How do you have it connected; etc) Thanks.




Additionally, are they in the same transmission? If so, then speed will be identical regardless of what each motor is doing.

[Hugh Meyer]

I didn't see any previous posts in this thread from Team 1741. Could you please provide some context for your post? (What is your drivetrain; What feedback sensor are you using; How do you have it connected; etc) Thanks.


The drive train is a 6 wheel drive. The center wheels are traction wheels. The front and back are omni wheels. All are driven from the center, which are direct drive. It uses two CIMs on the left transmission and two on the right transmission. One US Digital 250 CPR incremental encoder is used on each transmission. Each encoder is wired to the two Jaguars that drive the motors on the corresponding transmission. They are electrically isolated by opto isolators to prevent a ground loop. The PID speed control is done in each Jaguar independent of the other. The step commands are generated in software at 3 different velocities to help in tuning the PID loop.

Additionally, are they in the same transmission? If so, then speed will be identical regardless of what each motor is doing.

I know the speed will be the same. That is why I posted the current graph that shows amps. This is where the unbalanced differences show up.

-Hugh

[Ether]

The drive train is a 6 wheel drive. The center wheels are traction wheels. The front and back are omni wheels. All are driven from the center, which are direct drive. It uses two CIMs on the left transmission and two on the right transmission. One US Digital 250 CPR incremental encoder is used on each transmission. Each encoder is wired to the two Jaguars that drive the motors on the corresponding transmission. They are electrically isolated by opto isolators to prevent a ground loop. The PID speed control is done in each Jaguar independent of the other. The step commands are generated in software at 3 different velocities to help in tuning the PID loop.

Thank you, very thorough.

The provides the details necessary to make your post an excellent reference.

[kamocat]

Hugh,

Are you using the Jaguar to measure current?

Could we see a graph of their output voltages as well?

[Hugh Meyer]

Hugh,

Are you using the Jaguar to measure current?

Could we see a graph of their output voltages as well?


Marshal,

Yes we are using the Jaguar to measure this data.

Attached is the raw data file. Plot whatever you want. It is uploaded as a .h file, but it is really a .csv that wouldn't upload, so rename it .csv after you have it downloaded.

Not all of the fields are populated at this point, so if a field is all zeros, then that data column is not valid.

This is the same run that I posted in the previous thread.

If you have any insightful revelations please post back a reply.

If you are data hungry and want more PM me and I can give you access to our SVN server, if you want.

-Hugh

[kamocat]

Thanks!
It appears the PID loops match pretty well, with both motors sharing the load.
Here's a graph comparing voltage:
http://content.screencast.com/users/kamocat/folders/Jing/media/ec144dc2-9510-4f14-8fd1-2f5b3858052f/00000119.png

The only thing that seemed funny is that they Joysticks didn't correspond to the movement of the motors.

Would you happen to know what the time increment is? I realize that with 4 motors, the fastest you can acquire Voltage, Current, Speed, and Position is every 30-50ms, if you send the messages parallel to each Jaguar (as opposed to sequentially). Are you gathering data as quickly as possible, or are you gathering it every 1 second, or otherwise?

[Hugh Meyer]

Thanks!
It appears the PID loops match pretty well, with both motors sharing the load.

......

The only thing that seemed funny is that they Joysticks didn't correspond to the movement of the motors.

Would you happen to know what the time increment is? I realize that with 4 motors, the fastest you can acquire Voltage, Current, Speed, and Position is every 30-50ms, if you send the messages parallel to each Jaguar (as opposed to sequentially). Are you gathering data as quickly as possible, or are you gathering it every 1 second, or otherwise?

Marshal,

The joysticks were not controlling the system during this test. It was being driven to a specific RPM by our PID Testing code. The input was a step response. The programmers were suppose to put the commanded value data in the file, but it didn't get coded yet...that is still on the "to do" list.

I think the sample rate was 50 msec. I will check tonight and let you know if if is different. It might have been 100 msec.

All of the data is collected on each pass of the periodic loop. We don't really have any way to synchronize data sampling, so the resolution is the periodic rate. I don't know exactly what you mean by "you send the messages parallel to each Jaguar". We can only send messages to the Jaguars one at a time, but we do all of them each time through the main loop.

-Hugh

[kamocat]

I mean communicating to each Jaguar in a parallel thread.
This takes advantage of the space in between when a message is sent to the Jaguar, and when the Jaguar sends a reply.

If your current method is getting you the performance you want, and it's easier, keep doing it.

[Hugh Meyer]

I mean communicating to each Jaguar in a parallel thread.
This takes advantage of the space in between when a message is sent to the Jaguar, and when the Jaguar sends a reply.

If your current method is getting you the performance you want, and it's easier, keep doing it.

Interesting idea. If I understand what you are saying there would be a thread for each Jaguar. For example if I had 8 Jaguars I would have 8 threads, each thread responsible for its associated Jaguar? If this is what you mean, then what mechanism would you use for preventing all eight from trying to use the CAN bus at the same time? How would that be any faster than one thread just writing to all 8 in turn?

By the way, the period for the data I posted in previous threads was 100 milliseconds, not 50 msec.

-Hugh

[PhilBot]

When you tell a Jaguar in %Vbus or Vcomp to go "0", it doesn't ramp down, it just stops.


Yeah, I just discovered this.

At some level I understand it may help with safety.... letting the motor react to a stop request instantly... but darn it scotty, If I wanted a sudden stop I would have turned off the Ramp function.

When using the ramp feature to smooth the motion of... say.. an arm, it's just as important for it to stop slowly as speed up slowly. Wonder why TI chose to do this, with no way to turn it off.

Now I need to put in some stupid code to set the speed to 6 or -6 (outside the instant stop window) so it stops gracefully.

(I would expect however that the limit switches would stop instantly...)

Phil

[kamocat]

Interesting idea. If I understand what you are saying there would be a thread for each Jaguar. For example if I had 8 Jaguars I would have 8 threads, each thread responsible for its associated Jaguar? If this is what you mean, then what mechanism would you use for preventing all eight from trying to use the CAN bus at the same time? How would that be any faster than one thread just writing to all 8 in turn?

By the way, the period for the data I posted in previous threads was 100 milliseconds, not 50 msec.

-Hugh
Preventing simultaneous use of the RS232 port is done by the BlackJagPlugin.

From testing, I found that there's not a significant gain having more than 3 or 4 Jaguars communications in parallel. However, doing this won't hurt anything, so long as you leave some time for the ACK commands to go through.

If you'd like more information, I can start a seperate thread. I spent a good deal of my Beta testing time on this.

[Gary Bonner]

Am I correct that the solution discussed here is to wire the encoder to two Jaguars and run both Jags independently in closed loop speed mode? Can you elaborate or provide a schematic of how the encoders and opto isolators are wired? Do you think this would work in position mode?

Thanks.

[Hugh Meyer]

Am I correct that the solution discussed here is to wire the encoder to two Jaguars and run both Jags independently in closed loop speed mode? Can you elaborate or provide a schematic of how the encoders and opto isolators are wired? Do you think this would work in position mode?

Thanks.

Gary,

Yes, that is what I am suggesting. It seems to be working for us, but as others in this thread have mentioned it is not the "Ideal" solution. Other solutions presented will have delay in the synchronization process.

I do not know if it would work in position mode.

I will try to get a schematic posted, but as you know it is very close to ship date and we are very busy. It is on paper (aka napkin sketch) and not easily uploaded.

-Hugh

[mocibot]

That's an interesting method of doing it. It would probably be best to get the %Output status, not the Vout status, because the voltage would have to be scaled down anyway.
Then again, I don't know what your "getVoltage" function does. Has it been modified to get the actual voltage, or does it return %Output?

I think it would make sense to monitor it first and see if any problems arise.

I have a question on this, How do you get %Output status?

[jhersh]

I have a question on this, How do you get %Output status?

There isn't currently a status for that in the library, but the Jag supports it. It should be easy to add that to the library. Just follow the pattern of the other status messages.

-Joe

[techhelpbb]

If you connect the two GND wires together you can expect to have ground loop issues. This is only a problem with heavy loads where the motors are drawing significant current. We saw this issue last year in the CAN bus ground wire. We have an opto isolator in the circuit to prevent the ground loop.

So far the motors drive well. We see some unbalance, but not very much. We are still investigating if this unbalance is real, or inherit in our logging scheme.

Attached are two step response graphs from recent testing, one showing current and the other showing speed, both from the same run.

-Hugh

We originally split the encoder wires as I described before.

When we did this...

1. We found the chains from the gear boxes to the rear tires snagged and caused tuning issues, so we removed the chains.

2. We found one of the CIMs would always fault it's Jaguar...even unloaded and we replaced it (old CIMs....long hard life)

3. With the only drive wheels in the air we could tune the Jaguars with the cable split and it worked.

When we finished the actual robot instead of the kit of parts...

We had problems tuning one side with the split cables.

The side with issues, as it turned out, had the bad CIM back on it (this time it found a garbage can :rolleyes:).

Even without the bad CIM we still had issues with that side and occasionally with the other.

What we ended up doing to fix it:

We created an optoisolator board with Schmitt trigger TTL input and 74HC TTL output...actually we have several versions of this and I'm not sure we need all of the circuit for this. We wanted to make sure we considered all the possible twists so we went for overkill. This board requires 5V from the digital side car in it's current form and when I hand wired it, I put 7805 on it with a 4,700uF capacitor just to make comparisons with the sidecar's power.

Basically at this point, the encoder channels are each driving merely 1 TTL input, and that input is a Schmitt trigger with hysteresis. The Jaguars are each powering merely a single 74HC04 inverter and their channel inputs are the only thing connected to the inverter outputs.

It's entirely reasonable we could do without most if not all the TTL logic with careful selection of components.

As the final product gets power from the digital side car and doesn't actually reduce the cRIO's control, I think this *might* be legal. Guess we'll find out the hard way. If it's a problem, the PCB has the same headers at the cRIO digital I/O ports...so we could just connect to the cRIO and run the Jaguars like the Victor 884s via the CAN bus.

Regardless when I get a chance I'll put the schematics and documentation some place accessible.

The only thing I do wish we had was some motor capacitors, but even without them we made this work using mere 4 wire telephone wire to the encoders right next to the CIMs.

[taichichuan]

We originally split the encoder wires as I described before.

When we did this...

1. We found the chains from the gear boxes to the rear tires snagged and caused tuning issues, so we removed the chains.

2. We found one of the CIMs would always fault it's Jaguar...even unloaded and we replaced it (old CIMs....long hard life)

3. With the only drive wheels in the air we could tune the Jaguars with the cable split and it worked.

When we finished the actual robot instead of the kit of parts...

We had problems tuning one side with the split cables.

The side with issues, as it turned out, had the bad CIM back on it (this time it found a garbage can :rolleyes:).

Even without the bad CIM we still had issues with that side and occasionally with the other.

What we ended up doing to fix it:

We created an optoisolator board with Schmitt trigger TTL input and 74HC TTL output...actually we have several versions of this and I'm not sure we need all of the circuit for this. We wanted to make sure we considered all the possible twists so we went for overkill. This board requires 5V from the digital side car in it's current form and when I hand wired it, I put 7805 on it with a 4,700uF capacitor just to make comparisons with the sidecar's power.

Basically at this point, the encoder channels are each driving merely 1 TTL input, and that input is a Schmitt trigger with hysteresis. The Jaguars are each powering merely a single 74HC04 inverter and their channel inputs are the only thing connected to the inverter outputs.

It's entirely reasonable we could do without most if not all the TTL logic with careful selection of components.

As the final product gets power from the digital side car and doesn't actually reduce the cRIO's control, I think this *might* be legal. Guess we'll find out the hard way. If it's a problem, the PCB has the same headers at the cRIO digital I/O ports...so we could just connect to the cRIO and run the Jaguars like the Victor 884s via the CAN bus.

Regardless when I get a chance I'll put the schematics and documentation some place accessible.

The only thing I do wish we had was some motor capacitors, but even without them we made this work using mere 4 wire telephone wire to the encoders right next to the CIMs.

Please post the schematics to the group when you can. We're all waiting with baited breath...

TIA,

Mike