Go Down

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

billpealer

hello everyone:) can anyone make a skecth from this picture. thanks :)
Who ever posted that diagram is probably a hack.  That sketch won't work.

billpealer

Here is another drop of the Universal Saber library. I put a lot of work into this one to ensure it was compatible with the Arduino IDE. Once you properly install the library, all you should have to do is include the library in the usual way from the IDE.

I verified the library works with IDE versions 1.0.5 and 1.6.5r5.

I provided an abstract base class so that motion detection can be interpreted in a more generic way regardless of what hardware is being used. I also added a simple motion manager example that will work with the tilt+clash sensor combo as was used in my Mk II system. (This is how the cheap toys do it.) The clash is interrupt-driven so you will NEVER miss a clash. Ever. There is a long clash de-bounce to prevent double-trigger. (If you are hitting the saber more than once every 100ms then you're The Flash and should be out fighting crime, not spending time here!)

Updates:
1. Added motion detection!
SimpleMotionManager : Detect motion with swing+clash sensor.

2. Added a new blade type
CrossGuardBlade : A simple two-channel cross-guard blade!

3. Added examples to the library. Examples can be accessed from the IDE in the usual way.
SaberBlades : Test/demo the blades
Motion : Test/demo motion manager

4. Added a copy of the full GPL license. It's free! Keep it free!

I hope you folks find it useful. Feedback welcome.
Wow Jake,..  what did you go an do?
I have been out for a week with the fuggin flu and all this has come out!?
Help me out here with some mental prep....  i downloaded the zip,..  but i have  never actually used a library or anyone elses arduino work.

what are the .ino and .cpp files for?   I also do not have arduinio installed on the PC I am using right now.

Protonerd

Ok boys (and girls).

I nailed agressive power save mode with wake up via PCINT interreupts (other PIN than D2 and D3) :


I've got one problem tho... My ampmeter isn't accurate enough to catch those reading.
It can't read below 200mA :P

If you use main button to make your device wake up, you'll need to press it twice to ignite the saber.
Great, simply great! I've copied it into my old saber code and in a blink of an eye I was able to send me device to the Bahamas to relax.

First of all, big cudos, the code works. The saber can be woken up with either one of the switches.

For sure I also made some measurements. Due to the fact that my PSU is also not much better and cannot read anything below 10mA, I had to use a trick. I connected 1.5Ohm (smallest I happened to find at home) in series between the PSU+ and the VIN pin. After that I connected my multimeter between the 2 terminals of this makeshift shunt resistance (in all equipments current metering happens this way in fact).
Current consumed by the circuitry is therefore [U_psu-U_vin]/R_shunt.
During operation I measured between 80mV and 200mV (translating to ~50mA to 130mA (what does it mean: essentially nothing, because it does not reflect actual consumption in a real saber with LEDs on and full speaker activity, so just take the values as are, the deltas interest us!)

If the saber board is in idle mode (i.e. not in config and no in action, but doing nothing) I measured 55mV -> 36mA, then as the device entered sleep mode, I measured 40mV -> 26mA.

My first though was: well, that's not gonna save the world... But it bugged me, because I knew the code was right. So I looked at my board. Power LED of the Arduino Nano happily turned on, same for the LED of the MPU. Bumm, they eat mAs (not exactly sure how much, mut anything from 1mA to 20mA). The deep sleep only affects so far the Atmega, so the DFPlayer and the MPU draw an unknown current. This all means that we need to look at it from a different perspective: we need to consider the delta, which is 10mA.

Then I had the bright idea to simply disconnect the supply of both DFPlayer and the MPU. This reduced the current somewhat, but I expected more. Until I remember how whole chips can be back-supplied through their I/O's. This happened in this case as well, so not only VCC has to be disconnected, but the SCL and SDA of the MPU as well as both Rx and Tx of the DFplayer (and all the rest, busy, int of MPU)! With this more I came to following values:


Summary:
- saber on/action mode:                               50-130mA (just for reference)
- idle mode:                                                36mA
- sleep mode (with code from neskweek):      26mA
- idle mode (disconnect DFPlayer):                21mA
- idle mode (disconnect DFPlayer+MPU):       17mA
- sleep mode (disconnect DFPlayer+MPU):     7.3mA

So the end result of saving approx. 10mA did not change. The code works perfectly, and we do not know what draws the remaining 10mA (for sure LEDs, there is a considerable measurement inaccuracy of my makeshift instrumentation etc., and the FTDI chip probably draws also quite a current). But we know that a power is drawn by the other components as well. This will need on the long run maybe a new concept, either changing HW or (hopefully only) SW.

Big thanks to neskweek for his work, which enabled my measurements.

neskweek

#738
Mar 14, 2016, 11:20 pm Last Edit: Mar 14, 2016, 11:29 pm by neskweek
That's great you was able to measure those.

But I'm quite disapointed by the deep sleep readings. Ithought they would be lower :P

Seeing those readings, maybe the fact that I make use of PCINT for wake up, other pins than those of the buttons may still be powered :
 In the code I explecitly ask for DPIN 4 and 12 monitoring, but I didn't inquire the state of the other pins in those silly interrupts register (PCMSK0,PCMSK2) so ....

Soulbp

I was theorizing on clash detection with out a clash sensor, this is where delays limit potential. As it's a little different doing collision detection in a game world where you can trace out and find intersection the basic concepts can apply. Using velocity can be very telling however if you are not able to sample the data quickly enough it doesn't matter. A clash would occur when the size of the entire velocity vector is high, then drops abruptly there should be point of zero or near zero follows by a reversal of velocity. This is a bounce. That's what you want, this won't happen as easily without a real impact as even if your arm goes full stop or quickly changes direction you'll have ramp down before the velocity changes to zero and reverse, snapping your arm might approximate this but I'm doubtful it would register quite the same as a legitimate ate impact. To minimize accidental clash you can check both direction of travel and speed of travel.

JakeSoft

I was theorizing on clash detection with out a clash sensor, this is where delays limit potential. As it's a little different doing collision detection in a game world where you can trace out and find intersection the basic concepts can apply. Using velocity can be very telling however if you are not able to sample the data quickly enough it doesn't matter. A clash would occur when the size of the entire velocity vector is high, then drops abruptly there should be point of zero or near zero follows by a reversal of velocity. This is a bounce. That's what you want, this won't happen as easily without a real impact as even if your arm goes full stop or quickly changes direction you'll have ramp down before the velocity changes to zero and reverse, snapping your arm might approximate this but I'm doubtful it would register quite the same as a legitimate ate impact. To minimize accidental clash you can check both direction of travel and speed of travel.
That all sounds reasonable. Whip up an algorithm that doesn't consume a ton of memory or CPU and we'll be glad to try it out.

"I shall follow your career with great interest." --Counselor Palpatine

JakeSoft

Wow Jake,..  what did you go an do?
I have been out for a week with the fuggin flu and all this has come out!?
Help me out here with some mental prep....  i downloaded the zip,..  but i have  never actually used a library or anyone elses arduino work.

what are the .ino and .cpp files for?   I also do not have arduinio installed on the PC I am using right now.
To install the library, all you should need to do is copy the USaber folder from the .ZIP file to your C:\Users\<user name>\Documents\Arduino\libraries or C:\Users\<user name>\Arduino\libraries folder, depending on what version of the IDE you have installed.

After that, restart your Arduino IDE and USaber will show up under File->Examples. You can open any of the example sketches just like you can with the built in examples.

To include the library in your own sketch, just select Sketch->Import Library and select "USaber". It's really that easy.

Soulbp

That all sounds reasonable. Whip up an algorithm that doesn't consume a ton of memory or CPU and we'll be glad to try it out.

"I shall follow your career with great interest." --Counselor Palpatine
Reasonable yes, you point out two possible flaws. I need to read up more on the hardware and libs used. A basics theory might require a custom delay function that does a while loop pulling data from the axis hardware whichever type and breaks out of the loop early for a clash. Anyway, basicly in the main loop depending how frequently you can pull the data you'd want to store the velocity each loop through the code if (VSize(velocity) - VSize(lastloopvelocity) < somemagnitude) /// basicly the initial check would be did the velocity drop a large amount between loops, VSize being the magnitude or speed of the velocity then you can do late individual axis for directions or even see if the speed is + or minus as it should be a float that can give an indication of direction ,or che k first for zero to see if it dropped to zero and then next loop see if it reversed. I'll stop talking theory, I'll wait till I can put it into practice.

neskweek

I was theorizing on clash detection with out a clash sensor, this is where delays limit potential. As it's a little different doing collision detection in a game world where you can trace out and find intersection the basic concepts can apply. Using velocity can be very telling however if you are not able to sample the data quickly enough it doesn't matter. A clash would occur when the size of the entire velocity vector is high, then drops abruptly there should be point of zero or near zero follows by a reversal of velocity. This is a bounce. That's what you want, this won't happen as easily without a real impact as even if your arm goes full stop or quickly changes direction you'll have ramp down before the velocity changes to zero and reverse, snapping your arm might approximate this but I'm doubtful it would register quite the same as a legitimate ate impact. To minimize accidental clash you can check both direction of travel and speed of travel.
Yeah theory is cool. That's the exact thought I did use when started movement detection.

IMUs on the other hand does not detect deceleration fast enough. At least mine.
With this theory , you may  also trigger clash on fast movements when changing direction.

billpealer

Ok boys (and girls).

I nailed agressive power save mode with wake up via PCINT interreupts (other PIN than D2 and D3) :

Code: [Select]

#include <avr/sleep.h>
#include <avr/power.h>
#include <avr/interrupt.h> 


timeToDeepSleep = millis();


setup(){
// your stuffs
// Aux button (for example)
PCMSK0 |= (1 << PCINT4); // set PCINT4 (PIN 12) to trigger an interrupt on state change
// Main button (for example)
PCMSK2 |= (1 << PCINT20); // set PCINT20 (PIN 4) to trigger an interrupt on state change
//your stuffs
}


loop{

//Your stuffs
timeToDeepSleep = millis();
deepSleep();
//Your stuffs

}

void deepSleep() {

if (millis() - timeToDeepSleep >= DEEP_SLEEP) {
Serial.println(F("Powersave mode"));
delay(20);


set_sleep_mode(SLEEP_MODE_PWR_DOWN);   // sleep mode is set here
noInterrupts ();
// timed sequence follows

// enables the sleep bit in the mcucr register
sleep_enable();

// disable ADC
byte old_ADCSRA = ADCSRA;
ADCSRA = 0;

// turn off various modules
power_all_disable ();



//Reduce processor frequency
byte oldCLKPR = CLKPR;
CLKPR = bit(CLKPCE);
CLKPR = clock_div_256;

// turn off brown-out enable in software
MCUCR = bit (BODS) | bit(BODSE);  // turn on brown-out enable select
MCUCR = bit(BODS);   // this must be done within 4 clock cycles of above
// guarantees next instruction executed
// sleep within 3 clock cycles of above
interrupts ();
sleep_cpu ();

PCIFR |= bit (PCIF0) | bit(PCIF1) | bit(PCIF2); // clear any outstanding interrupts
PCICR |= bit (PCIE0) | bit(PCIE2); // enable pin change interrupts

sleep_mode();

// THE PROGRAM CONTINUES FROM HERE AFTER WAKING UP
// cancel sleep as a precaution
sleep_disable();
CLKPR = oldCLKPR;
power_all_enable ();
ADCSRA = old_ADCSRA;
CLKPR = bit(CLKPCE);
CLKPR = clock_div_1;
interrupts ();
delay(20);Serial.println(F("Normal mode"));delay(20);
timeToDeepSleep = millis();
}
}



// the followingis not needed if you use SoftwareSerial library or other libraries making use of those interruptes
#if defined(PCINT0_vect)
ISR(PCINT0_vect)

// No need to put stuff in there to make you out of sleep mode

}
#endif

#if defined(PCINT1_vect)
ISR(PCINT1_vect, ISR_ALIASOF(PCINT0_vect));
#endif

#if defined(PCINT2_vect)
ISR(PCINT2_vect, ISR_ALIASOF(PCINT0_vect));
#endif



I've got one problem tho... My ampmeter isn't accurate enough to catch those reading.
It can't read below 200mA :P

If you use main button to make your device wake up, you'll need to press it twice to ignite the saber.
thanks for this. i really have no plan on making a kill switch.

Are you going to attach the .h libraries so we can include them?

Soulbp

Yeah theory is cool. That's the exact thought I did use when started movement detection.

IMUs on the other hand does not detect deceleration fast enough. At least mine.
With this theory , you may  also trigger clash on fast movements when changing direction.
Thanks that's what I was hoping for from people who have handled the hardware. I was curious how refined IMU data is as it's essentially little balls pressing against walls, so I wasn't how well in practice it would be let alone how quickly you could sample the data.

Soulbp

http://www.digikey.com/product-search/en?v=497&mpart=H3LIS331DLTR
This may be a solution as it seems impact/collision detection is harder on the 6050 etc because they are low g. High g will give more refined data.

neskweek

Those are 3 axis accelerometer.

I am currently trying to have contacts with some companies who makes piezo tubes.

A simple piezo tube in the emiter should be enough to detect clashes and lockups. In theroy ;)

But for clashes the code Protonerd came up with on MPU6050 devices  is really neat. And it works with a damned high precision.

stinky1

#748
Mar 15, 2016, 07:25 pm Last Edit: Mar 15, 2016, 07:42 pm by stinky1
Can anyone update this drawing for a RGB 750mah type Luxeon Star/Cree type emitter?
I plan on using the Version 7 Type architecture with the state your own colors coding.
So many changes in mrk 8 compiliator compilation,  I'm wondering if it still works!!  It's just I can't afford to burn anything out as I have like no money left.

http://s1073.photobucket.com/user/cest_bastien1/media/Lightsaber/AS2_LEDstringSaberArduino_NeskweekRevised_zpsu5k0ljck.png.html

Damn thing is I ordered a 3w total,  1 watt per LED RGB star and the resistors to
limit them.   Figured out the Nano and PWM limits them from frying.=wasted dough/   So forget the 3w one,and i'll order a 9watt one,  just so all this isn't so confusing, as it seems everyone goes for the higher wattage one,  and it is the ones (9w) used in builds,  so KISS.
Order another part.......

You guys are making mad progress!!!  Thanks millions!

Ahhh more to buy......

JakeSoft

Anybody want to contribute an MPU6050 MotionManager to the USaber library? That seems to be the popular choice over in Proto's thread. I don't have the hardware to test it myself.

Go Up