View Full Version : 1 Encoder, 2 Jaguars
NetPlanet
16-01-2011, 15:58
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?
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).
NetPlanet
16-01-2011, 16:44
Thank you, we will certainly try this out
drakesword
16-01-2011, 23:31
Something along the lines of this . . .
Jag2.set(Jag1.getOutputVoltage() / Jag1.getBusVoltage()); //For voltage control mode
Jag2.set(Jag1.getOutputCurrent()); //For current control mode
Joe Ross
17-01-2011, 10:09
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.
s1900ahon
22-01-2011, 23:16
Perhaps the %Vbus mode will work better.
The %Vbus mode is the only one that I would try.
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:
http://content.screencast.com/users/kamocat/folders/Jing/media/e524e404-6bca-4c8b-a4af-d18f1553027c/log.png
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.
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
The brake/coast jumper only controls when the motor has an output of 0.
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/showpost.php?p=992435&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.
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.
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.
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.
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.
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
25-01-2011, 11:28
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
25-01-2011, 12:39
Has anybody actually tried the Y cable solution for the encoder?
Kevin Sevcik
25-01-2011, 12:40
Current balancing sounds a little too exciting, unless you've off-loaded the PID to the cRIO. Which we apparently just don't want to do. Doing a velocity PID on the master Jag and a current PID on the slave sounds like trouble, since the slave has a direct effect on the current output of the master. I'm not saying it couldn't work.... but it sure sounds like a recipe for interesting dynamics.
Well, that would certainly work for high-torque situations where the two motors might be useful.
I would filter it further to 8A, where the current sense accuracy increases to +-1A.
EDIT:
Kevin, you have a very good point. Perhaps it can be a more approximate follow, and aim for the average between the currents of both motors.
Doing a velocity PID on the master Jag and a current PID on the slave sounds like trouble, since the slave has a direct effect on the current output of the master.
As a first approximation, it just makes the master appear to have twice the torque gain. So you have to tune the master with the slave operational.
I'm not saying it couldn't work.... but it sure sounds like a recipe for interesting dynamics.
I think it could be made to work. The mechanical response (of the wheel speed - with the robot's wheels on the floor) is sufficiently slower than the current response that it seems that any weird dynamic interactions could be keep to an acceptable level.
N1njAgam3R
09-02-2011, 18:25
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?
Our team is trying to do the same thing and we haven't found anything yet, so anything you guys find out would be a huge help!
Our team is trying to do the same thing and we haven't found anything yet, so anything you guys find out would be a huge help!
check out this other thread:
http://www.chiefdelphi.com/forums/showthread.php?t=91130
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
12-02-2011, 21:05
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/showpost.php?p=1019889&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.
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.
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.
otherguy
16-02-2011, 22:25
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.
Using sync groups is pretty easy, there's just very little documentation.
I don't know if anyone else noticed, but the labview help files are useless for the polymorphic motor control VIs.
kamo created a decent guide which I think is what I found originally that helped me understand how it is supposed to work:
http://www.chiefdelphi.com/forums/showthread.php?p=1016852
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 agree that using the sync feature is probably not required, It was something we had in the code on our first test, and it has remained. I don't believe we have tested functionality without it in the loop. In the configuration we currently have set up: worst case the slave jag will lag the masters input by one loop iteration (since the slave output needs to be set before the VI exits).
We do appear to have some issues remaining which we haven't identified the solution to, but it appears that the black jag times out (its one of the masters). When this occurs, the outputs to the motor are no longer sent, and as a result our slave gets zero as an input voltage. Once this condition occurs communications remain active (solid yellow light) but motors wont move again until the bot is restarted. Other jags on the CAN buss remain operational. Any suggestions?
We do appear to have some issues remaining which we haven't identified the solution to, but it appears that the black jag times out (its one of the masters). When this occurs, the outputs to the motor are no longer sent, and as a result our slave gets zero as an input voltage. Once this condition occurs communications remain active (solid yellow light) but motors wont move again until the bot is restarted. Other jags on the CAN buss remain operational. Any suggestions?
It sounds like the Jag is browning out, and becoming reset.
It just so happens that I have a reconfiguration utility to deal with that, if you'd like to try it.
However, first it would be best to confirm the issue.
I've attached a VI "check for CAN brownout" you can put in Periodic Tasks to see if Jags have been incidentally rebooted.
The way this works is, Jaguars send an enumeration message on startup. This VI just waits for that message, and gets the device number from message ID. (This feature is not in the documentation, but was implemented in version 92)
I've also attached the reconfiguration utility, which detects rebooted Jags using the same principle. Please, don't have both of these in your code at the same time.
Now, if it turns out your Jaguars are not getting rebooted, then you have something very interesting happening. I believe I had trouble like this back in July of last year when I started working with CAN. Try re-enabling or reconfiguring the Jaguar. If you use the "get output" command, what do you get?
otherguy
18-02-2011, 00:55
Good news and bad news.
The good news is that our drive motors worked reliably all night.
The bad news is that our drive motors worked all night. I can't replicate the issue we saw yesterday. The code we were using was modified before I was able to use your debug VIs, and I ended up having to re-implement what we had from memory. Apparently the version in my memory was better this time, cause I couldn't get it to break tonight.
Hopefully we don't see this problem again, and if we do at least I'll have some tools on hand to test with.
Thanks for your help.
JasonStern
18-02-2011, 11:20
It sounds like the Jag is browning out, and becoming reset.
It just so happens that I have a reconfiguration utility to deal with that, if you'd like to try it.
However, first it would be best to confirm the issue.
I've attached a VI "check for CAN brownout" you can put in Periodic Tasks to see if Jags have been incidentally rebooted.
My team is still experiencing the motors no longer responding, but only with black jags using closed loop control (specifically speed control). Can you please provide the "check for CAN brownout" in pseudo code? We are using java and do not have labview installed. We tried adding monitoring for CANJaguarDriver.receiveMessage(ENUMERATION) messages, but it never seems to get triggered. It may be we coded it wrong, but a visual inspection of the jags gives no indication that they are restarting and we are using fully charged batteries.
Thanks!
Jason
My team is still experiencing the motors no longer responding, but only with black jags using closed loop control (specifically speed control). Can you please provide the "check for CAN brownout" in pseudo code? We are using java and do not have labview installed. We tried adding monitoring for CANJaguarDriver.receiveMessage(ENUMERATION) messages, but it never seems to get triggered. It may be we coded it wrong, but a visual inspection of the jags gives no indication that they are restarting and we are using fully charged batteries.
Thanks!
Jason
There should be a status function in the Java CANJaguar class that will tell you if there was a Jaguar reboot.
-Joe
JasonStern
21-02-2011, 12:38
There should be a status function in the Java CANJaguar class that will tell you if there was a Jaguar reboot.
-Joe
We added a check for the GetPowerCycle in a loop and it is returning false. In addition, it often (always?) causes a CANTimeoutException and seems to make the problem worse.
In order to reduce the amount of variables in the system, we removed the CRIO and 2CAN, built ourselves a serial cable, and used the BDC-COMM application to test the Jaguars. We are able to get the same results of the Jaguars locking up almost immediately by simply adjusting the speed set point back and forth a few times. Once this happens, the Jaguar no longer responds to any command, does not send any updates (voltage, speed, temp, etc) to BDC-COMM, and often stops BDC-COMM from controlling any other Jag.
However, if we click the Enumerate button, everything starts working again without having to do any sort of power cycle. Does anyone know the exact commands the BDC-COMM tool sends when the enumerate button is pressed? We would like to build a "recover jags" method in Java that does the same thing. It is less than ideal, but we want to make sure we can drive during our matches!!
Does anyone know the exact commands the BDC-COMM tool sends when the enumerate button is pressed? We would like to build a "recover jags" method in Java that does the same thing. It is less than ideal, but we want to make sure we can drive during our matches!!
If no-one has the answer, you could use an RS232 breakout box and wiretap with a simple sniffer app to capture the traffic.
JasonStern
21-02-2011, 13:29
If no-one has the answer, you could use an RS232 breakout box and wiretap with a simple sniffer app to capture the traffic.
Thanks, that is a great idea and Ill give it a try this evening when I'm back with the 'bot!
We haven't tuned the PID values at all yet, so my current theory is that maybe we have an unstable system or some sort of transient value that the Jaguar isn't handling well. I would hope the internal firmware would handle this cleanly, but if there is something like an integer overflow or other unexpected value going on I suppose it could cause the Jaguar to freeze. (If it matters, we have been testing with p = 0.1, i = 0.01, and d = 0.)
--Jason
JasonStern
21-02-2011, 21:47
I did as suggested and monitored the serial port as the BDC-COMM utility started. In order to decode the commands, I built the small program below. I hope someone else will find it helpful!
As it turns out, it doesn't look like the utility is sending any sort of reset command. Instead, it just sets all the various values to default. We added code to reinit the jags to our code and we can now recover them after they stop working. Unfortunately, they then stop working again shortly afterwards so it is definitely not a good workaround :mad:
I tried messing around with the speed set points using BDC-COMM and it seems likely the issue is caused by the change in values and in particular when going from a negative to a positive value. Can someone else try setting their PID values to something crazy and see if that causes their black jaguars to lock up?
Thanks,
Jason
Decoder program:
int[] valuesToCheck = {
0x1f020300, 0x1f020140, 0x000000C0, 0x02021c40, 0x02021c80, 0x02021cc0,
0x02021d00, 0x02021d40, 0x02021d80, 0x02021dc0, 0x02021e00, 0x02021640,
0x02020080, 0x020200C0, 0x00000140, 0x1f020340, 0x02021480, 0x00000140,
0x020214c0, 0x02021500, 0x02021580, 0x02021600, 0x020215c0};
Field[] fields = JaguarCANProtocol.class.getDeclaredFields();
for (int k = 0; k < valuesToCheck.length; k++) {
for (int i = 0; i < fields.length; i++) {
Field theField = fields[i];
if (theField.getType() == int.class) {
try {
int value = theField.getInt(null);
//remove the device id
if ((value & 0xFFFFFFF0) == valuesToCheck[k]) {
System.out.println("The " + k + " field is " + theField.getName());
break;
}
} catch (IllegalArgumentException ex) {
Logger.getLogger(Main.class.getName()).log(Level.S EVERE, null, ex);
} catch (IllegalAccessException ex) {
Logger.getLogger(Main.class.getName()).log(Level.S EVERE, null, ex);
}
}
}
Ouput:
The 0 field is LM_API_TRUST_EN
The 1 field is LM_API_HWVER
The 2 field is CAN_MSGID_API_DEVQUERY
The 3 field is LM_API_CFG_ENC_LINES
The 4 field is LM_API_CFG_POT_TURNS
The 5 field is LM_API_CFG_BRAKE_COAST
The 6 field is LM_API_CFG_LIMIT_MODE
The 7 field is LM_API_CFG_LIMIT_FWD
The 8 field is LM_API_CFG_LIMIT_REV
The 9 field is LM_API_CFG_MAX_VOUT
The 10 field is LM_API_CFG_FAULT_TIME
The 11 field is LM_API_STATUS_CMODE
The 12 field is LM_API_VOLT_SET
The 13 field is LM_API_VOLT_SET_RAMP
The 14 field is CAN_MSGID_API_HEARTBEAT
The 15 field is LM_API_TRUST_HEARTBEAT
The 16 field is LM_API_STATUS_CURRENT
The 17 field is CAN_MSGID_API_HEARTBEAT
The 18 field is LM_API_STATUS_TEMP
The 19 field is LM_API_STATUS_POS
The 20 field is LM_API_STATUS_LIMIT
The 21 field is LM_API_STATUS_POWER
The 22 field is LM_API_STATUS_FAULT
What firmware version is in your Jags ?
JasonStern
22-02-2011, 09:44
What firmware version is in your Jags ?
The latest available on the LM website: 92.
JasonStern
22-02-2011, 23:03
We have apparently confirmed the issue is related to the change in Vout values. If we apply a ramp of around 650 to the voltage mode, everything responds. However, if we remove the ramp limitation the Jaguar freezes. This was using BDC-Comm with only a single Black Jag on the bus and without editing any other settings. Is this type of behavior we should expect to see from a brownout condition?
Thanks,
-Jason
Yes, it sounds like you're browning out from drawing too much power at once.
It also sounds like you have a low battery, which is exasperating the issue.
If we apply a ramp of around 650
650 what? volts/sec ?
It's either V/s or %/s, depending on the mode.
Or maybe it's V/ms and %/ms. I think that might make more sense from what I've observed.
JasonStern
23-02-2011, 09:35
650 what? volts/sec ?
Whatever units the BDC-COMM utility expects :)
The documentation says it is in volts/s. However, the Jag docs indicate the calculations are performed at a 1Khz rate, so I'm guessing this is translated to 0.65 volts/ms internally.
--Jason
techhelpbb
24-02-2011, 00:04
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/showpost.php?p=1019889&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.
We never attempted this for position control, but I can confirm that you'll probably need the optoisolator as Hugh states...load on the CIMs certainly causes issues we did not see under much less load.
We made several PCBs to provide this isolation and I'm frankly not sure of any rules that prevent them, as long as they take power from the sidecar or the Jaguars.
If I read your post correctly, you didn't actually enable one Jaguar? Why?
Gary Bonner
24-02-2011, 15:28
Can anyone provide guidance on how to do the isolation? Any recommended part numbers? Would limit switches have the same issue?
Thanks.
techhelpbb
25-02-2011, 00:37
No limit switches will not suffer this issue.
As to the parts if you implement the whole thing...TTL and all...and strip off all the extras from the prototype we made.
The input from the encoders (both of them...one on either side):
74HC14
The optocoupler:
PS2501-4
The final outputs to the Jaguars:
74HC04 (one for each Jaguar so that's 4).
We used 680 Ohm pull up resistors for the diode side of the coupler.
We used 4.7k Ohm pull up resistors for the NPN transistor side of the coupler.
Depending on how crazed you want to get you might also need the Pan Pacific (Cinch Jones) headers (like the the ones on the Jaguar).
If you want to get really nuts get the PicoBlade connectors for the U.S. Digital encoders. Be warned those crimp pins are *very* tiny and you'll need the right crimper for it. Molex wants about $200 for that tool. Dig around on eBay and you'll find a cheaper solution for less than $100.
However, in the end, you could just butcher the tails for the encoders from U.S. Digital and use some female receptacle header for the Jaguar side then hand solder the PCB end of the wires to the PCB.
I sent you an e-mail in private, I don't have all the documentation ready to present yet, but I'll send you a schematic from the original idea.
taichichuan
25-02-2011, 10:16
No limit switches will not suffer this issue.
As to the parts if you implement the whole thing...TTL and all...and strip off all the extras from the prototype we made.
The input from the encoders (both of them...one on either side):
74HC14
The optocoupler:
PS2501-4
The final outputs to the Jaguars:
74HC04 (one for each Jaguar so that's 4).
We used 680 Ohm pull up resistors for the diode side of the coupler.
We used 4.7k Ohm pull up resistors for the NPN transistor side of the coupler.
Depending on how crazed you want to get you might also need the Pan Pacific (Cinch Jones) headers (like the the ones on the Jaguar).
If you want to get really nuts get the PicoBlade connectors for the U.S. Digital encoders. Be warned those crimp pins are *very* tiny and you'll need the right crimper for it. Molex wants about $200 for that tool. Dig around on eBay and you'll find a cheaper solution for less than $100.
However, in the end, you could just butcher the tails for the encoders from U.S. Digital and use some female receptacle header for the Jaguar side then hand solder the PCB end of the wires to the PCB.
I sent you an e-mail in private, I don't have all the documentation ready to present yet, but I'll send you a schematic from the original idea.
Any chance you could provide schematics to the group?
TIA,
Mike
techhelpbb
25-02-2011, 11:09
Any chance you could provide schematics to the group?
TIA,
Mike
As stated, absolutely.
However, I need a little more time to clean them up.
We twisted this idea around quite a few ways and I want to provide just the most basic schematic...otherwise it'll be way more complicated than you really need.
taichichuan
25-02-2011, 11:40
Thanks!
Mike
otherguy
26-02-2011, 17:42
If I read your post correctly, you didn't actually enable one Jaguar? Why?
Correct.
Our wiring was setup to split the single encoder to two jags. Our code was setup to drive only one motor at the time, to verify that the encoder counts were actually being read correctly. And to determine the correct motor polarities.
Again our tests weren't thorough, we quickly switched to a "slave" Jag being driven off the output from the "master" and this appeared to work well, so we didn't go further with the split encoder tests.
Hugh Meyer
28-02-2011, 10:56
It seems noise into the Jaguars is causing the reset issue mentioned here and in another thread. When one connects an encoder or other circuit to the encoder input it works as an antenna to pick up noise.
So far I have found a 25 uf cap across the + 5 volt pin and the gnd pin on the encoder connector fixes it.
This may not work if all ground loop issues are not resolved. The opto isolators are needed to remove the ground loops and the filter cap is needed to filter the spikes created by the back emf when the motors stop or change direction.
We are using shielded wire with the shield grounded at the Jaguar and open at the custom circuit board where the opto isolators are located.
The only connections back to the Jaguars are from the output transistor in the opto isolator. I have seen some high frequency roll off and trouble with phase shift causing direction changes. I am still working this issue. If the noise is really fixed I might try to add another pull-up on the opto board to the +5 volts from the Jaguar.
Has anyone else seen these issues?
-Hugh
techhelpbb
28-02-2011, 18:05
It seems noise into the Jaguars is causing the reset issue mentioned here and in another thread. When one connects an encoder or other circuit to the encoder input it works as an antenna to pick up noise.
So far I have found a 25 uf cap across the + 5 volt pin and the gnd pin on the encoder connector fixes it.
This may not work if all ground loop issues are not resolved. The opto isolators are needed to remove the ground loops and the filter cap is needed to filter the spikes created by the back emf when the motors stop or change direction.
We are using shielded wire with the shield grounded at the Jaguar and open at the custom circuit board where the opto isolators are located.
The only connections back to the Jaguars are from the output transistor in the opto isolator. I have seen some high frequency roll off and trouble with phase shift causing direction changes. I am still working this issue. If the noise is really fixed I might try to add another pull-up on the opto board to the +5 volts from the Jaguar.
Has anyone else seen these issues?
-Hugh
The board we used didn't drive the transistor into the Jaguars. It drove the inputs of the Jaguar with the outputs of the 74HC04 inverters the Jaguars themselves were basically powering (instead of the encoders). The inputs to the 74HC04 inverters were in turn connected to the NPN transistors pulled up with 4.7k - 6.8k resistors. Under other circumstances 4.7k would still leave enough margin to drive older 7400 series inputs.
To deal with the power supply issue for this circuit:
Initially we used a 7805 connected to the battery with a 4,700uF electrolytic capacitor on the input with a 10uF electrolytic and 0.022uF poly capacitor on the output. I'm almost positive we aren't allowed to do this on the robot. So we then started taking our power from the digital side car for the encoder side of the circuit.
Basically both our encoders, and the logic driving the optocoupler diodes, was powered by the digital side car with a small capacitor. As a matter of practice I'd be pretty concerned if that capacitor on the digital side car got too big as the inrush could have consequences.
I am still making efforts to provide these schematics. I'm sorry about the delay I'm extremely pressed for time lately.
I'm going to push to finish this up tonight...but no promises I haven't slept in some time.
Here is my interpretation/design from the discussions that have taken place here.
http://i.imgur.com/pqiZE.png
Please note that this is only for 2 Jaguars. This setup aids how 1712's robot is setup instead of having everything on one central board.
I'm pretty sure R1 and R2 need to be decreased in value here since I am using one pull-up per encoder input to feed two diodes in the opto-isolator. I need to look at the datasheet again for the PS2501 to verify the If of the diodes.
I didn't want to remove the schmitt-trigger inverters on the input since they will help with some noise. Availability of non-inverting schmitt-trigger buffers is fairly limited so as a result the inverters on the output of the opto-isolator are still required. Feel free to substitute appropriate HC04 and HC14 parts from those listed as I just used what was available in my part library here.
For those of you electrically inclined please review this for me. I very easily could have made a mistake as I didn't spend as much time on this as I really should. It'd be nice to catch an error now before I get some PCBs made.
Kevin
techhelpbb
14-03-2011, 14:11
Your schematic is unavailable, and I'm still swamped I'm very sorry about this.
It sounds like you have the right idea, however, please be aware that the source and sink of the other families of TTL are different.
I'd advise people to stick with the 74HC14 on the input side. Though the straight 7414 will work fine in this circuit, the BJT output stage can have some other issues in the capacitive realm.
In the original design we picked a pull up for the NPN transistor in the optocoupler that could accommodate the higher input requirements of the the 7400 series chips because I had considered tri-state and open collector outputs. It's not so easy to get 74HC16 or 74HC17 open drain parts.
For this application you don't need open collector, open drain or tri-state outputs from this circuit. The 74HC04 is quite efficient for the power it uses...just be sure to tie any inputs you do not use to one of the power supply rails...otherwise if you merely get near it, it might actually change state because of the 74HC series high input impedance. Now, you'd think that if the other gates in your integrated circuit were not actually driving any other circuits it wouldn't matter...but the noise from them jumping all around can walk back into the circuit's power supply locally.
I'm going to put my foot down and promise I'll have the documentation mostly done by Wednesday morning at the latest. It's entirely my issue delaying this as I have problems with my eyes.
techhelpbb -
I apologize for the missing schematic... I had it taken down after I realized a serious error in it and that Chief Delphi doesn't let me edit posts. This is one case where I don't want someone to make a mistake... Jags and encoders aren't cheap. I have since corrected the error over the weekend and will probably make an updated post this evening.
http://i.imgur.com/iFlzml.png (http://i.imgur.com/iFlzm.png)
(click for full size)
Everything from my previous post still applies here. By substituting 74HC14/74HC04 parts I mean that you don't have to use the SN74HC14 or SN74HC04. For example, I will be using the CD74HC14 and CD74HC04 from Texas Instruments. Other manufacturers will probably work, just verify against the datasheets.
A few notes here...
1) I bumped down the pull-up resistors from 680 ohms to 540 ohms. This will give If = ~6mA for the diodes in the opto-isolator. 680 ohms was a bit too close to the minimum If = 5mA for the opto-isolator part for my comfort, but will still work.
2) The NPN transistors driving the opto-isolator diodes are probably a bit of an overkill here as ~12mA is well within the rated current of the 74HC14. I'm not a huge fan of driving diodes directly from an IC output, but that is probably just the conservative design practices from work rubbing off on me.
3) U1 VCC is connected to the SIDECARVCC net and GND is connected to the SIDECARGND net. U2 VCC is connected to the JAG1VCC net and GND is connected to JAG1GND net. U4 VCC is connected to the JAG2VCC net and GND is connected to the JAG2GND net.
4) All of the headers are standard 0.1" pitch (spacing) headers. You could either wire directly to these connections or use the appropriate header parts.
I finished up a PCB design last night and will be ordering some from a manufacturer either tonight or tomorrow. Due to economies of scale I will probably have a few extra that 1712 will not be using. I would be willing to part with these at cost either assembled or left to the user to assemble. Do note that the PCB utilizes surface mount components except for the opto-isolator so surface mount soldering experience is recommended for DIY assembly. The board sizes in at 2.46" x 1.4". I can't guarantee any delivery date as I would prefer to test one of them out here before I send any out to avoid issues.
techhelpbb
14-03-2011, 18:44
That's about right. You shouldn't need the transistors at all.
I wanted to make sure to lower the coupling ratio...so I used the minimum.
I have the surface mount and the through hole version of the PS2501-4 and basically all the surface mount version is, is just the leads bent parallel to the surface, so no real weight savings.
The schematic I was working on had an extra trick, in that it was designed so you could test the circuit end to end without any tools. Figured we had enough people nervous about going this route that making it 'self test' was a the best solution to calm the nerves.
That's about right. You shouldn't need the transistors at all.
I wanted to make sure to lower the coupling ratio...so I used the minimum.
I have the surface mount and the through hole version of the PS2501-4 and basically all the surface mount version is, is just the leads bent parallel to the surface, so no real weight savings.
The schematic I was working on had an extra trick, in that it was designed so you could test the circuit end to end without any tools. Figured we had enough people nervous about going this route that making it 'self test' was a the best solution to calm the nerves.
Thanks for the taking the time to review the schematic. Second sets of eyes never hurt.
I'll take a look again at the diode current. I didn't consider the coupling ratio since I haven't really used opto-isolators before.
I noticed that too about the surface mount version of the PS2501-4 which surprised me. Other than automated manufacturing the benefits of going with the surface mount version are pretty small.
Also a great concept on the self test circuitry... I didn't really think of doing that since theoretically this has already been "proven" to work. I'll probably take the board into work once I get it and run a pulse generator on it to test the board.
techhelpbb
14-03-2011, 19:27
Thanks for the taking the time to review the schematic. Second sets of eyes never hurt.
I'll take a look again at the diode current. I didn't consider the coupling ratio since I haven't really used opto-isolators before.
I noticed that too about the surface mount version of the PS2501-4 which surprised me. Other than automated manufacturing the benefits of going with the surface mount version are pretty small.
Also a great concept on the self test circuitry... I didn't really think of doing that since theoretically this has already been "proven" to work. I'll probably take the board into work once I get it and run a pulse generator on it to test the board.
The hand soldered prototype that was slammed together made me nervous.
When I put this stuff up for people to look at, you'll see why. :yikes:
However, what really made me nervous was that it is is *really* hard to get a basic piece of test equipment into the circuit, it's got wires going in multiple directions and some of the junctions are too small. Never mind the fact that on our CIMiple gear box implementations the connectors are *very* hard to get to. I wanted people to be comfortable that from end to end, the wires and the logic work as planned. This way even those that don't fully understand have the hope of testing it. After all, because of the wires...something could break even if the circuit works.
Besides I sort of hoped that people would sit down with those they are mentoring and show them what it actually does on an oscilloscope. So it's both a learning tool...and a working piece of gear.
The optocoupler probably wasn't made smaller because they'd have to change the dimension between the LED and the phototransistor. Otherwise the specifications would change.
Tomorrow we'll move onto speed control
Is it tomorrow yet? :)
I'm interested in what you've found.
So, any word on whether the circuit performed as intended? I assume it did, though!
techhelpbb
16-03-2012, 17:41
So, any word on whether the circuit performed as intended? I assume it did, though!
Can I presume you are inquiring from the other teams?
What we had originally worked within the expectations we had of it. We didn't run it in competition not because of the splitter, but because CAN in general kept producing timeout errors and having other problems that eventually caused us to abandon CAN for PWM and later, after a few other troubles, to abandon the Jaguars in favor of the Victors.
To be additionally clear:
1. There were other issues in that particular drive train that caused it to be ill suited to the Jaguars. This is not an attempt to bash the Jaguars. That drive train was just not a good fit as it turned out.
2. Since the circuit in question was never actually fielded (to my knowledge) I can't be sure it's legal, but so far my research on the matter indicates it would have been legal last year and this year.
3. We did not use Jaguars this year at all.
4. I have 'too many eggs in my basket' currently the soonest I could slap all that on my test robot would be late May or June. When things finished off last year it got so quiet I didn't bother to continue with this work (by this work I mean this splitter, I built an entire robot and test equipment for that robot myself) because there didn't seam to be sufficient interest. Is there interest in me putting that on my schedule?
tech, I completely understand. CAN this year is particularly buggy for some reason. We managed to get it working well enough to be used on our main drivetrain. I found that loop times are very crucial and can't be easily modified, but with a little tweaking, you can get some very good performance out of it!
For our autoaim and shooter, CAN is essential, so we're trying to work out as much as possible before our regional next week. I've got the parts in hand to build the circuit and will report back once I've done some testing. We'll primarily be using this for our shooter to distribute the motor load a bit more evenly, so even if the circuit stops working, our shooter should still remain functional.
techhelpbb
19-03-2012, 14:12
tech, I completely understand. CAN this year is particularly buggy for some reason. We managed to get it working well enough to be used on our main drivetrain. I found that loop times are very crucial and can't be easily modified, but with a little tweaking, you can get some very good performance out of it!
For our autoaim and shooter, CAN is essential, so we're trying to work out as much as possible before our regional next week. I've got the parts in hand to build the circuit and will report back once I've done some testing. We'll primarily be using this for our shooter to distribute the motor load a bit more evenly, so even if the circuit stops working, our shooter should still remain functional.
If you end up using this circuit in actual competition please update this topic to confirm that it was actually accepted on a robot at a competition.
There are a lot of things that can be made, but the more unusual things get the higher the risk that at competition questions will be raised (I mean absolutely no disrespect to anyone...the rules are fairly numerous and sometimes a bit unclear).
Thanks
I'll definitely keep everyone updated!
Now, as for the rules, the way I understand it I am not able to use any motor controller other than the Jags or Victors to control a motor. All control signals must originate from the cRio. Now in the case of sensors, we are much less restricted on which sensor we are allowed to use, and more restricted on how we get the control signals to their respective inputs. As long as they get there, I don't see any reason for them to disallow it.
Since the sensors don't directly control a motor (they may provide feedback, but never direct control. You could argue that, in a way, they control the motors but then you could argue that without an initial condition, they cannot) then, as long as they are powered correctly, all add-on circuits should be legal.
I also plan on having some oscilloscope screenshots showing input and output, just to show that the circuit isn't fabricating anything false.
<https://www.sparkfun.com/products/9118>
I'd need to read the rules carefully, but this looks like a good off-the-shelf solution that should be easy to work with for most teams -- provided this sort of thing is legal. It doesn't violate the safety-related reasons for being very careful with motor control and solves the "1 Encoder, 2 Jaguars" problem in a clean way.
I'd actually use one of these for each of the two Jags and power them both from the DSC, in fact you could send the encoder inputs to the DSC directly, and then to each Jag through one of the isolators (for a total of three places where the encoder data could be read, the DSC and the two Jags).
Is that fast enough to be used on an encoder signal? I'm just a programmer, but the 5 microsecond switching time seems like it would screw up an encoder signal.
We're probably going to use the cRIO for dual motor gearbox encoder PID control. The master-slave solutions don't seem as reliable as using the cRIO.
Is that fast enough to be used on an encoder signal? I'm just a programmer, but the 5 microsecond switching time seems like it would screw up an encoder signal.
We're probably going to use the cRIO for dual motor gearbox encoder PID control. The master-slave solutions don't seem as reliable as using the cRIO.
The cRIO measures down to 6.525 us, so that is a pretty similar range.
FWIW, I don't think the propagation delay is going to be a problem either.
Anyone thinking of trying this should confirm, but my reading of 2013 R72 H makes me think this is legal to do:
R72 All outputs from sensors, custom circuits and additional electronics shall connect to only the following: H. the sensor inputs on the Jaguar motor controller.
So, this is likely a viable option (subject to confirmation of the legality), but note that I have not actually done this. One could also use this trick to connect both DCS inputs and Jag inputs to the same encoder.
FWIW, here's a part that seems like an even better choice, but only for teams that can deal with not having a breakout board: http://www.fairchildsemi.com/ds/FO/FOD0710.pdf.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.