Successful flight testing of MatrixNav is complete. MatrixNav is open source C firmware for the UAV DevBoard that provides pitch stabilization and return to launch functions for inherently stable aircraft that are controlled by rudder and elevator. MatrixNav is built on top of a method for integrating gyro signals into orientation information called direction-cosine-matrix (DCM). Flight tested firmware and documentation are available.A dozen test flights were made with an electric powered Gentle Lady under the following conditions:1. Both calm and windy conditions.2. Powered and gliding.3. Return to launch with the plane pointing away, toward, or perpendicular to me.4. Circling behavior under RTL control after the plane crosses the launch point.5. Hand launch in both manual and pitch stabilized modes.6. Landings with pitch stabilization turned on.MatrixNav completely solves an issue that I wrestled with in previous versions of my firmware: gyro cross coupling during a banked turn. If you attempt to use a pitch gyro signal to stabilize the pitch of a plane, it will measure a portion of the turn rate of the plane during a banked turn, and will cause the plane to dive into a turn if the bank angle is too great. The use of direction cosines eliminates the cross coupling and makes it simple to achieve a level turn at any bank angle.Furthermore, since MatrixNav relies mostly on gyros, not accelerometers, I was finally able to turn on pitch stabilization during hand launch.I added a feature to give the plane a kick during return to launch: you can program in the return to launch pitch angle. By deliberately pitching the nose down a bit, you can increase the return speed to better penetrate the wind.MatrixNav is intended for you to either use as-is, or to serve as the starting point for your own projects. So if you have a UAV DevBoard and want to use it to do some flying of an inherently stable plane, you will definitely want to try out MatrixNav.By the way, the MatrixNav documentation is not up-to-date about what the LEDs will do. Sorry about that, I really don't look at the LEDs anymore, they are usually hidden in my plane. Here is what they do:1. The LED on the EM406 will go out entirely, because MatrixNav puts the GPS communications in binary mode.2. Both LEDs on the the dev board will come on briefly during power up, to self test them.3. After power up, the green LED, stat2, will indicate whether or not MatrixNav is receiving valid pulses. It will be on continuously if there are valid pulses, otherwise it will go out.4. After power up, the red LED, stat1, will flash a few times, and then go out until the GPS is locked, and then it will resume flashing.After power up, MatrixNav goes through an initialization process that waits for both GPS lock and valid radio pulses. When pulses are received and when there is GPS lock, the rudder will wag a few times. When it stops wagging, MatrixNav records the present location as the return to launch point and you are cleared for takeoff.Bill Premerlani
Greetings,
Hello Bill,
Have a look at my synopsis here and let me know if you think I'm on the right track.
It seems like a little confusion has built up around the terminology being used for Bill's excellent implementation of Mahony's approach to estimating a DCM. A DCM or "Discrete Cosine Matrix" is simply a rotation matrix for transforming from one reference frame to another - In this case from a local earth based reference frame (North,East,Down) to a body reference frame. This is useful because all of our on board rate sensors are in the body frame but we need to know how the rates are impacting our local earth based orientation (which way is down? What is my heading?....).
DCM's are actually very commonly used in navigation as well as countless other areas where data needs to be rotated. The real magic is how to generate the DCM. Kalman filters can and often are used to generated DCM's. Most of the Kalman Filter implementations I've seen being used by hobbiest tend to be just single axis filters instead of a full up three axis implementation, so no DCM is necessary. Sometimes someone may have two filters running, one to handle roll and another to handle yaw for instance. The problem with this is non-linearities and cross coupling start to occur as the craft deviates from straight and level in more than one axis at a time (rolling over 45 degrees while also climbing for example.). The 3 axis simply can't be treated as independent for a truly robust solution.
But a Kalman filter approach could be used to generate a correct DCM and can be made to work very well. The problem with a properly implemented Kalman filter approach is that they are mathematically optimized to produce the statistically smallest error possible for a given set of input parameters. This means there is a lot of extra mathematical "baggage" involved (fine for the analyst with infinite processing power on there desktop) and the characteristics of the inputs (our rate sensors) needs to be fairly well understood and consistent. If we don't make good estimates of noise and gain, the Kalman Filter may take a long time to converge, or possibly never converge if things are too far off.
The exciting thing about Bill's work is that it gives us a full 3 axis implementation that handles all the cross terms correctly regardless of aircraft orientation and has been carefully designed to work with limited processing power.
Even if we continue to refer to this as the DCM approach I think it's important to remember that it's the estimation of the DCM that's unique and magical not the fact that a DCM is used. I would like to see a little more discussion about how the sensor inputs are merged to eliminate drift, offset and gain errors. This will be important when we attempt to use other sensors such a magnetometer to correct for these errors instead of (or in addition to) GPS and accelerometers. I look forward to Bill's upcoming paper.
I'm so excited about this approach that I've decided to design my own autopilot board. It will be based on a PIC32 and will include 5 PWM inputs and outputs, micro SD card based data logging, magnetometer, battery current and voltage monitoring, altimeter and airspeed measurements and much more. I plan on making this design open source and will post in a couple of days in a new thread when the schematics are ready for uploading.
Sorry for the long post. I wanted to thank Bill for sharing his work. That is very gracious of him. Most would have been tempted to keep it a guarded secret and attempt to profit from it. I got nothing against profit, but I think great things can happen when a community can share and work together.
What I am saying is that DCM is a non-linear approach based on the rotation group that provides a better solution to the problem of estimating aircraft attitude than Kalman filters does. It has superior performance and does not require a lot of computation. For a detailed explanation of the reasons why, you might want to read Mahony's paper. Here are a couple of things that Mahony has to say on the subject:
"Traditional linear and extended Kalman filter techniques...suffer from issues associated with poor modeling of the system...as well as potentially high computational requirements."
Mahony has developed a technique that "fully respects the non-linearities of rigid-body motion."
Mahony discusses an integrated approach for attitude estimation and control. However, the performance of the estimation portion of their approach performs so well, that you can build trivially simple controls on top of DCM and still get excellent performance.
With DCM, there are are no unknown model parameters to be computed, it is based entirely of the kinematics of rigid-body rotation.
DCM is fully functional the moment you turn it on.
Paul and I have an elegant, computationally efficient, implementation of DCM that is done entirely with multiplication and addition. There no divisions, and certainly no matrix inversions.
So, what I mean when I say that DCM "supercedes" Kalman filters, I mean that once word gets around concerning the advantages of DCM for attitude control, it will gain widespread usage.
By the way, if you haven't seen it, you might want to take a look at Louis LeGrand's video of a DCM demonstration.
By the way I do agree with you last statement:
"Or maybe another way of looking at it is that there are several problems here. The "hard" one (the one that you solved) is to take drifty readings from from gyros, accelerometers and GPS and compute an accurate measurement of orientation, position (and velocities?). Another separate control problem is to use that measurement to stabilize the aircraft and get it fly where/how you want it to fly. Is this the way to look at it?"
Yes, you are 100% correct.
However, DCM uses only half of the theory developed by Mahony. Mahony has developed a solution to the entire problem, both the estimation portion, and the control portion, in an integrated approach. I chose to use only the estimation portion at this time, because it is more than adequate for what I want to do with it. It is only the estimation portion that is running in Louis's demo.
So it is my opinion that Mahony is really on to something, and that his approach to estimation and control for UAVs will become the "gold-standard".
I'm not sure I understand how DCM can "supercede" the Kalmann Filter for an autopilot application. If I understand correctly, the DCM technique you developed yields a reliable realtime measurement of orientation, position (and angular/translational velocities?) of the aircraft?
I never worked with Kalman filters, but it appears that they yield a system's response in the future given a measurement of the current state of the system, control inputs, and a system model. If so, then, isn't the DCM-technique basically a really good measurement of the current state of the system? And can't it be incorporated into an autopilot based on a Kalmann filter. In other words, looking at the wikipedia entry for Kalman filter, I am thinking that the DCM-technique plays the role of "H" in the figure shown.
Or maybe another way of looking at it is that there are several problems here. The "hard" one (the one that you solved) is to take drifty readings from from gyros, accelerometers and GPS and compute an accurate measurement of orientation, position (and velocities?). Another separate control problem is to use that measurement to stabilize the aircraft and get it fly where/how you want it to fly. Is this the way to look at it?
In general, ARM microcontrollers and C/C++ developmet are not easy. I´m a programmer, I know at least 12 programming languages and I have worked with those in some differents languages and enviroments, and C is most dificult of then by distance. It is neccesary some experience to work, some know about debugging, and a lot of thicks around programming in C... Like jordi said, someday.... you will have the power!!!
But, once you have this, I think it is a very good architecture. Yo can do all that you want and so much more!!!!! And STM32 Cortex M3 is a powerfull moicrocontrollers due his periphericals...
Its interesting what you say about the STM32s, they do seem quite impressive chips in terms of I/O. However is it not a little overkill? Bill's mentioned before the current PIC barely uses more than a few percent of the total processing capability. Any idea of the difference in power consumption for instance?
Also, how easy are STMs to program in an embedded (PCB) system? I have had experience of using PICs but never used an STM.
Hi jordi and all!
At the moment, I´m debugging my first aproximation to MatrixNav in a STM32-H103.
Too, I´m looking others STM32 header boards, like Futurlec STM32 Stamp.... Does you know?
Perhaps, I will try to design a PCB based on a hight density version of this microcontroller.... in the summer, I will have a lot of time...
I believe SMT32 is the best option for UAVS too, i been using it for a while! But is to complex for noobz. But someday... someday... i will finish my smt32 autopilot, the ADC's are fantastic! isn't?
Comments
That is a very good synopsis. Thank you very much.
Regards,
Bill
Hello Bill,
Have a look at my synopsis here and let me know if you think I'm on the right track.
It seems like a little confusion has built up around the terminology being used for Bill's excellent implementation of Mahony's approach to estimating a DCM. A DCM or "Discrete Cosine Matrix" is simply a rotation matrix for transforming from one reference frame to another - In this case from a local earth based reference frame (North,East,Down) to a body reference frame. This is useful because all of our on board rate sensors are in the body frame but we need to know how the rates are impacting our local earth based orientation (which way is down? What is my heading?....).
DCM's are actually very commonly used in navigation as well as countless other areas where data needs to be rotated. The real magic is how to generate the DCM. Kalman filters can and often are used to generated DCM's. Most of the Kalman Filter implementations I've seen being used by hobbiest tend to be just single axis filters instead of a full up three axis implementation, so no DCM is necessary. Sometimes someone may have two filters running, one to handle roll and another to handle yaw for instance. The problem with this is non-linearities and cross coupling start to occur as the craft deviates from straight and level in more than one axis at a time (rolling over 45 degrees while also climbing for example.). The 3 axis simply can't be treated as independent for a truly robust solution.
But a Kalman filter approach could be used to generate a correct DCM and can be made to work very well. The problem with a properly implemented Kalman filter approach is that they are mathematically optimized to produce the statistically smallest error possible for a given set of input parameters. This means there is a lot of extra mathematical "baggage" involved (fine for the analyst with infinite processing power on there desktop) and the characteristics of the inputs (our rate sensors) needs to be fairly well understood and consistent. If we don't make good estimates of noise and gain, the Kalman Filter may take a long time to converge, or possibly never converge if things are too far off.
The exciting thing about Bill's work is that it gives us a full 3 axis implementation that handles all the cross terms correctly regardless of aircraft orientation and has been carefully designed to work with limited processing power.
Even if we continue to refer to this as the DCM approach I think it's important to remember that it's the estimation of the DCM that's unique and magical not the fact that a DCM is used. I would like to see a little more discussion about how the sensor inputs are merged to eliminate drift, offset and gain errors. This will be important when we attempt to use other sensors such a magnetometer to correct for these errors instead of (or in addition to) GPS and accelerometers. I look forward to Bill's upcoming paper.
I'm so excited about this approach that I've decided to design my own autopilot board. It will be based on a PIC32 and will include 5 PWM inputs and outputs, micro SD card based data logging, magnetometer, battery current and voltage monitoring, altimeter and airspeed measurements and much more. I plan on making this design open source and will post in a couple of days in a new thread when the schematics are ready for uploading.
Sorry for the long post. I wanted to thank Bill for sharing his work. That is very gracious of him. Most would have been tempted to keep it a guarded secret and attempt to profit from it. I got nothing against profit, but I think great things can happen when a community can share and work together.
Regards,
Brian
I noticed that link to the Mahony paper is not working right now.
Here is another link.
Bill
What I am saying is that DCM is a non-linear approach based on the rotation group that provides a better solution to the problem of estimating aircraft attitude than Kalman filters does. It has superior performance and does not require a lot of computation. For a detailed explanation of the reasons why, you might want to read Mahony's paper. Here are a couple of things that Mahony has to say on the subject:
"Traditional linear and extended Kalman filter techniques...suffer from issues associated with poor modeling of the system...as well as potentially high computational requirements."
Mahony has developed a technique that "fully respects the non-linearities of rigid-body motion."
Mahony discusses an integrated approach for attitude estimation and control. However, the performance of the estimation portion of their approach performs so well, that you can build trivially simple controls on top of DCM and still get excellent performance.
With DCM, there are are no unknown model parameters to be computed, it is based entirely of the kinematics of rigid-body rotation.
DCM is fully functional the moment you turn it on.
Paul and I have an elegant, computationally efficient, implementation of DCM that is done entirely with multiplication and addition. There no divisions, and certainly no matrix inversions.
So, what I mean when I say that DCM "supercedes" Kalman filters, I mean that once word gets around concerning the advantages of DCM for attitude control, it will gain widespread usage.
By the way, if you haven't seen it, you might want to take a look at Louis LeGrand's video of a DCM demonstration.
By the way I do agree with you last statement:
"Or maybe another way of looking at it is that there are several problems here. The "hard" one (the one that you solved) is to take drifty readings from from gyros, accelerometers and GPS and compute an accurate measurement of orientation, position (and velocities?). Another separate control problem is to use that measurement to stabilize the aircraft and get it fly where/how you want it to fly. Is this the way to look at it?"
Yes, you are 100% correct.
However, DCM uses only half of the theory developed by Mahony. Mahony has developed a solution to the entire problem, both the estimation portion, and the control portion, in an integrated approach. I chose to use only the estimation portion at this time, because it is more than adequate for what I want to do with it. It is only the estimation portion that is running in Louis's demo.
So it is my opinion that Mahony is really on to something, and that his approach to estimation and control for UAVs will become the "gold-standard".
Best regards,
Bill Premerlani
I'm not sure I understand how DCM can "supercede" the Kalmann Filter for an autopilot application. If I understand correctly, the DCM technique you developed yields a reliable realtime measurement of orientation, position (and angular/translational velocities?) of the aircraft?
I never worked with Kalman filters, but it appears that they yield a system's response in the future given a measurement of the current state of the system, control inputs, and a system model. If so, then, isn't the DCM-technique basically a really good measurement of the current state of the system? And can't it be incorporated into an autopilot based on a Kalmann filter. In other words, looking at the wikipedia entry for Kalman filter, I am thinking that the DCM-technique plays the role of "H" in the figure shown.
Or maybe another way of looking at it is that there are several problems here. The "hard" one (the one that you solved) is to take drifty readings from from gyros, accelerometers and GPS and compute an accurate measurement of orientation, position (and velocities?). Another separate control problem is to use that measurement to stabilize the aircraft and get it fly where/how you want it to fly. Is this the way to look at it?
But, once you have this, I think it is a very good architecture. Yo can do all that you want and so much more!!!!! And STM32 Cortex M3 is a powerfull moicrocontrollers due his periphericals...
Saludos desde el Café del Mar(Ibiza)! jajajjaja
Also, how easy are STMs to program in an embedded (PCB) system? I have had experience of using PICs but never used an STM.
Flare
At the moment, I´m debugging my first aproximation to MatrixNav in a STM32-H103.
Too, I´m looking others STM32 header boards, like Futurlec STM32 Stamp.... Does you know?
Perhaps, I will try to design a PCB based on a hight density version of this microcontroller.... in the summer, I will have a lot of time...
Saludos!
I believe SMT32 is the best option for UAVS too, i been using it for a while! But is to complex for noobz. But someday... someday... i will finish my smt32 autopilot, the ADC's are fantastic! isn't?
-
1
-
2
-
3
-
4
of 4 Next