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
#140 (comment).

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
#140 (comment).

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
#140 (comment).

[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
#140 (comment).

[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 #140.

—
Reply to this email directly or view it on GitHub #140 (comment).

[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 #140 (comment).

[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
#140 (comment).

—
Reply to this email directly or view it on GitHub
#140 (comment).

[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
#140 (comment).

—
Reply to this email directly or view it on GitHub
#140 (comment).

—
Reply to this email directly or view it on GitHub #140 (comment).

[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
#140 (comment).

—
Reply to this email directly or view it on GitHub
#140 (comment).

—
Reply to this email directly or view it on GitHub #140 (comment).

[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
#140 (comment).

—
Reply to this email directly or view it on GitHub
#140 (comment).

—
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
#140 (comment).

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
<#140 (comment)
.

—
Reply to this email directly or view it on GitHub
<#140 (comment)
.

—
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
#140 (comment).

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
<#140 (comment)
.

—
Reply to this email directly or view it on GitHub
<#140 (comment)
.

—
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
#140 (comment).

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 #140 (comment).

[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
#140 (comment).

—
Reply to this email directly or view it on GitHub
#140 (comment).

—
Reply to this email directly or view it on GitHub
#140 (comment).

—
Reply to this email directly or view it on GitHub
#140 (comment).

[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

<#140 (comment)
.

—
Reply to this email directly or view it on GitHub

<#140 (comment)
.

—
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

#140 (comment).

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
#140 (comment).

—
Reply to this email directly or view it on GitHub
#140 (comment).

[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

<#140 (comment)
.

—
Reply to this email directly or view it on GitHub

<#140 (comment)
.

—
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

#140 (comment).

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
#140 (comment).

—
Reply to this email directly or view it on GitHub
#140 (comment).

—
Reply to this email directly or view it on GitHub #140 (comment).

[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

<#140 (comment)
.

—
Reply to this email directly or view it on GitHub

<#140 (comment)
.

—
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

#140 (comment).

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
#140 (comment).

—
Reply to this email directly or view it on GitHub
#140 (comment).

—
Reply to this email directly or view it on GitHub #140 (comment).

—
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

<#140 (comment)
.

—
Reply to this email directly or view it on GitHub

<#140 (comment)
.

—
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

#140 (comment).

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
#140 (comment).

—
Reply to this email directly or view it on GitHub
#140 (comment).

—
Reply to this email directly or view it on GitHub
#140 (comment).

—
Reply to this email directly or view it on GitHub
#140 (comment).

[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 #140 (comment) . 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
#140 (comment).

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 #140 (comment) .Image removed by sender.