AC3.2-rc9 available through Mission Planner's beta firmwares link

[Randy Mackay]

     AC3.2-rc9 is now available through the Mission Planner’s Beta Firmwares link.  It’s just like –rc8 but it has an important parameter bug fix Tridge just found which is shown in red below.   The bug has apparently been there for a long time but now that we’ve found it, best to get it out there.

 

Changes from 3.2-rc7

1) EKF reduced ripple to resolve copter motor pulsing (only affects people who have set AHRS_EKF_USE to “1”)

2) Default Param changes:

    a) AltHold Rate P reduced from 6 to 5

    b) AltHold Accel P reduced from 0.75 to 0.5, I from 1.5 to 1.0

    c) EKF check threshold increased from 0.6 to 0.8 to reduce false positives

3) sensor health flags sent to GCS only after initialisation to remove false alerts

4) suppress bad terrain data alerts

5) PX4 dataflash RAM useage reduced to 8k so it works again

6) FRAM bug fix that could stop Mission or Parameter changes from being saved (Pixhawk, VRBrain only)

 

-Randy

 

From: Randy Mackay [mailto:rmac...@yahoo.com]
Sent: September 11, 2014 6:44 PM
To: drones-...@googlegroups.com; arducopt...@googlegroups.com
Subject: AC3.2-rc8 available through Mission Planner's beta firmwares link

 

 

     AC3.2-rc8 is now available through the Mission Planner’s Beta Firmwares link.  The few changes are in the ReleaseNotes.txt but also copied below.

              https://github.com/diydrones/ardupilot/blob/master/ArduCopter/ReleaseNotes.txt

 

Changes from 3.2-rc7

1) EKF reduced ripple to resolve copter motor pulsing (only affects people who have set AHRS_EKF_USE to “1”)

2) Default Param changes:

    a) AltHold Rate P reduced from 6 to 5

    b) AltHold Accel P reduced from 0.75 to 0.5, I from 1.5 to 1.0

    c) EKF check threshold increased from 0.6 to 0.8 to reduce false positives

3) sensor health flags sent to GCS only after initialisation to remove false alerts

4) suppress bad terrain data alerts

5) PX4 dataflash RAM useage reduced to 8k so it works again

 

     The lower AltHold gains may reduce the motor pulsing some APM2 users are seeing but if not we may need to add additional filtering.

 

     I have not included the fix to enable reset-yaw-to-armed-heading because although I have a patch, it needs some more dev testing.

            https://github.com/rmackay9/rmackay9-ardupilot/commit/fbf069838856a0d1b92ef6055eb6d6d183b4765c

 

-Randy

[Xerr Avon]

Hi,

I just upgraded a octaquad from RC4 to RC9, I got the compass not calibrated so I did the write eeprom trick (which worked fine on a quad and hexa as far as I know) but on the octaquad I am now getting a bit different message, it is "PreArm: compass inconsistent" I tried writing and rewriting both compass ID's but still getting the message. I will try a recalibrate compasses later..

John. 

[Balloonzaa Dynamics]

Randy,

    I have see issue is about Bad AHRS 's message on HUD when i had enabled AHRS_EKF_USE to 1. Please check firmware it. But after disable AHRS_EKF_USE to 0 is not have AHRS message. 

Thank and Best Regards,

Balloon

--
You received this message because you are subscribed to the Google Groups "ArduCopter Testers Team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to arducoptertest...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Lefebvre]

That's the message I get with rc7.  I believe it is due to the fact the internal compass calibration is hopeless with offsets >5000.  This due to the fact it is 1cm from the motor on my heli.  Nothing I can do about that.  And apparently at this time there is nothing that can be done to simply completely ignore the internal compass.  The only thing I can do is turn off Pre-Arm checks for compass.  However, I don't like that that leaves me vulnerable to other compass problems.

How bad are the offsets on your internal compass?

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[Craig Elder]

>>>I just upgraded a octaquad from RC4 to RC9

You need to complete a compass calibration so that both compasses are calibrated.

Also there are some issues with landing detection not determining that a vehicle has landed.

You received this message because you are subscribed to the Google Groups "ArduCopter Testers Team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to arducoptertest...@googlegroups.com.

[David Pawlak]

Wasn't there a parameter to ignore internal compass?? Maybe we just talked about it.So much has gone on, it's hard to remember.

[David Pawlak]

I'm getting the bad AHRS data as well. It arms OK.

My calibrations were fine with 3.2-rc7 just the yesterday.

Also noticed a little hesitance in param loading via telemetry and slow to get all the data flowing to the HUD. That might have been because of the change back from 3.1.5 not sure.

[Randy Mackay]

David,

 

     No there’s no parameter but we think it’s possible to disable by modifying a startup file on the SD card.  As long as the external compass is working the internal one will never be used.  The external one could fail but as long as arming checks are enabled you’ll know before take-off.  All this means you only need to worry about the possibility of an inflight failure and it’s hard to know which is worse, no compass at all or use the internal… perhaps no compass would be better because the heading will probably remain good for 30seconds or more even without a compass.

 

-Randy

[Robert Lefebvre]

Randy, pre-arm checks will not catch if the external compass fails.  This is because you have to turn off pre-arm checks just to arm in the first place, because the internal compass is so bad, we get the "inconsistent" message, and cannot arm.  We are forced to turn off the checks, just to fly.  Then we are open to the possibility of the external mag failing before a flight, and not knowing.

--
You received this message because you are subscribed to the Google Groups "ArduCopter Testers Team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to arducoptertest...@googlegroups.com.

[David Pawlak]

What does bad "AHRS Data refer to"? It doesn't seem to affect the ability to arm.

Is it safe to fly? Why does it indicate this now, when nothing has changed (calibrations etc.)since 3.2-rc7?

On Thursday, September 11, 2014 9:40:56 AM UTC-3, Randy Mackay wrote:

[Randy Mackay]

David,

 

     I’ve never seen that message.  Where are you seeing it?  If you have a log file that would be good.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of David Pawlak

Sent: September 12, 2014 9:04 PM
To: drones-...@googlegroups.com
Cc: arducopt...@googlegroups.com

--

[David Pawlak]

OK, went out and got a log.

Aside from problems establishing a solid connection via telemetry before I went to the field (long delay before HUD showed all the data. Don't know if it was recuperating terrain data which it might have lost with 3.1.5 just previous or what... At home before going to the field I did a gyro calibration just for fun.

But, at the field, connected OK and NO "AHRS Data bad" at first. But when I tried to arm it gave "Alt Disparity". Alt indicated "0". So I reset the octo and tried again.

This time AHRS data bad. But I could arm OK. So I flew. I was in Poshold so went to look at MP, and no more AHRS Data bad message.

Flew like a charm I bumped EKF_NOISE.... parameter from 1 to 3. and the octo was very flat in all directions into and with the wind.

It was fairly choppy today, but handled better than it has for a while.

Go figure.

[Emile Castelnuovo]

Good! nice to know...

Where you using the M8 as a GPS?

E.

[David Pawlak]

I guess I should post logs :)

On Thursday, September 11, 2014 9:40:56 AM UTC-3, Randy Mackay wrote:

[David Pawlak]

No, just the ublox that they sell on 3DR bought it in April.

[Xerr Avon]

Hi,

I also saw this bad "AHRS Data  message too, at least on  one copter after loading RC9, it went away after a little while.  I think it was only on one copter, a quad and I am using M8N and leah 6  GPS's.  I did not fly after loading RC9 but right now I have the copter ready to take off and I have not seen the bad "AHRS Data  since right after loading RC9 but I will keep an eye out for it.

John

[Xerr Avon]

I just flew RC9 on a quad, it flew great , only problem I saw was when trying to arm the first time ( I was getting the green blinking "all go" led) I got the 2 buzzer beeps, checked on the HUD said "Alt Disparity". my alt read 2 so it looks like maybe it did not try to reset the alt at arm, anyway I tried a preflight reboot from MP but didnt work still got "Alt Disparity". till I unplugged the battery and reconnected. then all was great

John

[Josh Welsh]

I’ve gotten it too in –rc6 or 7 and just ignored it as I figured it was a byproduct of the init routines.  It only ever occurred at the beginning when I plugged the batt in and connected, but after that I never heard it again.

[Marco Robustini]

There is a small problem that I noted yesterday, if during Acro mode you're running a few loops and level your quad switching to Stabilize probably an integral that is stored (the level of the quad remains tilted by about 10°) causes a drift for a few seconds, until the accelerometers are not relaxing.
Obviously this is an extreme case, it is not a maneuver that they all do, but unfortunately there is this problem, for now detected and tested with DCM.

Marco

[Paul Riseborough]

Marco

DCM (and to a lesser extent EKF) has a known tendency to wander off during successive loops in the plane application. The susceptibility seems to vary from board to board so I have a theory that IMU scale factor errors are partly to blame along with the GPS motion filter not being able to keep up.

If you post your log, I can tell if it is the same phenomena that we see on APMPlane. We don't get much data in this part of the flight envelope, so logs from flights like this are valuable.

Regards,

Paul

[Robert Lefebvre]

Marco, this has been like this for a long time, nothing new I don't think.  I noticed it last year when I started working on Acro.  The DCM algorithm simply isn't accurate going through a loop.  It could be because of scale factors as Paul mentions, or it could be because of known "fast trig" equations which are inaccurate, but used to save time on APM.  Jonathan knows more about this.

You should try the same manoever with EKF.  I have found it to be much more accurate.  But note that, due the scaling factors Paul mentions, if you do *too many* loops in fast succession, the EKF can fail and reset.  Apparently I almost had this on one test flight after doing about 5 rotations in 2 seconds.

--

You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[Josh Welsh]

Just to clarify, is the condition you, Paul and Marco are referring to only when switching to Stab from Acro after hard maneuvers, or can you expose this condition when flying only in ACRO with no switch to another mode?

[Robert Lefebvre]

Well... there's not one answer to that.  Ok, so when doing flips and things, the AHRS can go a little off.  There is an angle error, but you won't see this in rate mode (Acro).  It's only when you change back to Stabilize that the error becomes apparent.  I've seen errors up to... maybe 30 degrees after just two or three fast flips on a quad, with DCM.  And it takes a long time to straighten out.  This seems to be much better with EKF, I've only see a couple of degrees of error, maybe 5. Very minor.

However, the second part is, that in the last log of mine that Paul looked at, he said the EKF was pretty close to resetting after doing, I dunno, 5-10 really fast pirouettes.  I don't know what would have happened real-world if this had happened.  I think there may have been a little jerk in the rate, up to 10 degrees when it changed.  However, if you change to Stabilize at the same time this happens, it's hard to say what would happen, it might flip right upside down.  

[Josh Welsh]

Ah ok, thanks for the clarification.  That is what I expected but wanted to verify.

 

Most of the rate/ACRO testing I’ve been doing are flights flown 100% in Acro so that must be why I’m never seeing this issue.. that I know of.  If you’re bored, here’s the latest log; if you decide to look, I’d be curious to know if you see that condition.  This is with EKF off yet.

[Paul Riseborough]

Josh,

No major issues with the flight that I can see. EKF was well within limits throughout. DCM builds up to 10deg of roll error after some of the maneuvres. There was a significant offset on your X magnetometer that the EKF had to adapt to (your MagX offset should be -145, not the current value of -60).

Your flying is not producing the large g transients that Robs does and you are doing single flips (one stayed inverted briefly) not doing continuous rotations. Rob get the prize so far for being hardest on the estimators :)

Paul

[Robert Lefebvre]

I'm wondering if the manoever that threw it for fits on mine, was I pulled vertical, and did a falling pirouette.  That would take the compass out of the equation, and then the fast yaw rotations just confused it because of the scale error between the two gyros?

--

[Josh Welsh]

Ha, thanks Paul!  With Rob flying TradHeli he’ll be able to do more G’s than me, but…

 

Challenge Accepted.

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Paul Riseborough
Sent: Saturday, September 13, 2014 2:05 PM
To: drones-...@googlegroups.com
Subject: Re: [drones-discuss] Re: AC3.2-rc9 available through Mission Planner's beta firmwares link

 

Josh,

--

[Paul Riseborough]

Maybe - the EKF does use full 3D earth field and 3D measurements, so magnetometer is useful regardless of orientation, however during periods of high rotation, the weighting on magnetometer measurements is reduced as I originally had concerns about filter stability due to the effect of  magnetometer measurement latencies. I no longer have the same concerns, and given scale factor errors on gyros on your log are larger than I had anticipated, I think it would be appropriate to revisit the magnetometer weighting.

The current replay using 50Hz log data is not useful for logs that have rapid manoeuvres or high levels of vibration. so for this type of analysis I really need a logging option that turns on 400Hz logging of IMU data with all the other measurements that the EKF uses running at their respective rates. This will may need other logging to be turned off. Then the Tools/Relay facility needs to be updated to work with data.

[Jonathan Challinger]

Why couldn't EKF learn scale factors for the gyros over very long periods of time? Seems like it should be simple enough.

[Randy Mackay]

 

     There was an issue in –rc7 (and earlier) where the “extended status” was being reported before the copter had fully initialised.  I’ve fixed that in –rc9.

 

     I’ve also noticed that the gyros & accel can be bad immediately after a firmware update.  It seems more important with AC3.2 that after a firmware upgrade the board is power cycled.

 

-Randy

[Paul Riseborough]

Jonathan,

It would require adding 3 states to the main filter going from 22 to 25, and we are already pushing the limit of what is sensible to run within a 400Hz main loop call. This means it would have to be estimated using a reduced order auxiliary filter which would need to be derived, implemented and tested. At a minimum it would need to be 10 states (4 quaternion, 3 velocities and 3 scale factors). However if the error is due to non-linearity (a change in scale factor with rotation rate), then it will not work. Neither will it work if the scale factors are sensitive to temperature. The MPU6000 data sheet indicates a scale factor tolerance of 3% at 25degC with a 2% variation over temperature and a nonlinearity of 0.2%, so the temperature variation is of concern.

The word 'simple' wasn''t the first one that came to mind.

Regards,

Paul

[Randy Mackay]

 

     I had never thought about it before but I guess, like the compass, we should add scaling to the gyros in addition to the existing offsets.  The problem is that we can’t easily ask the user to spin the board at a precise speed to be able to collect the points in order to calculate the scaling, instead we can only rely on in-flight learning.

 

     I guess if every user had all the money in the world we could develop a device that rotates the pixhawk in 3 dimensions at know speeds and then capture the required points so we can do the scaling.  It would be a fun device to make although I can’t see it happening any time soon!

 

-Randy

[Arthur Benemann]

We are not doing temperature compensation on the gyros?

@Randy: Or we can just ask the users to buy one of these.

Arthur Benemann

[Marco Robustini]

The other big unsolved problem is the discrepancy that exists in the compass after yawing faster the quad with Simple mode, i need your feedback about this issue, please try this:

- engage Simple and check the direction of the virtual nose
- start to rotate faster the quad with yaw for one minute like in my video: https://www.youtube.com/watch?feature=player_detailpage&v=SdRZuQiS7G4&list=UUPcCCiqkWYZmvxVgHhDZDHA#t=323
- disengage Simple and check again the virtual nose

After this test i've a big error, over 45° of compass drift, and in this situation any operation that requires the compass obviously fails.
Other important issue are reported in my test list here: https://docs.google.com/spreadsheets/d/1yrYKJ-Txf5DBbEI7x4sk1p0Gts-5gjXCoiIdAyfnL7M/

Marco

[Marco Robustini]

I would add: even leaving inserted Simple you should realize that the error of the compass increases.

Marco

[Randy Mackay]

Marco,

 

     Thanks as always for the detailed testing.

 

     Re your list, the throttle pulsing when using EKF should be gone with –rc9 because Paul’s EKF smoothing has been included.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Marco Robustini

Sent: September 14, 2014 3:02 PM
To: drones-...@googlegroups.com
Cc: arducopt...@googlegroups.com

--

[Paul Riseborough]

Marco,

Watched the video - felt dizzy looking at it. This is likely the same effect that Rob has run into with his pirouettes which appears to be caused by scale factor errors on our gyros. I might be able to reduce this effect on the EKF by tuning and changing the way compass measurements are weighted when angular rates are high. I have created a patch which adjusts one of the internal EKF tuning parameters which in theory will reduce the heading drift during sustained spins which I will try this week.

https://github.com/priseborough/ardupilot/commit/f8162f3eeb823cf46801718e19e0b12d92190f21

If this effect is caused by scale factor errors, then the long term solution is to either calibrate or estimate those errors.

Randy,

How can i tell looking at the logs if the code is skipping any 400Hz frames ? That would introduce the equivalent to a scale factor error.

Regards,

Paul

[Jonathan Challinger]

Well, calibrating is pretty much out for our users.

I think we could estimate them and save them to parameters. I bet they'd stay relatively consistent over time, like most of our other sensors seem to.

Maybe copter should run at 200hz if we're already out of space? Or can we run EKF at 100hz and do 400hz interpolation using 400hz gyro data?

--

[Jonathan Challinger]

Or even run stabilize controllers at 100hz and rate controllers at 400hz, using interpolation to avoid derivative spikes (or change the rate controllers to use a PV-only derivative)?

[Paul Riseborough]

In a single threaded system, running a hybrid rate system or interpolating doesn't help in the sense that the EKF still has to complete its slowest frame in the time between rate updates which is 2.5 msec for a 400Hz rate loop. this means that after allowing for other processes and interrupts the slowest frame on the EKF should be designed to complete inside 1.5msec.

[Robert Lefebvre]

Is it reasonable to assume that the scale factor for a particular gyro, is the same in all axis? ie: if a user were to do a calibration in the yaw axis only, would the same scale factor apply to all 3 axis?

[Randy Mackay]

Paul,

 

     The PM message will tell us to some extent.  It will say how many loops are slow and how long the slowest took.  It doesn’t say though if it caught up on the next cycle (after a slow one) or if it skipped a cycle.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Paul Riseborough

Sent: September 14, 2014 4:09 PM
To: drones-...@googlegroups.com
Cc: arducopt...@googlegroups.com

Subject: [Bulk] [drones-discuss] Re: AC3.2-rc9 available through Mission Planner's beta firmwares link

 

Marco,

Watched the video - felt dizzy looking at it. This is likely the same effect that Rob has run into with his pirouettes which i believe is caused by scale factor errors on our gyros. I might be able to reduce this effect on the EKF by tuning and changing the way compass measurements are weighted when angular rates are high, but if it is caused by scale factor errors, then  the solution is to either calibrate or estimate those errors.

Randy,

How can i tell looking at the logs if the code is skipping any 400Hz frames ? That would introduce the equivalent to a scale factor error.

Regards,

Paul

On Sunday, 14 September 2014 15:59:10 UTC+10, Marco Robustini wrote:

The other big unsolved problem is the discrepancy that exists in the compass after yawing faster the quad with Simple mode, i need your feedback about this issue, please try this:

- engage Simple and check the direction of the virtual nose
- start to rotate faster the quad with yaw for one minute like in my video: https://www.youtube.com/watch?feature=player_detailpage&v=SdRZuQiS7G4&list=UUPcCCiqkWYZmvxVgHhDZDHA#t=323
- disengage Simple and check again the virtual nose

After this test i've a big error, over 45° of compass drift, and in this situation any operation that requires the compass obviously fails.
Other important issue are reported in my test list here: https://docs.google.com/spreadsheets/d/1yrYKJ-Txf5DBbEI7x4sk1p0Gts-5gjXCoiIdAyfnL7M/

Marco

[Paul Riseborough]

Rob,

It will be different for each axis

Paul

[Robert Lefebvre]

This "Alt Disparity" thing is really bad.  Seems like if I leave it sit for a few minutes while disarmed, I can't rearm, I have to reboot.  It's not a case of having to wait after boot for things to settle, it's actually OK to arm shortly have booting.  But if I leave it sit for a while, then it won't arm.

[Robert Lefebvre]

Paul, I think this is the log where I had the "Bad AHRS" message while flying in Acro. I'm not sure, because it doesn't seem to show up as a message in the log, but let me know if you can see it please.

I wasn't doing anything too radical, just a succession of hammerheads, sort of like a skateboarder on a half pipe.  So, not continuous rotation, but a bunch of accelerations probably with bad GPS signal because the puck was vertical.

[Randy Mackay]

 

     We don’t have any error messages stored to the dataflash when sensors (or the AHRS) go bad.  Issue raised.

          https://github.com/diydrones/ardupilot/issues/1387

 

-Randy

[Randy Mackay]

 

      You can check the inertial nav alt vs the baro alt.  If they’re off by more than 50cm then it’ll trigger that error.

 

     Like all the other checks it was implemented after a real support issue.  If you want to check your logs and figure out a level that would work better that’d be great.

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Robert Lefebvre

Sent: September 15, 2014 8:45 AM
To: drones-discuss

[Josh Welsh]

Is it possible this is bubbling up only inside of Mission Planner?

[Randy Mackay]

 

     Yes, the sensor health is sent to the GCS using the system status message.  We don’t log the sensor health to dataflash though.  So basically this info will appear on the HUD and in the tlogs but not in the dataflash logs.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Josh Welsh
Sent: September 15, 2014 1:41 PM
To: drones-...@googlegroups.com
Subject: RE: [drones-discuss] Re: AC3.2-rc9 available through Mission Planner's beta firmwares link

 

Is it possible this is bubbling up only inside of Mission Planner?

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com]
Sent: Sunday, September 14, 2014 6:53 PM
To: drones-...@googlegroups.com
Subject: RE: [drones-discuss] Re: AC3.2-rc9 available through Mission Planner's beta firmwares link

 

 

     We don’t have any error messages stored to the dataflash when sensors (or the AHRS) go bad.  Issue raised.

          https://github.com/diydrones/ardupilot/issues/1387

 

-Randy

 

--

[Josh Welsh]

If I can find a T-Log where it happened, would there be any value in that, or is it moot at this point? I saw your github post about logging the sensor health (and I think messages) to the dataflash..

[Christoffer Johnson]

HI, sorry about the last corrupted messages,

I also got the problem with Bad AHRS and also cant rearm after a while after landnig.
Could it be all thiese baro glitches I have? is that normal? Running EKF rc9 on PX4
I have foam over the baro.
Atached:
CTUN: ALT vs BarAlt

[Paul Riseborough]

Rob,

The EKF coped fine, albeit with a number of spikes in the GPS innovations. However during more than one of the manoeuvres, the EKF divergence test false triggered due to the combination of intermittent GPS and accelerations. This caused it to switch to DCM, reset the EKF and then switch back to EKF after 10 seconds. This is the first time I have seen the divergence test false trigger in flight (I have made it trigger during replay  during development), although the previous flight log you posted was getting close to doing so.

I think I need to revisit the threshold or pull that test out altogether. With the compass/velocity innovation health test now in place, it is superfluous.

Paul

[Paul Riseborough]

Randy,

Based on Robs log and looking at the log from the rapid yaw test I performed today on the IRIS, there has been an unintended consequence of the EKF smoothing patch which has made the divergence test more likely to false trigger. If this test false triggers, the AHRS will switch to DCM, reset the EKF, and switch back tot he EKF after 10 seconds to give it a chance to settle. The following patch reduces the sensitivity:

https://github.com/diydrones/ardupilot/pull/1389

I had planed to remove this particular test because there has never been a numerical divergence in the filter since the root cause was fixed early this year, however it was left in because a false trigger is annoying rather than flight terminating and EKF is not used by default.

Regards,

Paul

[Robert Lefebvre]

No, I don't think so Josh.  Because when I try to arm, the Pixhawk refused to arm and give the "Not gonna happen" note.  I tried repeatedly, but it will not arm.  Each time it says no, the GCS says "Alt Disparity".  The only thing I can do is reboot.

While working on auto missions yesterday, I basically had to reboot between every run, if I had updated the  waypoint file which took a minute.

--

[Robert Lefebvre]

Randy, can we even see it in the flash logs?  I was pretty sure it doesn't log if you're not armed?  The problem only occurs while disarmed.  I basically had to reboot any time I left the helicopter sitting more than a minute.  I'll have a quick look through my logs to be sure though.

[David Pawlak]

Same thing here. A tlog shows at least the AHRS data error. probably the Alt Disparity too. But no .bin
 or .log

[Brian DeBusk]

I can answer that one for you.  I had a flaky GPS external compass (that I didn't realize was flaky).  So it would fail-over to the internal compass buried between two 6S batteries.

I got off easy the first time.  It only hit the trees and cracked part of the frame and landing gear.

The second time (a couple of weeks later), it decided to fail-over to the second compass and wound-up in the pool.  It fried everything -- complete loss.

How about a flag like this:

NEVER_EVER_NEVER_EVER_USE_INTERNAL_COMPASS_EVER = 1

Thanks,

Brian

On Friday, September 12, 2014 4:27:55 AM UTC-4, Randy Mackay wrote:

David,

 

     No there’s no parameter but we think it’s possible to disable by modifying a startup file on the SD card.  As long as the external compass is working the internal one will never be used.  The external one could fail but as long as arming checks are enabled you’ll know before take-off.  All this means you only need to worry about the possibility of an inflight failure and it’s hard to know which is worse, no compass at all or use the internal… perhaps no compass would be better because the heading will probably remain good for 30seconds or more even without a compass.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of David Pawlak

Sent: September 12, 2014 7:21 AM
To: drones-...@googlegroups.com
Cc: arducopt...@googlegroups.com

Subject: [Bulk] Re: [drones-discuss] Re: AC3.2-rc9 available through Mission Planner's beta firmwares link

 

Wasn't there a parameter to ignore internal compass?? Maybe we just talked about it.So much has gone on, it's hard to remember.

On Thursday, September 11, 2014 3:45:06 PM UTC-3, robert.lefebvre wrote:

That's the message I get with rc7.  I believe it is due to the fact the internal compass calibration is hopeless with offsets >5000.  This due to the fact it is 1cm from the motor on my heli.  Nothing I can do about that.  And apparently at this time there is nothing that can be done to simply completely ignore the internal compass.  The only thing I can do is turn off Pre-Arm checks for compass.  However, I don't like that that leaves me vulnerable to other compass problems.

 

How bad are the offsets on your internal compass?

 

On 11 September 2014 14:17, Xerr Avon <xerr...@gmail.com> wrote:

Hi,

I just upgraded a octaquad from RC4 to RC9, I got the compass not calibrated so I did the write eeprom trick (which worked fine on a quad and hexa as far as I know) but on the octaquad I am now getting a bit different message, it is "PreArm: compass inconsistent" I tried writing and rewriting both compass ID's but still getting the message. I will try a recalibrate compasses later..

John. 

--

You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Paul Riseborough]

Using no compass is better than using a really bad one. In fact once gyro bias states have settled, EKF is happy without a compass indefinitely provided the vehicle is changing speed or direction periodically which enables it to correct the yaw error.

[Josh Welsh]

How about a flag like this:

NEVER_EVER_NEVER_EVER_USE_INTERNAL_COMPASS_EVER = 1

It seems a bit ambiguous.. 

[Randy Mackay]

 

     I’ve found that in master (and AC3.2) Whether it’s on purpose or not, the fail-over to the internal compass wasn’t working because of a bug (?) in the Compass::use_for_yaw() method.  It was always checking the health of the external compass instead of the primary compass.  This meant that if the primary failed over to the internal compass it wouldn’t automatically switch to it.

            https://github.com/rmackay9/rmackay9-ardupilot/commit/5c756f701b82b503733ba9493dd2e9f1a95be3b5

 

     It’s possible this is intentional (although I doubt it) so I’ll double check with Tridge before checking in the fix.

 

-Randy

[James Collings]

Hi,

time has come to stop just lurking here and try to contribute something again.  real life is calming down and im back flying - ive had several almost flawless hours of flight on 3.1.5, but yesterday flew 3.2 rc9 for the first time.  ive got several things to report, but after a full reset of the board and thorough revision of parameters hopefully will be able to fly again today to confirm it all.

this is on a tbs discovery with APM 2.5, 2212 980kv motors with 1038 props, 5000mAh 3S.  its a bit tail-heavy with no camera on the front now, AUW of 1.4Kg, but has been flying brilliantly with 3.1.5

--------------------

with 3.2 rc9:

the first thing is the loiter, it wasnt just poor on holding position, but actually frightening.  granted it was a slightly gusty day yesterday (it always is here), but this was terrible, i tried loiter several times but always switched back to stabilize very quickly as it seemed almost completely out of control.  in the attached log theres a short loiter in the first minute, hopefully i can get some more loiter time in this evening.

stabilize and alt hold were fine.  auto was reasonable although it seemed a bit vague when deciding which direction to head off in, it also seemed to stay shy of the configured ground and vertical speeds 12m/s, 3m/s up, 2.5m/s down. 

with mission planner i had a couple of issues too, try as i might i was unable to download logs - getting nothing but mavlink data all the time.  i actually reverted to 3.15 to get the logs out in the end.  also, it seems log parameters are mismatched with their headings again? in the attached log "Desired Roll" is obviously not showing the right data, it seems the values are shifted down one place with Desired Roll shown in the Roll field, Roll shown in the Desired Pitch field .. i dont know how many other parameters are affected.  i have updated mission planner with beta updates, but dont know if i should edit parameter definitions by hand? curiously the version reported in the logs is 3.1.5, though it definitely reports 3.2 rc9 at console???

--------------------

given that there are a whole host of new parameters i reset the board completely last night, reinstalled 3.2 rc9 and reviewed the full parameter list looking for anything out of order.  i havent seen anything too strange, but obviously theres a lot of new stuff so this is all at default values now.

as i say, hopefully will be able to fly again today to confirm this, but just wanted to know what the likely cause could be and therefore where to go looking for the solution.  one thing i have never done with this quad is the magneto interference test, though a problem there i would expect to cause problems in all flight modes?

regards,

james

[Xerr Avon]

Hi,

I have flown a couple flights on RC9, the only problem I am seeing is, I updated 2 Pixhawk copters (quad and a hexa) to RC9 the day it was on MP, I did not fly till yesterday.  when a bettery is first connected everything looks good (green flashing led) but when I tried to arm I got "Alt Disparity". in the hud and no arm. I disconnected the batt and reconnected and everything was fine. I flew then let the copter sit for about 30 min's, put a new battery on and got the same error till again I disconnected and reconnected.  I took the other copter out a Hexa and got the same "Alt Disparity". message till I disconnected and reconnected the batt.  It seems like if I let the copter sit for a half hour or so (not really sure about the time in between flights) I will get the "Alt Disparity". problem.

John

On Thursday, September 11, 2014 7:40:56 AM UTC-5, Randy Mackay wrote:

[Paul Riseborough]

John,

Yes, I have experienced the same problem. There is a check in line 13038 of ArduCopter.pde that fails the pre-arm check if the baro alt and INAV alt disagree by more than a metre. There can be problems with this in that the instantaneous baro alt is effected by wind gusts. For example if I start-up downwind of a line of buildings on a windy day, the baro pressure can fluctuate by more than 20 Pa or 2 metres. The baro and Z accelerometer can also be sensitive to temperature changes which sounds like is what's happening in your case as during the first power on, the board temperature will be changing.

Paul

[Robert Lefebvre]

Paul, the strange thing is though, that I usually manage to pass the test shortly after a bootup.  But then if I disarm and leave the heli sitting for a while, such as when I am working on a mission, then I go to arm with the heli having been booted up for a long time, it will fail the check.  I have to reboot, then it will arm immediately.  Then if I leave it sitting for a while again, it will fail the check when I got to arm again.

Randy asked for logs, but I can't get log data as it doesn't log when it's not armed?

[Xerr Avon]

Hi,

Thanks for the info. I don't think it was temperature, as for the pressure changing I cant say for sure but it was not windy.  the first flight, the copter set outside quite a while before I tried to arm it. I cant say for sure how long but I would guess at least 15 min's.  then after that flight it set outside at least 30 min's before I connected the battery.  The hexa did did not sit outside very long before I armed it.

Other than that it flew great!!

John

[Gary McCray]

Hi Paul,

I just brought up a new Pixhawk on RC 9 and had the same problem which caused about 10 seconds of consternation.

It's not a big deal, but obviously it is an annoyance and a possibly unnecessary confusion.

It seems like either a meter isn't enough or possibly this should simply be disabled during any unarmed condition and only (maybe reset and) turned on when it is actually armed.

Just a thought,

Gary

[Paul Riseborough]

We need to get an option in to turn on logging pre-arm. Until we do, it's all speculation.

[Randy Mackay]

 

     I guess enough people have complained about this that we need to loosen the pre-arm check.  So I’ve increased the acceptable range from 1m to 2m.  This is in master and AC3.2.

              https://github.com/diydrones/ardupilot/commit/d8d1b38a52fc3297b7b3378327d9995c88bdfe79

 

     It shouldn’t help to unplug/plug-in in the board.  It’s best just to wait a bit (like 10 seconds) and the inav altitude will catch-up with the baro alt.

 

     To make it easier to log from start-up, I’ve added a #define LOG_FROM_STARTUP to APM_Config.h.  Just uncomment that line and it’ll start logging immediately after initialisation.  Longer-term we should make this a parameter but we’ve run out of bits in both the LOG_BITMASK and the ARMING_CHECK.  This will go into master but not AC3.2.

      https://github.com/diydrones/ardupilot/commit/9bbf40109e3058f58cf26b61ec4312d20f4fd982

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Gary McCray

Sent: 20-Sep-14 10:06 AM
To: drones-...@googlegroups.com
Cc: arducopt...@googlegroups.com

[Randy Mackay]

James,

 

     Thanks for helping out with the testing.  I can’t do much with the logs I’m afraid because, as you said, they’re downloaded with AC3.1.5 so the logging headers are all off.  You can download via mavlink with AC3.2.  It’s actually mentioned as Warning #3 at the top of the AC3.2 beta testing thread.  http://diydrones.com/forum/topics/arducopter-3-2-beta-testing

 

     Re the loiter, I strongly suspect that the compass wasn’t set-up quite right or perhaps there’s a lot of interference from the motors.  The most common issue these days is the compass-orientation or compass-external parameters being set incorrectly and so far I’m suspecting people occasionally forget to select the correct checkbox on the MP’s compass set-up page but please tell me if you think this can’t possibly be the cause.  By the way, the Pixhawk supports multiple compasses and in AC3.2 we’ve taken advantage of this by including a suite of new pre-arm checks that makes setting up the compass incorrectly (and then flying) almost impossible.

 

     Thanks again, hopefully the next flight goes ok.

    

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of James Collings

Sent: 19-Sep-14 1:20 AM
To: drones-...@googlegroups.com
Cc: arducopt...@googlegroups.com

--

[Xerr Avon]

Randy,

I saw you said   "It shouldn’t help to unplug/plug-in in the board.  It’s best just to wait a bit (like 10 seconds) and the inav altitude will catch-up with the baro alt."  My impression was that this was not the case so yesterday I tried. it. For me on one copter anyway (I did not try another yet) that unplugging the copter and plugging back in is the only way to get to arm. I let the cpter set for at least 10 mins, trying to arm intermittently, and got the alt disparity every time till I reconnected the battery. Oh, before my first flight, I connected the batt as usual
 then disconnected and reconnected the battery a second time, I thought this would get rid of the alt disparity message, but it did not.

Just thinking, my usual routine, I connect the battery on a table on a porch then walk the copter to the take off point. so where I connect the battery is about 4 to 5 feet higher than where I arm it,  just in case there is a small chance it may have something to do with why I am getting this message.

John

[Robert Lefebvre]

No, it doesn't have anything to do with moving the heli up or down.  Mine does it just sitting on the table.  It's time that makes it do the alt disparity, for some reason, only way to fix it is reboot.  I'm surprised that not *everybody* has this problem, as all of mine do it.

[Gary McCray]

Hi Rob and Randy,

Depending on a barometer for altitude is what is the basis of the problem, the simple fact is a lot of factors can change perceived altitude by multiple meters.

Normal barometric air pressure shift can easily exceed this in less than a minute, gusty winds also and even small amounts of temperature change can cause a considerable effect.

And that's when its sitting still, dynamic flying conditions and prop wash can pressurize or depressurize the area around the barometer.

Not really advocating a alternate solution (GPS) or laser ranging for instance as a widely applicable cure although they can sure help.

Just need a reality check that the altimeter we use is really just an air pressure gauge which is every bit as useful for predicting weather changes as it is for determining altitude, possibly more so.

Basically in this instance you need to allow enough leeway to account for the myriad other causes of barometric shift.

Two meters will help a lot, but where I live the barometric pressure not infrequently changes several meters in altitude in less than a minute.

In alt hold you can watch the copter ride it up and down even though the log shows the same altitude.

Not really advocating for a better solution here, just people need to be aware that this is a not uncommon phenomenon and be prepared to deal with it.

Best,

Gary

[Robert Lefebvre]

Hi Gary, what you write is all correct, but I don't think is the cause of this problem.  The issues you raise have always been an issue, but it just hasn't been a problem until recently.  The way the algorithm works is that the barometer should "drag" the inertial navigation estimate to it's height slowly over time.  This has been the case since 3.0 anyway.  So while it's true that the baro is not a perfect long-range determination of altitude, it should be accurate to record "zero" when arming, as the inertial position is constantly being reset to zero before arming.  This Alt Disparity problem only cropped up within the last few RC's.  I'm not sure if it's a new check that is just too tight, or if it's that something got missed on a recent change the algorithm isn't working.

Cheers,

Rob

[Randy Mackay]

 

     Yes, I agree with Rob.

 

     I’ve recently increased the Alt Disparity to 2m and that change will go out with –rc10 shortly.

 

John,

     If the baro alt and inertial nav alt are never within 1m to allow passing the check then there could be an actual problem.  It seems very strange to me that the inertial nav and baro alt do not come together even after 10min.  I’d very much like to see a dataflash log file.

     I think you’re able to compile the code yourself right?  Could you load master onto your copter but uncomment line 44 of the APM_Config.h file (see below) so it produces logs immediately after initialisation?

#define LOG_FROM_STARTUP                          // start logging as soon as the board starts up instead of waiting for the vehicle to be armed

 

-Randy

[Thorsten]

Randy, 

it would be great if #define LOG_FROM_STARTUP could be turned into a 0/1 parameter. It would help during setting up/developing a copter - especially for detecting and analyzing vibrations (https://groups.google.com/forum/#!topic/drones-discuss/Xz-JAW32pc4)

Best regards,

Thorsten

[David Pawlak]

@Rob, Randy, I've only seen it recently, that is with -rc9. The reset clears it up.

[Robert Lefebvre]

That's exactly what I see.  Had it again tonight, but I didn't load rc10 yet.  I'd like to try the pre-arm logging fix to find the actual cause but haven't had time yet.

[Xerr Avon]

Randy,

Your goning to love this, I did as you asked, built the master with logging from init enabled, now I cannot get the alt disparity to show up.  maybe bcause it was running for a while while updating???  I dont know I did try letting it sit for a while but still  no alt disparity.  I will let it sit over night and try tomorrow and see what happens.  One thing I noticed, on this copter I had logs disabled "0" in the log bitmask parm but in the other copter that shows the alt disparity the log bitmask is set to -6146, I am sure that isnt the problem but wanted to include everything I changed.

John

[Randy Mackay]

Thorsten,

 

     Yes indeed.  When we switch over to the shared AP_Arming library that will come for free.

 

-Randy

[Xerr Avon]

Randy,

It is arming first try.  with RC9 I had to reboot every time I flew so something must have changed. I will go back to rc9 and see what happens

John

[jolyboy]

Just to confirm, is it permitted to just ignore the "bad ahrs" warning on the HUD?

[Robert Lefebvre]

I have been. I assume it's OK...  the HUD looks correct.  I get that error almost every time I boot my 500.  I don't think I was getting it with the gasser through.

On 26 September 2014 01:40, jolyboy <futur...@gmail.com> wrote:

Just to confirm, is it permitted to just ignore the "bad ahrs" warning on the HUD?

[David Pawlak]

I didn't seem to have any problems either. Flies well and logs look OK.

Once in the air, it disappears and (I'm fairly sure), it doesn't come back.

[Paul Riseborough]

It takes a few seconds for the AHRS to settle down after startup, or longer if it is on more of a lean.

[Randy Mackay]

     We should probably suppress the warning for a while so we don’t generate lots of support calls.  I’ve done this already with some of the other warnings that were appearing.

 

Paul,

     Would a set time-limit (like 20 seconds) before we start checking the ahrs health be a good method or is there some other indicator we could use?

 

-Randy

--

[Robert Lefebvre]

Yes, the only time I get it is if I boot up and immediately connect telemetry.  I just get it once, and it never comes back after that.  So I think we just need a timeout on it.

[Paul Riseborough]

Randy,

That would make sense. The time depends on the initial orientation of the vehicle. Twenty seconds should be plenty. With EKF I initialise10 seconds after GPS lock both to allow the GPS solution to settle, but also to allow time for DCM to settle. A a vehicle powered upside down should be the worse case.

Paul

[Xerr Avon]

Hi,

I have had this even after flying, once on the hexa I landed, disarmed and tried to rearm and I got the alt disparity.  However,  I know this probably doesn't make any sense but what seems to have worked for me is  a "rest to defaults" from the MP's Full parameter list page then loaded my  saved params back back in.  Both of my copters have not shown the alt disparity since I did reset to defaults.  I did a reset to defaults because I was lazy, I needed the default param for logs, so I did a reset and rewrote my saved params (except for the log param) I noticed since then on that copter I did not have the alt disparity. so when I was still seeing the alt disparity message on my other copter after loading rc10 I decided to try the reset on it and it seems to be working so far... 

I dont know if this is coincidence or if there is some new param or newly changed param that doesn't get updated correctly when changing firmware but it has been 3 days for one copter and 2 days for the other that I have not seen alt disparity since doing reset. ???.
 
John

[Robert Lefebvre]

I also get the alt disparity even after flying, then disarming and trying to rearm.  But what you say about the param resetting is interesting.  

[Xerr Avon]

Rob,

Please, try the reset, I am curious to see if that really did anything. I did do a file compare between my older parm save and a new one, I thought it was nothing there interesting but after you mentioned about connecting telemetry because some of the  SR2 and SR0 params did change.

John