Go Down

Topic: Arduino Lightsaber (Read 83596 times) previous topic - next topic

billpealer

#1080
Nov 18, 2016, 05:28 am Last Edit: Nov 18, 2016, 06:14 am by billpealer
atron,  PM me and we can take it on with small bites. i am not at my PC till monday. I have a test set up currently wired and we can plug your code into it then.

on a side note.  I have mastered the ADXL335,for swings.

not as bad as I thought.  but I can't get reads that can detect clash, or "tap" as it's called by the vernacular.  it has to do with the comparison sample rate. a tap happens fast 25-50ms, and my sample rate is about 50ms, so it literally misses taps.  i am working on it.

I suspect that is what nesweek is using for sensorless clash.  not manual acceleration comparison, but tap detected interrupts that are prebuilt into the 345, and the 6 Axis jobber that is going around. anyone want to comment on that hypothesis?

I am tho, very close to button less lockup using a novel sound file approach and the 335.  very smilar to the novel "all sounds have hum at the end" method, that i am pretty sure is being used by the elites here.   I will share and donate to the thread when I have some videos to put my money where my mouth is. the logic combined with the custom sound files to make it run may surprise a few here.  it didn't impress my wife.  i am hoping a few of you may appreciate it.  if (when) i get it to work, I foresee button less blaster deflection with choreographed yawing.  example... when  saber is horizontal and not swinging and detects yaw acceleration resolving to an abrupt lack of movement... play lazer bounce sound. this visually would look like rotj, scene where Luke is deflecting speeder bike fire. envision "punching" with the saber without swinging it.  the adxl335 can 100% discern the difference tween that movement and a swing.

as far as clashes with no clash sensor and JUST the 335....

I think I may have to wire it up to a saber and actually smack it , while in the hilt, to see if the values can prove discernible tween swing and tap.  having a few decimeters of cable on the 335 is a bad bench test.

the adxl345 has tap detection but wires a bit differently than the 335 and code requires .h libraries which I have an aversion to.. have seen example sketches for the 345 that are 400+ lines long just for tap / double tap .  wow!

anyone using the 345?

billpealer

#1081
Nov 18, 2016, 05:59 am Last Edit: Nov 18, 2016, 03:17 pm by billpealer
Tron, 

do the "Arduino Switch " tutorial.  debounce switch code is for toggling.  I only use it on my rollerball tilt sensors.  because without it, it would play a swing sound over and over if left in a static position. like a horizontal hold or a parry 8.

for the on/off single button code,  (thanks Jake) I use a simple bool condition.

and I could be reading your code wrong but it looks like your clash sensor is pin2 but your interupt is pin0.  shouldn't it be 2?    pin 2 is the Nano interrupt pin.

for the adxl335 you should simply be sampling the xyz values, reading and saving new/old values, measuring their difference and if said difference is within your movement threashhold , play swing sound. 

JakeSoft

#1082
Nov 18, 2016, 08:55 pm Last Edit: Nov 18, 2016, 08:57 pm by JakeSoft
Secondly I'm having trouble getting the interrupt for the clash sensor to work. Without the interrupt the clash sensor triggers the clash sound normally, but it just doesn't trigger nicely when combined with the accelerometer. Using the interrupt solves the problem with the accelerometer, but then something else happens, it's almost like the clash sensor interrupts itself when triggered repeatedly.

Code: [Select]
const int CLASHSENSOR = 2;

const int WT588D_DATA = 12;

void setup() {
 
  attachInterrupt(0, detectClash, LOW);

  pinMode(CLASHSENSOR, INPUT);
  digitalWrite(CLASHSENSOR, HIGH);

  pinMode(WT588D_DATA, OUTPUT);
  digitalWrite(WT588D_DATA, HIGH);     
  playSound(0x8);                     

}

void loop() {

}

void detectClash(){
  playSound(3);
  delay(500);
}

void playSound(byte addr){               
 
  digitalWrite(WT588D_DATA, LOW);
  delay(5);
  for(int i = 0; i < 8; i++){
    digitalWrite(WT588D_DATA, HIGH);
     
    if(bitRead(addr, i)){
      delayMicroseconds(600);
      digitalWrite(WT588D_DATA, LOW);
      delayMicroseconds(200);
    }else{
      delayMicroseconds(200);
      digitalWrite(WT588D_DATA, LOW);
      delayMicroseconds(600);
    }
  }
 
  digitalWrite(WT588D_DATA, HIGH);
  delay(2);
}

 





I encourage you to keep trying to figure things out. You'll be better off in the long run and able to build saber code that is exactly as you like (the entire point of going down the Arduino route, IMO). With that said, the Universal Saber Library has examples of what you're trying to do that you may be able to study and gain insight from. The SimpleMotionManager class does clash interrupt handling.

One thing I noticed is that you have a delay in your ISR (the detectClash() function) and you are also playing a sound directly from there. You don't generally want to do that. You want your ISR to get in and get out as quickly as possible. Instead of playing the sound directly from the ISR, have the ISR set a global variable and then have your loop() function check for this variable and clear it after playing the sound.

Remember that in practice, with those impact switches the interrupt will be triggered 5 or 6 times in less than 50 ms during a clash as it rattles back and forth before it settles. You don't want to attempt to play a sound on every single one of those, just the first one and ignore the others.

T_R_O_N

Thanks for the advice Jakesoft!

I was able to figure it out, and the clash interrupt is working marvelously. I'll have a look at the universal saber library now that I'm mostly done with the first version of my code. The reason that I didn't look at the library earlier is because I wanted to try and figure things out for myself first, that way I could have a better understanding of how everything works and functions together. I remember you said you want to teach people how to fish, and I really want to learn!

@Billpealer

That 0 is the direct interrupt number, on the arduino nano it corrisponds with pin 2. Using the 0 like that isn't wrong, and everything works, but as I've read in the description of the attachInterrupt() function, using the direct interrupt number isn't always the best way to do it. A better option, instead of just typing the direct interrupt number, is to use the function digitalPinToInterrupt(). When you pass the pin number as an argument to digitalPinToInterrupt() it returns the direct interrupt number. This preforms essentially the same task as just typing the direct interrupt number, but now the code is more readable, and you wont get errors when running the sketch on an arduino that has different direct interupt numbers for its pins.

So then the code in my sketch would look like this: attachInterrupt(digitalPinToInterrupt(CLASHSENSOR), detectClash, LOW);
instead of this: attachInterrupt(0, detectClash, LOW);

JakeSoft

Thanks for the advice Jakesoft!

I was able to figure it out, and the clash interrupt is working marvelously. I'll have a look at the universal saber library now that I'm mostly done with the first version of my code. The reason that I didn't look at the library earlier is because I wanted to try and figure things out for myself first, that way I could have a better understanding of how everything works and functions together. I remember you said you want to teach people how to fish, and I really want to learn!

@Billpealer

That 0 is the direct interrupt number, on the arduino nano it corrisponds with pin 2. Using the 0 like that isn't wrong, and everything works, but as I've read in the description of the attachInterrupt() function, using the direct interrupt number isn't always the best way to do it. A better option, instead of just typing the direct interrupt number, is to use the function digitalPinToInterrupt(). When you pass the pin number as an argument to digitalPinToInterrupt() it returns the direct interrupt number. This preforms essentially the same task as just typing the direct interrupt number, but now the code is more readable, and you wont get errors when running the sketch on an arduino that has different direct interupt numbers for its pins.

So then the code in my sketch would look like this: attachInterrupt(digitalPinToInterrupt(CLASHSENSOR), detectClash, LOW);
instead of this: attachInterrupt(0, detectClash, LOW);
We've got a quick learner here. That's exactly right! Nice fish'n. :-)

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy