Go Down

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

neskweek

#660
Feb 12, 2016, 10:12 am Last Edit: Feb 16, 2016, 09:12 am by neskweek
been working on this part, something about using the delay function to wait for the first sound to finish, is doing this. Need to replace this with a non-blocking delay... if anybody can come up with this solution please do share.  :)
Avoid delays at all cost ! Delays interfere with motion detection interrupts.

Have a look at my solution here (full code LightSaber Operating System)

SWING_SUPPRESS might require some tweaking depending of how much time is spend for a full loop in your code.

Canobi

Anyone here use photoshop?

For some reason the circuit artwork isn't printing at 1:1 scale and I don't know why.


billpealer

Of course thanks for that, without this thread i would not have come this far.
But sifting through all snippets of sample code is pretty hard work and contributing to a  more or less completed code would be more efficient, and more of a "open source" idea.
But that is my humble opinion.
one could re-post a collective file that is a repository of all the (useful) sample code people have contributed.  that would be nice. and a way to pay it forward.

2-3 weeks i'll have ADXL335 code to post. though analogRead code is hardly scarce.

billpealer

#663
Feb 15, 2016, 03:22 pm Last Edit: Feb 15, 2016, 03:34 pm by billpealer
Anyone here use photoshop?

For some reason the circuit artwork isn't printing at 1:1 scale and I don't know why.


do you use a laser or inkjet printer?  master your files as PDF (if you can)  print the PDF file in Reader and change your scaling to 1:1 or "original" or "100%"  depending on your printer make and model.
Don't print from a browser,  double click the local PDF and print from Adobe Reader 10 is best 11 has some bugs.  I can post screen grabs of 1:1 scale printing in Epson and HP printer dialog. If you are Canon or Lexmark, you are on your own.
make sure you have "border-less" or "edge to edge" turned OFF.  that should print to the scale you have in your original project.

Canobi

do you use a laser or inkjet printer?  master your files as PDF (if you can)  print the PDF file in Reader and change your scaling to 1:1 or "original" or "100%"  depending on your printer make and model.
Don't print from a browser,  double click the local PDF and print from Adobe Reader 10 is best 11 has some bugs.  I can post screen grabs of 1:1 scale printing in Epson and HP printer dialog. If you are Canon or Lexmark, you are on your own.
make sure you have "border-less" or "edge to edge" turned OFF.  that should print to the scale you have in your original project.
Thanks Bill :)

I use a Samsung laser printer and I've just set up laptop for the lab so may well have missed something. I'll have a look at the settings when I get back from work.

The PDFs need a bit of contrast adjustment as they come out off white which shows in the prints and use photoshop 5.

One thing is, I have to select pixle density on import and I'm wondering if that may be influencing things.

billpealer

Thanks Bill :)

I use a Samsung laser printer and I've just set up laptop for the lab so may well have missed something. I'll have a look at the settings when I get back from work.

The PDFs need a bit of contrast adjustment as they come out off white which shows in the prints and use photoshop 5.

One thing is, I have to select pixle density on import and I'm wondering if that may be influencing things.
that's prolly it.

make sure your pixel depth (density- measured in DPI dots/inch or PPI pixels/inch) is the same as your work space. (the native file)

300 dpi is a common print work space  72 dpi is for screens (LCD OLED, PLASMA CRT etc...)

photoshop menu chain  Image > Image Size   (select Image Size)  you should see the native DPI or PPI there.  or Alt+Ctrl + I

if your android circuit board making software is vector based  (you can zoom in as close as you want the the lines and text look good or even better) it most likely is exporting in 300dpi PDFs.

Canobi

Turned out a stupid print preference, the "pre" scaling was set to "shrink to print area".

Everything is printing and lining up properly again (whew!), I can stop panicking now lol.

JakeSoft

Special thanks to BillPealer for the tip about decaying your swing and clash sounds to the END of the hum sound. I've been mixing/remixing sound files for a while now, but the transitions from clash to hum were always (no pun intended) hit or miss. Since I employed this technique, the transitions are much smoother.

billpealer

Special thanks to BillPealer for the tip about decaying your swing and clash sounds to the END of the hum sound. I've been mixing/remixing sound files for a while now, but the transitions from clash to hum were always (no pun intended) hit or miss. Since I employed this technique, the transitions are much smoother.
not quite sure that was me.  You are adding clash and swing to the END of your hum?  like IN audacity? or WT playlists?  or are you altering your swing and clash sounds with your sound editor so they decay to a tone that is more akin to the ambient hum?   if so, you're welcome. LOL. 

wailer

one could re-post a collective file that is a repository of all the (useful) sample code people have contributed.  that would be nice. and a way to pay it forward.

2-3 weeks i'll have ADXL335 code to post. though analogRead code is hardly scarce.
Been experimenting with the 335 to get usable  readings.
I think the best way is to convert the readings to G force's to detect a swing so you can easily up or down the sensitivity.
You could even incorporate  a potmeter (also connected to analog in) to adjust this while using your saber, even have different swing sounds per reading (swing 1  +g swing 2 -g)
Have not been able to detect clashes with it but i think a standard clash detector (with a spring inside) should work better.
Some interesting code can be found here https://chionophilous.wordpress.com/2011/06/20/getting-started-with-accelerometers-and-micro-controllers-arduino-adxl335/
Hope i can post some code soon.

neskweek

#670
Feb 16, 2016, 11:22 am Last Edit: Feb 16, 2016, 12:22 pm by neskweek
Been experimenting with the 335 to get usable  readings.
I think the best way is to convert the readings to G force's to detect a swing so you can easily up or down the sensitivity.
You could even incorporate  a potmeter (also connected to analog in) to adjust this while using your saber, even have different swing sounds per reading (swing 1  +g swing 2 -g)
Have not been able to detect clashes with it but i think a standard clash detector (with a spring inside) should work better.
Some interesting code can be found here https://chionophilous.wordpress.com/2011/06/20/getting-started-with-accelerometers-and-micro-controllers-arduino-adxl335/
Hope i can post some code soon.
On MPU6050 device :

I did use quaternion instead to detect a swing: any w axe variation means the hilt did move.
As for swing sound : A simple random chose of swing sound do the same.

I did use G force variations to detect clashes. But I agree with that a clash/bump sensor would better suit that role.

one could re-post a collective file that is a repository of all the (useful) sample code people have contributed.  that would be nice. and a way to pay it forward.

2-3 weeks i'll have ADXL335 code to post. though analogRead code is hardly scarce.
I did post my full code, hoping people may complete it with other devices :
LightSaberOS

JakeSoft

On MPU6050 device :

I did use quaternion instead to detect a swing: any w axe variation means the hilt did move.
As for swing sound : A simple random chose of swing sound do the same.

I did use G force variations to detect clashes. But I agree with that a clash/bump sensor would better suit that role.
I did post my full code, hoping people may complete it with other devices :
LightSaberOS
Note that he used an MPU6050 which is a different animal than the ADXL335 chosen as the standard motion sensor in this thread. So keep that in mind when trying to apply techniques found in this code.

Protonerd

Note that he used an MPU6050 which is a different animal than the ADXL335 chosen as the standard motion sensor in this thread. So keep that in mind when trying to apply techniques found in this code.
When I started out, I took 3 sound modules (W588D, WT5001, DFPlayer) and switched between them quite frequently in my quest to find the Holy Gaplessness. I used compile directives (conditional inclusions) to be able to make the switch fast. If I had a - say - clash function, I had a piece of code for all 3 of them.

Something like this would be possible in neskweek's LSOS as well. For swings this would mean configuring whether a ball sensor, an MPU or an ADXL is used. For clash similarly. I guess such conditions already exists to define whether the code is running on an RGB or a LED string saber.

neskweek

#673
Feb 16, 2016, 09:44 pm Last Edit: Feb 17, 2016, 04:46 pm by neskweek
Note that he used an MPU6050 which is a different animal than the ADXL335 chosen as the standard motion sensor in this thread. So keep that in mind when trying to apply techniques found in this code.
I do concur that concerning the manner your get data from each module is totally different.

But concerning on how to treat them to obtain the result, it might be the same, from my point of view ;p

I was just giving the principles,that I used and that may remain the same, wathever the module is:

For a swing you want to detect a displacement in space. A simple difference between 2 Quaternion.w do the trick.

For a clash you want to detect a "violent" acceleration/deceleration followed by a "brutal" full stop.
Depending on the module you use and how fast it is able to change state you may need to do several passes throught the loop to detect changes of Magnitude (G force)


[Edit]

To make things clearer concerning Swing detection :
IMUs sucks at detecting change of positions in space. It could be achieved but you may end up with a huge code, and for our arduino device it's not what we want.

IMus are good at detecting acceleration and rotations.
When you play around with your saber, you changes its orientation (in other words, the IMU did rotate around its X/Y axes).

Differences between 2 quaternions are use to detect change of orientation, easily.
The only thing I omited is that you have to test around which axes the blade has rotated : you may don't want to trigger a swing when the saber did rotate along Z IMU's axe (like when Qui-Gon is burying is saber in a massive metalic airlock at the start of Episode 1).

[Edit 2]
While I was typing the last edit,  I realized one thing :
a test combining that a difference of 2 quaternions is above a certain value and that an X or Y acceleration is also above a certain value would be even more efficient :

The swing would be triggered only when making "wide" movements.

Hope it makes any sense ;)

billpealer

#674
Feb 17, 2016, 05:14 pm Last Edit: Feb 17, 2016, 05:14 pm by billpealer
I did post my full code, hoping people may complete it with other devices :
LightSaberOS
Thanks i'll take a look. Se if i can use it or abuse it.
Note that he used an MPU6050 which is a different animal than the ADXL335 chosen as the standard motion sensor in this thread. So keep that in mind when trying to apply techniques found in this code.
My hypothesis (untested) may be novel ( or not)-  will be to trigger swing, with the ADXL using a state change mechanic. quantify all the axis readings upon start up, and trigger the swing based on the total state change.

so- and the below code sample is me thinking out loud.  it is not syntax accurate.

setup for the pin outs and whatnot.

int state
State = AnalogRead (X+Y+Z);

void loop
If (New_State + State) is < or >  (300 - New_State) // this number is totally arbitrary till i solder up the ADXL and start getting reads from rests and swings.

Send_Command(1);  //swing
Delay (100); // if you can swing more than 10 times a second, have a cookie.

New_State = State;

Go Up