View Full Version : [Question(s)] Arbotix digitalRead() interfered by motors?

06-01-2013, 05:15 PM
I need to send simple commands from IOIO to Arbotix.
I have been trying to connect them using UART as the protocol, with the SoftwareSerial library.
I have managed sending data from the IOIO using Uart.getOutputStream().write() on the IOIO side and SoftwareSerial.read() on the Arbotix side.

Everything works until I connect my AX-12 motors.

Then, when I start fresh, I can send the 1st byte and then no more bytes are received. The Arbotix loop continues to run, but SoftwareSerial.available() keeps returning 0. Resetting Arbotix again enables receiving 1 byte and again no more.
My serial line is connected to digital pin 2 on the Arbotix with a pull-up 10K resistor to 5V.
I have tried powering the Arbotix from both FTDI and the motor 12V source with same results.

To make the setup simpler, I also tried just a simple digitalRead() from a push button connected to digital 2. Again, everything works until I connect the motors and start receiving strange inputs.

Any ideas?

06-01-2013, 10:53 PM
What baud rate are you using? SoftwareSerial is not a very high speed library, and also locks out other processes/interrupts while working.

06-02-2013, 06:16 AM
I am using 9600 baud.
However, the problem is not with SoftwareSerial since I am also getting strange input even if I just try to read a push button.
The push button digitalRead() works OK, but the moment I connect the motors, I start getting strange inputs.
It must have something to do with the current the AX-12 is taking, but I am no electronics expert.

06-02-2013, 08:22 AM
Note: I am not an Arbotix expert, but do have some experience with them.

From the information, it is hard for me to guess what is going on, without knowing the setup nor the code involved.

Whenever I run into issues where it is acting strange, me first instinct is to check your power setup. Are you using battery? If so is it charged. If wallwart does it have enough amperage to handle the motors...

As jwatte mentioned, SoftwareSerial does not work well with anything that relies on timely processing of interrupts as it disables interrupts for the time it takes to process one character. Both on output as it specifically disables interrupts and on input as once it receives a pin change interrupt to start the input, it stays in the interrupt handler until it processes inputting the entire character. So at 9600 baud, it will disable interrupts for a little over 1ms per character or about 16.67K clocks.

Now using digitalRead(), I don't know what issues you are having with strange inputs. One thing I ran into when I was porting the Phoenix code base to work with the PhantomX, is with the default Bioloid library, the code in Bioloid Controller (void BioloidController::interpolateStep() ) when called when hang in this code until a specified amount of time (default 1/30th of a second), since the last time it was called. This caused my code not to work the way I wanted it to as I wanted my code to call this in several different places as to not starve the processing of the servos, but I also wanted to process other things. So I built my own version of the library, where I could pass in a boolean (void interpolateStep(boolean fWait=true) ) to control if I wanted the code to perform this wait.

So for example in your code if you are looping off calling interpolateStep, and then doing a digitalRead, you will only do this digitalRead about 30 times per second. Again not sure if this is the issue you are running into?


06-02-2013, 02:21 PM
First, a meta question about your approach to debugging:
Do you have an oscilloscope, or a (USB) logic analyzer? If so, you should start seeing what's going on electrically. If not, you'll likely want to get one of each.
The absolutely cheapest Chinese crap isn't likely to help, but there are some reasonably low-cost items that do work wonders for knowing what's going on. These are the one I got when I ran into debugging brick walls, and they did unlock the problems:
Owon PDS5022T oscilloscope, $279: http://www.amazon.com/gp/product/B007T6XNCA/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=B007T6XNCA&linkCode=as2&tag=enchage-20
Saleae Logic 8-channel analyzer, $149: http://www.amazon.com/gp/product/B004G4ZKA6/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=B004G4ZKA6&linkCode=as2&tag=enchage-20

The oscilloscope has a bit of noise, but is fine for these kinds of problems (and many others.)
The logic analyzer comes with fantastic software, and even runs on Linux.

Now, for actual debugging:

I second the suggestion to check the battery, and check the wall wart. You may very well be seeing brown-outs because of insufficient power supply. You may be able to measure something with a multimeter, but a o'scope would tell you for sure.

If the problem is noise -- either on power, or on the signal wires -- then a fat capacitor across the +/- will often help. You can't do this on the signals so much (it will filter them) but on the power bus. Put a 10 uF ceramic AND a 220 uF electrolytic across the power bus to make sure there's no problems there.

Finally, are you feeding power to the servos through the Arbotix? (I don't have one; don't know how it works exactly.) You may want to break out the power, and actually feed it through a separate power injector, like the SMPS2Dynamixel, or just a cut-off piece of 3-wire cable. Just make sure you don't feed it on the wrong wire, or it will be expensive to fix :-)