Motor Shield Trouble

Hello,

I’ve been working on an Arduino-based pneumatic Nerf gun that functions much like a revolver and features full and semi automatic fire. The (15) rotating barrels are mounted on a hub and connected to a motor with a gearbox. Using a limit switch, the barrels can be indexed 24 degrees (360/15=24) to align each new barrel with the air outlet after every shot. The air outlet is controlled by a solenoid. The Arduino operates the motor and solenoid through the [NKC Motor Shield.

In most of my tests, the setup worked just fine. However, when I used the full-auto loop and reduced the delays that affect the rate of fire, the motor will start acting strange. It will suddenly start to rotate very slowly in brief, fast pulses of rotation. These pulses are not characteristic of anything my program might cause. They can be set off by subjecting the gun to a prolonged period of high rate of fire. Once it happens, the motor is stuck doing this regardless of any input from the gun’s switches. (Although I should note the pulses are slowed down by some, though never stopped). To break the cycle, the motor must be disconnected from the shield and reconnected, then it will work fine again instantly until the next bunch of pulses are set off. Throughout this process, the SN754410NE motor driver becomes extremely hot, enough to burn my skin.

Does anyone have an idea of what might be going on here? I’ve tried dozens of variations in my program to stop this problem but it persists. Could it be that the motor shield is not meant to handle such rapid switching?

Thanks!

Here it is working properly at low RoF. (I have to hold the limit switch myself, it’s not fully assembled yet)

http://s237.photobucket.com/albums/ff15 … nt=fai.mp4

Here it is after getting stuck at high RoF.

http://s237.photobucket.com/albums/ff15 … D00022.mp4

Here is the sketch:

//Naming input pins
#define trigger 2
#define indexing 8
#define selector 7

//Naming output pins
#define motor 10
#define dir_motor 13
#define valve 9
#define dir_valve 12


//Declaring variable with start value of 0
int indexingstate = 0;
int triggerstate = 0;
int oldtriggerstate = 0;
int selectorstate = 0;

void setup(){
  
  //Set input pins as inputs
  pinMode(trigger, INPUT);
  pinMode(indexing, INPUT);
  pinMode(selector, INPUT);
  
  //Set output pins as outputs
  pinMode(motor, OUTPUT);
  pinMode(dir_motor, OUTPUT);
  pinMode(valve, OUTPUT);
  pinMode(dir_valve, OUTPUT);
  
  //Setting motor and valve direction (irrelevant)
  digitalWrite(dir_motor, LOW);
  digitalWrite(dir_valve, LOW);
}

void loop(){
  
  //Read and store value of selector switch
  selectorstate = digitalRead(selector);
  
  
  //Begin semi-auto loop
  if(selectorstate == HIGH){
  
  //Read and store value of trigger switch
  triggerstate = digitalRead(trigger);
  //debounce delay
  delay(20);
  
  //If there is a transition from not pressed to pressed, Fire!
  if((triggerstate == HIGH) && (oldtriggerstate == LOW)){
  
  //Run motor until indexing switch is hit
  do{
    analogWrite(motor, 255);
    //possible delay
    delay(10);
    indexingstate = digitalRead(indexing);
  }while(indexingstate == LOW);
  
  //Stop motor
  analogWrite(motor, 0);
  //Open valve for 1 second
  delay(50);
  analogWrite(valve, 255);
  delay(50);
  //Close valve
  analogWrite(valve, 0);
  //RoF delay
  delay(10);
  }
  
  //If trigger is not pulled, do nothing.
  else{
    analogWrite(motor, 0);
    analogWrite(valve, 0);
    }
  
  //store current value of trigger switch as old value
  oldtriggerstate = triggerstate;
  
  }



  //Begin full-auto loop
  else{
  //Read and store value of trigger switch
  triggerstate = digitalRead(trigger);
  //Debounce delay
  delay(20);
  
  //If trigger is pulled, Fire!
  if(triggerstate == HIGH){
  
  //Run motor until indexing switch is hit
  do{
    analogWrite(motor, 255);
    delay(50);
    indexingstate = digitalRead(indexing);
  }while(indexingstate == LOW);
  
  //Stop motor
  analogWrite(motor, 0);
  //Open valve for 1 second
  delay(30);
  analogWrite(valve, 255);
  delay(30);
  //Close valve
  analogWrite(valve, 0);
  
  //RoF delay
  delay(50);
  }
  
  //If trigger is not pulled, do nothing.
  else{
    analogWrite(motor, 0);
    analogWrite(valve, 0);
    }
  }
}

Here is a concept picture of the limit switch:

http://i237.photobucket.com/albums/ff15 … witch2.png](Assembling the Freeduino (Arduino) Motor Shield « MCUKITS)

Spikes from the motor and drivers are probably getting into the Arduino supply. You need to pay attention to the power and ground wiring, and add filtering and suppression.

Thanks for the reply. I will make those corrections and in the meantime locate a second motor driver to supply more current, this motor is drawing far too much current for normal shields.

Edit: It’s occured to me that I really don’t need to vary the speed of this motor. Can I simply use a transistor to switch the motor on and off with a high/low signal from Arduino? The motor would get power from an external source that way too.

PointBlank017:

Here’re a few thoughts from my somewhat addled brain:

  • - That sounds much more like an overheating problem than a noise feedback problem. That said, if you always run the motor in the same direction, try putting a [flyback diode across the motor’s connection to the driver board.
  • - The driver chip has separate inputs for logic and motor power. Are you feeding them from the same source?
  • - I was about to chase down a datasheet for the driver IC, but noticed that I don't know what motor you're using, so I couldn't compare the motor's load with the IC's specs. If you'd care to rectify the gap in my knowledge, I'll try that. (If you have any data on what your inrush current is, that would also be helpful.)
  • - The [[datasheet](http://focus.ti.com/lit/ds/symlink/sn754410.pdf) does show 4 pins marked "HEAT SINK AND GROUND". Do those 4 pins have decent thermal connections to a suitable chunk of metal?
  • - You've probably told us at some point, but how is this thing reloaded? If it, like a conventional revolver, needs to be reloaded manually, then you don't need to be able to sustain rapid fire for more rounds than you have chambers. How many chambers will it advance past the barrel in the time it takes to start exhibitting the undesired behavior?
  • ](http://focus.ti.com/lit/ds/symlink/sn754410.pdf)

    Happy Hunting,

    Eric](Flyback diode - Wikipedia)

    I’ve read about flyback diodes and I will definitely try one. In fact it will be necessary when I redesign the circuit as I’ll mention later.

    The logic and motor power are being fed from the same source. There doesn’t seem to be any way for heat to dissipate from those pins. The motor is sealed inside an electric screwdriver so unfortunately I can’t get to it but under the test conditions it was pulling just under 1 amp so it was probably maxing out the shield anyway.

    When those barrels are properly in place, the motor pulls 3.6 amps so it’s unlikely I’ll be able to use the shield anyway. I’m considering the [MOSFET power driver kit because the MOSFET will handle the amp draw. I’m still concerned about rapid switching with the MOSFET because I need the motor to start and stop almost instantaneously. From what I’ve read about MOSFETs though, it’s not as simple as turning the logic signal on and off. Is there any way I can rapidly switch the RFP30N06LE so that there are no delays? That said, is PWM possible with this MOSFET? I really only need simple on and off, but PWM might be cool.

    In “full-auto” mode I’d like to be able to achieve 15 shots per second. Above all though, it’s important that the motor stops when the signal from Arduino stops otherwise the barrels might overshoot the air outlet.

    Thanks for the help once again. I’d be lost otherwise.](SparkFun MOSFET Power Control Kit - COM-10256 - SparkFun Electronics)

    PointBlank017,

    FWLIW, I doubt the switching frequency is the problem; it’s much more likely the current. (15 rounds per second is certainly a respectable firing rate for a mechanical system, but 15 Hz is an rather low frequency for solid state devices.) To test this, try running the program with a much smaller motor, say one that draws 100 mA at steady state. If you don’t have a smaller motor, you can always use a power resistor.

    The converse experiment, running the motor you now have in steady state and seeing if you get the same behavior, is fundamentally not valid. Motors (more generally, inductive loads) typically have inrush currents of several (3 to 10) times their running currents. If you run your motor in steady state and get the overheating problem, then you know it’s not the switching frequency. However, if you get the motor to run properly in steady state, that doesn’t prove that the current when you keep switching the motor on and off isn’t the problem.

    BTW, you might want to check on the difference between do and while loops. IIRC, the latter will always execute once and you may not want to have a 10 ms delay forced upon you. Alternatively, change the delay to 1 ms.

    Speaking of time, did you calculate the 15 rounds/second as being possible, or did you just decide that emptying the weapon in 1 second sounded like fun?

    I suggest a tests of your motor’s capabilities:

    Write a program to start the motor, keep it running, and record the times at which the firing position sensor is tripped. See how long it takes to get the first fifteen trips

    The angle travelled (2 pi radians, in this case) = 0.5 (angular acceleration) * (Trot^2)

    rearranging gets us:

    (angular acceleration) = 2 * (2 pi radians) / (Trot^2),

    where Trot is the time for the first rotation

    The way to minimize the time to cover a distance (in your case, an angle) with a mechanism capable of constant acceleration and deceleration (assuming those two are the same) is to accelerate for half the time, then decelerate for half the time. One can use the same equation to calculate the time it will take to accelerate through half of the angle between barrels. (Remember, we’ll be decelerating for the other half of the angle.)

    The angle travelled (2 pi radians/30, in this case) = 0.5 (angular acceleration) * (T12^2),

    where T12 is the time to move 12 degrees (1/2 of the angle between barrels).

    Rearranging:

    T12 = sqrt{(4/30) pi radians/(angular acceleration)}

    substituting from above:

    T12 = sqrt{(4/30) pi radians/(2 * (2 pi radians) / (Trot^2))} = sqrt {(1/30)*(Trot^2)} = Trot/sqrt(30)

    A full rotation (that is, to advance all 15 chambers past the firing point) takes 30 steps of 12 degrees or

    30*T12 = 30 * Trot /sqrt(30) = (sqrt(30)) * Trot

    The other thing that takes time is getting the round fired. Have you measured how long it takes for the air to blow the projectile clear of the barrel?

    If you had good variable speed control of the rotation, you could measure this by keeping the air flow on and seeing what the maximum rotational speed is at which the projectiles are ejected in a single pass.

    Alternatively, if you know the muzzle velocity, you can calculate the acceleration in the barrel from: v = aT.

    You could try different times of having the air valve open, but the time you get that way is likely to be distorted by switching time and fluid flow delays.

    Once you know how long it takes to step through 15 chambers and how long you must pause at each, you can figure out the minimum time to empty the cylinder.

    Here’s another “cheery thought”: Even if your motor is powerful enough to provide the angular acceleration you desire, controlling it will be rather difficult. Have you considered biting the bullet (I just couldn’t resist that one.) and using a stepper motor? They’re designed to work by starting and stopping at small angular displacements.

    But wait, there may be more. :wink: Do you really need to stop the cylinder to fire a round? What happens if you turn the air and motor on together, then turn them off after the cylinder has completed a rotation? That’s going to give you somewhat irregular firing (the time between chambers will decrease as the rotation rate increases), but so what? Frankly, I’d be more concerned about the effect of having a variable orifice between the chamber and the air source. Whether the latter matters, however, depends on a bunch of factors that make this one of those things it’s far easier to test than to calculate.

    Have Fun,

    Eric

    Eric,

    First off thank you for taking your time to offer so much advice.

    Whatever the cause of the problem may be, I don’t think I will dedicate time to isolating it unless it persists even with the MOSFET system I will be switching to. And if it does not persist with the MOSFET, it’s likely that the problem was the amp draw anyway being that the MOSFET will be able to handle it. Additionally, I will probably use an optoisolator to protect the Arduino from stray pulses.

    I selected 15 rounds per second as a desired maximum rate of fire based on the knowledge that the motor/gearbox/barrels are capable of rotating 360 degrees easily more than once per second. That, and 15 rps is about the maximum rate you’d like a gun to fire before it simply wastes ammo.

    I selected a do-while loop so that I can guarantee the motor will turn for at least one pass through the loop regardless of the indexing switch’s state. If it so happens that the gun is at rest and the indexing switch is pressed, (very likely) that one pass serves to rotate the barrels until the indexing switch is NOT pressed upon its first time being read within the do-while loop, allowing the loop to proceed until it IS pressed once again as planned. So, that first pass explains the 10ms delay.

    However, the 10ms delay poses a potential problem in that the motor might overshoot the indexing switch, preventing it from being read as HIGH, and lead to one or more barrels being skipped.

    I’ve found a way to eliminate that problem and the delay altogether using two normal while loops. The indexing switch will be read and if it is HIGH, the first loop will spin the motor until it is LOW. Once the switch is LOW (or if it already was), the second while loop will spin the motor until it is HIGH. This eliminates the need for that first pass, the delays, and rapid on/off switching that would have occurred before in the event the indexing switch was stuck HIGH somehow. Above all, it will ensure proper function no matter the position of the barrels.

    //Alternative to do-while loop for firing sequence
    
    indexingstate = digitalRead(indexing);
    //debounce delay
    
    //this loop will advance the barrels enough to unpress the indexing switch in case it is already pressed
    while(indexingstate == HIGH){
    //turn motor
    //short delay?
    digitalRead(indexing);
    }
    
    //indexing switch will now be LOW if it was not already
    
    //this loop will advance to the next barrel by stopping rotation when the indexing switch is pressed again
    while(indexingstate == LOW){
    //turn motor
    //short delay?
    digitalRead(indexing);
    }
    
    //indexing switch has been hit, fire valve.
    

    I’m also considering a simliar alternative using interrupts in the code.

    Because of the gearbox and the gray tube around which the barrels turn, there is enough friction present to stop the whole assembly almost dead in its tracks when the motor is switched off (another factor contributing to the high amp draw). But because of this, I can get away with keeping the motor full on until the indexing switch is hit. No need to calculate a deceleration period.

    As for the solenoid valve, it actuates a larger valve. Therefore after a certain duration of holding the solenoid open within the program, time and power are simply being wasted because the larger valve will continue to do its job once it’s been actuated regardless of the solenoid at that point. I have not actually calculated the time it takes for all the air to flow, but all necessary delays can easily be incorporated so that the air has finished flowing before the motor begins to turn over the next barrel. After measuring I might find that 15rps is no longer attainable, but I’m confident in the pneumatic parts’ ability to cycle quickly. If not, I will reduce the rate as necessary.

    I chose to have the gun work this way (turn until told to stop, fire, repeat) because consistent firing was a requirement in the planning. Since there are no mechanical detents positioning the barrels exactly in place, I can never be certain where they are. If I allow them to overshoot the air outlet after firing or somehow they’re rotated during use or manual reloading, the next series of shots will begin out of tune. I’m mainly aiming for consistency and predictability. It’s good to get a feel for how long after a trigger pull the gun will fire.

    And finally, I did consider a stepper motor. It was the first option I considered and it would be great for so many reasons, but I don’t think it would practical to build a gun with an onboard battery that’s suitable for a stepper motor. I’m aiming for several hundred shots off one charge. Even if I shut the motor off after each shot, I don’t think it would last as I need it to. I really would have liked to go that route, though.

    All that said, is there anything else I should consider? I’ve never worked with MOSFETs before and I’m not 100% sure they’re suitable here. Would it be a good idea to use an optoisolator? Couldn’t I just get away with a putting a diode between the Arduino’s output pin and the MOSFET gate? I was told to consider this [IC because it incorporates optoisolators on both channels.

    Thanks again. You have been extremely helpful.

    Mark](http://www.components.omron.com/components/web/PDFLIB.nsf/0/73EA60F3C9E535B785257201007DD5B4/$file/G3VM_62C1_F1_1210.pdf)

    PointBlank017:
    First off thank you for taking your time to offer so much advice.

    You’re most welcome! Thanks for providing the entertainment and for taking your time to indulge my curiosity.

    PointBlank017:
    I will probably use an optoisolator to protect the Arduino from stray pulses.

    In general, isolation is a good thing. Even if you don’t need it for noise, it’s a way of protecting the DO pin from the outrush current of satisfying the gate capacitance of the MOSFET.

    PointBlank017:
    I selected 15 rounds per second as a desired maximum rate of fire based on the knowledge that the motor/gearbox/barrels are capable of rotating 360 degrees easily more than once per second.

    Ah, but is the system capable of rotating 24 degrees in the first 67 milliseconds of power? The two are not even close to being equivalent. 360 degrees/second is 60 rpm, which isn’t all that fast. To turn 24 degrees in the 100th 67 ms period is a reasonable expectation. To turn it in the first 67 ms, though, requires rather impressive angular acceleration.

    PointBlank017:
    That, and 15 rps is about the maximum rate you’d like a gun to fire before it simply wastes ammo.

    I’ll have to take your word for it, although I do recall one person who thought the number was a bit higher. :wink: I went to grad school (while I was working as a semiconductor process engineer) with a guy who made automatic weapons for helicopter gunships. He had what I thought were “rather interesting” notions about what constituted a reasonable heat transfer rate. In fairness, he thought I had “rather interesting” notions about what constituted a reasonable operating temperature.

    PointBlank017:
    I selected a do-while loop so that I can guarantee the motor will turn for at least one pass through the loop regardless of the indexing switch’s state. If it so happens that the gun is at rest and the indexing switch is pressed, (very likely) that one pass serves to rotate the barrels until the indexing switch is NOT pressed upon its first time being read within the do-while loop, allowing the loop to proceed until it IS pressed once again as planned. So, that first pass explains the 10ms delay.

    Good point! I failed to consider from where you were likely to be starting. :oops:

    PointBlank017:
    Because of the gearbox and the gray tube around which the barrels turn, there is enough friction present to stop the whole assembly almost dead in its tracks when the motor is switched off (another factor contributing to the high amp draw). But because of this, I can get away with keeping the motor full on until the indexing switch is hit. No need to calculate a deceleration period.

    Well, that simplifies the control problem, but at a huge cost in operating energy.

    PointBlank017:
    As for the solenoid valve, it actuates a larger valve. Therefore after a certain duration of holding the solenoid open within the program, time and power are simply being wasted because the larger valve will continue to do its job once it’s been actuated regardless of the solenoid at that point.

    Have you tested that? Most of the small electropneumatic valves that are used to control air-operated valves connect their output ports to vent when they are in the inactive state. That way, if you turn off the electropneumatic valve, the air-operated valve also turns off. If your air-operated valve stays on after you turn off your electropneumatic valve, how do you turn off your air-operated valve? Do you have a second electropneumatic valve that relieves the actuating pressure? (I didn’t mean that last sentence to be snide, and there are such configurations in use. However, the most common way I’ve seen (and I see a fair number of these in my “day job”, much of which is reviewing industrial machinery designs) is to use an electropneumatic valve that, when its control signal is dropped, relieves the actuating pressure.)

    PointBlank017:
    I have not actually calculated the time it takes for all the air to flow, but all necessary delays can easily be incorporated so that the air has finished flowing before the motor begins to turn over the next barrel. After measuring I might find that 15rps is no longer attainable, but I’m confident in the pneumatic parts’ ability to cycle quickly. If not, I will reduce the rate as necessary.

    I think you’ll find that squeezing the cylinder advancing and the pneumatic firing cycles into 67 ms is an interesting challenge. Do you have some way to capture what’s happening and slow it down so you can watch? It seems to me that video at 100 frames per second or better would be useful. If that’s not handy, do you have a multichannel oscilloscope, logic analyzer, or other way to record events on a 10 ms or better time scale?

    PointBlank017:
    I chose to have the gun work this way (turn until told to stop, fire, repeat) because consistent firing was a requirement in the planning. Since there are no mechanical detents positioning the barrels exactly in place, I can never be certain where they are.

    If you’re relying on frictional braking, you might want to put a small mechanical detent in. That way, the angular deceleration will spike at just the right point, putting the chamber where you want it. Keep in mind, though, that the motor will need to overcome the detent to move to the next chamber (unless you want to put an active detent in).

    PointBlank017:
    And finally, I did consider a stepper motor. It was the first option I considered and it would be great for so many reasons, but I don’t think it would practical to build a gun with an onboard battery that’s suitable for a stepper motor. I’m aiming for several hundred shots off one charge. Even if I shut the motor off after each shot, I don’t think it would last as I need it to. I really would have liked to go that route, though.

    Without knowing how much torque you need, I can’t begin to try to find an appropriate stepper motor and look at the energy requirements.

    Speaking of energy requirements, what’s your compressed air source? Are you filling a tank, using something prepackaged (such as CO2 cartridges), or using a small pump (which also drains your battery)?

    PointBlank017:
    All that said, is there anything else I should consider?

    Probably, but one of the interesting parts of projects such as this is that you won’t find out what until you get there. :wink: Perhaps more usefully, the only thing that pops to mind is that you should provide a heat sink for the MOSFET. Keep in mind that the tab is electrically active on most such devices.

    PointBlank017:
    I’ve never worked with MOSFETs before and I’m not 100% sure they’re suitable here.

    You most likely have used MOSFETs before, just not explicity. In general, MOSFETs are commonly used for switching power on/off from a small control signal.

    PointBlank017:
    Couldn’t I just get away with a putting a diode between the Arduino’s output pin and the MOSFET gate?

    It’s not obvious to me how that would help. It would also complicate turning off the MOSFET. WIthout a diode, you can set the DO to LOW and have the Arduino sink the gate discharge current. If you put in a diode, you’ll need to add some other current path through which to discharge the gate.

    The MOSFET itself should provide substantial isolation from the motor’s flyback current, although you should provide a flyback diode to protect the MOSFET. If there’s a single-component means of protecting the DO, it’s probably putting a resistor in series between the DO pin and the MOSFET gate. That will limit the outrush current when you turn the MOSFET on and the inrush current when you turn the MOSFET off. (If you put a weak pulldown on the gate, you can reduce the inrush to the DO even further, at the cost of having to provide more current through the DO to keep the MOSFET switched on. In choosing your series resistor, remember that the RC time constant (R is the series resistor, C is the MOSFET’s gate capacitance) will limit how fast you can switch the MOSFET. According to the [datasheet, the gate capacitance is ~1500 pF. If you put in a 250 ohm resistor (which would limit the peak current to (5 V/250 ohm = 20 mA), RC is (250 ohms * 1.5E-9 F = 3.75E-7seconds, which seems rather unlikely to matter.

    PointBlank017:
    I was told to consider this [IC because it incorporates optoisolators on both channels.
    [/quote]That looks like a rather useful device, but not for your application. It’s rated at 0.5 A/channel and you appear to be drawing far above the combined ampacity of the two channels.

    PointBlank017:
    Thanks again. You have been extremely helpful.

    Again, you’re most welcome.

    Happy Hunting,

    Eric](http://www.components.omron.com/components/web/PDFLIB.nsf/0/73EA60F3C9E535B785257201007DD5B4/$file/G3VM_62C1_F1_1210.pdf)

    ](http://www.sparkfun.com/datasheets/Components/General/RFP30N06LE.pdf)

    I never realized that every single shot will essentially be starting from rest. That, along with time spent firing, I’m not sure 15rps is so simple anymore. Thanks for pointing that out. To achieve anything close to that I’d have a much easier time coding in an interrupt routine that just fires the valve while the barrels are still turning. Of course, that would depend on how quickly the valves can cycle and if I could even manage to coordinate the barrel’s rotation with the firing just right. For now I suppose I’m limited to semi-auto (which was actually my main objective in the first place) and low RoF full-auto.

    I will attempt to measure the valves’ cycle time but it’s not the easiest thing for me to do with what I have.

    The solenoid valve is a 3-way normally open valve and it actuates a quick exhaust. At rest, air (CO2 actually) will flow from a regulated tank through the solenoid, through the pilot port on the quick exhaust, and into a reservoir where it is stored. Upon receiving a signal, the solenoid stops supplying the quick exhaust with air while at the same time venting the air at the pilot port. This actuates the quick exhaust which lets air from the reservoir down the barrel. These quick exhaust valves are very sensitive. Once they’re actuated, they’re open. Here is one in use on an earlier project with a manual trigger valve: http://s237.photobucket.com/albums/ff15 … t=rspe.mp4

    http://i237.photobucket.com/albums/ff15 … 1295393351

    My thinking behind putting a diode after the DO pin was to protect it as an optoisolator would, but I didn’t realize current flowing back into a LOW pin was so important to switching the MOSFET. I won’t do that then. My thought behind that IC was to switch the two MOSFETS. Alone it doesn’t allow the amp draw, but I thought it would protect the Arduino.

    I have a rather convenient way of measuring the torque needed to overcome static friction so I will do that when I get home. But at this point, so much of the gun has been designed around the electric screwdriver and everything being housed inside that gray tube (The barrels rotate around it as well). I’m not sure if I would have room for a stepper. I do know, however, that the one Sparkfun sells will just barely make it inside the tube.

    I have a Duemilanove which I am using with a motor shield purchased from NKC off of Amazon. Not sure what version.

    I have it connected to a twin-motor gear box (tamiya 70097) which is mounted on a tracked vehicle chassis (tamiya 70108).

    If I tell the motors to go in one direction everything is fine, but once I try to reverse directions in the same program one side tweaks out and cannot decide what way it want to turn.

    I am powering everything off of the 9V through the board and shield.


    [knuckles](Brass Knuckles)

    You would get better help if you started your own thread instead of bringing up a 3 yr old thread.