Need Help coding motion detection with prop shield

Status
Not open for further replies.
W

Waterme11on

Active member
Hey I was wondering if anyone could help me out with coding a motion detection setup with the audio library.

So i want to open and shut a filter or change a mixer gain depending on whether the accelerometer detects motion. Meaning if my prop shield is moving it lets sound out, but if it's still it stays silent.
I figured it would involve using the raw ax, ay, az values from the accelerometer instead of using roll, pitch or yaw.
I also want to be able to have the prop shield resting in any orientation, as it is mounted within a sphere, meaning I cant just do an "if ay=1, mixer gain = 0" type of operation.

Could anyone point me in the right direction for figuring this out? Or if you have any suggestions for an alternate method at achieving the 'no motion = no sound' effect.

Cheers.
 
If you just want to detect angular changes the bare bones solution is just store the last value for each axis, compare to the new value and use that difference to drive your code. You have multiple axis and directions so you can either apply difference effects based on direction, or if you only want a positive rate of change you either if(x<0) x=-x; or X=ABS(x) https://www.arduino.cc/en/reference/abs

If you want to add the values together into a single output channel you can do just that, though this will be wrong with diagonal motion (going up 1 and right 1 gets output of 2, when actual travel ~1.4), you can use Pythagoras to get a more correct value square root of (x squared+y sqaured)-> float motion=sqrt(x*x+y*y);

Finally you will probably find that you need to apply a curve to the motion to get nice results from slow motion without things getting out of hand for wild swings. simple option is to check if your output reachs some minimum before actually apply the result and clamping the upper bound at something sane (never assume IMU output values won't glitch far enough to crash your math), or you can do things like use the sqrt of your value to get better dynamic range.
 
Hey thanks for the reply, what you mentioned will actually help me in the other areas of my project but in this particular instance i'm trying to detect when the ball is motionless.
For clarification my teensy is actually inside of a poi, which is a ball on the end of a rope which I swing around, Meaning that whenever im swinging it my readings are generally whack due to the centrifugal forces.

Would it work if I averaged all the accelerometer values and had my code detect if they all averaged at 1? since 1 should mean only gravity is effecting the ball, and not any centrifugal force?
I'm also really new to coding in general so i'm looking for some specific advice on what to write in my sketch.

Cheers.
 
Working out the net acceleration would work, though you may find that your axis are not quite calibrated together. If this poi is tethered to a single point, does this mean there is only one axis in direction of spin? This would mean you just watch one axis, and measure max, min and time to cycle between them to gather information about how fast it's spining. You may want to add some sort of display and user interface so you can spin a prototype see the numbers you get back and adjust towards the result you want. Can work better than trying to spin something while it's tethered to a PC.

Note also that you are doing two different things here, the first is programing, the second is algorithm design and is very much a different topic so if it's seeming hard that's why
 
I'll give the net acceleration a go and report back.
The poi as actually hand held and swung in various patterns and speeds, so the ball ends up rotating due to the rope twisting meaning I can't just use a single axis, and since the speed isn't constant I cant use time as a measurement.

I'm a complete noob at any type of programming or algorithm design so when you say things like how I'll need to apply a curve to the motion, or clamp an upper bound, I don't know what that entails code wise.
 
Clamping to a range is map
https://www.arduino.cc/en/reference/map
And really important in something like this where you don't want out of bounds results. If new to this sort of thing you really need to keep track of what size variables you are using, especially with any code you copy from 8 bit Arduino examples where they max at 128 or 32767. Thirty two thousand looks big, but if it's easy if you start squaring things to shoot past that. For your use it may be better to take your values to float as a first step, and keep them as floats until you have finished and then use floor
int finalIntX= floor(xfloat);
to know when you round numbers back. Swaping from float to int is possible but is a quick way to get unexpected results when you are new to this. Float may is much much slower but you are only doing a single set of maths here, the speed matters if you wanted to update a whole bunch of pixels but for just working out which way things are going will be easier working as float.

Would suggest you stoke up excel or other spread sheet of your choice, look at some sample raw values out of the IMU and look at some example math in the spread sheet. Is far easier to rough out your math in a spread sheet where you can tweak numbers and get results straight away then writing C, loading it up and then looking at numbers in the serial terminal.

Especially allows you to look at what extreme and minimal values in will give you as outputs, and what you would need to do to them to turn them into 256 colour values.

A practise exercise might be to try making a linear number series from 0 to 3G, and then try to produce a formua that runs from 0 to 256 as an output. Then add do a new formula which first takes the squareroot of the G value, but still gives 256 at the 3G. Graph the two sets of results and the second should give a curve which will give different attack rates at low and high loads. This isn't intended for direct use, but as an example of how to break a problem like this down into managable chunks.
 
Status
Not open for further replies.
Back
Top