28 replies to this topic

[Papkee]

Alright, first post. Here we go.

Presenting the first-ever (AFAIK) Computerized Stampede ECS-50

Using an arduino I had lying around and several parts from Sparkfun.net, I've been slowly assmebling my first-ever modified blaster, dubbed the Stampede ACB.

This gun has been modified in many different ways.

Power Supply

The battery container has been cut down to the lid alone, allowing for three Li-ion Batteries to be installed providing 11.1v of power [TODO: order batteries and holder]



Computer Control

The heart of the ACB is the Arduino UNO. This small microcontroller is what makes the whole thing tick. [TODO: solder connections]



Safety Switch

The (in my mind) rather annoying safety switch has been replaced with a pushbutton that can cycle through all firing modes. [TODO: Figure out how to code the modes]



Firing Control

The leads from the safety switch have been re-routed to a relay in the battery chamber. [TODO: Connect trigger to Arduino as well]




I hope you enjoy this little project of mine, and I do hope it inspires others to experiment with microcontrollers.

I will be posted updates as ordered parts are delivered and installed, and I'd also love to hear feedback and suggestions as well.

Thanks for reading!

FULL LIST OF PLANNED FEATURES
-Semi-auto, burst, and full auto firing modes
-Ammo counter & LCD display
-Integrated Holographic sight
-Internally rechargeable batteries (no need to take them out to recharge)
-Better Safety selection method (multiple-phase switch)

[roboman]

You do have a motor controller for that thing, right (unless there's a built-in controller that the trigger switch just activates)? If there isn't one in there, the arduino can only source something like 20mA from the I/O pins, which is not nearly enough to drive that motor. You'll need a power transistor or a relay to drive that thing, most likely.

You might also want to consider a switch to detect the position of the plunger at the extremes of its travel, so you don't have to rely on timing to get the cycle correct.

[Papkee]

You do have a motor controller for that thing, right (unless there's a built-in controller that the trigger switch just activates)? If there isn't one in there, the arduino can only source something like 20mA from the I/O pins, which is not nearly enough to drive that motor. You'll need a power transistor or a relay to drive that thing, most likely.

You might also want to consider a switch to detect the position of the plunger at the extremes of its travel, so you don't have to rely on timing to get the cycle correct.

Right now all I've done is replaced the safety switch with a relay. Power is still supplied from the main batteries and the button is used to cycle from safety to on. In the future the plan is to figure out how to add additional fire modes like semi-auto, triple-shot, etc.

[azrael]

WIP threeads aren't generally allowed so this probably won't stay open for too long, but cool I guess?
I don't know that a switch to detect plunger travel will work all that well, maybe an IR sensor? That's how I would do it.

There's been other builds that use Arduinos for ammo counting, so it's not the first "Arduino powered" mod.

[Papkee]

WIP threeads aren't generally allowed so this probably won't stay open for too long, but cool I guess?
I don't know that a switch to detect plunger travel will work all that well, maybe an IR sensor? That's how I would do it.

There's been other builds that use Arduinos for ammo counting, so it's not the first "Arduino powered" mod.

That's my biggest issue right now, figuring out how to count the shots. IR seems to make the most sense with this gun, but mounting it would present an issue (air loss)

And I know it's not the first blaster to be arduino powered, but as far as I can tell it's the first Stampede.

[azrael]

??
Where the heck are you thinking of mounting it? Haha.
If you're thinking about the barrel, it doesn't really matter if you seal it right. Besides, any "air loss" argument is moot if you haven't done a full seal bolt/barrel setup with something like brass, anyway. Tons or air being lost from that big old plunger in that case.

also, this.
https://www.google.c...lient=firefox-a

[Zorns Lemma]

It seems like you have a lot of issues you need to iron out during the build which is primarily why we don't allow build logs here.

[Papkee]

Well google lied to me then. >:|

But I suppose mine is a lot more compact than the top result. As for your other question if air is meaningless here then there's a nice empty space below the barrel perfect for a small sensor. Figure if I seal it up with some acrylic there shouldn't be too much of a loss.

And Zorn, you can close the topic if you'd like. I wasn't aware that logs were extremely erotic here.

[azrael]

Well google lied to me then. >:|

But I suppose mine is a lot more compact than the top result. As for your other question if air is meaningless here then there's a nice empty space below the barrel perfect for a small sensor. Figure if I seal it up with some acrylic there shouldn't be too much of a loss.

And Zorn, you can close the topic if you'd like. I wasn't aware that logs were extremely erotic here.

I just don't understand how there isn't TONS of space. You only need a 5mm IR LED and a 5mm phototransistor. That's tiny. There's plenty of places to mount them that will register a complete cycle, if you add the correct delay to allow for spring return and such.

[Papkee]

I just don't understand how there isn't TONS of space. You only need a 5mm IR LED and a 5mm phototransistor. That's tiny. There's plenty of places to mount them that will register a complete cycle, if you add the correct delay to allow for spring return and such.

I know! All the pictures I've seen have been crazy messes of wires taped to the sides. This gun is one of the most spacious I've seen, which is the main reason I chose it.

[Langley]

The trigger switch IS a cycle sensor. When the stampede is stock, there is a cam that depresses the trigger switch and keeps power flowing to the motor when the plunger tube is not fully cocked. I think it keeps the gun from getting stuck in a partially cocked position, or maybe it keeps the bolt sled out of the way so you can remove the mag. The trigger ALSO closes this switch, but if you remove the trigger and wire the switch up as a sensor input to your arduino instead of having the switch in series with the motors and battery, you can count the cycles.

[Papkee]

The trigger switch IS a cycle sensor. When the stampede is stock, there is a cam that depresses the trigger switch and keeps power flowing to the motor when the plunger tube is not fully cocked. I think it keeps the gun from getting stuck in a partially cocked position, or maybe it keeps the bolt sled out of the way so you can remove the mag. The trigger ALSO closes this switch, but if you remove the trigger and wire the switch up as a sensor input to your arduino instead of having the switch in series with the motors and battery, you can count the cycles.

You seem to know your way around the stampede. How would I wire it if I wanted to keep the trigger in? Would simply soldering two leads to the wires coming from the switch to the motor give me the same cycle detection?

[snakerbot]

The stampede's trigger cam thing is there to make sure the bolt is always open when at rest. Pulling the trigger pushes against the orange L-shaped cam behind it. Without the cam, as long as the trigger is pulled, the switch would remain closed, but if you release the trigger before the bolt has completed a cycle, then the problem would be that the motor stops right then and there. The cam works because when the bolt is forward, it also pushes the cam down, keeping the switch closed. Once the cycle has completed and the return spring is finished pushing the bolt back, then the cam moves up and releases the switch, turning off the motor. Unless the trigger is still held down, in which case the process starts anew.

I would imagine that you don't want the trigger to have anything to do with the mechanical parts of the fire control after your mod. You'll want the trigger to hit a switch which tells the arduino to do something. Keep the cam and the switch behind it in place, but mod the trigger so that it doesn't move the cam. Then wire a relay in parallel with the cam switch. So pull trigger, signal is sent to arduino, arduino closes relay, which starts motor going. Keep the relay closed for however many shots you want fired, then open it. The bolt is still partially forward at this point, so the bolt is pushing the cam down, keeping the motor running until it has finished its current cycle, even though the relay is closed.

Keep in mind that I'm a mechanical engineer, not electrical, so what I'm describing probably isn't the most efficient setup, but I do believe that it will work.

[Langley]

Keep the cam and the switch behind it in place, but mod the trigger so that it doesn't move the cam. Then wire a relay in parallel with the cam switch.

If the Arduino controls the relay, you could just as easily wire up the cam switch as a sensor, and program the arduino to keep the relay open IF the trigger switch OR the cam switch are closed. This would keep the bolt from stopping in a closed position, and it would allow you to count the number of times the cam switch as flipped from closed to open. That's the number of shots you've fired (if not the number of darts that have actually left the barrel)

[azrael]

I would probably use a transistor like a BS170 to drive the relay, and have the Arduino control that. If it's 5V logic (Never used the UNO) then just use 5V relays and power the BS170 with 5V.

[Papkee]

I've already ordered the relay. It's specially-made for the arduino so I'm good there. I was thinking if I soldered two wires to the motor leads and wired them as a sensor (of course limiting the current to acoid frying the arduino), then the arduino would be able to sense whenever the motor is activated. Then it could open and close the relay according to how many shots need to be fired. (boy, this code is adding up fast)

I'm guessing this will all be trial and error on my part. I'm probably going to try all of your methods and see which one works best.

[Papkee]

Also, here's the rough code I've written so far.

const int button = 1;
const int led = 3;
const int relay = 5;
int safety = 1;
int ledstate = 1; // LED is solid, safety on
int leddelay = 1000; // Time between LED blinks
int ledon = 10; //Time the LED is on
long previousMillis = 0;

void setup() {
  pinMode(button, INPUT); // Just a button
  pinMode(led, OUTPUT); // Just an LED
  pinMode(relay, OUTPUT); // Output to relay for safety switch
  digitalWrite(button, HIGH); // Use internal pullup resistor
  safety = 1; // Turn safety on
}

void loop() {
  
  // BUTTON CODE
  if (digitalRead(button) == LOW) {
    if (safety == 1) {
      safety = 0;
    }
    else {
      safety = 1;
    }
  }
  
  // MAIN VARIABLE HANDLERS
  if (safety == 0) { // If the safety is off
    ledstate = 0; // Blink the LED
    digitalWrite(relay, HIGH); // Close the Relay, safety is officially off
  }
  else {
    ledstate = 1; // LED is solid
    digitalWrite(relay, LOW); // Open the relay, safety is on
  }
  
  // LED FLASH CODE
  if (ledstate == 0) {
    unsigned long currentMillis = millis();
    if(currentMillis - previousMillis > leddelay) {
      // Reset the timer
      previousMillis = currentMillis;
      
      // Turn on the LED
      digitalWrite(led, HIGH);
      
      // Keep the LED on until the ledon time is over
      if(currentMillis - previousMillis > ledon) {
        
        // Reset the timer again
        previousMillis = currentMillis;
        
        // Turn the LED off
        digitalWrite(led, LOW);
      }
    }
  }
}

For those of you who are programmers, anything seem wrong here? It compiles okay.

[roboman]

I've done something similar with an arduino, using a push button as a mode switch of sorts. You're definitely going to want to set up that button as an interrupt, so that it stops the program and executes the section of code that changes the mode from safe to shoot. Otherwise, it'll be very hit-or-miss, so to speak, and may not reliably switch modes.

[Zorns Lemma]

For those of you who are programmers, anything seem wrong here? It compiles okay.

I've never done anything with an Arduino but I know plenty of C and this code looks just like C. I'm assuming some of the Arduino library functionality from your comments but here are some suggestions:

  // BUTTON CODE
  if (digitalRead(button) == LOW) {
    safety = !safety // @ZL: This is a much easier way to toggle a boolean since !0 = 1
  }

  // LED FLASH CODE
  if (ledstate == 0) {
    unsigned long currentMillis = millis(); // Declare this variable outside loop
                                            // so you don't reallocate memory all day

    if(currentMillis - previousMillis > leddelay) {
      // Reset the timer
      previousMillis = currentMillis;
      // @ZL: You're storing an unsigned long into a long here ^ ?
      //If you're expecting to overflow the long with your millis() the make previousMillis unsigned

There is also a problem with your loop, if I'm correct in assuming millis() just pulls in current circuit system time.

Currently your code doesn't turn the LED off, since the conditional to turn it off occurs inside the conditional to turn it on. If you simply move it outside, then you will never turn the LED on, since every 10 ms you will be repeatedly turning the LED off. You should only check to turn the LED on if it is already off, or turn it off when it is already on.

Here's my version, with different variable names to make things unambiguous and easier for myself:

// SOMEWHERE OUTSIDE loop()
  LED_is_on = (digitalRead(led) == HIGH);   // reads the current LED status
                                            // might be unnecessary if the LED always starts off
// IN loop()
  // MAIN VARIABLE HANDLERS
  ledstate = safetyOn; // I'm not sure why you have an ledstate variable if it just always
                        // takes on the value of safetyOn but sure w/e
  if (safetyOn) { // 0 is false, nonzero is true, so if(x == 0) is redudant
    digitalWrite(relay, LOW);
  }
  else {
    digitalWrite(relay, HIGH);
  }
  
  // LED FLASH CODE
  if (!ledstate) { //Remember, if(x) is same as if(x<>0), if(!x) is same as if(x==0)
    now = millis()
    if (LED_is_on && (now - lastTime) > LED_blinkFor) {
        lastTime = now;
        LED_is_on = 0;
        digitalWrite(led, LOW);
    } else if (!LED_is_on && (now - lastTime) > LED_nextBlink) {
        lastTime = now;
        LED_is_on = 1;
        digitalWrite(led, HIGH);
    }
}

Edit: My point about the LED toggle not functioning properly may be invalid if hardware limitations and code execution delay means that you will actually cover 10 ms of real-time while executing within one conditional. So your original code might work, but relying on hardware limitation for software functionality is pretty poor practice.

Edited by Zorn's Lemma, 26 June 2013 - 09:41 PM.
I used "then" as a variable so that code definitely wouldn't compile

[Langley]

I've done something similar with an arduino, using a push button as a mode switch of sorts. You're definitely going to want to set up that button as an interrupt, so that it stops the program and executes the section of code that changes the mode from safe to shoot. Otherwise, it'll be very hit-or-miss, so to speak, and may not reliably switch modes.

For what he's doing it shouldn't be a problem. He's not using the delay function anywhere, and there's nothing going on inside the loop that would hold things up. It wouldn't be a terrible idea, but if he's depending on us to debug is code without interrupts, he's going to have a hard time using them.

Edit: Incidentally, Work in Progress threads aren't allowed here. This sort of thing shouldn't really be posted until it's done. However, we're usually cool with threads asking for help if you are clear and provide photos and enough info to go on, so for now, I'm handling this as a help thread.

[Papkee]

Here's my version, with different variable names to make things unambiguous and easier for myself:

// SOMEWHERE OUTSIDE loop()
  LED_is_on = (digitalRead(led) == HIGH);   // reads the current LED status
                                            // might be unnecessary if the LED always starts off
// IN loop()
  // MAIN VARIABLE HANDLERS
  ledstate = safetyOn; // I'm not sure why you have an ledstate variable if it just always
                        // takes on the value of safetyOn but sure w/e
  if (safetyOn) { // 0 is false, nonzero is true, so if(x == 0) is redudant
    digitalWrite(relay, LOW);
  }
  else {
    digitalWrite(relay, HIGH);
  }
  
  // LED FLASH CODE
  if (!ledstate) { //Remember, if(x) is same as if(x<>0), if(!x) is same as if(x==0)
	now = millis();
    if (LED_is_on && (now - then) > LED_blinkFor) {
        then = now;
        LED_is_on = 0;
        digitalWrite(led, LOW);
    } else if (!LED_is_on && (now - then) > LED_nextBlink) {
        then = now;
        LED_is_on = 1;
        digitalWrite(led, HIGH);
    }
}

Edit: My point about the LED toggle not functioning properly may be invalid if hardware limitations and code execution delay means that you will actually cover 10 ms of real-time while executing within one conditional. So your original code might work, but relying on hardware limitation for software functionality is pretty poor practice.

What I'm doing is setting small timers to avoid using the delay() function and stopping everything. It's starting a timer with millis(), then using the duration variable to compare to the elapsed time. Although I do see the memory issue; it would make more sense to reset the timer to 0 every time.

For what he's doing it shouldn't be a problem. He's not using the delay function anywhere, and there's nothing going on inside the loop that would hold things up. It wouldn't be a terrible idea, but if he's depending on us to debug is code without interrupts, he's going to have a hard time using them.

Edit: Incidentally, Work in Progress threads aren't allowed here. This sort of thing shouldn't really be posted until it's done. However, we're usually cool with threads asking for help if you are clear and provide photos and enough info to go on, so for now, I'm handling this as a help thread.

You guys have given me plenty of help in this thread so technically it IS a help thread.

[Zorns Lemma]

What I'm doing is setting small timers to avoid using the delay() function and stopping everything. It's starting a timer with millis(), then using the duration variable to compare to the elapsed time. Although I do see the memory issue; it would make more sense to reset the timer to 0 every time.

I think I understand your code better than you. Like I've said, I've never read the Arduino SDK docs, but I can figure out what millis() or delay() do/would do. Do you see why your original code here doesn't actually cause the LED to flash?

  // LED FLASH CODE
  if (ledstate == 0) {
    unsigned long currentMillis = millis();
    if(currentMillis - previousMillis > leddelay) {
      // Reset the timer
      previousMillis = currentMillis;
      
      // Turn on the LED
      digitalWrite(led, HIGH);
      
      // Keep the LED on until the ledon time is over
      if(currentMillis - previousMillis > ledon) {
        
        // Reset the timer again
        previousMillis = currentMillis;
        
        // Turn the LED off
        digitalWrite(led, LOW);
      }
    }
  }

[Hammy]

I just realised that TODO means to do I thought it meant Toe, Doe

OK if you use a tranny to on/off a relay, don't forget the protection diode, as the reverse voltage induced by the relay coil on switching off the relay, could be enough to f the transistor.

[Papkee]

Alright, this project is still in business. It was a mistake to order a $5 soldering iron as the tip died after two days. I'm still waiting on batteries and a few other small parts, and I'm probably going to recode the software entirely.

@Zorns Lemma: I think I do. Is it because the function only runs when the led is off and therefore can never turn it on.

Progress is slowly being made (mostly because I put the gun in my closet and forgot about it) so expect to hear from me soon with new updates.

[Oryhara]

Completing the safety circuit as a means of firing the stampede is going to be unreliable. If the power to the motor is cut before the firing cycle is complete, you could have a dart in the breech, and one at the top of the magazine, which the breech attempts to chamber when you resume firing.
I did this once when installing a stampede in briefcase, and if you didnt fire the entire magazine, you had serious problems with jamming due to the firing cycle being partially completed.

The best way remotely(via arduino) actuate a stampede is to use the circuit that hasbro designed that mechanically ensures that the firing cycle is complete. Inside the stampede, there is a SPDT(single Pull Double Throw) switch that is pressed down by a lever and then held in that position by a part of the breech until the breech returns to the full rear position.

The two throws of this switch go to the motor and the firing circuit, while the center connects to the other lead of the motor. WHen this switch is in the 'off' position, it will form a closed loop with both leads of the motor, devoid of power, effectively providing a brake to the motor.
In the other position, this switch will complete a circuit with the motor and power source, making the motor spin and firing the stampede.

When I used a relay to drive a stampede, I kept this switch in the control circuit, upstream(logically) of the relay itself. THe relay directly powered the motor, and this switch actuated the relay. However, in order to know when the firing cycle was actually started, I had to wire a pin of the arduino to a part of this circuit downstream of this switch. The arduino then turn on power to the switch, which would in turn power the motor, wait a little bit(10ms or so) then turn off power and see if the switch was being held on. This would indicate that the breech had moved forward enough to engage the switch mechanically, and that kept the relay powered until the firing cycle was completed.

This ensured that the stampede fired a round precisely and reliably.

I'll post code once i go get some pictures of how i did this.

Edit:
Pictures of the switch im talking about above.



I was unsatisfied with the final product when i finished this project in march, and it has since been scrapped for parts(the arduino, LCD display, AR15 Grip), or I would provide a firing video.
It was a while ago that i designed this, but if memory serves, I wired the top (right as pictured) pole of that switch to the arduino, the middle goes to the relay control pin, and the lower pole to ground. My relay board was low active, so during the firing cycle, when the breech forces the middle and lower pins to connect(second picture), the relay is held active, regardless of the arduino's input. The line going to the relay also goes to another pin on the arduino, as the sensor for when the firing cycle is complete, but this is not strictly neccessary for your application.

Edited by Oryhara, 11 August 2013 - 05:23 PM.