just 4 a test. wish not to bother u *_^
Acceleration
Started by ●October 30, 2007
Reply by ●October 31, 20072007-10-31
Reply by ●October 31, 20072007-10-31
Fred Marshall wrote:> "Jerry Avins" <jya@ieee.org> wrote in message > news:r-SdnUlYoaBba7ranZ2dnUVZ_gGdnZ2d@rcn.net... > >> Fred, >> >> Are there any digital velocity sensors? Even for analog, a good one is >> hard to come by. The usual kind of wound tachometer has scalloping from >> the commutator effect and the brush drop can introduce significant error. >> There are ways around these defects. The best I ever used was a homopolar >> generator with mercury "brushes" driving a hall-effect current sensor. >> That was eventually replaced with a two-phase encoder with 2000 lines per >> track, yielding 4000 cycles out of an XOR gate. >> > > > Jerry, > > I don't know. I've only used a 1000 line tach for a phase-locked speed > servo - which is actually a position servo in the guts of it - since the > phase lock is on the position of the tach lines. > > I think the Navy is still using the differentiating velocity measurizer I > designed into a tester in the 60's. It ran off of a film-based > potentiometer - position sensor. Wire-wound would have been a disaster! > The pickoff noise and the motor (being measured) jitter were bad enough! It > worked but what a kludge.Fred, I'm afraid there's no monopoly on kludges. The encoder-based tachometer worked with a fast clock and a counter. Every tick latched the counter's output and reset it. The latch then holds reciprocal velocity and fed a divide-by-N circuit. Another counter accumulated output pulses for a fixed time, yielding a number proportional to velocity. (Actually, inversely proportional to the time between ticks.) I used to get a kick out of thinking those things up and making them work. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●October 31, 20072007-10-31
>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 willtry>> and adapt the thoery papers I have read, if a filter is needed atall.>> >> 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 aScmitt>> Trigger which the passes the signal directly to the input pin of theDSP.>> >> The wheel has a rolling circumference of 1990mm and the 'vane' hasfourty>> 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 to10>> 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? Gareth
Reply by ●October 31, 20072007-10-31
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%20Time%20Intervals.pdf 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
Reply by ●October 31, 20072007-10-31
>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 Ihave>> >> received so far. It has given me ideas to try, which I am busydoing.>> >> The math, I must say, I am finding difficult (Kalman Filters etc) asI>> >> can't seems to find any working examples to adapt / play with. Iwill>> 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 onthe>> >> 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 ofthe>> 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 fastas>> >> possible. Currently I am working on 40 pulses per calculation,which>> >> equates to one wheel revolution, idealy I would like to change thisto>> 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 etcand>> find that the target environment has extreme vibration from a solidmounted>> high revving engine, making getting any useful data from anaccelerometer>> 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%20Time%20Intervals.pdf >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. 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). 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. 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...
Reply by ●October 31, 20072007-10-31
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 at www.scilab.org is 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 -
Reply by ●October 31, 20072007-10-31
>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 neededat>> >> all. >> >> >> >> To put it into persepective, the setup is as follows: >> >> >> >> The sensor is a Hall Effect digital out sensor (very good andnoise>> >> >> 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 intoa>> >> 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 perrevolution.>> >> The >> >> >> Dynamic range needs to be 10MPH to 200MPH (89Hz to 1786 Hz). >> >> >> >> The response time for calculating acceleration needs to be asfast>> as >> >> >> possible. Currently I am working on 40 pulses per calculation, >> which >> >> >> equates to one wheel revolution, idealy I would like to changethis>> 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, ADetc>> 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 25nanosecond>> >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 ofthe>> 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 inacurciesare>> 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 Matlabetc,>> so have to create an excel spreadsheet and use VBA to perform the math->> which I will do. >VBA will work but Scilab at www.scilab.org is 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 onewheel>> speed against another. (another whole set of issues when I finally getthe>> 'trivial' acceleration working!), although I have tried and failed toget>> 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! Gareth
Reply by ●October 31, 20072007-10-31
Gareth wrote:>> Gareth wrote: >>> Hi >>> >>> I am having trouble ( a lot of trouble ) trying to get meaningful and >>> timely acceleration data. >>> >>> In essence, I have a wheel speed sensor that picks up around 40 to 100 >>> pulses per wheel revolution (adjustable). This is captured by a 16bit >>> Micro/DSP. >>> >>> All I want to assert, with reasonable accuracy is the wheel > acceleration. >>> My acceleration data at the moment is all over place. >>> >>> How can I filter the data in real time so that I can assert wheel >>> acceleration? eg. DO I need to implement a Kalman filter or is there a >>> faster way of doing this? >>> >>> In other words, as a test, I have fitted this setup to a car and > steady >>> acceleration does not show steady acceleration data - it's all over > the >>> place. I can see the acceleration component, but is is saturated with >>> acceleration spikes. >>> >>> >>> >> Gareth, >> The methood you describe is very sensitive to any errors in pulse-timing > >> caused by road vibration and wheel eccentricity. Also, if you are >> taking the readings of a driven wheel you will have the influence of >> the pulsating torque of the engine as well. >> >> I suggest the following: >> 1. Measure the time between pulses, as you are doing, and compute the >> differences. This gives you dt/d(theta) for 40 to 100 instants per >> revolution. >> 2. Compute the difference between these values to give you a set of >> d^2t/d(theta)^2 values. The reciprocal of these gives you a set of >> acceleration values. >> 3. Average the acceleration values for one complete revolution of the >> wheel at a time to minimise errors due to wheel eccentricity. >> 4. If you can afford a slower response, put the acceleration values >> through a FIR filter, the longer the better. >> >> Regards, >> John >> > > Hi John > > Thank you for your reply. Most helpful. Please may I ask you to help me > through your formulas so that I can implement them. > > You have given: A.) dt/d(theta) and B.) d^2t/d(theta)^2 > > I take it that in A, dt is the difference in time, what is d(theta)? > > Sorry if I am coming accross as dumb, I just need some clarity please. > Do you have any simple working examples that I can play about with? > > ..Gareth > >Gareth, First a correction. As you already have the time between pulses, step 1 is not needed. On reflection, what I would suggest is: Compute (1/t2 - 1/t1)* 2 /(t1 + t2) Where t1 and t2 are successive measurements of the time between pulses. This will give you a measure of the acceleration in degrees/s^2. Filter or average the stream of acceleration values. Multiply by (360 / pulses per rev.) to scale the results to degrees per second per second. Unfortunatley I don't have any useful examples to send you. Regards, John
Reply by ●October 31, 20072007-10-31
"Gareth" <gareth@nonick.net> writes:> [...]Hi Gareth, Would it be possible for us to get samples of the actual counter values that were collected? I'd like to see the data directly, maybe play with it a bit. Knowing the acceleration profile of the data that was collected would help too. Also, what is the counter clock frequency? -- % Randy Yates % "She's sweet on Wagner-I think she'd die for Beethoven. %% Fuquay-Varina, NC % She love the way Puccini lays down a tune, and %%% 919-577-9882 % Verdi's always creepin' from her room." %%%% <yates@ieee.org> % "Rockaria", *A New World Record*, ELO http://www.digitalsignallabs.com
Reply by ●October 31, 20072007-10-31
Gareth wrote: ...> Hmmn! Makes sense. From the above, I would need to sample at 1s to get > useful data, much too slow!For starters, use a finer encoder. My gut says about 4000 ticks per turn, but I haven't done the math. I don't think engine vibration really bothers you much unless your wheel is turning nearly as fast as the engine, which I doubt. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
