47 replies to this topic

[Tim Trueman]

If I was building my own AHRS I would want multiple filters running in the case that one of them diverged or something happened.

1. Would you agree—that two filters running simultaneously would be ideal?
2. If the EKF I've built can be ported what other algorithm would make sense?
3. Who can do such a dirty deed (work on the other filter)?

[Angus]

Running two filters simultaneously would be ideal if either of the filters couldn't be trusted 100%.
As far as what other filter I guess it would be beneficial to have something quite different, possibly the complete DCM.

We have lots of processing power, as long as you used fixed point math. Since the STM32 doesn't have an FPU we can't do floating point math without adding lots of overhead. To get more than one filter going we would probably need to stick with fixed point.

Once the hardware is here and we can start testing things we will know how much we can do on the processor. I think it will be quite a while before we hit the processing power limit of the STM32.

We also have a different STM32 on the AHRS than before. We are using one with 128k of flash (compared to 64k before) so we have lots of space to fit multiple filters.

[Tim S]

I wonder if that would provide a false sense of security.

I would imagine that a failing filter would give inaccurate results, rather than invalid ones.

How would you:
    a) Detect filter failure (obviously Divergence, as you mentioned) would be a pretty good sign something was going odd)
     Choose which signal to trust.

My gut feeling would be that twice as much heavy maths means twice as much potential for bugs, and you're still left with the problem of not knowing which data to trust.

On the other hand, that kind of capacity would be really useful for testing and tuning filtering strategies against each other, and diverging results could trigger a basic limp-home mode or parachute trigger).

Oh,  and Hi everyone,  I'm normally a professional loiterer at places like this,  but I heard about the OpenPilot project on the DIYDrones podcast, and thought it was really interesting because of the approach you guys are taking and because the project is based out of Australia so I can actually get hold of the parts without worrying about shipping/export restrictions etc.

[dankers]

Welcome Tim, personally I would agree, one solid filter is the way to go. I believe Mr. Trueman is basically saying don't trust his filter too much right now and also being modest. However if his EKF has issues, we will make sure we fix them so it is solid and won't diverge and we learn as we go. Humble developers write the best code and we are real happy Tim T is coming along for the ride

Multiple different filters running on the same AHRS is just over complex and not only waste cycles but has its own set of issues like the ones you point out so we likely do want to avoid this.

As you are likely aware, the beauty of an AHRS rather than an IMU or a single board solution is that we can treat it as a separate black box, whilst Tim T is working on his EKF, Vassilis (one of the founders) has some code he did for another project based on DCM that he could adapt for the AHRS. Finally, we are a project to make something cool and totally non-commercial, I believe our AHRS will be very attractive to other projects because of the $250 price, if it was sold commercially it would be around $600. If other projects do adapt it, I hope they will do the right thing and give back some code.  

My hope with both OpenPilot and the AHRS is that we get a large community around both of them.

[Tim S]

For in-flight testing purposes I would imagine that the Kalmann orientation outputs (pitch/yaw/roll) shouldn't deviate too far from the current, or maybe linearly smoothed magnetometer values, and if the filter is under/over-reporting rotation rates from the gyros the Autopilot's PID should oscillate around it's set-point, or a running tally of gyro readouts would start getting out of sync with the reported orientation much faster than drift.

Actually, now that I look back on that paragraph, running all those checks manually probably isn't any less work than hacking together some kind of alternative filter. (And don't look at me, I tried to write a Kalmann from first principles and failed).

But really I have no idea. I'm really looking forward to seeing how well the magnetometer works, I know general aviation is starting to use them a lot, I went for a flight in a Piper with an Aspen (http://www.aspenavionics.com/ <-- website plays a sound on entry) on the weekend, it uses a magnetometer + gps) for it's artificial horizon / positioning. And the Horizon seemed rock solid and quite responsive.

It'll be great for the project to have a solid AHRS, I imagine a UAV focussed Kalmann implementation which is unambiguously open source will get a lot of interest.

[James]

As I understand it the aim of openpilot is to operate on a large number of different platforms which means the AHRS filter can not be tightly tuned for any of them. Aspen Avionics will know the dynamics of general aviation planes very well. Unless openpilot relies on the end user to tune the filter, it'll be quite a challenge to get a high precision 'one size fits all' filter.

Back on the original post, it's a sensible idea. EKFs are prone to go numerically unstable. If there's spare capacity then maybe something for the future?

[Paul_BB]

Tim Trueman, on 22 February 2010 - 05:06 PM, said:

If I was building my own AHRS I would want multiple filters running in the case that one of them diverged or something happened.

1. Would you agree—that two filters running simultaneously would be ideal?
2. If the EKF I've built can be ported what other algorithm would make sense?
3. Who can do such a dirty deed (work on the other filter)?

Hi Tim,

I've contacted Dave and I am willing to help the team with EKF or DCM. I see that you are also working on an EKF and Vassili on a DCM so I hope I don't interfere too much.
How may I help the team on those subjects ?

Cheers,
Paul

[Vassilis]

All,

I implemented the DCM as per Bill's and Paul's paper and flight tested it on my quad. It works fairly well but there are a few things missing (yaw drift and centripetal force corrections). Besides that it worked fairly well, I had to do some heavy oversampling and FIR filtering on the raw data before I used them in the DCM.

The platform I used is the CHR-6D IMU which is also using the STM32! I added my code on top of the already open sourced code that had the sensor acquisition and filtering already implemented. I also have a Matlab script that I used for simulation and post processing of data.

We should be able to use that as a starting point and get an AHRS up and running fast.

More information and the source code can be found at:

http://vrhome.net/va...the-chr-6d-imu/

From your experience what is the best way to go, EKF or DCM? I have tried both but on a different platform so I can not make a direct comparison, also I would not claim that I fully understand the math so you may be able to shed some light on the pros and cons. Personally I find the DCM easier to understand and I have not seen any issues in my basic implementation (which can be certainly improved!).

Also I would recommend that we start with one filter (EKF or DCM) and focus on making it work reliably.

@Paul, Tim,

We could definitively use some help on this one! If we decide to start with the DCM, I am sure there are plenty of improvements and optimizations to be made. I recommend that you have a look at the DCM implementation and let us know if it is worth improving or starting with an EKF from scratch. We still have a lot to learn on both DCM and EKF so your help would be greatly appreciated.

Let me know if you have any questions on the code.

[dankers]

As Paul's EKF is already written and he himself states it is 10 times better than DCM, plus it is the area Tim T is interested in, I would say we go to Paul's EKF from the start. Save double lifting and saves adding bits to DCM when the EKF is complete.

Just my thoughts.

[Angus]

I think we should start with the EKF filter that Paul has written, since it should be fairly trivial for us to port that to our hardware, as it's already written in C and fairly complete.
We already have PiOS mostly finished so things like chip setup and ADC is all ready to go.

DCM was only a stop gap to let us get an AHRS working so we weren't held back with the flight code, since Paul already has a working EKF in C, I think we should focus on implementing that, if that's ok with Paul.

[Paul_BB]

Angus, on 27 February 2010 - 05:34 AM, said:

I think we should start with the EKF filter that Paul has written, since it should be fairly trivial for us to port that to our hardware, as it's already written in C and fairly complete.
We already have PiOS mostly finished so things like chip setup and ADC is all ready to go.

DCM was only a stop gap to let us get an AHRS working so we weren't held back with the flight code, since Paul already has a working EKF in C, I think we should focus on implementing that, if that's ok with Paul.

That's ok with me. I'll just have to adapt the code to magnetometers rather than GPS but that's not big deal. We only need to extract the projection of the magnetic vector onto the earth X-Y plane. No need to delay the quaternion because the magnetometers do not have any lag. We have the processing power so let's go for EKF. We will have a 1° accuracy. But first, we need to test the magnetometers near a running brushless motor.

Cheers,
Paul

[Angus]

Your exactly right, we have the processing power for a reason, we might as well take advantage of it and use it.

The magnetometers will need a bit of testing to see how susceptible to brushless motors they are, if it is quite bad I was thinking we could try using the GPS to correct any bias?

1° accuracy would be great! What I am really interesting in though is the drift, but with the EKF and the gyros we have I think we should be able to get it fairly low, especially when we start doing things like temperature compensation lookup tables

[Paul_BB]

Angus, on 27 February 2010 - 12:29 PM, said:

Your exactly right, we have the processing power for a reason, we might as well take advantage of it and use it.

The magnetometers will need a bit of testing to see how susceptible to brushless motors they are, if it is quite bad I was thinking we could try using the GPS to correct any bias?

1° accuracy would be great! What I am really interesting in though is the drift, but with the EKF and the gyros we have I think we should be able to get it fairly low, especially when we start doing things like temperature compensation lookup tables

A freind of mine has tested this week the Xsens IMU and reported that it was immune to the 1000W running brushless motor when it was located 15 cm away from it.

I think that we will not need the temperature compensation with the EKF.

[Angus]

Paul_BB, on 27 February 2010 - 12:49 PM, said:

A freind of mine has tested this week the Xsens IMU and reported that it was immune to the 1000W running brushless motor when it was located 15 cm away from it.

I think that we will not need the temperature compensation with the EKF.

Temperature compensation hardware is there if we need it, but the process of running a sweep through a temperature range is out of most people reach, so it would be good if we don't need it.

That is very impressive by the XSense. Do you know if that is from the raw sensor or if there is some sort of digital filtering involved?

[Vassilis]

I may have missed a few discussions here, if there is already code for the EKF then we should not bother with the DCM.

Can somebody give me some details on why the EKF is so much better (or point me to the thread if it was discussed already)?

[Tim Trueman]

Angus, on 27 February 2010 - 12:29 PM, said:

Your exactly right, we have the processing power for a reason, we might as well take advantage of it and use it.

The magnetometers will need a bit of testing to see how susceptible to brushless motors they are, if it is quite bad I was thinking we could try using the GPS to correct any bias?

1° accuracy would be great! What I am really interesting in though is the drift, but with the EKF and the gyros we have I think we should be able to get it fairly low, especially when we start doing things like temperature compensation lookup tables

This should cover any magnetometer calibration you need to do: http://dronedynamics...eticsensors.pdf

[Tim Trueman]

I think EKF is the way to go and there may be times where having a VGO or DCM or something makes sense (I've never seen a working EKF that doesn't have singularities but I would love to be proven wrong).

While my code isn't in C it is open source and rapidly improving (and it knows when it's departed and which output has departed): http://github.com/dronedynamics/Shumai

Paul here are some questions for you:

• What are the required sensors/inputs?
  
• What are the outputs (e.g. do you do wind estimation?)
  
• How do you know your EKF is within 1 degree of accuracy? Can we benchmark your EKF in a simulator?
  
• How far along is your code?
  
• Is it currently open-source / can we see it?
  
• What did you base your code on? A paper? Your own research?
  
• Can we combine efforts?

[Paul_BB]

Angus, on 27 February 2010 - 01:16 PM, said:

Temperature compensation hardware is there if we need it, but the process of running a sweep through a temperature range is out of most people reach, so it would be good if we don't need it.

That is very impressive by the XSense. Do you know if that is from the raw sensor or if there is some sort of digital filtering involved?

No I don't know. I've ask my freind but he does not know if he read raw magnetometer data or something already filtered.

[Paul_BB]

Tim Trueman, on 27 February 2010 - 05:55 PM, said:

I think EKF is the way to go and there may be times where having a VGO or DCM or something makes sense (I've never seen a working EKF that doesn't have singularities but I would love to be proven wrong).

While my code isn't in C it is open source and rapidly improving (and it knows when it's departed and which output has departed): http://github.com/dronedynamics/Shumai

Paul here are some questions for you:

• What are the required sensors/inputs?
  
• What are the outputs (e.g. do you do wind estimation?)
  
• How do you know your EKF is within 1 degree of accuracy? Can we benchmark your EKF in a simulator?
  
• How far along is your code?
  
• Is it currently open-source / can we see it?
  
• What did you base your code on? A paper? Your own research?
  
• Can we combine efforts?

Hi Tim,

Inputs:
magnetometer mx my mz
accelerometer accx accy accz
gyrometer gx gy gz
airspeed magnitude (or GPS speed is airspeed not available)

Outputs:
Quaternion
DCM matrix
Euler angles

Attached is the code I used to simulate the Kalman (in a txt file, I cannot upload a .c file)
I cannot attach the .doc draft where I explain the EKF ? You can find it here:
http://diydrones.com/page/uav-devboard
look for "Paul Bizard S-Function"

I already benchmarked the EKF with my airplane Simulink simulator. I developped the DCM with Bill Premerlani and then the EKF alone to benchmark the DCM.
It is accurate up to 1°.

It relies on the GPS for yaw estimation and GPS speed for centrifugal compensation but it will easily be converted to the magnetometer and the airspeed.

I will test the conversion with my simulator.

Of course we can join our efforts !

My work is based on the DCM we developped with Bill P.
The structure is the same, the difference is what is done with the error:
- a simple PI for DCM
- Kalman gain for EKF

I used the quaternion representation for the EKF to minimize the number of states (the computational load)

Attached Files

•  EKF.txt   40.22K   322 downloads

[Paul_BB]

Vassilis, on 27 February 2010 - 03:14 PM, said:

I may have missed a few discussions here, if there is already code for the EKF then we should not bother with the DCM.

Can somebody give me some details on why the EKF is so much better (or point me to the thread if it was discussed already)?

Hi Vassili,

EKF is better than DCM because DCM uses a simple Proportional Integral feedback to compensate for gyro drift while EKF is based on Kalman's theory. Kalman filtering is an identification method close to the recursive least squares algorithm. It minimizes the state variance.
I've read somewhere that the Apollo program could of not happen without the Kalman filter.

There is not one airplane, one rocket, one missile or one satellite in the world without a KF.
You have KF for linear problems, EKF for non linear problems. (You also have better for non linear problem with the Unscented KF -UKF-, and particle filters).

In the case of the airplane attitude estimation it is very stable. The performance of a filter is defined by the accuracy and the stablility.
I have compared DCM and EKF for airplane attitude estimation: for the same robustness, EKF is 10x more accurate, or, put it another way, for the same accuracy EKF is 10x more robust.