- Sat Mar 31, 2012 10:24 am
#142169
- Compute 8 point moving average of the raw ADC readings
- Compute the slope of the average from the last 2 available averages
- If that slope is more negative than a threshold (= -1 ATM) then increment a counter but cap that counter to N max (= 9 ATM)
- When the slope is less negative than the threshold decrement the counter but cap that at 0 min
- If the counter >= threshold2 (= 4 ATM) then declare the gearbox to be "offsrping"
The above works fairly well with the M16 but produced false "detections" and missed some cycles with the other AEGs. Also the inrush current can vary in it's nature quite a bit and trip up the above. I limit the above to only work when time since trigger > time threshold, presently 100 msecs. I found that slight differences in the aforementioned thresholds and limits made differences in the "offspring" detections, sometimes out of all proportion to what I'd thought the changes would do. In other words it's tricky and too sensitive (IMO) to be ready for prime time. For the M16 it works OK, for the others ... not so much.
I choose 8 for the moving average to be "speedy" on an MCU. You can subtract out the last of the 8 ADC readings, add in the new ADC reading to make a moving sum and then right shift that by 3 to get a divide by 8. But this is silly now that I think about it. What you should code for is a moving sum, compute the slopes from the moving sum (not the average), and scale the new slope threshold to be 8 times greater than my slope threshold. An average is just an extra (and unneeded) divide. I may try that in Excel just to be sure.
I also tried a linear "best fit" estimation to get the slope, using 3 and 5 points (not something I'd want to do in an MCU), and that helped with the other AEGs as they were a lot noisier than the present M16. The 2 point slope did NOT work reliably with them, it seems to with the M16.
My guess is that the above will work for the times when the motor has been running for more than 500 msecs (past the inrush period) fairly well. The M16 is very repeatable past 500 msec and not that noisy (in the raw current readings). For other AEGs it was semi-working but required so much fine tuning I thought it not workable in real life. Having the slope detector try to detect the 1'st cycle or the first 3 or 5 (burst mode) is iffy. But I didn'tspend a lot of time trying to improve it after you went to the BB detector. Maybe I can re-look at it and see if the mental break time will result in some new and better ideas. The good thing is we have a wealth of data we can use as input to any algorithm. We can see if it works or not with Excel (or whatever) as a simulation tool and be able to compare those outputs to the actual BB detections to know the truth. No need to code up stuff for the Arduino and 10 people can be running 10 different sims to see what works.
StaticDet5 wrote:OK, so now the hard part.This is the tricky part. And the reason I was recommending the BB detector as the means to do it. What I've done in Excel was implement a crude negative slope detector. It looks for the slope to be more negative than 1 ADC count/msec and do so for at least 4 consecutive msecs (a steep enough slope for long enough was the general idea). When that happens it declares the gearbox to be "offspring" (see my prior plots). The slope was computed from the 8 point moving average of the raw ADC readings. So pseudo-code would be something like this ...
We've been able to examine graphs and figure out where the peaks are. How do I write the computer code to figure that part out, while still keeping it speedy? It looks like we should be able to reliably identify the gearbox cycles. Hell, we can eyeball it ourselves, even with the moving baseline during the initial two shots.
Did you folks already work this out? I ask, because this is stuff I haven't done before.
- Compute 8 point moving average of the raw ADC readings
- Compute the slope of the average from the last 2 available averages
- If that slope is more negative than a threshold (= -1 ATM) then increment a counter but cap that counter to N max (= 9 ATM)
- When the slope is less negative than the threshold decrement the counter but cap that at 0 min
- If the counter >= threshold2 (= 4 ATM) then declare the gearbox to be "offsrping"
The above works fairly well with the M16 but produced false "detections" and missed some cycles with the other AEGs. Also the inrush current can vary in it's nature quite a bit and trip up the above. I limit the above to only work when time since trigger > time threshold, presently 100 msecs. I found that slight differences in the aforementioned thresholds and limits made differences in the "offspring" detections, sometimes out of all proportion to what I'd thought the changes would do. In other words it's tricky and too sensitive (IMO) to be ready for prime time. For the M16 it works OK, for the others ... not so much.
I choose 8 for the moving average to be "speedy" on an MCU. You can subtract out the last of the 8 ADC readings, add in the new ADC reading to make a moving sum and then right shift that by 3 to get a divide by 8. But this is silly now that I think about it. What you should code for is a moving sum, compute the slopes from the moving sum (not the average), and scale the new slope threshold to be 8 times greater than my slope threshold. An average is just an extra (and unneeded) divide. I may try that in Excel just to be sure.
I also tried a linear "best fit" estimation to get the slope, using 3 and 5 points (not something I'd want to do in an MCU), and that helped with the other AEGs as they were a lot noisier than the present M16. The 2 point slope did NOT work reliably with them, it seems to with the M16.
My guess is that the above will work for the times when the motor has been running for more than 500 msecs (past the inrush period) fairly well. The M16 is very repeatable past 500 msec and not that noisy (in the raw current readings). For other AEGs it was semi-working but required so much fine tuning I thought it not workable in real life. Having the slope detector try to detect the 1'st cycle or the first 3 or 5 (burst mode) is iffy. But I didn'tspend a lot of time trying to improve it after you went to the BB detector. Maybe I can re-look at it and see if the mental break time will result in some new and better ideas. The good thing is we have a wealth of data we can use as input to any algorithm. We can see if it works or not with Excel (or whatever) as a simulation tool and be able to compare those outputs to the actual BB detections to know the truth. No need to code up stuff for the Arduino and 10 people can be running 10 different sims to see what works.
Last edited by Mee_n_Mac on Sat Mar 31, 2012 11:33 am, edited 3 times in total.