MatrixNav is released.

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
E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • William,
    Thanks for your response. Any chance we can take a look at the Simulink Model of your algorithm? We currently have our own controls and 6DOF model, I would really like to take a look at the Simulink section of your algorithm itself.

    Really looking forward to read your paper when it's done.

  • Looking forward to the paper on the math + physics behind this. Thanks again.
  • T3
    SLUGS Team,

    Paul Bizard and I added two things to the algorithm described in the Mahony paper: a novel normalization technique, and a well known technique for compensating for centrifugal acceleration that had not occurred to Mahony. Paul has done extensive Simulink modeling and simulations, including models of DCM, the controls, and the plane. Together we have worked out the theory.

    The Mahony paper is quite good, and they derive some excellent math. Paul and I are presently writing a paper that will explain the technique in a way that is accessible to a wider audience. We will be sure to include a derivation and the equations for the normalization. It is taking longer than we hoped.

    The implementation of DCM is efficient and elegant. Louis LeGrand at Intel recently ported it to his "InertiaDot IMU". You might want to take a look at his video.

    Best regards,
    Bill Premerlani
  • Hello William,
    I would be very interested in taking a look at the theory behind this to implement it in a Simulink Model, which would, I think, make it more understandable from the academic point of view. I wonder if you have anything written about it (even hand written notes would do, if you have them) . I don't mean the documentation you currently have from the implementation point of view, which by the way is really good. I rather mean a derivation and the equations behind it. I will begin by reading the paper you mention on one of your first comments but if I understand correctly, the novelty of your algorithm lies in the normalization of the DCM. Am I right in saying that? Or are there more differences between your implementation and the above mentioned paper?

    Congrats on your results. Thanks for sharing your work!
  • I can highly recommend STM32 if you need a lot more servo channels: 12+ HW servo outputs in LQFP64. I spent several days comparing PIC32, AVR32, STM32, and picked SMT32 for my AP mainly due to its free toolchain (gcc, openocd), 512k flash / 64kB RAM, and excellent peripherals (3 12 bit ADCs, DAC, 12+ HW servo outputs, servo input on any pin, 3 USARTs, 2 SPI, etc). PIC32 is probably faster computationally, but has far weaker IO (only 5 HW PWM outputs), and MCHP's toolchain commercialization is somewhat irritating.
  • T3

    That is good news indeed.

    Now, some good news for you: porting my firmware from the dsPIC30F4011 to the dsPIC30F6010A should be trivial. The board that you have in mind sounds impressive. Good luck, and let me know if there is any way that I can help you.


  • Bill,

    Good news on the 4 servo / 5 RC input board :)

    I've been following the dev of MatrixNav and was planning on developing just such a board in the summer after my finals. Was planning on using a DSPIC30F6010A in the TQFP 80 package so as to enable 4 independant PWMs and use two sets of headers for the remaining pins so as to enable a lot of upgradability. My aim is to use this for a heli if i can, so i wanted the possibility of adding a Magnetometer on an expansion board etc.

    Do you know if the MatrixNav code would port directly as its a PIC of the same family? ( Other than modding a few pin outs and changing the headers for the 6010A )

  • T3

    In the immediate future I am going to stabilize roll and pitch for a Golderg "Endurance" that I have (which is no longer in production), with the board that I have. It is a two axes of control airplane with ailerons and and a V tail that is controlled like an elevator. I plan to control ailerons and V tail through my board and control throttle directly.

    The board that I have will work with 3 servos and listens to 4 RC inputs. So you could easily do ailerons, rudder, elevator, if you are willing to do manual control of throttle by connecting that servo directly to you Rx. Or you could do ailerons, elevator and throttle on something like the Endurance.

    There have been several requests for 4 servos and 5 RC inputs. So, yes, I am planning a new dev board to do that. I am not sure when it will be released, right now it is in the conceptual phase. I will give updates from time to time.
  • Hi Bill,

    This is a really exciting project! I notice that you've mentioned working on a project to stabilize roll as well. Are you planning a new dev board that would allow control of 4 servos and would listen to 5 RC inputs? Or were you thinking of using the existing board and just dropping control of the rudder or throttle channel?

  • T3
    By the way, one of my next projects is going to be to stabilize a neutrally stable plane. DCM should make that rather easy to do. There is a certain element in the matrix that can be used to regulate roll orientation, and there is another that you can use to regulate pitch orientation.
This reply was deleted.