I've been reviewing the latest developments in "Adaptive Control" as opposed to PID control and came across this video of a quad adapting to a broken rotor blade. Hopefully, we will soon use these types of algorithms in our own diydrones projects.
With added noise and time varying input and a bit of modification the results are still amazing. The filter settles in a single movement, capturing gain, spring constant and drag.
As mentioned in a previous post, gain is the most difficult to measure. The time window for measurement is short compared to the remaining movement period. The gain measurement tends to be polluted in phases where it can not be measured. This was fixed by switching off the gain estimation when it is difficult to measure. It is a hack but it works well for now.
The other parameters are very dependant on getting the gain measurement correct and stable. Once the gain is fixed, The other paramters fix themselves.
At the moment drag is modelled as linear with velocity and springiness as linear with position. This could change to a different function if it fits the measured system better.
The measurements are so good that I am condident that some parameters could have more than one order. For example, the gain/input response could have a first and third order term. This would help solve actuator non linearities.
Even order parameters are a problem since the system is not symmetrical that way. It looks like even orders can be approximated by an expansion of odd orders.
I will post the matlab files and results to anyone wishing to comment, use or plagiarize.
Some caution:
I am not sure that the shape of the noise is correct. Some of the measurement noise should be linked together and some independant.
I need to add some well shaped turbulence noise to the simulation. At the moment this process noise is just random added.
Next steps:
Modify the filter to each axis of the flight model. I need an aerodynamics expert for this.
Move this whole process into a flight simulator plugin. Testing and tuning will be easier there than the real world where debugging is difficult.
Credit must go to Yi Cao of Cranfield University. He posted this excellent matlab EKF. The key feature of this EKF is the numerical analysis of functions to find differential gradient. In other words, much brainwork is removed so development time is very quick.
Matlab is working very nicely. I am using an extended kalman filter to estimate system parameters gain, force, damping and spring. It is quite stable and settles quickly on clean synthesized data.
Next step is to add some noise and try a variable input instead of a step function.
Eventually I will attach this whole thing to real world data. I am prepared for dissapointment.
Thanks for the advice on matlab. It certainly solves data plotting problems and my maths is far from excellent. It has been a long while since I used matlab but the re-learning should not be too painful.
I am not sure how quick and simple the learning filter can be.
Rudder inputs result in a yaw position but it takes time to get there
Roll input can be very slow to respond at low airspeed, large wing span and/or high mass
I am still looking for any ready made solutions. Descriptions of Kalman filter smoothing functions seem to suggest that is the right thing to use.
Thanks for the explanation, I truly misunderstood what you meant on the first post.
Of course the parameter estimation has to be obtained from a Dynamic Response, I failed to specify what I was asking. What kind of test do you plan on implementing? From my experience the parameters obtained with the best algorithm always are as good as the test itself.
My original comments where based on the assumption that the community wanted something "quick and simple", but seeing ambition and scope you should probably dismiss some of them.
If your math is not "excellent" I would definitely recommend Matlab! It has saved me hundreds of hours when I'm working with anything math intensive.
The tuning has to be based on some kind of dynamic response. There is no way to measure parameters in a stable/static system.
The parameters I require should be observable by the following thinking:
1. Gain is acceleration caused by input. Mass is assumed constant/unity.
Gain can be measured by change of acceleration on change of input
The key problem is correlation between input change and gain change
any phase / lag causes a very false measurement.
2. Drag can be measured by the terminal velocity at a constant input.
It is easiest to measure drag at low displacement and high velocity.
Large displacement means interference from spring effects
3. Spring constants are measured by either
a. The terminal position at constant input (i.e. rudder vs yaw angle)
b. Acceleration change when returning input to zero.
c. Change in velocity over distance.(hardest)
Each of these conditions is detectable. Reliably detectable is another problem. The kalman gain equations come in useful for this.
I do not intend to have a true live system. The measurements should not be immediately used for the control loop. My preference is to have a groundstation review the results at a lower data rate than the raw data. The groundstation can then do further data fits to airspeed and other parameters. The final result should be a cross between modelled performance and lookup tables.
I am hopefull that I can get a filter to settle in a few cycles i.e. roll the aircraft a few times in each direction.
You are right about instability. So far I have only managed to make my filter settle under some very restricted conditions.
One notable problem is calculation around zeros. The calc for spring constant is Force/displacement. At low displacement the result is very sensitive. At zero displacement the maths crashes.
The maths (matrix or otherwise) needs to be scaled around the conditions to avoid this. There may be another way but I am not seeing it yet.
My investigations are so far based on an excel spreadsheet. This has been good for initial investigation but it is difficult for implementing matrix maths. I intend to move to matlab or C++. There are some good kalman libraries for each.
There is also an auto parameter fitting library that needs a little more investigation.
Hope this helps in some way. Unfortunately I have more questions than answers at the moment.
It is a one time only calculation process since it's based on a long test. Normally a 1 or 2 hour test is used to feed the system and calculate the parameters. This aproach reduces drastically the impact of individual datapoints.
Continuous processes have some major disadvantages because they can become unstable very quickly... which is really bad for a UAV.
Can you elaborate a bit more about your tunning strategy? Are you planning on tunning based on the dynamic response?
Is that a one time calculation process or a continuous learning process?
I am developing a learning process to go on the autopilot. I would like to avoid relying on high bandwidth telemetry links.
A one time process is not appropriate for the AP because of data storage requirements. It needs a continuous process that can understand the difference between good and bad datapoints.
I do not expect perfect results. +-30% measurement would do for a start.
I hope to measure these parameters to tune a PID or other:
Non linear gain (input and input^2)
Drag (velocity^2?)
Springiness (linear and non linear)
I am pretty sure I will be re-inventing the wheel. If you know of any good proven open source wheels, please let me know.
The algorithm is really not that complicated, it's based on the classic recursive aproach of the minimum square roots identification algorithm. The only problem I could forsee is that a fairly random noise signal must be used to stimulate the system, which could be complicated on a quadrotor or a plane, BUT I'm sure we can find a workarround.
I don't know where I have the code since I wrote it like 1.5 years ago, but I'll start looking.
Maybe we could port the code to the ardupilot station, or we could build it as a standalone.
@ Raymundo, I do not have labview (our quadrotor controller design is AVR-based, but does not use Ardupilot). But if you're willing to share the algorithm details, I would certainly like to take a look.
Comments
With added noise and time varying input and a bit of modification the results are still amazing. The filter settles in a single movement, capturing gain, spring constant and drag.
As mentioned in a previous post, gain is the most difficult to measure. The time window for measurement is short compared to the remaining movement period. The gain measurement tends to be polluted in phases where it can not be measured. This was fixed by switching off the gain estimation when it is difficult to measure. It is a hack but it works well for now.
The other parameters are very dependant on getting the gain measurement correct and stable. Once the gain is fixed, The other paramters fix themselves.
At the moment drag is modelled as linear with velocity and springiness as linear with position. This could change to a different function if it fits the measured system better.
The measurements are so good that I am condident that some parameters could have more than one order. For example, the gain/input response could have a first and third order term. This would help solve actuator non linearities.
Even order parameters are a problem since the system is not symmetrical that way. It looks like even orders can be approximated by an expansion of odd orders.
I will post the matlab files and results to anyone wishing to comment, use or plagiarize.
Some caution:
I am not sure that the shape of the noise is correct. Some of the measurement noise should be linked together and some independant.
I need to add some well shaped turbulence noise to the simulation. At the moment this process noise is just random added.
Next steps:
Modify the filter to each axis of the flight model. I need an aerodynamics expert for this.
Move this whole process into a flight simulator plugin. Testing and tuning will be easier there than the real world where debugging is difficult.
Credit must go to Yi Cao of Cranfield University. He posted this excellent matlab EKF. The key feature of this EKF is the numerical analysis of functions to find differential gradient. In other words, much brainwork is removed so development time is very quick.
http://www.mathworks.com/matlabcentral/fileexchange/18189
Please excuse my lack of maths terminology. It has been a long time since I did maths class. I am wishing I had payed more attention.
Kalman still rocks...
I'm glad you're getting good results with matlab! Keep me posted about your results...
Ray,
Matlab is working very nicely. I am using an extended kalman filter to estimate system parameters gain, force, damping and spring. It is quite stable and settles quickly on clean synthesized data.
Next step is to add some noise and try a variable input instead of a step function.
Eventually I will attach this whole thing to real world data. I am prepared for dissapointment.
Kalman is the man...no question, he rocks!
Matt
Thanks for the advice on matlab. It certainly solves data plotting problems and my maths is far from excellent. It has been a long while since I used matlab but the re-learning should not be too painful.
I am not sure how quick and simple the learning filter can be.
Rudder inputs result in a yaw position but it takes time to get there
Roll input can be very slow to respond at low airspeed, large wing span and/or high mass
I am still looking for any ready made solutions. Descriptions of Kalman filter smoothing functions seem to suggest that is the right thing to use.
Matt
Matt
Thanks for the explanation, I truly misunderstood what you meant on the first post.
Of course the parameter estimation has to be obtained from a Dynamic Response, I failed to specify what I was asking. What kind of test do you plan on implementing? From my experience the parameters obtained with the best algorithm always are as good as the test itself.
My original comments where based on the assumption that the community wanted something "quick and simple", but seeing ambition and scope you should probably dismiss some of them.
If your math is not "excellent" I would definitely recommend Matlab! It has saved me hundreds of hours when I'm working with anything math intensive.
Ray,
The tuning has to be based on some kind of dynamic response. There is no way to measure parameters in a stable/static system.
The parameters I require should be observable by the following thinking:
1. Gain is acceleration caused by input. Mass is assumed constant/unity.
Gain can be measured by change of acceleration on change of input
The key problem is correlation between input change and gain change
any phase / lag causes a very false measurement.
2. Drag can be measured by the terminal velocity at a constant input.
It is easiest to measure drag at low displacement and high velocity.
Large displacement means interference from spring effects
3. Spring constants are measured by either
a. The terminal position at constant input (i.e. rudder vs yaw angle)
b. Acceleration change when returning input to zero.
c. Change in velocity over distance.(hardest)
Each of these conditions is detectable. Reliably detectable is another problem. The kalman gain equations come in useful for this.
I do not intend to have a true live system. The measurements should not be immediately used for the control loop. My preference is to have a groundstation review the results at a lower data rate than the raw data. The groundstation can then do further data fits to airspeed and other parameters. The final result should be a cross between modelled performance and lookup tables.
I am hopefull that I can get a filter to settle in a few cycles i.e. roll the aircraft a few times in each direction.
You are right about instability. So far I have only managed to make my filter settle under some very restricted conditions.
One notable problem is calculation around zeros. The calc for spring constant is Force/displacement. At low displacement the result is very sensitive. At zero displacement the maths crashes.
The maths (matrix or otherwise) needs to be scaled around the conditions to avoid this. There may be another way but I am not seeing it yet.
My investigations are so far based on an excel spreadsheet. This has been good for initial investigation but it is difficult for implementing matrix maths. I intend to move to matlab or C++. There are some good kalman libraries for each.
There is also an auto parameter fitting library that needs a little more investigation.
Hope this helps in some way. Unfortunately I have more questions than answers at the moment.
Matt
It is a one time only calculation process since it's based on a long test. Normally a 1 or 2 hour test is used to feed the system and calculate the parameters. This aproach reduces drastically the impact of individual datapoints.
Continuous processes have some major disadvantages because they can become unstable very quickly... which is really bad for a UAV.
Can you elaborate a bit more about your tunning strategy? Are you planning on tunning based on the dynamic response?
Is that a one time calculation process or a continuous learning process?
I am developing a learning process to go on the autopilot. I would like to avoid relying on high bandwidth telemetry links.
A one time process is not appropriate for the AP because of data storage requirements. It needs a continuous process that can understand the difference between good and bad datapoints.
I do not expect perfect results. +-30% measurement would do for a start.
I hope to measure these parameters to tune a PID or other:
Non linear gain (input and input^2)
Drag (velocity^2?)
Springiness (linear and non linear)
I am pretty sure I will be re-inventing the wheel. If you know of any good proven open source wheels, please let me know.
Matt
The algorithm is really not that complicated, it's based on the classic recursive aproach of the minimum square roots identification algorithm. The only problem I could forsee is that a fairly random noise signal must be used to stimulate the system, which could be complicated on a quadrotor or a plane, BUT I'm sure we can find a workarround.
I don't know where I have the code since I wrote it like 1.5 years ago, but I'll start looking.
Maybe we could port the code to the ardupilot station, or we could build it as a standalone.