The PX4 autopilot is an amazing open source platform for research. It is one of the first open source autopilots capable of running an on-board extended kalman filter and other advanced control and navigation algorithms. It is also mass produced by 3D Robotics and very affordable.
Hardware Accelerated Extended Kalman Filter
Recently I have completed a C++ matrix library wrapper around the CMSIS digital signal processing library. This means we can now type matrix math like this:
// continuous covariance prediction
P = P + (F * P + P * F.transpose() + G * V * G.transpose()) * dt;// attitude correction
Vector y = zAtt - zAttHat; // residual
Matrix S = HAtt * P * HAtt.transpose() + RAttAdjust; // residual covariance
Matrix K = P * HAtt.transpose() * S.inverse();
Vector xCorrect = K * y;
P = P - K * HAtt * P;// attitude fault detection
float beta = y.dot(S.inverse() * y);// position correction
Matrix S = HPos * P * HPos.transpose() + RPos; // residual covariance
Matrix K = P * HPos.transpose() * S.inverse();
Vector xCorrect = K * y;
P = P - K * HPos * P;// position fault detection
float beta = y.dot(S.inverse() * y);
Not only is this very easy to read (similar to Matlab/ScicosLab), it is also hardware accelerated! Thanks to the CMSIS library, multiple floating point operations are executed in one CPU cycle. The result is running a 9 state, 9 measurement discrete time extended kalman filter only consumes 20% of the ARM cortex M4 processor.
You can see the entire example here.
Sensor Level HIL
In order to develop and test the EKF I also developed the capability for full sensor-level hardware-in-the-loop testing. Simulated sensor data is sent from the flight simulator directly to the autopilot. This means you can run a very high fidelity UAV simulation while sitting at your desk.
You can see the python script to run PX4 hardware in the loop here.
Object Oriented Control Library
For those that have followed my development, you know that I am a big fan of object-oriented code. While developing the fixed-wing autopilot, I also created a new control library that has a similar feel to what I wrote for ArduPilotOne. This makes it easy for control engineers and the like , who are familiar with block diagram control systems, to easily translate their ideas to code.
You can see an example here for fixed wing.
The features above are just some that I have recently contributed. There are many developers working on PX4 from around the world and many new developments happening every day! Soon a very powerful optical flow board will be released! I hope that you will join this great community!
Comments
Thanks for the input Bill! I intended to say vertical component of lift = weight, but I agree there are more complicating factors such as pitch rate etc. Since I just need the expected accel in the body frame do you think I can use the kinematics and calculate what it should be with pitch rate etc, and would this then be valid for both fixed wing and quads?
Also, it should be clarified that this is a combined attitude and position Kalman Filter. If you guys intend to use it for APM attitude estimation you will need to chop it in half :-). The combined filter can do cool things like correct the navigation velocity direction when it figures out that your attitude needs to be corrected.
It would indeed be interesting to see a performance comparison done on an attitude EKF and the DCM approach, but I think that it would be difficult to compare this combined EKF to the DCM since they have different capabilities.
Andrew and James,
Here is a link to a previous discussion of using EKF instead of DCM.
Paul Bizard did some simulations comparing his version of EKF with the first version of DCM, and reports that EKF performed better than DCM, particularly with respect to gyro offsets. I am not sure if Paul has repeated his simulations to incorporate recent improvements to DCM.
For example, I have extended DCM in several ways since we started out, to handle some problem situations that most folks are not even aware of, such as an effect I call "dizzy gyros", described in this post, which is an effect in which a very small accelerometer offset error or slight gyro gain error can create very large attitude estimation errors during sustained high rate rotations, and can even cause the computations to diverge. It would be interesting to see how EKF handles those situations.
Some of the other improvements in DCM are described here, such as a method for removing magnetometer offsets and a method for auto-aligning the gyro with the magnetometer, which is useful if the magnetometer is mounted separately from the gyros.
I speculate that EKF might be more accurate than the original version of DCM, but the steady improvements that have been made to DCM might narrow the performance gap, and might even produce better performance under some conditions.
So, it would be interesting to compare EKF with extended DCM. But if they do not agree, how will we know which one is right?
Best regards,
Bill Premerlani
Hi James,
Regarding compensation of accelerometer measurements for acceleration....
Lift does not in general equal weight for an aircraft, unless the plane is flying level in a perfectly straight line, without turning.
I do not think that estimating centrip acceleration with g*tan(phi) is going to work very well, for several reasons:
1. Just because a plane is banked does not guarantee that it is turning in a circle that corresponds to that bank angle. The centrip acceleration depends on other things as well.
2. Pitch rate comes into play as well, that is not included in g*tan(phi).
3. It is the error in phi that we want to remove, and any error in phi will cause error in the calculation, which will feed on itself.
The accelerometers measure the acceleration vector minus the gravity vector or vice-versa, depending on what sign convention that you use. You can also show that this identically equals the vector sum of the aerodynamic forces on the plane, which is equal and opposite to gravity only when the plane is not accelerating. When the plane is turning, even in a steady turn, it is accelerating.
What you are trying to get is a vertical reference, which is gravity. So, this means you must somehow account for acceleration, both centripetal, and forward.
For a fixed wing aircraft, you can estimate centripetal acceleration by computing the cross product of the rotation rate vector with the air (not ground) velocity vector. You can estimate forward acceleration as the time rate of change of the magnitude of the air velocity. Both computations assume that the wind speed is constant. Under those conditions, the time rate of change of the velocity in ground frame of reference is the time rate of change of the air velocity vector, which can be decomposed into components perpendicular and parallel to the air velocity vector. The perpendicular component is rotation rate crossed with air velocity vector. The magnitude of the parallel component is the time rate of change of the magnitude.
For multicopters, the above technique does not work. There are a couple of other options. One method is to ignore acceleration. There is another method that I have developed, described here and here, that is rigorously correct. However, it does require that you have accurate yaw information. It is my understanding that Tridge and Jonathan implemented it. Initially they had some problems with it, but I think they extended the idea, and now have something working.
Best regards,
Bill Premerlani
I think the ideal thing to do would be to run both AHRS_PX4_kalman and AHRS_DCM at the same time, fly them side by side on a fast moving aircraft (plane or copter) and look carefully at the differences in the attitude estimate. I think we could learn a lot from the comparison.
I suspect the biggest advantage of the EKF will come when a sensor fails or is otherwise degraded. Otherwise I'd be surprised if it gives a big difference, but it would be nice to find out!
Cheers, Tridge
Great to hear you have it working Tridge!
This is great work James!
Regarding the people asking about ArduCopter for PX4, we expect the next release of ArduCopter (2.9.1) will support the PX4. It has been test flown a few times already and is flying well. The current github master branch supports PX4 for ArduPlane, ArduCopter and APMrover2.
This is a port of the existing code that runs on APM2 and APM1. It doesn't use the EKF that James has been working on, although I hope that will be an option at some point in the future (probably via a AHRS_kalman_px4 class).
I've done lots of flights of my SkyFun with ArduPlane on PX4 and it is flying very nicely.
Cheers, Tridge
@Angelo The relevant code is here:
I ignore the accel correction currently at high g's. With the math library though you can see that it would be relatively easy to add it. If we assume the vertical component of lift = weight and make some other assumptions, we can use the equations here: http://en.wikipedia.org/wiki/Banked_turn . Then the mag of the centrip accel would be g*tan(phi). The direction would be in the intermediate frame before the final roll rotation to the body frame. At one point I had this, but was concerned about the generality of the the vertical component of lift = weight assumption. Possibly we could do a check on the vertical acceleration? What is your opinion?
James,
DCM made correction for dynamic acceleration (centripetal and velocity change). The original PX4 EKF doesn't. What about yours ? If yes, will it work also under high G's ?
Angelo
@Gary, I believe the port of Arducopter to PX4 is pretty much done, for quads only. I think it's being beta test flown right now. They still have to do some work to make this easily useable for regular people. Also, the IO board is not working yet, so anything that requires more than 4 PWM streams won't work.
Hi James,
thanks ... i check it and i think that i need your help for have some suggestions about the integration in arducopter32.
About the uORB and nuttx i prefer to continue to use our revision of code without O.S. because we have a lot of fly hours on it . In my early test on nuttx i see that in some situation the O.S. don't serve the interrupt in real time as i expect so i prefer to use flat loop in main code as in standard 8 bit arducopter. When we finish the developing of AP_HAL_VRBRAIN we start on VRBRAIN 4.5 to test nuttx.
Best Roberto
-
2
-
3
-
4
-
5
-
6
of 6 Next