[WIP] Stampede ACB, the Arduino-powered Stampede ECS
#1
Posted 19 June 2013 - 10:53 PM
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)
"But I can't hit with my driver!"
"Just hit with your putter; rules don't define you!" - anonymous
#2
Posted 19 June 2013 - 11:16 PM
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.
Youtube
LS and Retaliator boltsleds are currently available at https://www.facebook.com/RoboM8/
#3
Posted 20 June 2013 - 09:15 AM
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.
"But I can't hit with my driver!"
"Just hit with your putter; rules don't define you!" - anonymous
#4
Posted 20 June 2013 - 11:19 AM
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.
http://nerfscience.blogspot.com/
#5
Posted 20 June 2013 - 12:29 PM
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.
"But I can't hit with my driver!"
"Just hit with your putter; rules don't define you!" - anonymous
#6
Posted 20 June 2013 - 12:55 PM
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
http://nerfscience.blogspot.com/
#7
Posted 20 June 2013 - 06:05 PM
Kruger and Dunning (1999)
#8
Posted 20 June 2013 - 10:25 PM
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.
"But I can't hit with my driver!"
"Just hit with your putter; rules don't define you!" - anonymous
#9
Posted 20 June 2013 - 11:56 PM
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.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.
http://nerfscience.blogspot.com/
#10
Posted 21 June 2013 - 11:20 AM
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.
"But I can't hit with my driver!"
"Just hit with your putter; rules don't define you!" - anonymous
#11
Posted 21 June 2013 - 03:28 PM
You can poop in my toilet anytime champ.
2016 Nerf War Schedule
Bless you, my son. Now recite 3 New Members Guides and 5 Code of Conducts for your sins.
#12
Posted 21 June 2013 - 11:04 PM
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?
"But I can't hit with my driver!"
"Just hit with your putter; rules don't define you!" - anonymous
#13
Posted 21 June 2013 - 11:37 PM
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.
#14
Posted 22 June 2013 - 09:37 AM
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)
You can poop in my toilet anytime champ.
2016 Nerf War Schedule
Bless you, my son. Now recite 3 New Members Guides and 5 Code of Conducts for your sins.
#15
Posted 22 June 2013 - 10:35 AM
http://nerfscience.blogspot.com/
#16
Posted 22 June 2013 - 12:00 PM
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.
"But I can't hit with my driver!"
"Just hit with your putter; rules don't define you!" - anonymous
#17
Posted 22 June 2013 - 01:13 PM
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.
"But I can't hit with my driver!"
"Just hit with your putter; rules don't define you!" - anonymous
#18
Posted 22 June 2013 - 01:17 PM
Youtube
LS and Retaliator boltsleds are currently available at https://www.facebook.com/RoboM8/
#19
Posted 24 June 2013 - 02:26 AM
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
Kruger and Dunning (1999)
#20
Posted 24 June 2013 - 07:13 AM
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.
You can poop in my toilet anytime champ.
2016 Nerf War Schedule
Bless you, my son. Now recite 3 New Members Guides and 5 Code of Conducts for your sins.
#21
Posted 26 June 2013 - 10:38 AM
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.
"But I can't hit with my driver!"
"Just hit with your putter; rules don't define you!" - anonymous
#22
Posted 26 June 2013 - 09:16 PM
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); } } }
Kruger and Dunning (1999)
#23
Posted 26 June 2013 - 10:07 PM
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.
#24
Posted 07 August 2013 - 04:14 PM
@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.
"But I can't hit with my driver!"
"Just hit with your putter; rules don't define you!" - anonymous
#25
Posted 11 August 2013 - 04:46 PM
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.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users