AHRS Secret Sauce quadrations and inu open source code

[duecedriver]

I posted this over at reddit This should be all the secret sauce code we need, save for integrating the pressure altitude function, etc. Its C based code and should be simple to roll into the current software.

it includes all the quaternions calcs to offset acceleration and kalman filters and drift correction algorithms... ENJOY!!

keep up the great work!!

[–]skypuppy7 1 point 15 hours ago The BNO055 chip, ($35 from Adafruit, cheapest I've found yet) has "sensor fusion" hardware and software already on the chip. You just set the flags and ask for the data via the I2C lines. I'm working toward incorporating it into stratux but I have to learn Qt first --- and that AIN'T easy. I've used several excellent debuggers over the years but Qt is blowing my mind. Also, a separate GPS chip will be needed. permalinksavereportgive goldreply [–]duecedriver[S] 1 point 20 minutes ago That chip is interesting... I believe that we must focus on one hardware solution and program against it... This chip has advantages of built in inu and quaternions calculations but lacks gps/glonass/ and pressure alt capability so that would require another chip. The RY83AI is the most robust hardware solution but would require the secret source be written and or adopted from open source. It would give a more fine tuned control of the output and be easier since the source is in C not adafruit.. this is really the simplest fix right here... here is the entire codebase required for those that know C and how strutux is constructed.

http://www.x-io.co.uk/open-source-ahrs-with-x-imu/

The x-IMU‘s propriety on-board IMU and AHRS sensor fusion algorithms provide a real-time measurement of orientation relative to the Earth. Many projects require access to algorithm source code so that it may be run off-board, modified or used to post-process sensor data and take advantage of non-real-time techniques. This open source project implements Madgwick’s AHRS and IMU algorithms in C# and demonstrates their real-time performance alongside the x-IMU’s own propriety algorithm. The source code also includes Madgwick’s implementation of Robert Mayhony’s so called ‘DCM filter‘ in quaternion form.

[cyoung]

I believe that we must focus on one hardware solution and program against it...

Agreed, the MPU6050 has this "sensor fusion" function on the DMP (Digital Motion Processor).

[duecedriver]

I think that the RY chip would be better since it includes a gps and pressure alt.. but would need to rework the open source IMU AHRS code linked above. also, lots of people have already bought the hardware.. not that it should be a prime consideration but hey.. they are here because they are cheap!!

[ssokol]

I was a initially a fan of the RY835AI, but in trying to use it I've changed my mind. The soldering is poor. The battery is utter crap, making it perform a cold start after only a few days without a connection. The GPS takes forever to cold start, even outside on a clear day. It lacks a port for an external antenna. Several people have complained about receiving DOA units. The price is certainly low, but if you consider what people are using this thing for that doesn't hold mean too much.

I guess I'm fine with us sticking with the Invensense MPU-6050 6-DoF IMU, the Bosh BMP180 pressure sensor, the Honeywell HMC5983 magnetometer, and the u-blox GPS. I just hope we can find a better package. Anyone know anyone at Adafruit, Sparkfun, Seeedstudio, or any of the other hobby electronics boutiques?

On Sun, Dec 13, 2015 at 3:12 PM, duecedriver notifications@github.com wrote:

I think that the RY chip would be better since it includes a gps and pressure alt.. but would need to rework the open source IMU AHRS code linked above. also, lots of people have already bought the hardware.. not that it should be a prime consideration but hey.. they are here because they are cheap!!

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-164298764.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

[skypuppy]

Check out the Bosch BNO055. Adafruit has them at $35 last I heard. I bought two.

On 12/13/2015 10:02 PM, Steven Sokol wrote:

I was a initially a fan of the RY835AI, but in trying to use it I've changed my mind. The soldering is poor. The battery is utter crap, making it perform a cold start after only a few days without a connection. The GPS takes forever to cold start, even outside on a clear day. It lacks a port for an external antenna. Several people have complained about receiving DOA units. The price is certainly low, but if you consider what people are using this thing for that doesn't hold mean too much.

I guess I'm fine with us sticking with the Invensense MPU-6050 6-DoF IMU, the Bosh BMP180 pressure sensor, the Honeywell HMC5983 magnetometer, and the u-blox GPS. I just hope we can find a better package. Anyone know anyone at Adafruit, Sparkfun, Seeedstudio, or any of the other hobby electronics boutiques?

On Sun, Dec 13, 2015 at 3:12 PM, duecedriver notifications@github.com wrote:

I think that the RY chip would be better since it includes a gps and pressure alt.. but would need to rework the open source IMU AHRS code linked above. also, lots of people have already bought the hardware.. not that it should be a prime consideration but hey.. they are here because they are cheap!!

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-164298764.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-164336323.

[duecedriver]

@skypuppy

you have any wired up yet?

[skypuppy]

@deucedriver

Yes, wired and talking to the Beaglebone Black using I2C (almost exact same code for Pi) but have not gone beyond verifying comms. Still trying to get my head around Qt as that is now my IDE of choice for embedded systems. Eclipse is ok, but I want more power. So I can take over the world, of course, then Mater of the Universe. :)

I have two version of BNO055, one of which is the Adafruit unit. I like it better as it gives more options on how to use the chip and it's data, as well as better construction of the hardware.

On 12/14/2015 09:19 AM, duecedriver wrote:

@skypuppy https://github.com/skypuppy

you have any wired up yet?

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-164464274.

[cyoung]

Thanks for posting @duecedriver, we're making progress towards this. Going to close this now as it has become less relevant with the current releases, give the latest a try.

[duecedriver]

so have you gotten the coding hooks into the onboard MPU processing or are you coding angular accelerations into stratux and working with raw gyro data?

On Jan 10, 2016, at 4:25 PM, cyoung notifications@github.com wrote:

Closed #140 https://github.com/cyoung/stratux/issues/140.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#event-510594091.

[cyoung]

We're using the MPU's processing directly now, but we have access to the raw data as well which we will need for the next steps.

[duecedriver]

sounds like things are moving along nicely..

so can you enumerate what you believe is working correctly vs still a work in progress.. has accelerated gravitational vectors been solved or is it still nulling bank in a coordinated turn? have you successfully filtered out jitter and spurious indications induced by vibration etc…

On Jan 10, 2016, at 6:42 PM, cyoung notifications@github.com wrote:

We're using the MPU's processing directly now, but we have access to the raw data as well which we will need for the next steps.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170406529.

[skypuppy]

The Kalman filters in the IMU cpu should already have those handled. Assuming they're using Kalman and not some of the others. Worst case would be simple moving averages. ptui.

On 01/11/2016 08:51 AM, duecedriver wrote:

sounds like things are moving along nicely..

so can you enumerate what you believe is working correctly vs still a work in progress.. has accelerated gravitational vectors been solved or is it still nulling bank in a coordinated turn? have you successfully filtered out jitter and spurious indications induced by vibration etc…

On Jan 10, 2016, at 6:42 PM, cyoung notifications@github.com wrote:

We're using the MPU's processing directly now, but we have access to the raw data as well which we will need for the next steps.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170406529.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170576723.

[duecedriver]

kalman filtering in and of itself does not handle accelerated vectors.. it is a method of blending 2 or more sources that are providing the same information to blend into a solution. also can be used for dampening.

as of the latest video post over at reddit, it would appear that the software is still not handling accelerated flight.. provided he is on the latest release.

you really need to figure out if the onboard MPU is doing no shit linear quadratic or cosine matrix or some other form of accelerated flight blending of gyro sources…. then worry about whether its filtering the output with kalman to stabilize it..

an easy way to test this is sit in an office chair that can spin.. hold the unit in the flight orientation in front of you, spin the chair.. the horizon should not move and the slip ball should peg to the outside of the spin.. if it doesn’t.. you dont have it working yet. the ball in the slip indicator points to ‘virtual’ gravity.. i.e. .. the accelerated vector. the turn indicator indicated the direction of rotation.. the artificial horizon always seeks true vector to earth, not the induced velocity vector.

now with the non disclosure contracts that I am under I cant point you to anything more specific but have given just about every source link that should be required to implement this...

I have posted countless references for you all to look at so as not to reinvent the wheel for source code and papers by people who already have this figured out.. as well as links to the manufacturers codebase for the 6050 and its MPU sample code base… have they been reverenced yet for usability?

here is yet another excellent paper to look at.. http://www.icas.org/ICAS_ARCHIVE/ICAS2010/PAPERS/569.PDF

On Jan 11, 2016, at 11:43 AM, skypuppy notifications@github.com wrote:

The Kalman filters in the IMU cpu should already have those handled. Assuming they're using Kalman and not some of the others. Worst case would be simple moving averages. ptui.

On 01/11/2016 08:51 AM, duecedriver wrote:

sounds like things are moving along nicely..

so can you enumerate what you believe is working correctly vs still a work in progress.. has accelerated gravitational vectors been solved or is it still nulling bank in a coordinated turn? have you successfully filtered out jitter and spurious indications induced by vibration etc…

On Jan 10, 2016, at 6:42 PM, cyoung notifications@github.com wrote:

We're using the MPU's processing directly now, but we have access to the raw data as well which we will need for the next steps.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170406529.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170576723.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170612988.

[duecedriver]

you have to determine if the MPU is doing the work for you using euler angles or quaternion… if both are available though the MPU I would go with the latter for the following reason.

Euler angles are more human understandable and also good for decomposing rotations into indiviual degrees of freedom (for kinematic joints and the like) but have disadvantages like ambiguity and gimbal lock. In practice I would prefer quaternions, as they easier to compute with (for the computer, not for humans) and more efficient. You have to make three rotations and multiply them together when rotatiing by euler angles, whereas a quaternion is only one rotation and as it already encodes the sin and cos, the conversion from quaternion to matrix is quite efficient.

if its doing neither, then you have to go the the various sources I have posted and decide if you can understand and integrate the existing code that is available… if you cant.. well we probably won’t be getting AHRS anytime soon since while euler is mostly understandable to a non math PHD.. quadrernions make my head explode.. the major drawback of euler is gimbal lock but that should not be an issue unless someone wants to do acro, and from what I understand.. unlike a physical gimbal, there may be ways to artificially keep the code from gimbal locking … by keeping out of the deadman.

On Jan 11, 2016, at 11:43 AM, skypuppy notifications@github.com wrote:

The Kalman filters in the IMU cpu should already have those handled. Assuming they're using Kalman and not some of the others. Worst case would be simple moving averages. ptui.

On 01/11/2016 08:51 AM, duecedriver wrote:

sounds like things are moving along nicely..

so can you enumerate what you believe is working correctly vs still a work in progress.. has accelerated gravitational vectors been solved or is it still nulling bank in a coordinated turn? have you successfully filtered out jitter and spurious indications induced by vibration etc…

On Jan 10, 2016, at 6:42 PM, cyoung notifications@github.com wrote:

We're using the MPU's processing directly now, but we have access to the raw data as well which we will need for the next steps.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170406529.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170576723.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170612988.

[ssokol]

There's an Australian guy named Samuel Cowan who created a fixed-wing drone autopilot application called Firetail. He also wrote a lot about the problems of handling acceleration values - how to subtract them out of the vector matrix. He's taken his blog down (unfortunate, as it had lots of good commentary about how all this works) but you can still find his code out there. Here's a copy:

https://bitbucket.org/camelsoftware/firetail/src

If you google around you'll find videos of his drone autopilot flying autonomous courses quite well. Apparently the sensor fusion system worked well enough to keep the drones upright and on course.

On Mon, Jan 11, 2016 at 11:45 AM, duecedriver notifications@github.com wrote:

kalman filtering in and of itself does not handle accelerated vectors.. it is a method of blending 2 or more sources that are providing the same information to blend into a solution. also can be used for dampening.

as of the latest video post over at reddit, it would appear that the software is still not handling accelerated flight.. provided he is on the latest release.

you really need to figure out if the onboard MPU is doing no shit linear quadratic or cosine matrix or some other form of accelerated flight blending of gyro sources…. then worry about whether its filtering the output with kalman to stabilize it..

an easy way to test this is sit in an office chair that can spin.. hold the unit in the flight orientation in front of you, spin the chair.. the horizon should not move and the slip ball should peg to the outside of the spin.. if it doesn’t.. you dont have it working yet. the ball in the slip indicator points to ‘virtual’ gravity.. i.e. .. the accelerated vector. the turn indicator indicated the direction of rotation.. the artificial horizon always seeks true vector to earth, not the induced velocity vector.

now with the non disclosure contracts that I am under I cant point you to anything more specific but have given just about every source link that should be required to implement this...

I have posted countless references for you all to look at so as not to reinvent the wheel for source code and papers by people who already have this figured out.. as well as links to the manufacturers codebase for the 6050 and its MPU sample code base… have they been reverenced yet for usability?

here is yet another excellent paper to look at.. http://www.icas.org/ICAS_ARCHIVE/ICAS2010/PAPERS/569.PDF

On Jan 11, 2016, at 11:43 AM, skypuppy notifications@github.com wrote:

The Kalman filters in the IMU cpu should already have those handled. Assuming they're using Kalman and not some of the others. Worst case would be simple moving averages. ptui.

On 01/11/2016 08:51 AM, duecedriver wrote:

sounds like things are moving along nicely..

so can you enumerate what you believe is working correctly vs still a work in progress.. has accelerated gravitational vectors been solved or is it still nulling bank in a coordinated turn? have you successfully filtered out jitter and spurious indications induced by vibration etc…

On Jan 10, 2016, at 6:42 PM, cyoung notifications@github.com wrote:

We're using the MPU's processing directly now, but we have access to the raw data as well which we will need for the next steps.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170406529.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170576723.

— Reply to this email directly or view it on GitHub < https://github.com/cyoung/stratux/issues/140#issuecomment-170612988>.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170630432.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

[ssokol]

Oh, and for the record, I'm in favor of whatever IMU component works best but I'm not a fan of Reyax - too many issues with their boards and I don't really like having the GPS on the same module.

If we can't find an existing IMU that fits our needs (and I bet we can - check out Adafruit, Sparkfun, Pololu, Ebay, and Aliexpress) we can have a board made up that uses whatever parts you prefer.

On Mon, Jan 11, 2016 at 12:02 PM, Steven Sokol steven.sokol@gmail.com wrote:

There's an Australian guy named Samuel Cowan who created a fixed-wing drone autopilot application called Firetail. He also wrote a lot about the problems of handling acceleration values - how to subtract them out of the vector matrix. He's taken his blog down (unfortunate, as it had lots of good commentary about how all this works) but you can still find his code out there. Here's a copy:

https://bitbucket.org/camelsoftware/firetail/src

If you google around you'll find videos of his drone autopilot flying autonomous courses quite well. Apparently the sensor fusion system worked well enough to keep the drones upright and on course.

On Mon, Jan 11, 2016 at 11:45 AM, duecedriver notifications@github.com wrote:

kalman filtering in and of itself does not handle accelerated vectors.. it is a method of blending 2 or more sources that are providing the same information to blend into a solution. also can be used for dampening.

as of the latest video post over at reddit, it would appear that the software is still not handling accelerated flight.. provided he is on the latest release.

you really need to figure out if the onboard MPU is doing no shit linear quadratic or cosine matrix or some other form of accelerated flight blending of gyro sources…. then worry about whether its filtering the output with kalman to stabilize it..

an easy way to test this is sit in an office chair that can spin.. hold the unit in the flight orientation in front of you, spin the chair.. the horizon should not move and the slip ball should peg to the outside of the spin.. if it doesn’t.. you dont have it working yet. the ball in the slip indicator points to ‘virtual’ gravity.. i.e. .. the accelerated vector. the turn indicator indicated the direction of rotation.. the artificial horizon always seeks true vector to earth, not the induced velocity vector.

now with the non disclosure contracts that I am under I cant point you to anything more specific but have given just about every source link that should be required to implement this...

I have posted countless references for you all to look at so as not to reinvent the wheel for source code and papers by people who already have this figured out.. as well as links to the manufacturers codebase for the 6050 and its MPU sample code base… have they been reverenced yet for usability?

here is yet another excellent paper to look at.. http://www.icas.org/ICAS_ARCHIVE/ICAS2010/PAPERS/569.PDF

On Jan 11, 2016, at 11:43 AM, skypuppy notifications@github.com wrote:

The Kalman filters in the IMU cpu should already have those handled. Assuming they're using Kalman and not some of the others. Worst case would be simple moving averages. ptui.

On 01/11/2016 08:51 AM, duecedriver wrote:

sounds like things are moving along nicely..

so can you enumerate what you believe is working correctly vs still a work in progress.. has accelerated gravitational vectors been solved or is it still nulling bank in a coordinated turn? have you successfully filtered out jitter and spurious indications induced by vibration etc…

On Jan 10, 2016, at 6:42 PM, cyoung notifications@github.com wrote:

We're using the MPU's processing directly now, but we have access to the raw data as well which we will need for the next steps.

— Reply to this email directly or view it on GitHub <https://github.com/cyoung/stratux/issues/140#issuecomment-170406529 .

— Reply to this email directly or view it on GitHub <https://github.com/cyoung/stratux/issues/140#issuecomment-170576723 .

— Reply to this email directly or view it on GitHub < https://github.com/cyoung/stratux/issues/140#issuecomment-170612988>.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170630432.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

[duecedriver]

I agree and have said similarly..

drawback of the reyax board.. 1 I dont mind the gps chip being on the board, but no external antenna.. keeps it too close to the noise and no 40mm copper ground plane 2 it uses a much older 6050.. and there are now much better fully integrated 9DOF solutions from the same chip maker (invensense) 3 reyax won’t let me talk to an engineer nor will they provide the specifics on how the 6050 and other components have been wired (there are options) and without that detailed integrator level information.. its just taking shots in the dark

benefit to an external puck GPS.. you can place it away from the unit.. hell if your unit has a cable on the ads-b antennas too, you can place the unit on the floor. which is cooler, less vibration, and less EMI, and closer to the axis of the aircraft.. the preferred mounting area of the portable system I consulted on.. only the antennas needed to up by the window

there are several gyro boards out there that others have mentioned that could be good candidates… I suggest sticking with a solution that does full on board qualdrninion process to make life a bit easier.. to get a really rock solid implementation though.. the position calculation provided by the MPU should be kalman filtered with the position readings of the GPS.. as provided by the paper referenced earlier...

On Jan 11, 2016, at 1:06 PM, Steven Sokol notifications@github.com wrote:

Oh, and for the record, I'm in favor of whatever IMU component works best but I'm not a fan of Reyax - too many issues with their boards and I don't really like having the GPS on the same module.

If we can't find an existing IMU that fits our needs (and I bet we can - check out Adafruit, Sparkfun, Pololu, Ebay, and Aliexpress) we can have a board made up that uses whatever parts you prefer.

On Mon, Jan 11, 2016 at 12:02 PM, Steven Sokol steven.sokol@gmail.com wrote:

There's an Australian guy named Samuel Cowan who created a fixed-wing drone autopilot application called Firetail. He also wrote a lot about the problems of handling acceleration values - how to subtract them out of the vector matrix. He's taken his blog down (unfortunate, as it had lots of good commentary about how all this works) but you can still find his code out there. Here's a copy:

https://bitbucket.org/camelsoftware/firetail/src

If you google around you'll find videos of his drone autopilot flying autonomous courses quite well. Apparently the sensor fusion system worked well enough to keep the drones upright and on course.

On Mon, Jan 11, 2016 at 11:45 AM, duecedriver notifications@github.com wrote:

kalman filtering in and of itself does not handle accelerated vectors.. it is a method of blending 2 or more sources that are providing the same information to blend into a solution. also can be used for dampening.

as of the latest video post over at reddit, it would appear that the software is still not handling accelerated flight.. provided he is on the latest release.

you really need to figure out if the onboard MPU is doing no shit linear quadratic or cosine matrix or some other form of accelerated flight blending of gyro sources…. then worry about whether its filtering the output with kalman to stabilize it..

an easy way to test this is sit in an office chair that can spin.. hold the unit in the flight orientation in front of you, spin the chair.. the horizon should not move and the slip ball should peg to the outside of the spin.. if it doesn’t.. you dont have it working yet. the ball in the slip indicator points to ‘virtual’ gravity.. i.e. .. the accelerated vector. the turn indicator indicated the direction of rotation.. the artificial horizon always seeks true vector to earth, not the induced velocity vector.

now with the non disclosure contracts that I am under I cant point you to anything more specific but have given just about every source link that should be required to implement this...

I have posted countless references for you all to look at so as not to reinvent the wheel for source code and papers by people who already have this figured out.. as well as links to the manufacturers codebase for the 6050 and its MPU sample code base… have they been reverenced yet for usability?

here is yet another excellent paper to look at.. http://www.icas.org/ICAS_ARCHIVE/ICAS2010/PAPERS/569.PDF

On Jan 11, 2016, at 11:43 AM, skypuppy notifications@github.com wrote:

The Kalman filters in the IMU cpu should already have those handled. Assuming they're using Kalman and not some of the others. Worst case would be simple moving averages. ptui.

On 01/11/2016 08:51 AM, duecedriver wrote:

sounds like things are moving along nicely..

so can you enumerate what you believe is working correctly vs still a work in progress.. has accelerated gravitational vectors been solved or is it still nulling bank in a coordinated turn? have you successfully filtered out jitter and spurious indications induced by vibration etc…

On Jan 10, 2016, at 6:42 PM, cyoung notifications@github.com wrote:

We're using the MPU's processing directly now, but we have access to the raw data as well which we will need for the next steps.

— Reply to this email directly or view it on GitHub <https://github.com/cyoung/stratux/issues/140#issuecomment-170406529 .

— Reply to this email directly or view it on GitHub <https://github.com/cyoung/stratux/issues/140#issuecomment-170576723 .

— Reply to this email directly or view it on GitHub < https://github.com/cyoung/stratux/issues/140#issuecomment-170612988>.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170630432.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441 — Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170636547.

[skypuppy]

Yeah, either trap the divide by zero in an error-trap routine (not sure if Linux supports that) or add cpu cycles by testing for the zero condition every time and simply substitute 0.001 or somesuch.

On 01/11/2016 12:00 PM, duecedriver wrote:

you have to determine if the MPU is doing the work for you using euler angles or quaternion… if both are available though the MPU I would go with the latter for the following reason.

Euler angles are more human understandable and also good for decomposing rotations into indiviual degrees of freedom (for kinematic joints and the like) but have disadvantages like ambiguity and gimbal lock. In practice I would prefer quaternions, as they easier to compute with (for the computer, not for humans) and more efficient. You have to make three rotations and multiply them together when rotatiing by euler angles, whereas a quaternion is only one rotation and as it already encodes the sin and cos, the conversion from quaternion to matrix is quite efficient.

if its doing neither, then you have to go the the various sources I have posted and decide if you can understand and integrate the existing code that is available… if you cant.. well we probably won’t be getting AHRS anytime soon since while euler is mostly understandable to a non math PHD.. quadrernions make my head explode.. the major drawback of euler is gimbal lock but that should not be an issue unless someone wants to do acro, and from what I understand.. unlike a physical gimbal, there may be ways to artificially keep the code from gimbal locking … by keeping out of the deadman.

On Jan 11, 2016, at 11:43 AM, skypuppy notifications@github.com wrote:

The Kalman filters in the IMU cpu should already have those handled. Assuming they're using Kalman and not some of the others. Worst case would be simple moving averages. ptui.

On 01/11/2016 08:51 AM, duecedriver wrote:

sounds like things are moving along nicely..

so can you enumerate what you believe is working correctly vs still a work in progress.. has accelerated gravitational vectors been solved or is it still nulling bank in a coordinated turn? have you successfully filtered out jitter and spurious indications induced by vibration etc…

On Jan 10, 2016, at 6:42 PM, cyoung notifications@github.com wrote:

We're using the MPU's processing directly now, but we have access to the raw data as well which we will need for the next steps.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170406529.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170576723.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170612988.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170635286.

[skypuppy]

At least two of the android flight apps (that talk to the stratux) already do the gps position/altitude averaging, no matter how hotly I ask them on the phone to at least give me a switch to turn that off with. So "averaging" on the stratux and yet again in the app is a recipe for not-good-things (registered trademark.) :) Consider climbing, landing, or flying through terrain where you're hugging the ground.

On 01/11/2016 12:18 PM, duecedriver wrote:

I agree and have said similarly..

drawback of the reyax board.. 1 I dont mind the gps chip being on the board, but no external antenna.. keeps it too close to the noise and no 40mm copper ground plane 2 it uses a much older 6050.. and there are now much better fully integrated 9DOF solutions from the same chip maker (invensense) 3 reyax won’t let me talk to an engineer nor will they provide the specifics on how the 6050 and other components have been wired (there are options) and without that detailed integrator level information.. its just taking shots in the dark

benefit to an external puck GPS.. you can place it away from the unit.. hell if your unit has a cable on the ads-b antennas too, you can place the unit on the floor. which is cooler, less vibration, and less EMI, and closer to the axis of the aircraft.. the preferred mounting area of the portable system I consulted on.. only the antennas needed to up by the window

there are several gyro boards out there that others have mentioned that could be good candidates… I suggest sticking with a solution that does full on board qualdrninion process to make life a bit easier.. to get a really rock solid implementation though.. the position calculation provided by the MPU should be kalman filtered with the position readings of the GPS.. as provided by the paper referenced earlier...

On Jan 11, 2016, at 1:06 PM, Steven Sokol notifications@github.com wrote:

Oh, and for the record, I'm in favor of whatever IMU component works best but I'm not a fan of Reyax - too many issues with their boards and I don't really like having the GPS on the same module.

If we can't find an existing IMU that fits our needs (and I bet we can - check out Adafruit, Sparkfun, Pololu, Ebay, and Aliexpress) we can have a board made up that uses whatever parts you prefer.

On Mon, Jan 11, 2016 at 12:02 PM, Steven Sokol steven.sokol@gmail.com wrote:

There's an Australian guy named Samuel Cowan who created a fixed-wing drone autopilot application called Firetail. He also wrote a lot about the problems of handling acceleration values - how to subtract them out of the vector matrix. He's taken his blog down (unfortunate, as it had lots of good commentary about how all this works) but you can still find his code out there. Here's a copy:

https://bitbucket.org/camelsoftware/firetail/src

If you google around you'll find videos of his drone autopilot flying autonomous courses quite well. Apparently the sensor fusion system worked well enough to keep the drones upright and on course.

On Mon, Jan 11, 2016 at 11:45 AM, duecedriver notifications@github.com wrote:

kalman filtering in and of itself does not handle accelerated vectors.. it is a method of blending 2 or more sources that are providing the same information to blend into a solution. also can be used for dampening.

as of the latest video post over at reddit, it would appear that the software is still not handling accelerated flight.. provided he is on the latest release.

you really need to figure out if the onboard MPU is doing no shit linear quadratic or cosine matrix or some other form of accelerated flight blending of gyro sources…. then worry about whether its filtering the output with kalman to stabilize it..

an easy way to test this is sit in an office chair that can spin.. hold the unit in the flight orientation in front of you, spin the chair.. the horizon should not move and the slip ball should peg to the outside of the spin.. if it doesn’t.. you dont have it working yet. the ball in the slip indicator points to ‘virtual’ gravity.. i.e. .. the accelerated vector. the turn indicator indicated the direction of rotation.. the artificial horizon always seeks true vector to earth, not the induced velocity vector.

now with the non disclosure contracts that I am under I cant point you to anything more specific but have given just about every source link that should be required to implement this...

I have posted countless references for you all to look at so as not to reinvent the wheel for source code and papers by people who already have this figured out.. as well as links to the manufacturers codebase for the 6050 and its MPU sample code base… have they been reverenced yet for usability?

here is yet another excellent paper to look at.. http://www.icas.org/ICAS_ARCHIVE/ICAS2010/PAPERS/569.PDF

On Jan 11, 2016, at 11:43 AM, skypuppy notifications@github.com wrote:

The Kalman filters in the IMU cpu should already have those handled. Assuming they're using Kalman and not some of the others. Worst case would be simple moving averages. ptui.

On 01/11/2016 08:51 AM, duecedriver wrote:

sounds like things are moving along nicely..

so can you enumerate what you believe is working correctly vs still a work in progress.. has accelerated gravitational vectors been solved or is it still nulling bank in a coordinated turn? have you successfully filtered out jitter and spurious indications induced by vibration etc…

On Jan 10, 2016, at 6:42 PM, cyoung notifications@github.com wrote:

We're using the MPU's processing directly now, but we have access to the raw data as well which we will need for the next steps.

— Reply to this email directly or view it on GitHub

<https://github.com/cyoung/stratux/issues/140#issuecomment-170406529 .

— Reply to this email directly or view it on GitHub

<https://github.com/cyoung/stratux/issues/140#issuecomment-170576723 .

— Reply to this email directly or view it on GitHub < https://github.com/cyoung/stratux/issues/140#issuecomment-170612988>.

— Reply to this email directly or view it on GitHub

https://github.com/cyoung/stratux/issues/140#issuecomment-170630432.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441 — Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170636547.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170639521.

[duecedriver]

if you are climbing, landing or flying though high terrain and you are ref your portable.. you will not be of this world for very long.. just about as bright as people that use to build their own overlay approaches and fly to instrument minimums in a VFR certified aircraft on a compaq ipaq handheld.. yep there were plenty that would regularly tell me in the developers forum how superior their bluetooth GPS (this was 10+ year ago) was far superior to an ILS…

if you are saying that pure GPS would be better.. probably not.. since down in terrain the multipathing of GPS becomes problematic and with less of the constellation in view PDOP HDOP AND VDOP go to shit unless your GPS costs $100k…

in everthing from fighter jets to 777 and 747 aircraft.. almost all navigational solutions are blended… with the exception of the barometric altimeter.. which should be the only thing your should be low leveling with.. and that should be done visually .. not with an altimeter to begin with..

On Jan 11, 2016, at 1:47 PM, skypuppy notifications@github.com wrote:

At least two of the android flight apps (that talk to the stratux) already do the gps position/altitude averaging, no matter how hotly I ask them on the phone to at least give me a switch to turn that off with. So "averaging" on the stratux and yet again in the app is a recipe for not-good-things (registered trademark.) :) Consider climbing, landing, or flying through terrain where you're hugging the ground.

On 01/11/2016 12:18 PM, duecedriver wrote:

I agree and have said similarly..

drawback of the reyax board.. 1 I dont mind the gps chip being on the board, but no external antenna.. keeps it too close to the noise and no 40mm copper ground plane 2 it uses a much older 6050.. and there are now much better fully integrated 9DOF solutions from the same chip maker (invensense) 3 reyax won’t let me talk to an engineer nor will they provide the specifics on how the 6050 and other components have been wired (there are options) and without that detailed integrator level information.. its just taking shots in the dark

benefit to an external puck GPS.. you can place it away from the unit.. hell if your unit has a cable on the ads-b antennas too, you can place the unit on the floor. which is cooler, less vibration, and less EMI, and closer to the axis of the aircraft.. the preferred mounting area of the portable system I consulted on.. only the antennas needed to up by the window

there are several gyro boards out there that others have mentioned that could be good candidates… I suggest sticking with a solution that does full on board qualdrninion process to make life a bit easier.. to get a really rock solid implementation though.. the position calculation provided by the MPU should be kalman filtered with the position readings of the GPS.. as provided by the paper referenced earlier...

On Jan 11, 2016, at 1:06 PM, Steven Sokol notifications@github.com wrote:

Oh, and for the record, I'm in favor of whatever IMU component works best but I'm not a fan of Reyax - too many issues with their boards and I don't really like having the GPS on the same module.

If we can't find an existing IMU that fits our needs (and I bet we can - check out Adafruit, Sparkfun, Pololu, Ebay, and Aliexpress) we can have a board made up that uses whatever parts you prefer.

On Mon, Jan 11, 2016 at 12:02 PM, Steven Sokol steven.sokol@gmail.com wrote:

There's an Australian guy named Samuel Cowan who created a fixed-wing drone autopilot application called Firetail. He also wrote a lot about the problems of handling acceleration values - how to subtract them out of the vector matrix. He's taken his blog down (unfortunate, as it had lots of good commentary about how all this works) but you can still find his code out there. Here's a copy:

https://bitbucket.org/camelsoftware/firetail/src

If you google around you'll find videos of his drone autopilot flying autonomous courses quite well. Apparently the sensor fusion system worked well enough to keep the drones upright and on course.

On Mon, Jan 11, 2016 at 11:45 AM, duecedriver notifications@github.com wrote:

kalman filtering in and of itself does not handle accelerated vectors.. it is a method of blending 2 or more sources that are providing the same information to blend into a solution. also can be used for dampening.

as of the latest video post over at reddit, it would appear that the software is still not handling accelerated flight.. provided he is on the latest release.

you really need to figure out if the onboard MPU is doing no shit linear quadratic or cosine matrix or some other form of accelerated flight blending of gyro sources…. then worry about whether its filtering the output with kalman to stabilize it..

an easy way to test this is sit in an office chair that can spin.. hold the unit in the flight orientation in front of you, spin the chair.. the horizon should not move and the slip ball should peg to the outside of the spin.. if it doesn’t.. you dont have it working yet. the ball in the slip indicator points to ‘virtual’ gravity.. i.e. .. the accelerated vector. the turn indicator indicated the direction of rotation.. the artificial horizon always seeks true vector to earth, not the induced velocity vector.

now with the non disclosure contracts that I am under I cant point you to anything more specific but have given just about every source link that should be required to implement this...

I have posted countless references for you all to look at so as not to reinvent the wheel for source code and papers by people who already have this figured out.. as well as links to the manufacturers codebase for the 6050 and its MPU sample code base… have they been reverenced yet for usability?

here is yet another excellent paper to look at.. http://www.icas.org/ICAS_ARCHIVE/ICAS2010/PAPERS/569.PDF

On Jan 11, 2016, at 11:43 AM, skypuppy notifications@github.com wrote:

The Kalman filters in the IMU cpu should already have those handled. Assuming they're using Kalman and not some of the others. Worst case would be simple moving averages. ptui.

On 01/11/2016 08:51 AM, duecedriver wrote:

sounds like things are moving along nicely..

so can you enumerate what you believe is working correctly vs still a work in progress.. has accelerated gravitational vectors been solved or is it still nulling bank in a coordinated turn? have you successfully filtered out jitter and spurious indications induced by vibration etc…

On Jan 10, 2016, at 6:42 PM, cyoung notifications@github.com wrote:

We're using the MPU's processing directly now, but we have access to the raw data as well which we will need for the next steps.

— Reply to this email directly or view it on GitHub

<https://github.com/cyoung/stratux/issues/140#issuecomment-170406529 .

— Reply to this email directly or view it on GitHub

<https://github.com/cyoung/stratux/issues/140#issuecomment-170576723 .

— Reply to this email directly or view it on GitHub < https://github.com/cyoung/stratux/issues/140#issuecomment-170612988>.

— Reply to this email directly or view it on GitHub

https://github.com/cyoung/stratux/issues/140#issuecomment-170630432.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441 — Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170636547.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170639521.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170649628.

[RobertGary1]

Saved me. I was put in a holding vector once and atc seemed to have forgotten about me. Saw terrain on my portable and queried. Surprised controller gave me an immediate turn. Saying that these devices are not suitable as primary sources of data is not justification to not make them as good as possible.

-Robert

On Jan 11, 2016, at 11:18 AM, duecedriver notifications@github.com wrote:

if you are climbing, landing or flying though high terrain and you are ref your portable.. you will not be of this world for very long.. just about as bright as people that use to build their own overlay approaches and fly to instrument minimums in a VFR certified aircraft on a compaq ipaq handheld.. yep there were plenty that would regularly tell me in the developers forum how superior their bluetooth GPS (this was 10+ year ago) was far superior to an ILS…

if you are saying that pure GPS would be better.. probably not.. since down in terrain the multipathing of GPS becomes problematic and with less of the constellation in view PDOP HDOP AND VDOP go to shit unless your GPS costs $100k…

in everthing from fighter jets to 777 and 747 aircraft.. almost all navigational solutions are blended… with the exception of the barometric altimeter.. which should be the only thing your should be low leveling with.. and that should be done visually .. not with an altimeter to begin with..

On Jan 11, 2016, at 1:47 PM, skypuppy notifications@github.com wrote:

At least two of the android flight apps (that talk to the stratux) already do the gps position/altitude averaging, no matter how hotly I ask them on the phone to at least give me a switch to turn that off with. So "averaging" on the stratux and yet again in the app is a recipe for not-good-things (registered trademark.) :) Consider climbing, landing, or flying through terrain where you're hugging the ground.

On 01/11/2016 12:18 PM, duecedriver wrote:

I agree and have said similarly..

drawback of the reyax board.. 1 I dont mind the gps chip being on the board, but no external antenna.. keeps it too close to the noise and no 40mm copper ground plane 2 it uses a much older 6050.. and there are now much better fully integrated 9DOF solutions from the same chip maker (invensense) 3 reyax won’t let me talk to an engineer nor will they provide the specifics on how the 6050 and other components have been wired (there are options) and without that detailed integrator level information.. its just taking shots in the dark

benefit to an external puck GPS.. you can place it away from the unit.. hell if your unit has a cable on the ads-b antennas too, you can place the unit on the floor. which is cooler, less vibration, and less EMI, and closer to the axis of the aircraft.. the preferred mounting area of the portable system I consulted on.. only the antennas needed to up by the window

there are several gyro boards out there that others have mentioned that could be good candidates… I suggest sticking with a solution that does full on board qualdrninion process to make life a bit easier.. to get a really rock solid implementation though.. the position calculation provided by the MPU should be kalman filtered with the position readings of the GPS.. as provided by the paper referenced earlier...

On Jan 11, 2016, at 1:06 PM, Steven Sokol notifications@github.com wrote:

Oh, and for the record, I'm in favor of whatever IMU component works best but I'm not a fan of Reyax - too many issues with their boards and I don't really like having the GPS on the same module.

If we can't find an existing IMU that fits our needs (and I bet we can - check out Adafruit, Sparkfun, Pololu, Ebay, and Aliexpress) we can have a board made up that uses whatever parts you prefer.

On Mon, Jan 11, 2016 at 12:02 PM, Steven Sokol steven.sokol@gmail.com wrote:

There's an Australian guy named Samuel Cowan who created a fixed-wing drone autopilot application called Firetail. He also wrote a lot about the problems of handling acceleration values - how to subtract them out of the vector matrix. He's taken his blog down (unfortunate, as it had lots of good commentary about how all this works) but you can still find his code out there. Here's a copy:

https://bitbucket.org/camelsoftware/firetail/src

If you google around you'll find videos of his drone autopilot flying autonomous courses quite well. Apparently the sensor fusion system worked well enough to keep the drones upright and on course.

On Mon, Jan 11, 2016 at 11:45 AM, duecedriver notifications@github.com wrote:

kalman filtering in and of itself does not handle accelerated vectors.. it is a method of blending 2 or more sources that are providing the same information to blend into a solution. also can be used for dampening.

as of the latest video post over at reddit, it would appear that the software is still not handling accelerated flight.. provided he is on the latest release.

you really need to figure out if the onboard MPU is doing no shit linear quadratic or cosine matrix or some other form of accelerated flight blending of gyro sources…. then worry about whether its filtering the output with kalman to stabilize it..

an easy way to test this is sit in an office chair that can spin.. hold the unit in the flight orientation in front of you, spin the chair.. the horizon should not move and the slip ball should peg to the outside of the spin.. if it doesn’t.. you dont have it working yet. the ball in the slip indicator points to ‘virtual’ gravity.. i.e. .. the accelerated vector. the turn indicator indicated the direction of rotation.. the artificial horizon always seeks true vector to earth, not the induced velocity vector.

now with the non disclosure contracts that I am under I cant point you to anything more specific but have given just about every source link that should be required to implement this...

I have posted countless references for you all to look at so as not to reinvent the wheel for source code and papers by people who already have this figured out.. as well as links to the manufacturers codebase for the 6050 and its MPU sample code base… have they been reverenced yet for usability?

here is yet another excellent paper to look at.. http://www.icas.org/ICAS_ARCHIVE/ICAS2010/PAPERS/569.PDF

On Jan 11, 2016, at 11:43 AM, skypuppy notifications@github.com wrote:

The Kalman filters in the IMU cpu should already have those handled. Assuming they're using Kalman and not some of the others. Worst case would be simple moving averages. ptui.

On 01/11/2016 08:51 AM, duecedriver wrote:

sounds like things are moving along nicely..

so can you enumerate what you believe is working correctly vs still a work in progress.. has accelerated gravitational vectors been solved or is it still nulling bank in a coordinated turn? have you successfully filtered out jitter and spurious indications induced by vibration etc…

On Jan 10, 2016, at 6:42 PM, cyoung notifications@github.com wrote:

We're using the MPU's processing directly now, but we have access to the raw data as well which we will need for the next steps.

— Reply to this email directly or view it on GitHub

<https://github.com/cyoung/stratux/issues/140#issuecomment-170406529 .

— Reply to this email directly or view it on GitHub

<https://github.com/cyoung/stratux/issues/140#issuecomment-170576723 .

— Reply to this email directly or view it on GitHub < https://github.com/cyoung/stratux/issues/140#issuecomment-170612988>.

— Reply to this email directly or view it on GitHub

https://github.com/cyoung/stratux/issues/140#issuecomment-170630432.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441 — Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170636547.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170639521.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170649628.

— Reply to this email directly or view it on GitHub.

[duecedriver]

and I AM saying that to make them as good as possible.. ALL available inputs should be USED and BLENDED appropriately..

you initial message was vague.. and well.. useless since it did not address why you feel that the blended solution that your program uses is no good.. nor what it is that you prefer or why.. .. pure GPS or pure altimetry

just.. well... bitching.. which is not productive..

[skypuppy]

@deuce, are you looking for a fight, argument, or what? This is not the place for such infantile emotions. We are trying to make stratux better here, and all viewpoints are welcomed but please, please, keep technical "facts" restricted to what is true, lest programmers spend days/weeks following a bad path.

On 01/11/2016 01:18 PM, duecedriver wrote:

if you are climbing, landing or flying though high terrain and you are ref your portable.. you will not be of this world for very long.. just about as bright as people that use to build their own overlay approaches and fly to instrument minimums in a VFR certified aircraft on a compaq ipaq handheld.. yep there were plenty that would regularly tell me in the developers forum how superior their bluetooth GPS (this was 10+ year ago) was far superior to an ILS…

if you are saying that pure GPS would be better.. probably not.. since down in terrain the multipathing of GPS becomes problematic and with less of the constellation in view PDOP HDOP AND VDOP go to shit unless your GPS costs $100k…

in everthing from fighter jets to 777 and 747 aircraft.. almost all navigational solutions are blended… with the exception of the barometric altimeter.. which should be the only thing your should be low leveling with.. and that should be done visually .. not with an altimeter to begin with..

On Jan 11, 2016, at 1:47 PM, skypuppy notifications@github.com wrote:

At least two of the android flight apps (that talk to the stratux) already do the gps position/altitude averaging, no matter how hotly I ask them on the phone to at least give me a switch to turn that off with. So "averaging" on the stratux and yet again in the app is a recipe for not-good-things (registered trademark.) :) Consider climbing, landing, or flying through terrain where you're hugging the ground.

On 01/11/2016 12:18 PM, duecedriver wrote:

I agree and have said similarly..

drawback of the reyax board.. 1 I dont mind the gps chip being on the board, but no external antenna.. keeps it too close to the noise and no 40mm copper ground plane 2 it uses a much older 6050.. and there are now much better fully integrated 9DOF solutions from the same chip maker (invensense) 3 reyax won’t let me talk to an engineer nor will they provide the specifics on how the 6050 and other components have been wired (there are options) and without that detailed integrator level information.. its just taking shots in the dark

benefit to an external puck GPS.. you can place it away from the unit.. hell if your unit has a cable on the ads-b antennas too, you can place the unit on the floor. which is cooler, less vibration, and less EMI, and closer to the axis of the aircraft.. the preferred mounting area of the portable system I consulted on.. only the antennas needed to up by the window

there are several gyro boards out there that others have mentioned that could be good candidates… I suggest sticking with a solution that does full on board qualdrninion process to make life a bit easier.. to get a really rock solid implementation though.. the position calculation provided by the MPU should be kalman filtered with the position readings of the GPS.. as provided by the paper referenced earlier...

On Jan 11, 2016, at 1:06 PM, Steven Sokol notifications@github.com wrote:

Oh, and for the record, I'm in favor of whatever IMU component works best but I'm not a fan of Reyax - too many issues with their boards and I don't really like having the GPS on the same module.

If we can't find an existing IMU that fits our needs (and I bet we can - check out Adafruit, Sparkfun, Pololu, Ebay, and Aliexpress) we can have a board made up that uses whatever parts you prefer.

On Mon, Jan 11, 2016 at 12:02 PM, Steven Sokol steven.sokol@gmail.com wrote:

There's an Australian guy named Samuel Cowan who created a fixed-wing drone autopilot application called Firetail. He also wrote a lot about the problems of handling acceleration values - how to subtract them out of the vector matrix. He's taken his blog down (unfortunate, as it had lots of good commentary about how all this works) but you can still find his code out there. Here's a copy:

https://bitbucket.org/camelsoftware/firetail/src

If you google around you'll find videos of his drone autopilot flying autonomous courses quite well. Apparently the sensor fusion system worked well enough to keep the drones upright and on course.

On Mon, Jan 11, 2016 at 11:45 AM, duecedriver notifications@github.com wrote:

kalman filtering in and of itself does not handle accelerated vectors.. it is a method of blending 2 or more sources that are providing the same information to blend into a solution. also can be used for dampening.

as of the latest video post over at reddit, it would appear that the software is still not handling accelerated flight.. provided he is on the latest release.

you really need to figure out if the onboard MPU is doing no shit linear quadratic or cosine matrix or some other form of accelerated flight blending of gyro sources…. then worry about whether its filtering the output with kalman to stabilize it..

an easy way to test this is sit in an office chair that can spin.. hold the unit in the flight orientation in front of you, spin the chair.. the horizon should not move and the slip ball should peg to the outside of the spin.. if it doesn’t.. you dont have it working yet. the ball in the slip indicator points to ‘virtual’ gravity.. i.e. .. the accelerated vector. the turn indicator indicated the direction of rotation.. the artificial horizon always seeks true vector to earth, not the induced velocity vector.

now with the non disclosure contracts that I am under I cant point you to anything more specific but have given just about every source link that should be required to implement this...

I have posted countless references for you all to look at so as not to reinvent the wheel for source code and papers by people who already have this figured out.. as well as links to the manufacturers codebase for the 6050 and its MPU sample code base… have they been reverenced yet for usability?

here is yet another excellent paper to look at.. http://www.icas.org/ICAS_ARCHIVE/ICAS2010/PAPERS/569.PDF

On Jan 11, 2016, at 11:43 AM, skypuppy notifications@github.com wrote:

The Kalman filters in the IMU cpu should already have those handled. Assuming they're using Kalman and not some of the others. Worst case would be simple moving averages. ptui.

On 01/11/2016 08:51 AM, duecedriver wrote:

sounds like things are moving along nicely..

so can you enumerate what you believe is working correctly vs still a work in progress.. has accelerated gravitational vectors been solved or is it still nulling bank in a coordinated turn? have you successfully filtered out jitter and spurious indications induced by vibration etc…

On Jan 10, 2016, at 6:42 PM, cyoung notifications@github.com wrote:

We're using the MPU's processing directly now, but we have access to the raw data as well which we will need for the next steps.

— Reply to this email directly or view it on GitHub

<https://github.com/cyoung/stratux/issues/140#issuecomment-170406529 .

— Reply to this email directly or view it on GitHub

<https://github.com/cyoung/stratux/issues/140#issuecomment-170576723 .

— Reply to this email directly or view it on GitHub <

https://github.com/cyoung/stratux/issues/140#issuecomment-170612988>.

— Reply to this email directly or view it on GitHub

https://github.com/cyoung/stratux/issues/140#issuecomment-170630432.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441 — Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170636547.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170639521.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170649628.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170659844.

[duecedriver]

we are trying to make it better... and to make it better requires resources and knowledge of which I attempt to post both... I dont throw out opinion or just out of hand shoot down peoples efforts that are brining MEANINGFUL food to the table.. but when I put up this or that.. if you dont want to use it, read it or reference it fine.. but I dont need, nor do the developers need useless comments that are not contributing..

now if you find error in fact with information I post.. by all means correct it factually and I will be the first to say well done..

so @skypuppy what am I discussing that is not technical, or facts...

[duecedriver]

@skypuppy

so lets just take a look at this thread... from the beginning..

I posted up a reference to some nice open sourse arhs code.... based on Madgwick’s AHRS and IMU algorithms in C#

then the thread devolved into a 'what hardware should we use' and 'i have this board' conversation for a bit.. which really should have been over in the other thread that I started talking about baselining hardware first.. but thats besides the point..

so 6 hours ago I get the notification that @cyoung is closing the thread as he has made progress..

I reply and ask how things were going and to see what has been figured out and working and what is not..

then you chime in with how all that should be handled by kalman filtering on the chip if its even on the chip.. ie.. nothing useful..

so, I posted another link to a paper that discusses the technical issues..

which then starts to further devolve into a 'I have this and I dont like that' conversation..

so, compared to the technical literature and discussions on industry accepted algorithms that I have posted today in this thread.. what have you contributed that actually works... or could lead to something working...

now looking at a video that a user posted today over on the reddit site.. provided he didn't dork up his wiring or is using outdated code.. it does not appear as if AHRS is working yet... he would go into a turn and the AHRS did not follow...

therefore the renewed push into looking into the workings of the MPU on board processing of the chosen rayax board and the conversation on euler and quaternion calculation... and if we cant get the information from reyax on this chip I agree with others that perhaps the months spent trying to get a round peg in a square hole should end and we find a suitable piece of hardware that we can code against.. hopefully having an onboard processor to handle the calcs to free up the pi, and also do it right since I really dont think the developers here have the phds in mathematics or the chops to code the quaternion formulas from scratch...

[jzeevi]

Can I suggest a technique for this type of thing we use on another forum? When things get “excited” ANYONE can call a timeout by sending a note that says “pizza”.

When that happens, the engaged parties must let the thread go, immediately. They can engage off the thread (i.e. personal emails)

If someone then wants to reopen a thread on something this forum is for, they can do so – as a separate thread.

If that ideas acceptable: “pizza!”

            josef

From: duecedriver [mailto:notifications@github.com] Sent: Monday, January 11, 2016 2:38 PM To: cyoung/stratux Subject: Re: [stratux] AHRS Secret Sauce quadrations and inu open source code (#140)

@skypuppy https://github.com/skypuppy

so lets just take a look at this thread... from the beginning..

I posted up a reference to some nice open sourse arhs code.... based on Madgwick’s AHRS and IMU algorithms in C#

then the thread devolved into a 'what hardware should we use' and 'i have this board' conversation for a bit.. which really should have been over in the other thread that I started talking about baselining hardware first.. but thats besides the point..

so 6 hours ago I get the notification that @cyoung https://github.com/cyoung is closing the thread as he has made progress..

I reply and ask how things were going and to see what has been figured out and working and what is not..

then you chime in with how all that should be handled by kalman filtering on the chip if its even on the chip.. ie.. nothing useful..

so, I posted another link to a paper that discusses the technical issues..

which then starts to further devolve into a 'I have this and I dont like that' conversation..

so, compared to the technical literature and discussions on industry accepted algorithms that I have posted today in this thread.. what have you contributed that actually works... or could lead to something working...

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170682768 . https://github.com/notifications/beacon/APJ34RA9AGxYEgkXnUihAubUmoKCqb9xks5pZAo4gaJpZM4G0T7G.gif

[duecedriver]

@jzeevi huh.. pizza eh.. hehe... thats a good one and that must be a lively board

actually what would have worked better would have been when I replied specifically to @cyoung.. that other parties don't all feel like they have to spout off about everything.. especially when they were not addressed... and dont know what they are talking about...

here the problem is that when a thread gets started and material get put out.. the thread invariably devolves from discussing that specific material and into a peanut gallery

another perfect example is look at the post I put out this morning on GPS algorithms as a new thread.. in the paper was a algorithms for gps altitude correction using barimetrics.. just like todays IFR precision approach receivers.. any guess who weighed in within moments just bashing.. without probably reading the attached technical paper to see the wealth of information within..

again.. you dont like it.. dont use it but keep it to yourself...

[Bagarre]

As long as we're all trying to constructively contribute to improving the software, heated discussions can are healthy. It's when the comments turn inflammatory or insulting that problems occur. It would be a shame if a mis interpretation turned into alienation and Stratux gets a bad reputation.

It's the challenge of open source. Everyone gets to read and comment.

[ssokol]

I've been in open source for 15 years. This is really quite tame. Nobody has even approached the Godwin's Law threshold.

If you get frustrated chances are good that it's simply miscommunication. If not, it's probably an honest disagreement. Happens. Nothing personal.

Be happy - fly more.

-S

On Mon, Jan 11, 2016 at 3:10 PM, David Ross notifications@github.com wrote:

As long as we're all trying to constructively contribute to improving the software, heated discussions can are healthy. It's when the comments turn inflammatory or insulting that problems occur. It would be a shame if a mis interpretation turned into alienation and Stratux gets a bad reputation.

It's the challenge of open source. Everyone gets to read and comment.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170690681.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

[jzeevi]

Opinions are like a**s. Every has one, but no one wants to see anybody else’s.

The forum that idea came from is (shocker!) an aviation forum dedicated to the Ercoupe and all its variants. There are experts, wanna-be experts, regular guys, and noob’s. The problem is, for an airplane that old, everyone has ideas about what is, what was intended, and what should be. Sigh.

As long as folks stick to the subject at hand (like an old boss of mine said “Make it about the work, not the person”) it works quite well – differences of opinion notwithstanding.

I hope we do that here.

            josef

From: duecedriver [mailto:notifications@github.com] Sent: Monday, January 11, 2016 2:57 PM To: cyoung/stratux Cc: Josef Zeevi Subject: Re: [stratux] AHRS Secret Sauce quadrations and inu open source code (#140)

@jzeevi https://github.com/jzeevi huh.. pizza eh.. hehe... thats a good one and that must be a lively board

actually what would have worked better would have been when I replied specifically to @cyoung https://github.com/cyoung .. that other parties don't all feel like they have to spout off about everything.. especially when they were not addressed... and dont know what they are talking about...

here the problem is that when a thread gets started and material get put out.. the thread invariably devolves from discussing that specific material and into a peanut gallery

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/140#issuecomment-170687430 .Image removed by sender.