Hi, This problem could be a number of things, as the other responders have said. Without seeing the data, no one is going to be able to give you much help. If you like, I'll be glad to take a look at it. Steve Smith (website: www.DSPguide.com).
Acceleration
Started by ●October 30, 2007
Reply by ●November 1, 20072007-11-01
Reply by ●November 1, 20072007-11-01
>Hi, This problem could be a number of things, as the other respondershave>said. Without seeing the data, no one is going to be able to give youmuch>help. If you like, I'll be glad to take a look at it. >Steve Smith >(website: www.DSPguide.com). > > >Hi I am writing code to capture real time data, and will post. But the following is calcultaed ticks per pulse of 100 seq. pulses - generated by a (obviously not very good) function generator set at 830Hz (Tick Time is : 25.24376006nS) 1CF8 [0] 47144 1CFC [1] 47145 1D00 [2] 47154 1D04 [3] 47153 1D08 [4] 47154 1D0C [5] 47159 1D10 [6] 47157 1D14 [7] 47154 1D18 [8] 47147 1D1C [9] 47150 1D20 [10] 47152 1D24 [11] 47146 1D28 [12] 47146 1D2C [13] 47165 1D30 [14] 47160 1D34 [15] 47160 1D38 [16] 47146 1D3C [17] 47145 1D40 [18] 47151 1D44 [19] 47151 1D48 [20] 47152 1D4C [21] 47159 1D50 [22] 47158 1D54 [23] 47160 1D58 [24] 47149 1D5C [25] 47154 1D60 [26] 47150 1D64 [27] 47148 1D68 [28] 47147 1D6C [29] 47154 1D70 [30] 47154 1D74 [31] 47159 1D78 [32] 47157 1D7C [33] 47148 1D80 [34] 47147 1D84 [35] 47152 1D88 [36] 47153 1D8C [37] 47152 1D90 [38] 47158 1D94 [39] 47161 1D98 [40] 47157 1D9C [41] 47148 1DA0 [42] 47155 1DA4 [43] 47152 1DA8 [44] 47149 1DAC [45] 47148 1DB0 [46] 47161 1DB4 [47] 47162 1DB8 [48] 47160 1DBC [49] 47151 1DC0 [50] 47146 1DC4 [51] 47143 1DC8 [52] 47149 1DCC [53] 47150 1DD0 [54] 47154 1DD4 [55] 47156 1DD8 [56] 47160 1DDC [57] 47155 1DE0 [58] 47156 1DE4 [59] 47157 1DE8 [60] 47153 1DEC [61] 47153 1DF0 [62] 47153 1DF4 [63] 47158 1DF8 [64] 47158 1DFC [65] 47156 1E00 [66] 47147 1E04 [67] 47150 1E08 [68] 47150 1E0C [69] 47160 1E10 [70] 47152 1E14 [71] 47161 1E18 [72] 47165 1E1C [73] 47160 1E20 [74] 47150 1E24 [75] 47154 1E28 [76] 47149 1E2C [77] 47148 1E30 [78] 47145 1E34 [79] 47159 1E38 [80] 47161 1E3C [81] 47158 1E40 [82] 47154 1E44 [83] 47152 1E48 [84] 47154 1E4C [85] 47154 1E50 [86] 47155 1E54 [87] 47157 1E58 [88] 47161 1E5C [89] 47163 1E60 [90] 47155 1E64 [91] 47151 1E68 [92] 47149 1E6C [93] 47149 1E70 [94] 47150 1E74 [95] 47149 1E78 [96] 47160 1E7C [97] 47160 1E80 [98] 47156
Reply by ●November 1, 20072007-11-01
On Oct 31, 2:08 pm, pnachtwey <pnacht...@gmail.com> wrote:> That should work OK IFF you get a MUCH higher resolution feeback > system. As I pointed out above the minimum acceleration you will be > able to detect is going to be (distance per pulse)/T^2 = 0.04975m/ > (0.01s)^2= 497 m/s^2 which isn't very useful. You need to get the > distance per pulse down a lot. Then we can talk about the filter.I may be wrong about the number of pulses per revolution required. I have simulated this on my Mathcad and have found you may get by with your current 40 pulses per revolution if you are willing to make some compromises. The good news is that the alpha-beta filters works pretty well. I am surprised myself but now I must know what update rate you need and what the accuracy you need. The compromise you must make is that the accuracy is not that good at low speeds. This is because many updates can go by without seeing a pulse. So here is what I suggest. At low speeds you use the technique I showed in my previous link. At higher speeds the alpha-beta filter technique should be used. You must determine where the change will occur. This is a common trick in motion controllers. Peter Nachtwey
Reply by ●November 2, 20072007-11-02
On Oct 31, 2:43 pm, "Gareth" <gar...@nonick.net> wrote:> >On Oct 31, 11:56 am, "Gareth" <gar...@nonick.net> wrote: > >> >On Oct 31, 9:17 am, "Gareth" <gar...@nonick.net> wrote: > >> >> >On Oct 31, 2:37 am, "Gareth" <gar...@nonick.net> wrote: > >> >> >> Hello Again. > > >> >> >> I must say that I am overwhelmed by the help and feedback that I > >> have > >> >> >> received so far. It has given me ideas to try, which I am busy > >> doing. > >> >> >> The math, I must say, I am finding difficult (Kalman Filters etc) > as > >> I > >> >> >> can't seems to find any working examples to adapt / play with. I > >> will > >> >> try > >> >> >> and adapt the thoery papers I have read, if a filter is needed > at > >> >> all. > > >> >> >> To put it into persepective, the setup is as follows: > > >> >> >> The sensor is a Hall Effect digital out sensor (very good and > noise > >> >> >> free). > >> >> >> It is a very noisy environment, so there is bound to be noise on > >> the > >> >> >> cables connecting the sensor to my system board. > > >> >> >> The system board itself has the digital sensor input coming into > a > >> >> Scmitt > >> >> >> Trigger which the passes the signal directly to the input pin of > >> the > >> >> DSP. > > >> >> >> The wheel has a rolling circumference of 1990mm and the 'vane' > has > >> >> fourty > >> >> >> slots in it (some have 64+ slots), so fourty pluses per > revolution. > >> >> The > >> >> >> Dynamic range needs to be 10MPH to 200MPH (89Hz to 1786 Hz). > > >> >> >> The response time for calculating acceleration needs to be as > fast > >> as > >> >> >> possible. Currently I am working on 40 pulses per calculation, > >> which > >> >> >> equates to one wheel revolution, idealy I would like to change > this > >> to > >> >> 10 > >> >> >> or 20 pulses per solution. > > >> >> >I would look at using an acceleromter. They are easy to use. > > >> >> >Peter Nachtwey > > >> >> Hi Peter > > >> >> I have tried almost every MEMS accelerometer out there, memsic, AD > etc > >> and > >> >> find that the target environment has extreme vibration from a solid > >> mounted > >> >> high revving engine, making getting any useful data from an > >> accelerometer > >> >> very difficult ( for me! ). Am I missing somthing? > > >> >You should be able to filter the accelerometer to eliminate unwanted > >> >high frequency data. This should be easy as the frequency of the > >> >motor is MUCH higher than the frequency of car acceleration. > > >> >The method you are using just won't work. Here is why > > >ftp://ftp.deltamotion.com/public/NG/Mathcad%20-%20Acceleration%20from... > >> >I am assuming an acceleraton from stop using the data you provided. > > >> >You can see that your method will work well at low speed but not at > >> >higher speeds. I can change the parameters to reflect a 25 > nanosecond > >> >timer but that only makes the error about 8 times less. I think this > >> >is a losing battle. Notice the anount of filtering changes with the > >> >frequency or speed :(. > > >> >If the acceleromter doesn't work then the only option I see is using > >> >constantant time intervals and high count/rev encoders like a motion > >> >controller would. Then you can use the alpha beta etc filters. > > >> >What ever you do you should really do the math up front like I have > >> >done here so you can see what you are up against. I don't think you > >> >are making a math errors like others do. I just think your method is > >> >wrong because even if the math is done right you still have bad > >> >results. > > >> >What you are doing is not a trivial exercise. > > >> >Peter Nachtwey > > >> Hi Peter > > >> Wow! I am totally blown away! Thank you! > > >> Unfortunately, the formulas run off the page, so I am loosing track of > the > >> actual math, but I can see where you are going I think. > > >The equations that run off the page are continued on page 5 and 6. > >You just need to print them out and put pages 5 and 6 next to the > >pages that had the equations run off the page. In the end it makes no > >difference because it is the graph that shows what you are up against. > > >> In a nutshell, if I understand you right, the faster the wheel turns, > the > >> lower the captured timer values and therefore any system inacurcies > are > >> significantly multiplied. > > >> I will try the time interval method next (10ms interrupt). > > >That should work OK IFF you get a MUCH higher resolution feeback > >system. As I pointed out above the minimum acceleration you will be > >able to detect is going to be (distance per pulse)/T^2 = 0.04975m/ > >(0.01s)^2= 497 m/s^2 which isn't very useful. You need to get the > >distance per pulse down a lot. Then we can talk about the filter. > > >> I agree with the math first approach, but am not familiar with Matlab > etc, > >> so have to create an excel spreadsheet and use VBA to perform the math > - > >> which I will do. > >VBA will work but Scilab atwww.scilab.orgis free. What these > >packages don't do is the symbolic math which I find to be handy. That > >is why I use Mathcad. > > >> This is all going to take me a bit of time - would you be put out if I > >> came back to you for help with filters? - I really have to see this > >> project through and am struggling. > > >> I can't use acceleromters in this application as I am augmenting one > wheel > >> speed against another. (another whole set of issues when I finally get > the > >> 'trivial' acceleration working!), although I have tried and failed to > get > >> meaningful data out an acceleromter for a another similar application > >> which is now shelved because of this. > > >> Gareth...- Hide quoted text - > > >> - Show quoted text - > > Hi Peter > > Hmmn! Makes sense. From the above, I would need to sample at 1s to get > useful data, much too slow! > > GarethI may be wrong about the number of pulses per revolution required. I have simulated this on my Mathcad and have found you may get by with your current 40 pulses per revolution if you are willing to make some compromises. The good news is that the alpha-beta filters works pretty well. I am surprised myself, but now I must know what update rate you need and what the accuracy you are willing to live with given the 40 pulse per revolution limit. The compromise you must make is that the accuracy is not that good at low speeds. This is because many updates can go by without seeing a pulse. So here is what I suggest. At low speeds you use the technique I showed in my previous link. At higher speeds the alpha-beta filter technique should be used. You must determine where the change will occur between time/count and counts/time will occur. Peter Nachtwey
Reply by ●November 2, 20072007-11-02
>I may be wrong about the number of pulses per revolution required. >I have simulated this on my Mathcad and have found you may get by with >your current 40 pulses per revolution if you are willing to make some >compromises. The good news is that the alpha-beta filters works >pretty well. I am surprised myself, but now I must know what update >rate you need and what the accuracy you are willing to live with given >the 40 pulse per revolution limit. > >The compromise you must make is that the accuracy is not that good at >low speeds. This is because many updates can go by without seeing a >pulse. > >So here is what I suggest. At low speeds you use the technique I >showed in my previous link. At higher speeds the alpha-beta filter >technique should be used. You must determine where the change will >occur between time/count and counts/time will occur. > > Peter Nachtwey > >Hi Peter Thanks for the pose - very interesting. What would be determind low speed? What if I used the falling edge as well as the rising edge to double the pulses - although the duty of the pulse is not 50% , more like 60/40. Or even, what if I made new vanes and seriously increased the number of pulses per revolution to broaden the dynamic range. How would I implement alpha-beta filter? Regards, Gareth
Reply by ●November 3, 20072007-11-03
On Nov 2, 1:29 am, "Gareth" <gar...@nonick.net> wrote:> >I may be wrong about the number of pulses per revolution required. > >I have simulated this on my Mathcad and have found you may get by with > >your current 40 pulses per revolution if you are willing to make some > >compromises. The good news is that the alpha-beta filters works > >pretty well. I am surprised myself, but now I must know what update > >rate you need and what the accuracy you are willing to live with given > >the 40 pulse per revolution limit. > > >The compromise you must make is that the accuracy is not that good at > >low speeds. This is because many updates can go by without seeing a > >pulse. > > >So here is what I suggest. At low speeds you use the technique I > >showed in my previous link. At higher speeds the alpha-beta filter > >technique should be used. You must determine where the change will > >occur between time/count and counts/time will occur. > > > Peter Nachtwey > > Hi Peter > Thanks for the pose - very interesting. > What would be determind low speed?That would be the point where the interval/count method and the counts/ interval method are the same. What if I used the falling edge as well> as the rising edge to double the pulses - although the duty of the pulse is > not 50% , more like 60/40. Or even, what if I made new vanes and seriously > increased the number of pulses per revolution to broaden the dynamic > range.Didn't try that and won't.> > How would I implement alpha-beta filter? >ftp://ftp.deltacompsys.com/public/NG/Mathcad%20-%20KalmanAlphaBeta%20Gareth.pdf Most of the effort goes into setting up the test not the Kalman or alpha-beta filter. You can get somewhat the same results with a Butterworth filter. What the alpha-beta filter does that is different from the Butterworth filter is that the F matrix gives the filter 'inertia' . That is the filter just wants to maintain the current state and resist change. You can see that when the acceleration changes the Alpha-Beta filter will lag just like any other filter. One can get MUCH better response if the motor torque or some other information can be used to drive the filter. In this case the filter becomes a Kalman filter again. At the bottom I have the implementation for the simplest form of the Alpha-Beta filter. You can adjust the bandwidth to get the response you want. It is very simple and the micro controller should have no problem keeping up. There are a few parameters that you can play with. They are the sample time and bandwidth. Are you using this for a racing application? Peter Nachtwey
