Jrk21v3 + LACT4P-12V-20 - USB connection lost during runtime

There is no absolute maximum length of wire between the jrk and the motor but shorter wires permit more power to be delivered to the motors. How long are your wires?

Maybe motor noise is causing this problem. You could try putting a capacitor between the jrk’s A and B terminals and see if that helps.

–David

Hi,

the motor has about 50cm of cabling attached, and I’ve added two 30cm extension cords. They are intended for high-end graphic cards (8-pin power connector) and should easily do 150 watts of power. So the wiring is pretty thick, but there is no shielding, which might impair signal quality. Our problem however occured before inserting these extensions, it’s just more convenient for the jrk placement and also more secure to have coded and tight fitting connectors.

I’ve added a quite large capacitor between the A-B connectors and the power supply and did a few minutes of testing, but I think the system is now even more prone to failure. It’s a massive EPCOS 22000µF/40V that has 10mOhm ESR/100Hz and may take ripple currents up to 9.6A :smiley:
I’ll try a smaller one right between the A-B terminals next time, if you could suggest a capacity point?

I meant a capacitor more like 0.1 uF, but it probably won’t make that much of a difference.

The problem is more likely to be with your power supply. Could you provide more details about what it is? You said it provides “6A@20V and is checked to supply at least 17V in the worst case.” How did you check it? How long are the leads from the power supply to the jrk?

The actuators are designed to run at 12 V and they have a stall current of 10 A at that voltage. If you’re running them at 20 V, the stall current would be around 10*20/12 = 16.6 A. The actuator will briefly draw the stall current if you start it up immediately at full speed so that could cause problems. You might be able to get around this by using the jrk’s max duty cycle and max acceleration settings.

–David

Hi,

well, a blocking capacitor differs from a large supporting capacitor, so it might be worth a try.

Max. 6A @ 15/16/18/19/20V or 5A @ 22/24V is the specificated output. 17V was measured while switching motor directions, which should use the most power. Test was at full duty cycles. I know that there may be peaks that I’m unable to detect without an oscilloscope, but as described below, even a better power supply doesn’t work.

Cable length is 1.6m (power supply leads) + 0.2m (adapter) + 0.4m to the jrk.

Settings at the moment are:
Max duty cycle 350
Max acceleration 15
Brake duration 0
Max current 3.996
Current calibration 37

I just checked with another power supply (a regulated one, triple output), type EA-PS2316-050 which is capable of 32V @ 5A / 16V @ 10A. It never shows above 0.6 amps in regular use with the settings above. And, more important: I’m not able to move more than about 10 times until the jrk is lost. Same with lowered supply voltages of 15V and 12V with up to 1.2A as measured by the power supply itself. Seems like the jrk is built to work best with the cheapest chinese crap supplies :mrgreen:

I’m sorry you’re still having trouble even with a different power supply.

If you haven’t done it already, could you try unplugging one of the leads of the linear actuator motor (so it can’t move) and see if the problem still happens?

It’s interesting that your failure rate changed when you switched to a different power supply. I think this means that working on the power supply is a good idea. It sounds like the power supply voltage is dropping at least 3 V (from 20 V to 17 V) while switching directions. I think this is the root of your problem, and there are two things you can try to reduce it:

  • You could try adding capacitance between the jrk’s GND and VIN lines. A few hundred µF would probably be OK, but since you have a 22000µF capacitor you might as well put it there and see if it helps. It should be mounted close to the jrk.
  • Try using the brake duration parameter. If you set it to a value that is large enough, it would prevent the jrk from driving the motor while the motor is moving in the opposite direction. I would set it to something big like 1000 ms at first to see if that helps, but you’ll probably want to try reducing it later so you can get better control of the motion.

It sounds like the cables between the power supply and the jrk are only 0.4m, which should be ok.

You said your max acceleration is 15, but what is the PID period?

–David

Hi,

yes, sorry, I forgot to tell you. The jrk ran overnight without problems when the motor was powered off. Maybe I should do another run in order to make sure this is reproducible and not just by coincidence.

I found that interesting, too. However, voltage doesn’t drop by 3V, as in regular use I do not switch directions that fast. In fact, the motor is at rest most of the time. It is mounted upside down and should carry some measuring equipment (tiny and light). Upon request, the motor starts and moves down to a specific, ever-the-same target point, stays there for about 15 seconds, and moves back. It then pauses for about half an hour. That’s it.

PID settings are:
Proportional coefficient = 6/2² = 1.5
Integral coefficient = 0.125
Derivative coefficient = 0.5
PID period 25 ms
Integral limit 500
Feedback dead zone 2
Reset integral -> off
At lower voltages this is quite slow (although that doesn’t matter in my application), but with ~20V it is reasonable fast.

Disconnecting the capacitor and switching back to the old power supply, the performance is now worse than ever before. I can hardly do any movements at all. My Excel test program was able to do three moves, and after reconnecting and using the jrk config tool, connection got lost after setting one single target in auto set target mode…without motor attached, it worked fine for the last ten minutes.
I think the jrk is about to die and I’ll return it. Hopefully the replacement will work as intended.
Thank you very very much for your patience and support :smiley: CU soon…

Thanks for reporting the results with the actuator disabled.

With a PID period of 25ms and acceleration of 15, it should take about 600/15*25 = 1000 ms for the jrk to accelerate from rest to full speed, so that sounds good.

I’m sorry you are still having trouble. The two suggestions I made in my last post still stand (adding capacitance between GND and VIN near the jrk, and using the brake duration parameter). Let us know if your jrk does die, and please be sure to ask us before returning anything.

–David

Hello from RAL Space Robotics. The jrks are great! we used them in many robots but now that we moved USB control we are experiencing a similar (to the one described above) issue with the jrk 12v12. We are using 6 jrk 12V12 to control drive motors of a robot. The power to the motors are from some LiFe batteries, the usb line is connected to an industrial grade (surge protected) powered USB hub and the hub is connected to a low power ARM single board computer (Beagleboard). We are running Ubuntu Linux and a custom python script dealing with the USB control of the jrks.

During operation randomly a jrk drops out, and the serial line is disconnected and we are unable to reconnect to it unless we power the jrk off and back on…

Just to note our PID and acceleration settings are set up so the motor reaches 0-100% power in 1 seconds and we were logging the current which never reached the current limit of the jrk.

We haven’t experienced the issue with the motors disconnected but I will do more test on this on Monday.

We will also try adding the capacitors as you suggested and report back.

Hi
I work with Kisdia above.
we have all of the pololus going into the hub.
the usb lead from the hub to the Beagleboard has no ground or power lines. this has stopped the previous issue of the beagleboard being shut down by the noise.
could the noise be causing the 5 Volt from the mini usb to be disrupted?
how is this power generated on the pololu?
Thanks
Wayne

Hello, Wayne and Kisdia.

I’m sorry you are having trouble with the USB connection to the jrk.

Could you give me more details about the error you are having? Do you see any messages about it in “dmesg”? What happens to the jrk’s two virtual COM ports? What are the jrk’s LEDs doing during the error?

Could you give me more information on your LiFe batteries and drive motors? Links to product web pages would be great.

Really? Standard USB cables have ground and power lines. Where did this modified cable come from?

All the grounds are all connected together, including the ground on the USB connector and the GND going to your battery. When both USBand VIN power are present, as they are in your system, the VIN supply powers the motors and a 5 V linear regulator. There is a simple circuit to choose between the on-board regulated voltage and the USB voltage, with the regulator power taking precedence. The ~5 V output of that circuit powers the microcontroller.

–David

Hi David

As we are driving the robot sometimes one of the pololus will stop responding to commands and continue with the last command given.
In linux the COM ports are visible. Sometimes we can reconnect straight away. Othertimes we cannot connect to the COM Ports. The serial port is blocked. In this case we need to hard reboot the pololus.
if we can connect the green LED is on if not it is off.

we are using two sets of 4 LiFe cells in series to give 14.8V Nominal.
the motors are standard DC Brushed motors with a gear box.
the control side of the robot (including USB hub) is powered by one set of batteries and the motors are driven from the other.

The USB cable was modified by me as only Data was needed and previously the the beagleboard was crashing from this noise.

i was wondering is something similar from the hub to the pololus would work?

Thanks
Wayne

Hi David,

Thanks for the quick reply, your help is much apprechiated. We think it might be a noise issue, so we are putting some 0.1uF capacitors accross the motors. Do you think it is worth putting some accorss the input lines?

Many Thanks,

Aron

When the jrk turns off its green LED, it’s because it’s not getting any power from the USB port and/or it’s not detecting any packets on the USB port. We’ve seen this sort of thing a few times before and I think it happens because some sort of noise is getting to the USB port and causing it to turn off, perhaps as a method of protecting itself.

Putting capacitors on the motor is a good idea, as described here:
pololu.com/docs/0J15/9

It would also be good to put a couple hundred microfarads of a capacitance between the jrk’s GND and VIN lines. Let me know if that helps!

Do you have an oscilloscope for monitoring the power lines?

Does your system have the “dmesg” utility? Do you see any messages about the problem when you run “dmesg” at the command line?

I’m kind of surprised that your modified USB cable is working without a GND line. I’m not sure if the same thing would work between the jrk and the hub. At the very least, if you’re going to make it work you would have to feed some 5 V power source into the jrk’s USB port so that it detects USB power and starts up its USB circuitry.

–David

Hi David,

We added the capacitors both on the motors and at the in line of the jrk 0.1uF in both case.
Also we think we experience less dropouts, but they still occur. We are experiencing diferent kinds of dropouts.

Our connection goes: 6 x motors* => 6 x jrk => industrial grade powered surge protected USB hub => single board computer, the disconnected usb line is between the single board computer and the hub and both the hub and the computer are provered from a smaller “clean” battery while the jrk and the motors are powered by the main battery.

I cases below it was only one pololu which dropped out. (not nescessarily the same one so it doesn’t seem to be a faulty board)

  1. mode one
    We don’t see the green LED turning off anymore (it is possible that they only turn off for a very short time when the dropout occurs), but in one failure mode the green LED starts flashing.
[2063.112335] tty_port_close_start: tty->count 1 port count = 0.

In this case I can’t reconnect to the jrk. I need to reboot the computer or the pololu.

  1. mode two, we believe this might be due to the hub
    In this case I can reconnect right away.
    Here is the printout from dmesg:
[157.202087] hub 1-2.5:1.0: port 6 disabled by hub (EMI?), re-enabling...
[157.227386] usb 1-2.5.6: USB disconnected, device number 10
[157.486206] usb 1-2.5.6: new full-speed USB device number 12 using ehci-omap
[157.610412] usb 1-2.5.6: New USB device found, idVendor=1ffb, idProduct=0085
  1. mode three, similar to mode 2 but doesn’t seem to effect the hub
[988.693847] usb 1-2.5.1: USB disconnected, device number 6

again I can reconnect right away after the error

*http://docs-europe.electrocomponents.com/webdocs/0bf3/0900766b80bf315e.pdf

Hello.

I’m glad you are experiencing fewer dropouts. It sounds like you are able to recover from Mode 2 and Mode 3 automatically, so we should focus on fixing Mode 1. The next time Mode 1 happens, could you try shorting the jrk’s RST line to its GND for second? This should reset the internal state of the jrk and to the computer it should look like you unplugged the jrk. After you stop shorting those two pins, hopefully things will work again.

–David

Hello David,

Just an update on this, adding the capacitors connecting each motor terminal to the case of the motor (as your guide suggested) got rid of the noise causing this issue. Only the next few weeks will tell if it is completly fixed but at the moment we cant induce a "drop-out"
We also found that using 0.1 uF and 47 nF capacitors in paralel cut out more noise.

Thanks,

Aron

Great! I’m glad you fixed the issue, and thank you for letting me know. Were you inspecting the power lines with an oscilloscope to see the level of noise?

–David

Hi
the initial tests seem to show a major improvement (this was done with a test rig clamped to the desk and me trying to stop it to induce noise). after adding the capacitors it wasnt possible to make the system drop out.

i have copied the same set up into the robot and now the dropouts are back. It appears there is still noise and 6 of the pololus attached to a hub seems to drop out the USB. We have a few more tests to try on monday to make sure we are having the same issues, or if this is a fun new issue.

is there a reason the pololu would disconnect itself or would it maybe induce noise down the USB line that would make the computer unhappy? having the 5Volt line disconnected still allows it to drop out. this implies it is the whole usb comms part going wrong, not just the power line.

i have seem that a few others have had this issue which seems to be fixed by using the RX and TX lines, i guess these use a different area or is the usb port just a USB to serial port adaptor and the serial ports connect after it?

thanks
Wayne

I’m sorry your problems have returned. Please let me know what the results of your tests are if you do them.

What do you mean when you say you have copied the same set up? Did you just move all the components (including the computer) onto a robot chassis, or have some of the components in the system changed?

Previously you said that only one jrk would drop out at a time, but now all 6 of them are dropping out. Is that correct? What are the LEDs doing and do you see any messages in dmesg? Does the hub itself drop out, i.e. is the hub still visible when you run lsusb?

The jrk will not try to disconnect itself from USB (unless you send it the command to get it into bootloader mode). I think the problem is electrical noise from your motors interfering with the hub or the Beagleboard. You might be able to figure out which is happening if you put 3 jrks on one hub and 3 jrks on the other.

My understanding is that you only disconnected the 5V line between the hub and the computer, not between the hub and the jrks. You might want to try disconnecting the power line between the hub and jrks, but you would have to supply 5V from somewhere to the USB power line so that the jrk detects power from USB and does the right thing.

The jrk has a native USB connection; there is no USB-to-serial chip on it.

–David

We kept having trouble with the native USB connection. For the benifit of future users it is far easier to use the serial connection. With a TTL serial cable (you can buy nice cables which have the USB to Serial built in the USB plug) it works perfectly all the time. So if you are struggling with the same problem you might want to consider just leaving it and switching. There are no real disadvantages of using serial coms.