Playing With Accelerometers
Forumsregeln
Bitte beachte die Forumsregeln!
Bitte beachte die Forumsregeln!
Re: Playing With Accelerometers
I like it!
Nice mathimatical description in the linked document.
Ans also a nice overview of different hardware components.
Nice mathimatical description in the linked document.
Ans also a nice overview of different hardware components.
Re: Playing With Accelerometers
Hi reivilo,
Nice models,
Which formulae don't work?
BTW. I think 1 TX is enough for the joystick because the counter inputs can be used as digital inputs.
In the past I've built an IMU with the Freescale accelerometer. For orientation they are adequate, integration to obtain speed and position is next to impossible.
If you think an engineer can help you, don't hesitate to pose your problem.
Ad
Nice models,
Which formulae don't work?
BTW. I think 1 TX is enough for the joystick because the counter inputs can be used as digital inputs.
In the past I've built an IMU with the Freescale accelerometer. For orientation they are adequate, integration to obtain speed and position is next to impossible.
If you think an engineer can help you, don't hesitate to pose your problem.
Ad
 Peterholland
 Beiträge: 324
 Registriert: 01 Nov 2010, 22:28
 Wohnort: Poederoyen NL
Re: Playing With Accelerometers
Hello Ad + Rei Vilo,
Using traditional diods on the endswitsches is may be also possible ?!....
Peter
Poederoyen NL
Using traditional diods on the endswitsches is may be also possible ?!....
Peter
Poederoyen NL
Peter Poederoyen NL
Re: Playing With Accelerometers
Yes, or even switching the motor off directly with the switches, no diodes required. I posted the schematic once on the old forum but that's gone now.
The advantage is that it always works even if your program fails, the disadvantage is that your program doesn't know it has reached a limit. For that you still need two inputs.
The circuit is simple: the common contacts of the endswitches go to the motor, the normally closed contacts go to the respective outputs of the TX, the normally open contacts go to ground. If you need feedback connect the motor connections to two inputs. When the motor is running one of these inputs should be high, if that isn't the case, the motor has reached an endpoint. Note that this circuit stops the motor but allows it to drive in the opposite direction.
The advantage is that it always works even if your program fails, the disadvantage is that your program doesn't know it has reached a limit. For that you still need two inputs.
The circuit is simple: the common contacts of the endswitches go to the motor, the normally closed contacts go to the respective outputs of the TX, the normally open contacts go to ground. If you need feedback connect the motor connections to two inputs. When the motor is running one of these inputs should be high, if that isn't the case, the motor has reached an endpoint. Note that this circuit stops the motor but allows it to drive in the opposite direction.
 Peterholland
 Beiträge: 324
 Registriert: 01 Nov 2010, 22:28
 Wohnort: Poederoyen NL
Re: Playing With Accelerometers
Reivilo's accelerometerDEACCM3D has the same possiblities as the "3Achsen BeschleunigungsSensorModul N5170" we are talking in the FTCommunityforum:
http://www.neuholdelektronik.at/catsho ... 911307ae92
Both are based on an ADXL330 from Analog Devices.
Solutions for the accelerometerDEACCM3D problems can also be used for the "3Achsen BeschleunigungsSensorModul N5170"
Grüss,
Peter
Poederoyen NL
http://www.neuholdelektronik.at/catsho ... 911307ae92
Both are based on an ADXL330 from Analog Devices.
Solutions for the accelerometerDEACCM3D problems can also be used for the "3Achsen BeschleunigungsSensorModul N5170"
Grüss,
Peter
Poederoyen NL
Peter Poederoyen NL
Re: Playing With Accelerometers
Hi,
I guess the problem is not easy, there is indeed a lot of inertia and a relatively weak drive. Nevertheless we can try to model the system. You start by applying a voltage to the motor, when we assume that the motor is lightly loaded, the angular velocity will be proportional to the voltage (w=Km*V).
The lift of a wing (according to an aeronautical engineer I asked) is proportional to the square of the forward speed (L ~ w^2). This simple formula needs some nuance because the formula is for large airplane wings and does not necessarily scale to small wings (flies don't fly like like airplanes). The lift exerts a torque on your balance (T=2*L*l), 2 because you have two motors, l is the length of one arm. This torque gives an angular acceleration T/I where I is the moment of inertia (I = 2*Mm*l^2) where Mm is the mass of the motor, l again the length and 2 because there are two motors. When you work this all out you see that the angular velocity is proportional to the square of the voltage but apart from the note about lift, the motors will also be slowed down because of drag but OK, it's only an approximation. What you measure however is not the angular acceleration, I presume you measure the horizontal axis of the accelerometer (at the pivot) which value is proportional to the sine of the angle. From angular acceleration to angle we need two integration steps and this is one of the things that make it difficult to stabilize the loop. As a solution you could take a gyro and create a nested loop but that was not the idea of the excercise. You could mount the sensor close to the motor, the zaxis would then approximate the angular acceleration. But you can also try to leave it as it is and try to stabilize the loop with eg. a PID controller. The I action will probably make things worse so a starting point could be a PD controller. Because of the double integration the proportional control will already act as integrating control and the derivative control will act as proportional control. Now the real fun starts because the derivative (angular velocity) is not available, hence we have to compute it by differentiation from the angle. This operation is susceptible to noise. You already tried to filter the noise with a moving average (a low pass filter) and a median filter. The median filter is fast but works only well for spikelike noise, the moving average does the opposite of differentiating so the time constant must be carefully chosen. The presented model contains a lot of constants, some can be measured but especially with the aerodynamics things become complicated (Reynold's number, viscosity of air), so it is probably easier to put some voltages on your motors and try to measure the resulting acceleration. A PD controller has only two parameters, with some experimenting you may find a stable solution.
Ad
I guess the problem is not easy, there is indeed a lot of inertia and a relatively weak drive. Nevertheless we can try to model the system. You start by applying a voltage to the motor, when we assume that the motor is lightly loaded, the angular velocity will be proportional to the voltage (w=Km*V).
The lift of a wing (according to an aeronautical engineer I asked) is proportional to the square of the forward speed (L ~ w^2). This simple formula needs some nuance because the formula is for large airplane wings and does not necessarily scale to small wings (flies don't fly like like airplanes). The lift exerts a torque on your balance (T=2*L*l), 2 because you have two motors, l is the length of one arm. This torque gives an angular acceleration T/I where I is the moment of inertia (I = 2*Mm*l^2) where Mm is the mass of the motor, l again the length and 2 because there are two motors. When you work this all out you see that the angular velocity is proportional to the square of the voltage but apart from the note about lift, the motors will also be slowed down because of drag but OK, it's only an approximation. What you measure however is not the angular acceleration, I presume you measure the horizontal axis of the accelerometer (at the pivot) which value is proportional to the sine of the angle. From angular acceleration to angle we need two integration steps and this is one of the things that make it difficult to stabilize the loop. As a solution you could take a gyro and create a nested loop but that was not the idea of the excercise. You could mount the sensor close to the motor, the zaxis would then approximate the angular acceleration. But you can also try to leave it as it is and try to stabilize the loop with eg. a PID controller. The I action will probably make things worse so a starting point could be a PD controller. Because of the double integration the proportional control will already act as integrating control and the derivative control will act as proportional control. Now the real fun starts because the derivative (angular velocity) is not available, hence we have to compute it by differentiation from the angle. This operation is susceptible to noise. You already tried to filter the noise with a moving average (a low pass filter) and a median filter. The median filter is fast but works only well for spikelike noise, the moving average does the opposite of differentiating so the time constant must be carefully chosen. The presented model contains a lot of constants, some can be measured but especially with the aerodynamics things become complicated (Reynold's number, viscosity of air), so it is probably easier to put some voltages on your motors and try to measure the resulting acceleration. A PD controller has only two parameters, with some experimenting you may find a stable solution.
Ad
Zuletzt geändert von Ad2 am 30 Nov 2010, 10:28, insgesamt 1mal geändert.
Re: Playing With Accelerometers
Hi (or Bonjour, but that's about as far as my French goes
Interesting problem. I was able to get it to work with a PID controller and a Kalman filter. You have to apply a Kalman filter to the accelerometer data to be able to do anything useful with it (although yours seems pretty noisy). A simple 1 dimensional Kalman filter was sufficient in my case. Here's what it does to your data:
I spent about 5 minutes tuning the PID controller to get it to return to the mid point whenever I tip it off. I'm sure it can do better, but I'm not a PID tuning expert. I may also be running into the limits of the accelerometer w.r.t. providing a reliable derivative or rotational speed measurement (the 'D' term of the PID). With a more unstable equilibrium (like a balancing robot) the accelerometer alone won't be sufficient, and you'll need a gyro to measure rotational speed.
Here's the RoboPro file with the (reusable) Kalman filter: http://82.95.86.128:8080/ftpub/Windmill.rpp. Video: http://www.youtube.com/watch?v=U2vZon150EQ
I'm using a Sparkfun breakout board with an ADXL203 accelerometer. It also has a gyro, so I'm working on a balancing robot now. That also needs a good rotation counter on the robot axes to get robot position and speed. The FT encoder motors are useless here, as the pulses don't tell you what direction the robot is moving. I just got myself a couple of incremental encoders for that purpose. Will keep you posted.
Willem Evert Nijenhuis.
Interesting problem. I was able to get it to work with a PID controller and a Kalman filter. You have to apply a Kalman filter to the accelerometer data to be able to do anything useful with it (although yours seems pretty noisy). A simple 1 dimensional Kalman filter was sufficient in my case. Here's what it does to your data:
I spent about 5 minutes tuning the PID controller to get it to return to the mid point whenever I tip it off. I'm sure it can do better, but I'm not a PID tuning expert. I may also be running into the limits of the accelerometer w.r.t. providing a reliable derivative or rotational speed measurement (the 'D' term of the PID). With a more unstable equilibrium (like a balancing robot) the accelerometer alone won't be sufficient, and you'll need a gyro to measure rotational speed.
Here's the RoboPro file with the (reusable) Kalman filter: http://82.95.86.128:8080/ftpub/Windmill.rpp. Video: http://www.youtube.com/watch?v=U2vZon150EQ
I'm using a Sparkfun breakout board with an ADXL203 accelerometer. It also has a gyro, so I'm working on a balancing robot now. That also needs a good rotation counter on the robot axes to get robot position and speed. The FT encoder motors are useless here, as the pulses don't tell you what direction the robot is moving. I just got myself a couple of incremental encoders for that purpose. Will keep you posted.
Willem Evert Nijenhuis.
Zuletzt geändert von winijenh am 07 Jan 2011, 13:19, insgesamt 3mal geändert.
Re: Playing With Accelerometers
To preprocess digital signals, people are making very often use of the so called DSP microcontrollers.
For example the DsPIC30 and DsPIC33 series (www.MicroChip.com).
Beside this hardware, there is also a DSP library with suitable functions, like filters etc.
There exist a lot of books about this subject and this on different level of abstraction level.
A PID is a nice but complex control system.
"winijenh" mention already the subject of tuning a PID.
How to determinate the constant for the:
) gain (factor)
) integration (time constant)
) differentiation (time constant)
So that you are sure that the system will be stable enough?
Or would it possible that a simple P control could do the job?
(Integration=0; differentiation=0;)
How many PID users are realy using the I and D part?
For example the DsPIC30 and DsPIC33 series (www.MicroChip.com).
Beside this hardware, there is also a DSP library with suitable functions, like filters etc.
There exist a lot of books about this subject and this on different level of abstraction level.
A PID is a nice but complex control system.
"winijenh" mention already the subject of tuning a PID.
How to determinate the constant for the:
) gain (factor)
) integration (time constant)
) differentiation (time constant)
So that you are sure that the system will be stable enough?
Or would it possible that a simple P control could do the job?
(Integration=0; differentiation=0;)
How many PID users are realy using the I and D part?
Re: Playing With Accelerometers
Carel,
Pcontrol only works in the simplest cases, with very slow results. You almost always need at least the derivative or integral term. There are simple manual tuning procedures, such as described here http://en.wikipedia.org/wiki/PID_contro ... ual_tuning, and the Ziegler–Nichols method (same Wikipedia article) provides good indications for useful values. Essentially, you start with the zeroing out the integral and derivative terms, cranking up the proportional term until the system oscillates continuously. Then you turn the proportional term back to 5060% of that value, and increase the derivative term to get a more 'snappy' positioning. Use of the integral term is full of pitfalls.
The TX has enough power do run a couple of PID algorithms in combination with a few 1 or 2 dimensional Kalman filters at 100Hz. No need for DSP for relatively simple 2 dimensional models, e.g. a Kalman filter calculating position and speed out of noisy position data and applied PWM values. I suspect you can get even more complex work done on the TX than that, when coding in C (rather than RoboPro) and hand optimizing the code.
Willem Evert Nijenhuis
Pcontrol only works in the simplest cases, with very slow results. You almost always need at least the derivative or integral term. There are simple manual tuning procedures, such as described here http://en.wikipedia.org/wiki/PID_contro ... ual_tuning, and the Ziegler–Nichols method (same Wikipedia article) provides good indications for useful values. Essentially, you start with the zeroing out the integral and derivative terms, cranking up the proportional term until the system oscillates continuously. Then you turn the proportional term back to 5060% of that value, and increase the derivative term to get a more 'snappy' positioning. Use of the integral term is full of pitfalls.
The TX has enough power do run a couple of PID algorithms in combination with a few 1 or 2 dimensional Kalman filters at 100Hz. No need for DSP for relatively simple 2 dimensional models, e.g. a Kalman filter calculating position and speed out of noisy position data and applied PWM values. I suspect you can get even more complex work done on the TX than that, when coding in C (rather than RoboPro) and hand optimizing the code.
Willem Evert Nijenhuis
Re: Playing With Accelerometers
@Winnijenh Nice video, your solution seems to work well, did you use the gyro or just the accelerometer?
Further to my previous post, an accelerometer on the arm at distance R sees the following accelerations:
horizontal (towards pivot): ax = ac + g*sin(phi) where ac is the centripetal acceleration (R*w^2 with w=angular velocity)
vertical: az = R*at + g*cos(phi) where at is the tangential angular acceleration, g is the acceleration of gravity
So we have 2 equations with 3 interesting unknowns: phi, w and at. When R=0 (sensor at pivot), phi can be computed as atan2(ax, az).
When we move the machine into the horizontal plane, g moves to the yaxis and ax and az correspond to centripetal and tangential acceleration but we have no information about phi.
When we have two accelerometers, one near a motor and the other in the middle or near the other motor, we can solve all three unknowns and the system can be controlled with three nested loops each with proportional control and without a gyro. But of course this is only theory....
Ad
Further to my previous post, an accelerometer on the arm at distance R sees the following accelerations:
horizontal (towards pivot): ax = ac + g*sin(phi) where ac is the centripetal acceleration (R*w^2 with w=angular velocity)
vertical: az = R*at + g*cos(phi) where at is the tangential angular acceleration, g is the acceleration of gravity
So we have 2 equations with 3 interesting unknowns: phi, w and at. When R=0 (sensor at pivot), phi can be computed as atan2(ax, az).
When we move the machine into the horizontal plane, g moves to the yaxis and ax and az correspond to centripetal and tangential acceleration but we have no information about phi.
When we have two accelerometers, one near a motor and the other in the middle or near the other motor, we can solve all three unknowns and the system can be controlled with three nested loops each with proportional control and without a gyro. But of course this is only theory....
Ad
Re: Playing With Accelerometers
@Ad2: I used just the accelerometer to recreate rei_vilo's experiment. In fact, I used only 1 axis (like rei_vilo) and took an arcsin to get the angle, which is an approximation at best, as you point out. Accelerometers typically do not have a linear response (mine doesn't): the response is less at the extreme's (1g and +1 g). So for small angles using 2 axis and computing phi as arctan2(x,z) is only a marginal improvement, as long as the angles are small (say < 35 degrees), especially since the z signal get too close to the noise levels of the TX AD converter at the extreme's.
I'd love to get some practical data on how good (or bad) the approximation is, when the (single, 2 axis) sensor is removed R from the pivot axis. And how much better will the data get when I use a 2nd sensor to account for lateral acceleration?
In practice though, for a balancing robot, it seems that the gyro is used as the main sensor, and the accelerometer functions to correct gyro drift only and to provide some absolute sense of 'up'.
As soon as I get my incremental encoders mounted on the PowerMotors, I'll start working on the balancing bot...
Willem Evert.
I'd love to get some practical data on how good (or bad) the approximation is, when the (single, 2 axis) sensor is removed R from the pivot axis. And how much better will the data get when I use a 2nd sensor to account for lateral acceleration?
In practice though, for a balancing robot, it seems that the gyro is used as the main sensor, and the accelerometer functions to correct gyro drift only and to provide some absolute sense of 'up'.
As soon as I get my incremental encoders mounted on the PowerMotors, I'll start working on the balancing bot...
Willem Evert.
Re: Playing With Accelerometers
Hi,
The main advantage of the atan2 function is that you almost cannot have domain errors (only 0/0). When you don't need the zchannel you are probably right about resources because you don't have to filter that channel. Otherwise I don't think that atan2 is significantly more expensive than asin.
Ad
The main advantage of the atan2 function is that you almost cannot have domain errors (only 0/0). When you don't need the zchannel you are probably right about resources because you don't have to filter that channel. Otherwise I don't think that atan2 is significantly more expensive than asin.
Ad
Re: Playing With Accelerometers
Great stuff!
Actually, what I would like to see in your last plot is the deviation from the linear fit. What you did with Excel was to put a straight line through your data, e.g. [arcsin(x) ↦ atan2(x, y)] = A * x + B, where B is ideally zero and A is ideally one. Probably your fit returned some slightly different values, which is a good thing. You can look at your values via "Display equation on chart" in the trendline's options. Then apply the linear function you found to your data, dividing the arcsin(x) values by that function. Ideally, you would see f(x) = 1, e.g. one for all values and perfect correlation. Subtract one from that to see something around f(x)=0, and you see the deviation /in percent/.
Any deviations from zero are interesting at this point, giving insight to the precision of your conversion (1%? 0.1%? 5%?), as well as any remaining signal that could be considered as nonnoise.
Actually, what I would like to see in your last plot is the deviation from the linear fit. What you did with Excel was to put a straight line through your data, e.g. [arcsin(x) ↦ atan2(x, y)] = A * x + B, where B is ideally zero and A is ideally one. Probably your fit returned some slightly different values, which is a good thing. You can look at your values via "Display equation on chart" in the trendline's options. Then apply the linear function you found to your data, dividing the arcsin(x) values by that function. Ideally, you would see f(x) = 1, e.g. one for all values and perfect correlation. Subtract one from that to see something around f(x)=0, and you see the deviation /in percent/.
Any deviations from zero are interesting at this point, giving insight to the precision of your conversion (1%? 0.1%? 5%?), as well as any remaining signal that could be considered as nonnoise.
Re: Playing With Accelerometers
Hi all,
I'm not quite sure what we are trying to prove here. With an ideal sensor and measurement both methods are equivalent, I only suggested the atan2 function because of its domain properties (less need to scale) and the fact that it works for the full circle whereas other functions work only for a semicircle. When using the arcsin you have to scale the argument to [1, 1] with atan2 you only have to scale an argument when there is a significant gain difference in the two channels. I have not analysed the influence of noise and disturbances, I expect it to be a little bit better in the atan2 case because you use more data but the differences will not be dramatic. Furthermore the sensitivity of the arcsin decreases with increasing angle (derivative goes to zero near +/ 90 degrees), with the atan2 is effect is much less because for angles greater than 45 degrees you effectively start using the arctan of the supplementary angle.
But it remains true that this comes at a cost. I think that other factors like zero calibration, noise and drift are larger sources of error than the choice of function (especially in the range [45, 45] degrees).
Ad
I'm not quite sure what we are trying to prove here. With an ideal sensor and measurement both methods are equivalent, I only suggested the atan2 function because of its domain properties (less need to scale) and the fact that it works for the full circle whereas other functions work only for a semicircle. When using the arcsin you have to scale the argument to [1, 1] with atan2 you only have to scale an argument when there is a significant gain difference in the two channels. I have not analysed the influence of noise and disturbances, I expect it to be a little bit better in the atan2 case because you use more data but the differences will not be dramatic. Furthermore the sensitivity of the arcsin decreases with increasing angle (derivative goes to zero near +/ 90 degrees), with the atan2 is effect is much less because for angles greater than 45 degrees you effectively start using the arctan of the supplementary angle.
But it remains true that this comes at a cost. I think that other factors like zero calibration, noise and drift are larger sources of error than the choice of function (especially in the range [45, 45] degrees).
Ad
Zuletzt geändert von Ad2 am 06 Dez 2010, 14:27, insgesamt 2mal geändert.
Re: Playing With Accelerometers
As far as I can see, rei_vilo was trying to increase the sensor's precision by adding the second channel to the computation. This should reduce noise.
Of course I agree that it would be more reasonable to make a detailed analysis of the function "actual angle > measured angle" than of this computation trick.
Heiko
Of course I agree that it would be more reasonable to make a detailed analysis of the function "actual angle > measured angle" than of this computation trick.
Heiko

 Beiträge: 13
 Registriert: 09 Dez 2010, 15:35
Re: Playing With Accelerometers
Hello Willem Evert,
I am very impressed by your Robopro program "Windmill", especially by the use of a kalman filter.
For better understanding (of the filter) can you give me some background info of the used formulas.
and how did you determine the process noise sigma (80) ?
kind regards
Rien van Harmelen
I am very impressed by your Robopro program "Windmill", especially by the use of a kalman filter.
For better understanding (of the filter) can you give me some background info of the used formulas.
and how did you determine the process noise sigma (80) ?
kind regards
Rien van Harmelen
Re: Playing With Accelerometers
Rien,
Well, Carel provided some bed time reading...
The easiest way to determine the Kalman parameters is by trial and error. Of course there's theoretical input (like expected noise is in the order of X mV), but in practice what I do is I record the measured values in a list, save it as a .csv file, and build a spreadsheet with the Kalman filter (like this one I did with rei_vilo's numbers: http://82.95.86.128:8080/ftpub/Equilibrium.xlsx), where I can play with the parameters and see their effect in a graph.
Regards,
Willem Evert.
Well, Carel provided some bed time reading...
The easiest way to determine the Kalman parameters is by trial and error. Of course there's theoretical input (like expected noise is in the order of X mV), but in practice what I do is I record the measured values in a list, save it as a .csv file, and build a spreadsheet with the Kalman filter (like this one I did with rei_vilo's numbers: http://82.95.86.128:8080/ftpub/Equilibrium.xlsx), where I can play with the parameters and see their effect in a graph.
Regards,
Willem Evert.
Zuletzt geändert von winijenh am 27 Feb 2011, 15:16, insgesamt 1mal geändert.
Re: Playing With Accelerometers
Hi Rien and Willem Evert,
Now the theory, background and best practice come together.
Without theory and background, a best practice will not exist.
And a best practice without theory and background is not so far away from learning by doing (structured try and error). But what is the difference between learning by doing (structured try and error) and try and error?
Now the theory, background and best practice come together.
Without theory and background, a best practice will not exist.
And a best practice without theory and background is not so far away from learning by doing (structured try and error). But what is the difference between learning by doing (structured try and error) and try and error?
Zuletzt geändert von vleeuwen am 11 Dez 2010, 14:43, insgesamt 1mal geändert.
 Peterholland
 Beiträge: 324
 Registriert: 01 Nov 2010, 22:28
 Wohnort: Poederoyen NL
Re: Playing With Accelerometers
Bonsoir/Hallo Rei Vilo + Willem Evert,
I also build the two propellerWindmill using the Neuhold BeschleunigungssensorModul N5170
http://www.neuholdelektronik.at/catsho ... ts_id=3586
and trying the WindMill Robo Pro project file shared by winijenh aka. Willem Evert Nijenhuis in his post.
Is M1 the left Motor ? ............turning left giving liftup ?
Is M2 the right Motor ? ............turning left giving liftup ?
Is the Range of I2 about 1.2 V (left) ? 1.5V (middle) ? and 1.8 (right) ?
Grüss,
Peter
Poederoyen NL
I also build the two propellerWindmill using the Neuhold BeschleunigungssensorModul N5170
http://www.neuholdelektronik.at/catsho ... ts_id=3586
and trying the WindMill Robo Pro project file shared by winijenh aka. Willem Evert Nijenhuis in his post.
Is M1 the left Motor ? ............turning left giving liftup ?
Is M2 the right Motor ? ............turning left giving liftup ?
Is the Range of I2 about 1.2 V (left) ? 1.5V (middle) ? and 1.8 (right) ?
Grüss,
Peter
Poederoyen NL
Zuletzt geändert von Peterholland am 27 Dez 2010, 21:45, insgesamt 1mal geändert.
Peter Poederoyen NL