Migration of MP-H to Mainstream MatrixPilot

[John McClelland]

HI Ben

 

I am replying to this as a new thread since this is such an important topic.

 

Your plan sounds great, although I can only imagine what that diff file will look like!

 

I am looking out the window at a few feet of snow, flying has been on hold obviouusly.  So that means I will concentrate on code over the Winter and catch up on my TODO list for MP-H.

 

Happiest of Holidays to everyone

 

John

 

 

Hi guys,

First of all, I've bought into the plan of waiting until MP_Heli is
more stable before converting it over to the newer codebase, so please
don't take this as pressure of any kind.  :)  It's just my ramblings
on how I would go about updating MP_Heli to the new codebase whenever
we all decide to do that.

The first task before converting it over will be to figure out the svn
revision number of the MP code that MP_Heli is based upon, and then
running a big diff from that old revision to the current state of
MP_Heli, to see a complete set of changes that make up the heli
modifications.

Then we can figure out which changes apply to the code that is now
MatrixPilot, and which set of changes apply to the code that is now in
the libUDB and libDCM libraries.

Then we can figure out how to add the necessary new functionality to
the libraries.  Since MatrixPilot and MP_Heli will share the same copy
of the library code, we'll have to decide which of these changes we
want to apply to both apps, and which changes should be optional, and
only enabled by the heli code.

After that, we'll just make a copy of the current MatrixPilot app,
call it MatrixPilot-Heli or any other name you chose, and merge all
the remaining changes into that app.

How does that sound to you guys as a future integration roadmap?

Ben



On Mon, Dec 20, 2010 at 2:53 PM, Marcus Fahlén <marcus...@gmail.com> wrote:
> John,
> We found out that there is is some fundamental faults in the calculations of
> centripetal forces, or the conversion of the coordinate systems used. As I
> pointed out; I'm rather "fresh" on this subject but I'll do my best to
> learn.
> I can cantact Ben and hear how much he is willing to help me (as a beginner)
> to get going with a migration. That doesn't mean that the current MP-H
> development has to stop, but we could build a code base to try to make the
> "big leap" at a later point in time.
> I am as I mentioned retired, due to injuries and side effects of these. I
> have a lot of time to spend, but not much money to buy hardware I'm afraid .
> (Luckily I have a "sample account" at Microchip so I can get the basic CPU's
> for different projects for free.) I just got ten dsPIC30F4011 in DIL
> packaging meant for building a "HILSIM UDB-clone" so that I don't have to
> use my (later) flying UDB as bench test equipment which tends to ruin them
> rather quickly.
>
> Talk to you later!
>
> My best regards
>
> / Marc
> On Mon, Dec 20, 2010 at 7:25 AM, John McClelland <mcclell...@gmail.com>
> wrote:
>>
>> Hi Marcus
>>
>> Just a VERY short history of the development of MP-H...
>>
>> Yes it started with Aileron Assist (this was a while back). I wrote some
>> code to control the swash and few a few other things to get started. Bill
>> and I then got a version that should work for my TREX 450. I started
>> testing and immediately found that the gyros on the Red Board were too
>> sensitive to vibrations and would always saturate. We tried various
>> filtering and vibration isolation, but nothing really worked. Bill sent me
>> a Green Board with gyros with better vibration sensitivity, but limited rate
>> characteristics. It wasn't until we got the Invensense gyros did things
>> start to work.
>>
>> Once we got pitch and roll stabilization to work I had some discussions
>> with Ben and Bill about trying to integrate with the mainstream MatrixPilot
>> development. There were pluses and minuses, but in the end I jumped in the
>> deep end and got the (then) current version of MP 2.0 converted to helis.
>> This is basically MP-H.
>>
>> As MP continued to develop, I had more discussions with Bill and Ben and
>> we decided that we had a lot of work on MP-H to catch up with even 2.0 since
>> we still had to impliment yaw stabilization, heading hold, and navigation.
>> So trying to fully integrate MP-H with MP did not seem like the best
>> investment in time and effort at this point.
>>
>> It has always been my intention to make the jump to fully integrated MP
>> once we had all the basics in place. We have made a lot of progress, but
>> much remains. The heading hold work turned out to be a huge effort and
>> still isn't 100%. We are hoping that some of the residual problems are
>> related to the glitching reported on the extra output channels (which we use
>> for yaw). I haven't had time to get that patch in so don't really know if
>> that is it or not.
>>
>> So the heli guys talk to the MP guys, but I'm sure we can do better. Bill
>> was a major contributor to both.
>>
>> I haven't looked at what it takes to convert to the 3.x structure. I'm
>> sure Ben can tell us what is involved since it should be whatever diffs have
>> been made between 2.0 and 3.x.
>>
>> If Ben and Peter (and/or others in the MP dev team) are willing to help, I
>> am willing to put in the effort...but it's just me right now with a long
>> TODO list.
>>
>> Back to the original question, I take it that HIL sim doesn't work
>> yet....even if we were to convert to 3.x if I understand you correctly.
>> Maybe at some point.
>>
>> Best
>> John
>>
>> ----- Original Message -----
>> From: Marcus Fahlén
>> To: uavhel...@googlegroups.com
>> Sent: Sunday, December 19, 2010 10:56 PM
>> Subject: Re: Heli and Quad Users shout out
>> John,
>> My intentions with the X-Plane and HIL-simulation was from the beginning
>> to use it for helicopter simulations since I had a few nasty surprises that
>> cost me a lot of cash that I really couldn't afford to fix. Now when the
>> helicopter is in flying condition again I wanted a simulation environment to
>> test all aspects of the code and hardware before trying to get it airborne
>> again with the UDB in the cockpit.
>> When I started to ask around a little among the people that has written
>> the plugin used for interfacing MatrixPilot to X-Plane I was told to first
>> migrate the code base to the "new" standard that we have called "the 3.X"
>> for a while. (It's the one that is built on the libUDB and libDCM libraries.
>> This should do the work much easier and would open the doors for using some
>> of the other great stuff that has been developed by the MP dev. crew. I
>> started to look at it using the guidelines given to me by Ben Levit
>> (studying the migration of the RollPitchYaw demo for UDB.) I was rather
>> surprised when I realized that this wasn't the common goal for the rest of
>> the heli community, and I then understood that there is no real cooperation
>> between the MP development team and the MP-H development (team?). I was of
>> the impression that you had been "pushed" in that direction before, but were
>> unwilling to go that route.
>> When I couldn't get any help in developing anything for the "old" code
>> base I concentrated on learning as much as I could about the plugin,
>> datarefs and the "MP3.X" code base. I have since then been busy "debugging"
>> MP3.X and the HIL-plugin. That is; I have used 100's of hours to find and
>> point out faults in the plugin that wasn't so obvious at the first glance.
>> Now there is said to be work going on to rectify the HIL plugin so that it
>> works as it is supposed to, but I have no idea about the progress here. It's
>> only a few weeks since I got my complaints classified as an "issue" or
>> "issues" with the HILSIM plugin for X.Plane.
>> My understanding is that you have been busy with the magnetometer part of
>> the project which is vital to the further development of working rotor wing
>> code for the UDB. For a while it looked to me as there were several guys
>> that were working on horizontal translation algorithms, but it has been dead
>> silent in the "uavheliboard" for a long time now. My guess was that all came
>> down to working magnetometer for control of the nose attitude, which I
>> believe is the base for the work on translational algorithms in combination
>> with altimeters with greater accuracy then a standard GPS. (barometric
>> altimeters in combination with ultrasound or anyting else with millimeter
>> resolution and accuracy.
>> I have had my ideas about how this should work, but since I'm not a
>> programmer I can only speculate and do "pseudo code" for manipulating a
>> rotor wing drone. (I was thinking vector math based on accelerometer and
>> gyro inputs.) As I have understood the "original" Mahony papers is dealing
>> more with vertical (helicopter type) drones with counter rotating rotors
>> than airplanes. This was also a discussion among the MP devs to do a more
>> "Mahonyish" code base.
>> I have no idea about what this really means to us, but I guessed that the
>> "new" (3.X) code base was a step in that direction.
>> Then I don't understand (based on my knowledge level) why the heli code
>> shouldn't migrate to the same code base?
>> Isn't it a "relative" easy task to port the MP-Hv2 code to the 3.X code
>> base? On Ben it sounded like even I with my VERY limited C-skills should be
>> able to pull it off (with some help and guidance from him).
>> I Have not had the energy to study all the different versions of the heli
>> code since my health is deteriorating rapidly, but my guess is that it is
>> originally based on the "Aileron Assist". Am I right?
>> Would it be a monstrous task to do this "porting" so that the helicopter
>> specific control routines can use the libDCM and libUDB libraries?
>> If we were able to do this there is so much more to "leach" from the MP3.X
>> There is virtually new functions and options coming each day. I hardly keep
>> up with trying all the new development code being produced these days. In
>> the last few weeks we have had added support for PPM input (8ch in and 8ch
>> out), camera targeting that works wonderfully, Matt's CAN-Bus co-processor
>> board that opens for some interesting possibilities, support for a bunch of
>> telemetry protocols which of MAVINK seems to be the most sensible since it's
>> binary, and now last we have "bumped" the speed of the telemetry UART to
>> ridiculous speeds by using the internal (fast) clock and a 8x multiplier.
>> (I'm currently running my telemetry at 57600 baud and had it running at
>> 230400 just for test.
>> I really can't see why we shouldn't do a move towards the 3.X code base so
>> I would be very glad if you could describe the hurdles (in a very short
>> format and understandable way so that even an old soldier can get an idea of
>> what's the catch). Just point out the main problems that hides from my
>> un-experienced point of view, so I could get a better picture of what's
>> going on and which path is the most sensible to take.
>> My whole involvement in this project is to learn C programming and to
>> create a new base for a source of living for the future.
>> I have some ideas that have been growing in my head for the last 10
>> years... Now it looks like they might become a reality in my lifetime. (A
>> small, cheap drone that's available to almost anyone, but more importantly;
>> a drone that actually can do some useful work.)
>> I'm thinking SAR (Search And Rescue) since this is what I have been dong
>> for the last 10 years on the side of my ordinary work as a computer network
>> engineer.
>> My understanding of the MP-H is that it's your "brain child". I will no
>> try to convince you to do this or that. My knowledge in this area is much to
>> modest for that, and it's not my kind of being to try to "push" peole in
>> directions against their will. I just want an (short) explanation to why the
>> roadmap doesn't include migration of the MP-H to MP3.X code base.
>> My very best wishes for a merry Christmas and a happy new year to you and
>> your family.
>> Talk to you later
>> / Marcus
>>
>>
>> On Mon, Dec 20, 2010 at 1:18 AM, John McClelland
>> <mcclell...@gmail.com> wrote:
>>>
>>> Hi Marc
>>>
>>> Will be good to have you flying again.
>>>
>>> I'm very interested in your HIL sim work. Do you have it working for our
>>> MP-H code? I am putting together some ideas on navigation and flight states
>>> and trying them out on the simulator would help a lot.
>>>
>>> Best
>>> John
>>>
>>> ----- Original Message -----
>>> From: Marcus Fahlén
>>> To: uavhel...@googlegroups.com
>>> Sent: Sunday, December 19, 2010 5:15 PM
>>> Subject: Re: Heli and Quad Users shout out
>>> Hi John,
>>> Yes, I'm still with you...
>>> I have a defect UDB that will not be flying my helicopter anymore before
>>> it at least get's it's daughter board replaced.
>>> I have been promised a new one by Sparkfun. After I have changed the gyro
>>> board I will continue where I left (doing initial tests on a .50 nitro). In
>>> the meantime I have been busy studying the MP3.X code and done quite a lot
>>> of HIL simulations using X-Plane to help develop the MP3.X I have also
>>> written code for supporting the 868 PRO XBee (extended range XBee's with a
>>> pesky duty cycle of 10%). These are ideal for long range telemetry (80km),
>>> but with only 10% duty cycle (10 minutes of active transmission per hour).
>>> This problem has kept me occupied but now it's solved.
>>> Cheers!
>>> /Marc

 

[Marc-X]

Ben, John,


To me it sound like a plan at least. I shall not involve myself too
deep in the technical aspects of the discussion, but this at least is
a way I think will help MP-H to survive and make good use of all the
late improvements to the "mainstream" (3.X) version of MP.

Jsut call out if there is some tedious task that needs to be done that
even my C-skills can handle!

Cheers! (and Merry Christmas to you both and everybody else)

/Marc

On Dec 20, 4:37 pm, "John McClelland" <mcclelland.j...@gmail.com>
wrote:

> > On Mon, Dec 20, 2010 at 7:25 AM, John McClelland <mcclelland.j...@gmail.com>

[stev...@live.cn]

Hi Guys,

I think I have successfully integrated the MPHV2 with the
MatrixPilot_mavlink version790 and performed a branch test on my CCPM
heli. The result looks great! The AIRFRAME_HELI setting can coexist
with the normal plane's setting right now (I think) plus the support
of the amazing MAVLINK protocal.... I have sent a copy to John
already. After his review and making sure it is doing the right thing
then it will be a great news, for me at least.

Regards,
Steven

> ...
>
> read more »

[John McClelland]

Hi Steven

That is great news! I have been spending all my time udating to V3 and
working with Jerry on Quad FW. Migration to MP has always been an important
TODO, but never had the time.

Let me take a look. If it looks OK we could include the V3 mods as well.

Best,

Hi Guys,

Regards,
Steven

> > On Mon, Dec 20, 2010 at 2:53 PM, Marcus Fahl�n <marcus.fah...@gmail.com>

> read more �

[Marcus Fahlén]

Steven,

I'm EXTREMELY curious on your work since I have had the same intentions and did a whole lot of research for the migration. If you have successfully merged the MP-Hv2 with the trunk version of MP I'm the first one to scream YIPEEE! And congratulate you. Do you have a repository for your code so that I can have a closer look at it and compare it to the planned migration I had in mind?

Sincerely.

Marcus Fahlén

Sent from my Sony Ericsson XPERIA™.

Hi Steven

Hi Guys,

Regards,
Steven

> > On Mon, Dec 20, 2010 at 2:53 PM, Marcus Fahlén <marcus.fah...@gmail.com>

> read more »

[john mac]

I have bench tested Steven's migrated code and it seems to behave
reasonably in stabilized mode. That is a very good sign. I need to
chase down a few subtle issues and eventually flight test. But this
is a big step forward if we get it all to work.

Thanks to Steven for this good work!

John

On Feb 3, 10:07 am, "John McClelland" <mcclelland.j...@gmail.com>
wrote:

> > > On Mon, Dec 20, 2010 at 2:53 PM, Marcus Fahl�n <marcus.fah...@gmail.com>

> ...
>
> read more »

[Marcus Fahlén]

Is there a chance I could have a look at it too?
(I have been working in the same direction, but were early "stuck" due to limited skills)

Sincerely.

Marcus Fahlén

Sent from my Sony Ericsson XPERIA™.

[Wouter van Verre]

Does this migration include Bill's patch to increase the ADC sampling rate? I think this patch would increase performance on quads and helis, because it treats vibrations as signals instead of noise.

Wouter van Verre

[John McClelland]

I will let Steven speak to this in detail, but my reading of the code is
that it is using the higher clock speed and oversampling options. Still
testing on my end.

[stev...@live.cn]

Hi,

Yes. I am using mavlink version 790 as the base code. It works by
averaging the IMU's input data 30,000 times a sec and thrown off the
FILTERSHIFT we used for enhanced S/N ratio previously. It has been
proven to provide a more stable roll, pitch and yaw drift. This could
be a great starting point for future heli development. Please correct
me if I explained anything wrong. Thanks.

Regards,
Steven



On Feb 4, 8:53 pm, Wouter van Verre <wouter_van_ve...@hotmail.com>
wrote:

> Does this migration include Bill's patch to increase the ADC sampling rate? I think this patch would increase performance on quads and helis, because it treats vibrations as signals instead of noise.
>
> Wouter van Verre
>

> ...
>
> read more »

[Marc-X]

Steven,

I tried to "re-structure" your work to follow the MatrixPilot 3.x
directory structure with poor results. I can't get it to build (while
your "flat" structure builds just fine).
One question:

In the "protocol.h" file you have an #include "string.h"
I can't find that file anywhere inside the project. Is it external?

Cheers!

/ Marc

> ...
>
> read more »

[Marc-X]

Steven, John and everybody else:

I have now a re-structured version of the code that compiles cleanly.
It's built using the "MP3.x" structure, with libDCM, libUDB,
MatrixPilot and MAVLink in separate directories.

I can mail a zipped archive if anyone is interested.


Cheers!


/ Marc

> ...
>
> read more »

[John McClelland]

Hi Marcus

Yes please send.

I did a flight test today. While the swash behaved properly on the bench,
it had oscillations in flight. They looked similar to what I have seen in
the past with too small a FILTERSHIFT for a given gain setting. However
Steven is using Bill's oversampling patch which does not use FILTERSHIFT.
MP-H V2 with same gain settings flew fine.

I am waiting to see if Steven had to modify his gains when using
oversampling.

Best,
John
----- Original Message -----
From: "Marc-X" <marcus...@gmail.com>
To: "UAVHeliBoard" <UAVHel...@googlegroups.com>
Sent: Friday, February 04, 2011 2:33 PM
Subject: Re: Migration of MP-H to Mainstream MatrixPilot

Cheers!

/ Marc

> > > Marcus Fahl�n <marcus.fah...@gmail.com> wrote:
> > > >Is there a chance I could have a look at it too?
> > > >(I have been working in the same direction, but were early "stuck"
> > > >due to limited skills)
>
> > > >Sincerely.
>

> > > >Marcus Fahl�n
>
> > > >Sent from my Sony Ericsson XPERIA�.

> read more �

[Marc-X]

Hello,

Now I'm setup for testing the merged MP-H MP 790.
On the firs try I didn't get any response to my radio (using my
settings from earlier MP-H versions)

I tried to re-build my "MP3.x-structured" version of "MP-H 790" with
inverted PPM signal input.
That didn't work:

servoMix.c: In function 'servoMix':
servoMix.c:214: error: syntax error before ')' token

I get the same result with Stevens original "flat" directory
structure.
Any one else who have tried this (inverted PPM signals)?

Cheers!

/ Marc

On Feb 4, 11:11 pm, "John McClelland" <mcclelland.j...@gmail.com>
wrote:

> ...
>
> read more »

[Marc-X]

Another thing regarding the merged version:

Is a GPS required now for this code to work?

/ Marc

> ...
>
> read more »

[John McClelland]

I was able to compile Steven's version for standard PWM inputs with no
errors.

No GPS is required as before.

Swash behaves as expected on the bench in Stabilized Mode.

Problem is oscillaitions in flight.....Haven't heard back from Steven if he
flew this code with standard gains or not.

John
----- Original Message -----

From: "Marc-X" <marcus...@gmail.com>
To: "UAVHeliBoard" <UAVHel...@googlegroups.com>

Sent: Saturday, February 05, 2011 6:01 AM
Subject: Re: Migration of MP-H to Mainstream MatrixPilot

/ Marc

> > > > > Marcus Fahl�n <marcus.fah...@gmail.com> wrote:
> > > > > >Is there a chance I could have a look at it too?
> > > > > >(I have been working in the same direction, but were early
> > > > > >"stuck"
> > > > > >due to limited skills)
>
> > > > > >Sincerely.
>

> > > > > >Marcus Fahl�n
>
> > > > > >Sent from my Sony Ericsson XPERIA�.

> > > > > >> > > On Mon, Dec 20, 2010 at 2:53 PM, Marcus Fahl�n

> read more �

[Marc-X]

Sorry guys, I did a F-up (didn't assign a value for
"AILERON_SECONDARY_CHANNEL_REVERSED"
That's the reason I got this eror...

/ Marc

On Feb 5, 1:59 pm, Marc-X <marcus.fah...@gmail.com> wrote:

> ...
>
> read more »

[stev...@live.cn]

Hi John,

Sorry to tell you about that but I haven't get my UDB board fixed on
the Heli right now and with lots of cables brought from sparkfun
sticking out... I need to go to the RC store to buy some cables
suitable for intstalling onto heli. In addition, I am in Australia and
the weather is too hot here and too windy, I am not an expert in
controlling RC heli, so flying my heli outside at daytime could be a
challenge for me. Anyway, I will get the work done and try to find an
indoor place where it allows me to fly a heli. Thanks for testing the
code and feedback, John. I will try to figure out whether the gains
should be increase/decrease in order to eliminate the oscillations
during the flight.

Regards,
Steven

On Feb 6, 12:15 am, "John McClelland" <mcclelland.j...@gmail.com>
wrote:

> I was able to compile Steven's version for standard PWM inputs with no
> errors.
>
> No GPS is required as before.
>
> Swash behaves as expected on the bench in Stabilized Mode.
>

> Problem is oscillations in flight.....Haven't heard back from Steven if he

> > > > > > Marcus Fahl�n <marcus.fah...@gmail.com> wrote:
> > > > > > >Is there a chance I could have a look at it too?
> > > > > > >(I have been working in the same direction, but were early
> > > > > > >"stuck"
> > > > > > >due to limited skills)
>
> > > > > > >Sincerely.
>

> > > > > > >Marcus Fahl�n
>
> > > > > > >Sent from my Sony Ericsson XPERIA�.

> ...
>
> read more »

[John McClelland]

Hi Steven

No problem. I must have misunderstood that you actually flew with this
code.

I will try to chase down the gain issue, since it requires flying the heli.

I am still concerned that some problems with early MP which I fixed in MP-H
may have gotten migrated to the more recent version of MP and could now be
"double fixed". I just have to pour through the code to see what you did.

An example of this is fix to extra channel output twitching that I fixed up
in MP-H, which I presume was already fixed in the version of MP you migrated
to.

Best

John
----- Original Message -----
From: <stev...@live.cn>
To: "UAVHeliBoard" <UAVHel...@googlegroups.com>
Sent: Saturday, February 05, 2011 6:29 AM
Subject: Re: Migration of MP-H to Mainstream MatrixPilot

Hi John,

Regards,
Steven

> > > > > > Marcus Fahl�n <marcus.fah...@gmail.com> wrote:
> > > > > > >Is there a chance I could have a look at it too?
> > > > > > >(I have been working in the same direction, but were early
> > > > > > >"stuck"
> > > > > > >due to limited skills)
>
> > > > > > >Sincerely.
>

> > > > > > >Marcus Fahl�n
>
> > > > > > >Sent from my Sony Ericsson XPERIA�.

> read more �

[XieS.X.]

Hi John,

I have look through the code today but I don’t think the buffer flush code
has been fixed in the original MP_mavlink. I assume you develop the new
buffer flush code by moving the #if (NORADIO == 0) around? However, I am
not so clear about the purpose of doing that, to fast return to manual? The
way I construct the mearged code is added the #if(AIRFRAME_TYPE ==
AIRFRAME_HELI ) in front of the protion of the code that belongs to HELI
with #else following the normal plane's code.

Regards,
Steven

From: John McClelland
Sent: Sunday, February 06, 2011 12:43 AM
To: uavhel...@googlegroups.com
Cc: John McClelland

Hi Steven

Hi John,

Regards,
Steven

> > > > > > Marcus Fahl�n <marcus.fah...@gmail.com> wrote:
> > > > > > >Is there a chance I could have a look at it too?
> > > > > > >(I have been working in the same direction, but were early
> > > > > > >"stuck"
> > > > > > >due to limited skills)
>
> > > > > > >Sincerely.
>

> > > > > > >Marcus Fahl�n
>
> > > > > > >Sent from my Sony Ericsson XPERIA�.

> read more »

[John McClelland]

Steven

 

The buffer flush change was in radioIn.c.   Each channel gets its event buffer flushed during the processing of the interrupt. Usually, there is nothing to flush, but in the rare event that an interrupt gets lost due to a very short pulse glitch, the stale events will get flushed from the buffers.

 

The fast return to manual was put in during developement when we wanted to be sure we could quickly go from stabilized to manual mode.  It checks that both the stabilize flag is set AND the mode switch is in the stabilize mode.  The flag gets changed in states.c, so there is the possibility that the switch was thrown but the flag not yet set.  The check was done in the 40Hz loop rather than the outer loop.  I usually stay in stabilized mode now all the time, so it is not a big issue. 

[XieS.X.]

Hi John,

 

Thanks for your explaination. Now everything’s making sence! I just realized that the MP code did fixed the buffer flush problem. So the #if(AIRFRAME_TYPE == AIRFRAME_HELI ) in radioIn_udb.c  is not necessary at all.  I just check the old AileronAssistRv7 and found it did not use the buffer.

 

In addition, I think the fast return to manual is quite useful and may become critical in terms of future deevelopment.

 

In order to reduce yaw drift, do you think we could just use magneto_udb.c included in the firmware for the magnetometer? The magneto input just updating the DCM values and does not affect the MPH code at all.

[John McClelland]

Steven

OK thanks for following up on that. I agree we still need fast return to
manual as we develope new functionality...particularly altitude control...so
it will stay, just not used a lot in current release (since it is pretty
stable).

In V3 I have added the magnetometer code (as well as Heading Hold)...so I
will eventually get that migrated as well.

As best i can tell from the code, the magnetometer code works as follows:
Calibrates and corrects for magnetic declination
Magnetic field vector in body frame is transformed to earth frame
Determine the yaw error in the DCM by taking the cross product of the
measured X-Y magnetic field in the
earth frame with the expected X-Y magnetic field in the earth frame
Reset DCM North
Gyros (omega) are also corrected through correction terms that include
the yaw error

[John McClelland]

Hi Steven

 

I did a quick demo to show the effect of the magnetometer.

 

The set up is I power up, after offsets recorded I rotate the heli in figure 8's to let the magnetometer calibrate properly.  Then I position the heli on the bench roughly pointing North, run for a couple minutes, then rotate the heli to roughly West and continue to record.

 

I write out omega[2] which is the Z gyro, corrected for yaw error, omega[2] which is not yaw corrected, and rmat[4] which is the cosine of the angle between the heli direction (Y body) and what the DCM thinks is North (Y earth).

 

In the attached pictures you will see the effect of the magnetometer ON and OFF.

 

Mag ON pulls the DCM into true North rather quickly.  You can see the difference between the two calculated gyro signals and the tiime lag to correct to the proper value.  Theta is the angle from the DCM.  The step corresponds to about 90 degrees (actually more like 100), but you have to do a little geometry to get the angle change since the heli was on the other side of N before the rotation.  It is divided by 4 just to make it fit on the plot.

 

Mag OFF shows the constant yaw drift since there is no yaw reference to lock to.  Here the two gyros are about the same since no error signal.

 

Hope this helps in understanding what you have seen without a magnetometer.  For a plane flying, the GPS will give a North reference, but the GPS will not report this at rest or in a hover.

[John McClelland]

I was able to do a quick flight test today (just as it was starting to snow) to check my theory that the gains need to be lowered when using the oversampling option in the migrated MP-H to MP code.

 

"Standard" gains are KP = 0.2, KD = 0.1

This produced oscillations at takeoff.

 

I cut all gains in half and the heli was stable. 

 

I was not able to do extensive testing due to the weather, but at least the most obvious problem can be corrected with lower gains.

 

I know there are so errors in the migration, so I would still not recommend flying this code until adequate testing has taken place.