Tank airsoft gun control

Hi @zefd,

   Debugging a piece of code by just looking at it, especially when it includes interactions with sensors, motors, etc. is always tricky, so I hope you won't mind if I make a suggestion for you to try.

Think about dividing your programme into 'sections', utilising functions, and test out each function separately, before combining them into a final programme that performs the whole task.

(If you are not familiar with functions, then there are lots of tutorials on the web, and it is an essential tool to be familiar with. Feel free to post a new question, if you get stuck.)

------------------------

I know nothing about guns, so you may need to adapt my suggestions below, but looking at your intro, perhaps you could start by creating a new test program, whose only task (excepting Serial prints) is to "load" the gun.

As I am not familiar with the exact wiring, timing, etc. of your system, I will just provide a crude pseudocode example, which you will need to convert it to 'real' C++ code, using your knowledge and experience of your system:

void function loadGun ( ?parameters if needed? ) {

  // add in code to perform load action

}

// ------------------

void setup () {

  // set pins to output or input   (I'll only show one line as a placeholder for you copy as many as needed ....
  pinMode(motorIn1, OUTPUT);    //motor control, on/off ...etc. ... (adjust as necessary, etc.)

  Serial.begin(9600); // Start serial communication (optional, for debugging)
  delay(1000); //Delay to allow system to stabilize

  Serial.println("Loading gun in 1 second");

  delay (1000);

  // call loadGun function to load gun

  loadGun (?arguments if needed?);

  Serial.println("gun loaded");

}

//----------

void loop () {

   // nothing to do

}

------------------------

Note, it calls the function loadGun() just once in setup(), as the entire programme task.

Test this mini-programme, and make sure it performs the task correctly.

------------------------------------

Now, I assume that running this programme will leave the gun 'primed' and it should fire, if an appropriate second programme is subsequently executed. So write and test a comparable programme to fire the gun. Perhaps the pseudocode version might be something like:

void function fireGun ( ?parameters if needed? ) {

  // add in code to perform 'fire' action, assuming gun is already loaded, when this programme is executed

}

// ------------------

void setup () {

  // set pins to output or input
  pinMode(motorIn1, OUTPUT); //motor control, on/off etc. ... (adjust as necessary, etc.)

   Serial.begin(9600); // Start serial communication (optional, for debugging)
  delay(1000); //Delay to allow system to stabilize

  Serial.println("Firing gun in 1 second");

  delay (1000);

  // call load function to fire gun

  fireGun (?arguments if needed?);

  Serial.println("gun fired");

}

//----------

void loop () {

   // nothing to do

}

Assuming this code now performs the expected task, you have two functions, loadGun() and fireGun(), which, importantly, you know perform the required sub-tasks.

Hence, create a third programme, which includes both of these two functions, and calls them in a convenient consecutive manner. If you are careful to use copy and paste, without modifying the code, of these functions, then any 'problems' with this new programme, should be confined to the code outside the function definitions, which should simplify tracing the issue(s).

--------------

You may note in my pseudocode examples, I have moved all the active code into setup(), leaving loop() with nothing. I suggest the 'first' version of your programme follows the same style, so that you can concentrate on getting the gun to load and fire correctly just once.

When you have a version of code that achieves this aim, you may wish to make use of loop(), to create a fourth programme that can fire multiple times.

------------------------------------

Sorry, this is not a simple 'change line 7 to ...' type of fix. Perhaps someone else will provide one?

However, it is a description of the kind of approach I would make, if I was writing and/or debugging the code on my bench, so hopefully it is also an introduction to an approach you can use in the future.

---------------------

Of course, if you hit a problem with creating and debugging any of these simplified programmes, feel free to ask another question.

Good luck and best wishes, Dave

@zefd,

To pulse the motor, I am using a pulse-in from an RC receiver. I have the ardunio uno seeing the signal. But not able to get the signal to the pulse motor to shoot.

I see a few issues here.

First, GPIO pin 5 is used for input from the RC signal. How that is performed isn't clear but I'm going to assume it is working.

const int Trigger = 5;  // Define the pin for the RC receiver signal

void setup() {
    //...
    pinMode(Trigger, INPUT);    // RC input pin
    //...
}

For each iteration of the loop function, the input is read using the Arduino pulseIn function

void loop() {
    // Read the PWM signal duration,
    // Timeout 30ms 30000
    int duration = pulseIn(Trigger, HIGH, 10000);

    //...

(Note: the inaccurate timeout comment )

The pulseIn function waits up to 10000 microseconds for the Trigger signal to go from LOW to HIGH. pulseIn returns the length of the pulse (in microseconds) before the signal went back to LOW or 0 if no pulse started before the 10 msec timeout.

Note that after the call to pulseIn, no more than 10 msecs have passed and the value of Trigger is LOW. (not accurate but the nominal case I think)

The value of duration is checked against the threshold value (1.5 msec). If it's above the threshold the cannon (Trigger2) should fire. Except, it tries to do more than that.

// Check if the duration is within the threshold
if (duration != 0 && duration > threshold) {
    // Trigger PWM signal goes high to fire
    digitalWrite(Trigger, HIGH);
    digitalWrite(Trigger2, HIGH);
    Serial.println("Trigger ON");
    Serial.println("Trigger2 ON");
} else {
    //...
}

(Note: the comment is inaccurate. The check is if the duration is above the threshold.)

The issue is the code tries to set the Trigger from LOW to HIGH. But Trigger is an INPUT not an OUTPUT pin.

If the duration is at or below the threshold then it tries to set Trigger LOW

if (duration != 0 && duration > threshold) {
    //...
} else {
    digitalWrite(Trigger, LOW);
    Serial.println("Trigger OFF");
}

which is not possible. Note Trigger pin is already LOW.

The remainder of the loop deals with the motor so we can ignore it.

So, the loop takes ~10 msec to run. Without knowing how the Trigger pin is connected to the RC input I can only assume that it does function somehow.  Assuming is does work it looks like the it will set Trigger2 but never reset it. So, when the gun fires it won't stop.

@davee has given an outline of how you might want to structure the code so you can test individual operations. I would recommend doing that.

- Tim

Thanks for the great suggestions. I will be working on them. I thought I would post some photos as a reference that may help with more suggestions. I am including the small test codes I used. What I think happened was that the individual test codes worked correctly, but when integrated into the larger code, they were messed up. 

[code]
//Tank gun cycle code 

//pin assignments ardunio
const int motorIn1 = 3; // high to turn on motor forward
//const int motorEnA = 6; //motor speed pin, not used connect to high
const int CycleStop = 2; // interrupt (Int0)
int CycleSState = 0; // variable for reading the Cycleswitch status

void setup() {
  // set pins 
  pinMode(motorIn1, OUTPUT); //motor control, on/off
  //pinMode(motorEnA, OUTPUT); // uncommet if using speed control
  pinMode(CycleStop, INPUT_PULLUP); // cycle stop switch, normally high, button triggers low to stop cycle
  Serial.begin(9600); // Start serial communication (optional, for debugging)
  //delay(3000); //Delay to allow system to stablize
}

void loop() {
  
  //Controlling speed (0   = off and 255 = max speed):     
  //analogWrite(6, 255); //ENA pin

    // read the state of the cycle button value:
  CycleSState = digitalRead(CycleStop);

 if (CycleSState == HIGH){ // check CycleStop status
  digitalWrite(motorIn1, HIGH); // motor on, cycle switch off
  Serial.println("CycleStop OFF");
  Serial.println("Motor On");
  
 } else {
  digitalWrite(motorIn1, LOW); // motor off, cycle switch on
  Serial.println("CycleStop ON");
  Serial.println("Motor OFF");
 }


}
[/code]

[code]
// RC signal test code
// Define the pin for the RC receiver signal
const int inputPin = 2;

// Define the pin for the LED control
const int LED_Pin = 13;

// Define a threshold value for the PWM signal (adjust based on your RC receiver)
const int threshold = 1500;  // Example value (adjust as needed)

void setup() {
  // Set the LED pin as an output
  pinMode(LED_Pin, OUTPUT);
  // Start serial communication (optional, for debugging)
  Serial.begin(9600);
}

void loop() {
  // Read the PWM signal duration
  int duration = pulseIn(inputPin, HIGH, 30000); // Timeout 30ms

  // Check if the duration is within the threshold
  if (duration != 0 && duration > threshold) {
    // Turn the LED ON
    digitalWrite(LED_Pin, HIGH); 
    Serial.println("LED ON");
  } else {
    // Turn the LED OFF
    digitalWrite(LED_Pin, LOW); // 
    Serial.println("LED OFF");
  }
}
[/code]

Hi @zefd,

What I think happened was that the individual test codes worked correctly, but when integrated into the larger code, they were messed up.

  Sorry, if I am unnecessarily overemphasising one of my points, but I feel it is one that many people find tricky to comprehend at first, and of course I can't have a simple face-to-face conversation to find out how much you already know and how much of my sermon was understandable. So please accept my apologies if I am explaining what you already know.

----

I deliberately recommended putting each 'action', like loadGun() or fireGun(), into an independent function that can be called in the main programme flow as a simple function call, without having to worry about integrating the individual lines of the respective function.

The point being, the content of each such function becomes a tested block, whose content is 'sealed'. Thus, when it is copied to the later main programme, it should still behave in the same way as it did in the original mini-test programme that it was developed in.

Whilst this 'workflow' is far from impregnable, it is usually an order of magnitude more robust than simply copying a few lines of code from one programme to another. 

If dividing your code into structured blocks, like these functions, is new to you, then you may find it challenging at first, but with a little practice, it will become much clearer, and you will realise how much it helps.

Best wishes and good luck, Dave

@davee I understand what you are saying, I am currently working on putting the test programs into functions. I have a little practice with functions, but still learning.

Somehow the photos didn't get included.

Hi @zefd,

  A few comments about your circuit.

• The red wire from the 12V battery is shown connected to the +5V pin of the Arduino and the RC receiver ... probably just a drawing error, but you might like to update it.

• Your Cycle stop switch is relying on the Input_Pullup of the Arduino chip. This may actually work, but the internal pull-up source is roughly equivalent to a rather high value resistance, whose value is only loosely defined with many microcontroller chips. This makes the circuit vulnerable to stray electrical noise pulses, etc. I would always advise adding an external pull-up resistor, usually with a value in the range 1kOhm to 10kOhm. Resistor to be connected between your 'yellow wire' and +5V output from the Arduino.
  • The Input_Pullup facility is provided by the microcontroller manufacturer, to save the cost and PCB (printed circuit board) space of an external component, is provided for situations like a circuit configuration switch or jumper mounted on the PCB, physically very close to the microcontroller, so the chance of stray electrical pick up is very small, and the switch/jumper is never operated or changed, after the initial manufacturing configuration and testing phase. Relying on it for external switches, possibly connected by wires, and operated in normal use, is risking intermittent fault problems.

• In addition, most mechanical switches suffer from 'switch bounce' such that they make and break several times when actuated to close. Again, this may not be a problem in your case, but it is better to be aware and armed with a solution if it shows up. These bounces typically last for a fraction of second, during which time the microcontroller may 'see' both high and low levels, and the programme may attempt to respond to both cases, causing a confused result. A capacitor, often around 100 microFarads, connected between your 'yellow wire and ground', will rapidly discharge when the contacts touch, and continue to hold the pin low for a period of time, whilst the contacts momentarily separate, thus 'removing' the momentary 'highs'. The actual value of the capacitor may need adjusting for the particular circuit, etc. 
  • If the value is too high, it will tend to delay the time the circuit recognises that the switch is legitimately open.
  • If the value is too low, it may not mask all the bounces.

• An 'economy' box of mixed values of electrolytic capacitors is a handy resource for such occasions!

Best wishes and good luck with using functions in your code, Dave

@davee Thank you for pointing out the wiring error, it is now fixed. The cyclestop switch doesn't seem to suffer from switch bounce, but as a precaution, I will add the 100uf cap. The pull-up resistor seems to work, but I may add the external one to be safer. There is a lot of noise coming from the other electronics. What is not on the wiring photo is that I added filter caps on all power lines.

@zefd 

The schematic helped to bring the project into focus for me. If you have the component parts list, that would be a great help as well. There are two parts that I'm unfamiliar with; (I lie. I'm not familiar a ton pf parts.) The IR receiver and the airsoft mechanism.

IR Receiver

Have you selected this part already?

I've assumed that this is a receiver similar to the one Dave uses in RC Robot Car - RC Controls and Arduino. I'm not familiar with this component so I put on my learning hat and looked into it. As I understand that component, the radio signal is separated into multiple channels, each channel providing an analog input value. Depending on the component, the channels are broken out into separate connections and there is one connection that has a PWM or PPM signal. (Pulse Width or Position Modulation). This looks like the signal that the posted code uses.

The use of the PWM/PPM signal seems unusual to me. The PWM/PPM sends all the channel values on a single wire. The PWM sends a separate PWM signal for each channel while the PPM signal combines the channels into a more compressed form. However, the posted code doesn't read the channel values but uses channel signal duration to control firing the gun. I infer this is meant to simulate an irregular firing pattern instead of a monotonic RAT-A-TAT-TAT ... repeat.

If so, my only observation is that it sets up a "dissonance" between trigger pull and firing. It's interesting though.

Airsoft

Do you have a link to how this component operates? Datasheet or something. It seems like it's similar to a pinball machine spring pull lever.

Re: function decomposition.

If you are having trouble with that then don't struggle, just shout out and I can walk you through it.

@tfmccarthy The RC (radio control) is the same as that used in Dave's video. My unit is a 6-channel Aerosky (used from a home-built drone years ago). I am not sure how to explain about how the uno reads the RC signal. What I understand is that the receiver makes a pulse duration longer or shorter depending on the position of the joystick. The pulseIn() Function reads the longer or shorter pulse and sets a trip point in my case. 

The airsoft unit is from a 1/16 scale tank, and uses a spring to shoot BB. I have no specs other than the motor runs on 6V and the leaf switch(cyclestop) closes when the breach is ready to fire. Pulse the motor, and it pops and shoots.

Posted by: @zefd

↑

I am having a major problem with my project. Background on project: The airsoft gun uses a motor to load a BB. I am using an ardunio uno. When the system powers up, and after a delay. The gun goes into the loading cycle. At the end of a cycle, it closes a leaf switch and stops the motor. Then you pulse the motor and it shoots. In my code, I have the motor working and the leaf switch input to stop the motor. To pulse the motor, I am using a pulse-in from an RC receiver. I have the ardunio uno seeing the signal. But not able to get the signal to the pulse motor to shoot. Could someone look the code over and let me know what I am missing?

[code]
//Tank gun code by ZefD

//pin assignments ardunio
const int motorIn1 = 3; // high to turn on motor forward
const int motorIn2 = 8; // motor control pin 2
//const int motorEnA = 6; //motor speed pin, not used connect to high
const int CycleStop = 2; // interrupt (Int0)
const int Trigger = 5; // Define the pin for the RC receiver signal
const int Trigger2 = 4; // Define second trigger pin
const int threshold = 1500; // Define a threshold value for the PWM signal, start with 1000
int CycleSState = 0;         // variable for reading the Cycleswitch status


void setup() {
  // set pins to output or input
  pinMode(motorIn1, OUTPUT); //motor control, on/off
  pinMode(motorIn2, OUTPUT); // motor control 2
  //pinMode(motorEnA, OUTPUT); // uncommet if using speed control
  pinMode(Trigger, INPUT);  // RC input pin
  pinMode(Trigger2, OUTPUT); // second trigger output to make motor turn for short burst to fire
  pinMode(CycleStop, INPUT_PULLUP); // cycle stop switch, normally high, button triggers low to stop cycle
  Serial.begin(9600); // Start serial communication (optional, for debugging)
  delay(1000); //Delay to allow system to stablize
}

void loop() {
  //delay(500); // slow system down
  int duration = pulseIn(Trigger, HIGH, 10000); // Read the PWM signal duration, Timeout 30ms 30000

  if (duration != 0 && duration > threshold) {  // Check if the duration is within the threshold
    // Trigger PWM signal goes high to fire
    digitalWrite(Trigger, HIGH);
    digitalWrite(Trigger2, HIGH);
    Serial.println("Trigger ON");
    Serial.println("Trigger2 ON");
   

  } else {
    digitalWrite(Trigger, LOW);
    Serial.println("Trigger OFF");
  }


  //Controlling speed (0   = off and 255 = max speed):
  //analogWrite(6, 255); //ENA pin

  // read the state of the cycle button value:
  CycleSState = digitalRead(CycleStop);



  if (CycleSState == HIGH) { // check CycleStop status
    digitalWrite(motorIn1, HIGH); // motor on, cycle switch off
    //digitalWrite(8, HIGH);
    //Serial.println("CycleStop OFF");
    //Serial.println("Motor On");

  } else {
    digitalWrite(motorIn1, LOW); // motor off, cycle switch on
    //Serial.println("CycleStop ON");
    //Serial.println("Motor OFF");
  }


}
[/code]

You're setting the input pin Trigger (pin 5) to HIGH. This is wrong.

You should never use digitalWrite on an input pin. You're reading the signal, not writing to it.

I've been working on the code for gun control. As suggested, I placed each section as a function.

I am working on a safety function "Arming_Gun();". The code sees the switch (working on adding debounce).

What I need to figure out is if the switch was left armed when power was turned off. How can the gun cycle and fire be disabled until the switch is set to safe when the power is turned back on?

[code]
// Zef tank gun control

const int Arming_Pin = 12; //Arming button
int ArmingState = 0;  // variable for reading the arming status
const int LED_Pin = 13; // the number of the LED pin
const int motorIn1 = 5; // high to turn on motor forward
const int CycleStop = 2; // interrupt (Int0)
int CycleSState = 0; // variable for reading the Cycleswitch status
const int inputPin = 3; // Define the pin for the RC receiver signal
const int threshold = 1500;  // Define a threshold value for the PWM signal

void setup() {
  pinMode(Arming_Pin, INPUT_PULLUP); // set pin to input
  pinMode(LED_Pin, OUTPUT); //set pin to output
  pinMode(motorIn1, OUTPUT); //motor control, on/off
  pinMode(CycleStop, INPUT_PULLUP); // cycle stop switch, normally high, button triggers low to stop cycle
  Serial.begin(9600); // Start serial communication (optional, for debugging)

}

void loop() {
  Arming_Gun();
  //Gun_cycle();
  //Fire_Gun();
  
}

  int Arming_Gun(){
  // read the state of the pushbutton value:
  ArmingState = digitalRead(Arming_Pin);

  // check if the switch is pressed. If it is, the ArmingState is LOW:
  if (ArmingState == LOW) {
    // turn LED on:
    digitalWrite(LED_Pin, HIGH);
    Serial.println("Gun armed");
    
  } else {
    // turn LED off:
    digitalWrite(LED_Pin, LOW);
    Serial.println("Gun safe");
  }
  }
  int Gun_cycle(){
    // read the state of the cycle button value:
  CycleSState = digitalRead(CycleStop);
  
  // check if the switch is pressed. If it is, the buttonState is HIGH:
 if (CycleSState == HIGH){ 
  digitalWrite(motorIn1, HIGH); // motor on, cycle switch off
  Serial.println("CycleStop OFF");
  Serial.println("Motor On");
  
 } else {
  digitalWrite(motorIn1, LOW); // motor off, cycle switch on
  Serial.println("CycleStop ON");
  Serial.println("Motor OFF");
 }
  }
  int Fire_Gun(){
     // Read the PWM signal duration
  int duration = pulseIn(inputPin, HIGH, 30000); // Timeout 30ms

  // Check if the duration is within the threshold
  if (duration != 0 && duration > threshold) {
    // Turn the LED ON
    digitalWrite(LED_Pin, HIGH); 
    Serial.println("LED ON");
  } else {
    // Turn the LED OFF
    digitalWrite(LED_Pin, LOW); // 
    Serial.println("LED OFF");
  } 
  }
  
  
[/code]

@zefd 

What I need to figure out is if the switch was left armed when power was turned off.

The simple answer is to save the switch state to non-volatile memory (see SPIMemory library) The caution is you need to initialize the state by reading it from memory and save the state every time the switch changes state.

On reflection, however, I'm not convinced this is needed.

How can the gun cycle and fire be disabled until the switch is set to safe when the power is turned back on?

As I understand the design, the purpose of the safety switch is to disable the loading and firing the gun. The leaf switch controls loading the gun from the pellet hopper; it's a pressure switch that's activated by the weight of the pellets in the hopper. If the safety switch is a simple throw switch, then adding it in series with the leaf switch will enable/disable power to the leaf switch and thus control the loading operation. For this you don't need to save the safety switch state.

The firing mechanism is not well defined, but I assume it can be controlled in a similar manner; In both cases the safety switch either opens or closes the circuit for the power to the subcomponents. If there are different power sources for the components then I think this gets a bit more complex.

@tfmccarthy, On the gun mechanism, there is a motor and cam system that pulls back the breach to allow a pellet to drop in. There is a leaf switch set to close when the breach get to full back position. The leaf switch stops the motor just before it fires. If you apply a pulse to the motor, it will fire.