Hi,
For our robot project we’re using the Pololu Simple High-Power Motor Controller 24v23 for our motors. We’re programming them in C# with Monodevelop on Arch Linux. We used the older version last year and unfortunately we’re running into problems. Our motor controllers are resetting (we catch the exception and resume them) and the problem gets worse with higher voltages. (We’ve tried 12 to 26 volts) The problems occurs more often when the motors are stressed (our robot needs to be able to drive through and dig sand). We usually can catch the exception and resume in a reasonable amount of time so we don’t loose control, but occasionally we can’t reconnect and loose control. We’ve been testing the motor controllers individually and without the USB Hub. My advisor suspects that the USB Hub could be causing the problem, he thinks it’s sending a reverse voltage (I’m not sure of the correct terminology since I’m not an electrical engineer) back to the motor controllers. I noticed on the info sheet that there isn’t any reverse voltage protection, so maybe this is the problem.
Also, the exception being thrown is the same one we experienced last year when the older version of the motor controllers were rated for a voltage higher than they actually could handle. (One of my team members emailed about the problem last year)
Thank you for helping!
Hello.
I am sorry you are having trouble with the Simple Motor Controller.
Before doing any more experiments, I recommend setting the “Command Timeout” setting on the Simple Motor Controller to something reasonable for your application; then at least the robot won’t drive away when the communication is disrupted.
You said you are using Arch Linux, but what kind of computer do you have? Could you elaborate on what you mean by “older version”? Specifically, what recent change to the SMC are you referring to? What libraries are you using to talk to the Simple Motor Controller? What exception are you getting, and which library is producing it? Do you have any more information about the error condition, such as what the LEDs on the simple motor controller are doing when it happens, or what messages appear in the output of dmesg?
What do you mean by “resume”? Is that some sort of low-level reset of the USB port, or is it something higher-level? It would help if you could tell me names of specific libraries and functions in them.
In general, we have seen many situations where some kind of electrical noise can cause intermittent problems with a USB port, but we haven’t characterized it or come up with a great solution. If all else fails, you might try using the Simple Motor Controller’s serial interface, or getting a USB opto-isolator. I haven’t tried it, but this opto-isolator might help.
–David
David,
Thanks for your response. Here are some additional details which may
clarify our problems:
We are using a combination of 6 24v23 and 2 18v7 simple motor controllers. In the past we have used just the 18v7 controllers, but replaced them this year as they did not meet our voltage requirements. The two in use (18v7) receive power through a voltage converter (24 to 12). We are limited by our netbook (HP Mini 5100 Series) to 3 USB ports, requiring the use of USB hubs to meet our needs.
Using this setup, our motor controllers disconnect from software.
When this happens, we receive the Limit/Kill Switch Error. (when I can get to the lab, I’ll reply with the exact output)
Our software is designed to reconnect to the affected motor controllers after a short timeout. Unfortunately, the same exceptions are often thrown upon attempting to reconnect. During this time, the status LEDs on the affected controllers flash red.
Our current code for handling these exception is given below:
Here is where we catch the exception, when we’re trying to send a command
public void Run()
{
while(!_stopA)
{
if (change_speedA)
{
try
{
controllerA.resume();
controllerA.setSpeed((short)(speedA + speedB));
}
catch
{
Thread.Sleep(500);
Console.WriteLine("error {0} {1}", device_idA, device_labelA);
reset_motor(true, device_idA, speedA);
}
change_speedA = false;
}
}
}And here is out reset_motor method where we attempt to reconnect to the controller
public void reset_motor (bool val, string id, int speed)
{
bool try_connect = false;
do
{
try
{
List<DeviceListItem> deviceList = Smc.getConnectedDevices();
foreach (DeviceListItem i in deviceList)
{
if (i.serialNumber.Equals(id))
{
if (val)
{
this.controllerA = new Smc(i);
Thread.Sleep (10);
this.controllerA.resume();
this.controllerA.setSpeed((short)speed);
}
else
{
this.controllerB = new Smc(i);
Thread.Sleep (10);
this.controllerB.resume();
this.controllerB.setSpeed((short)speed);
}
}
}
try_connect = true;
}
catch
{
Console.WriteLine("Failed to make connections to motors, retrying");
}
}while (!try_connect);
Console.WriteLine("Connection to motors success");
}Again, thank you for taking time to help us.
Thanks for the additional information. It looks like you are using C# classes from the Pololu USB SDK. It might be helpful to know the actual exception that is being thrown, so if you could change your catch statements to print out the class and message of the exception that would be good. Also, it’s hard to be sure that you are actually getting the same exception multiple times unless you do that, right? Or does your environment automatically print out exception information?
A flashing red LED is not one of the expected LED feedback modes of the Simple Motor Controller. What are the other LEDs doing during that time? Do you suppose the flashing could correspond to the 500-ms retry loop you are doing in the Run method?
I already mentioned some things to try. Another good thing to try would be adding acceleration and deceleration limits so that the motor speed does not change too abruptly.
You have 8 controllers in the system; do all of them exhibit this problem or just some of them?
Since simply making a new Smc object isn’t working for you, you might try to do a low-level reset of the USB port. I have not tried it, but doing something like this might help you recover:
unix.stackexchange.com/a/7457
Also, did you get the assembled version or the kit version of these controllers? If you got the kit verison, it is very important to solder in the blue capacitor and for the capacitor to be in the right orientation.
–David
Hi David,
Thanks again for helping us out.
We got to the lab today and ran the motors to see the exception. We had it print out the the console, here it is below:
System.Exception: There was an error setting the USB kill switch. ---> System.Exception: Control transfer failed ---> System.Exception: Pipe error.
at Pololu.UsbWrapper.LibUsb.throwIfError (Int32 code) [0x00000] in <filename unknown>:0
at Pololu.UsbWrapper.LibUsb.throwIfError (Int32 code, System.String message) [0x00000] in <filename unknown>:0
--- End of inner exception stack trace ---
at Pololu.UsbWrapper.LibUsb.throwIfError (Int32 code, System.String message) [0x00000] in <filename unknown>:0
at Pololu.UsbWrapper.UsbDevice.controlTransfer (Byte RequestType, Byte Request, UInt16 Value, UInt16 Index) [0x00000] in <filename unknown>:0
at Pololu.SimpleMotorController.Smc.setUsbKill (Boolean active) [0x00000] in <filename unknown>:0
--- End of inner exception stack trace ---
at Pololu.SimpleMotorController.Smc.setUsbKill (Boolean active) [0x00000] in <filename unknown>:0
at Pololu.SimpleMotorController.Smc.resume () [0x00000] in <filename unknown>:0
at Robot.Motor.Run () [0x00000] in <filename unknown>:0 We were able to reconnect to the controller and continue driving it.
Also, we looked again at the controllers while the exception happened and it turns out that the LED lights were not flashing red. The yellow LED flashes when not in the exception, and solid during an exception. And green is always solid.
All the controllers in the system have this problem, especially if they are under stress. (Digging in sand) And the EE’s did install the capacitors.
Hello. Thanks for the details on the exception. It would also help if you could run “dmesg” right after the exception happens and tell us what you see.
A solid yellow LED is not one of the expected LED feedback modes of the Simple Motor Controller unless it is in bootloader mode and an upload has begun. However, based on what you said about the green LED, I don’t think it is in bootloader mode. It might look like the yellow LED is on solid if the Simple Motor Controller is getting reset hundreds of times per second. However, that theory doesn’t explain why your motors would be moving. The next time the yellow LED is on solid, if you have an oscilloscope available, it would be interesting to measure the voltage on one side of the LED to see what the signal looks like; it doesn’t particularly matter which side you measure.
I think your best bet is to figure out how to do a low-level reset of the USB port, as I mentioned before. Hopefully there is some way for the computer to send a command to the hub to disable and re-enable a port. There might be different levels of reset available too; if you can run a command that actually disconnects the 5V power from the USB port, that would probably be the best. If the connection to the hub itself has been lost, then you would need to reset the port that the hub is plugged into. You should see that post I linked to, and use dmesg and lsusb as debugging tools. To figure out what file you would write the command to, you would need to use ls to inspect what devices are visible in /sys/bus/usb/devices .
Are you able to get out of the bad state if you reset a Simple Motor Controller by temporarily shorting its RST line to the GND pin? If so, that might suggest a hardware solution.
Unfortunately, I do not know the root cause of this type of problem. We have looked into problems like this before and it generally seems like some sort of electrical noise is happening that makes the USB port shut off power and/or communication to the device; I suspect that is what you are experiencing. Here is a post about a similar problem that was nearly solved by adding more capacitors: Jrk21v3 + LACT4P-12V-20 - USB connection lost during runtime This is for a different motor control product. In the end, they decided to use the serial interface, so that is another option you could try, though I do understand it would be a lot of work to rewire everything and change your software. I think another person was able to fix a similar problem by using a different power supply. If you want to share the details about how you are powering things, and show us some pictures of your system, we might be able to offer some more advice.
–David
Sorry I didn’t respond in a while, I was finishing the semester at school.
Thank you for helping us, we learned a lot from your posts and I think we might be able to alleviate the problem.
Again, thank you for helping us!
Alison
Edit:
Oh, and it seems to be the electrical noise issue that you described in your last post, Thanks!