Re: [Paparazzi-devel] Critical behaviour of baro_ms5611_i2c

[Rolf Nöllenburg]

Hi Felix,

 

I still have the problem of broken d2s from time to time, but I'm flying with the dirty workaround I described a few mails ago. It works ok for the moment as it takes a look at the current value of d2 and replaces it with the previous one, if it seems to be broken. In case of a replacement, a counter increases by one so I'm able to track the events. It occures randomly but I have often flights with at least one event and in one flight of about 25 minutes I saw 12 events in the log.

 

As you see, I don't have a solution which is pushable and I didn't have taken the time to search the cause of the problem so far. I also never tried it on master branch.

 

As no one else seems to have this problem, it could be a hard- and software specific problem of my setup. Anyway, I'll give an update when I have found the source of the problem.

 

Cheers,

Rolf

 

Gesendet: Mittwoch, 17. April 2013 um 11:02 Uhr
Von: "Felix Ruess" <address@hidden>
An: "Paparazzi devel list" <address@hidden>
Betreff: Re: [Paparazzi-devel] Critical behaviour of baro_ms5611_i2c

Hi Rolf,

what is the status on this?

If this needs to be fixed in v4.2 please let us know, or even better make a pull request with the fix on github ;-)

Did you also run long tests for the code in master?
 

It's really important that problems like this get properly fixed in the main Paparazzi repository.
But for that to become a reality we need the help from all of you to get the fixes back (not enough if you have them locally fixed for you).
There are so many drivers and combinations supported that not everything can be tested by the few core committers we have.
 

Cheers, Felix

 

On Mon, Feb 4, 2013 at 1:21 PM, "Rolf Nöllenburg" <address@hidden> wrote:

My observations:
I made a static 200 minute test yesterday and no glitches of d2 occurred.
Last friday I had seven glitches in 170 minutes on the bench.
Some randomly chosen flightlogs of the last four months revealed 3 glitches in 355 minutes.

The flights were carried out with an old height calculation where estimator_z recovered (peaks: ground_alt+2500m -> ground_alt-380m -> normal height within 2 seconds) and only led to a short but intense "bow". I don't want to know what the plane would have done with estimator_z=nan.

My conclusion so far: these glitches do occur but at rare intervals - at least with my setup. My previously mentioned interval of once in 20 minutes was way to pessimistic, sorry for that.

@michal: I'll have a closer look to your code, thank you for that hint.



-------- Original-Nachricht --------
> Datum: Sat, 2 Feb 2013 18:53:59 -0200
> Von: Eduardo lavratti <address@hidden>
> An: Paparazzi developer forum <address@hidden>
> Betreff: Re: [Paparazzi-devel] Critical behaviour of baro_ms5611_i2c

>
> HUmmmm i am using ppz v4.2 +yapa + ms5611.
> I made 5x 45~55min flight this week without any problem with baro.

> Date: Sat, 2 Feb 2013 09:28:17 -0700
> From: address@hidden
> To: address@hidden
> Subject: Re: [Paparazzi-devel] Critical behaviour of baro_ms5611_i2c
>
> Hi Rolf,
>
> i think this glitch can occur when you are asking for D2 value before the
> conversion is done. I ran to it when I was writing ms5611 drivers for
> master branch. It helped to slightly rearrange the periodic and event functions
> (see
> https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/boards/lisa_m/baro_board_i2c.c). It was written for Lisa M 2.0, but might be
> useful for yapa too.
>
>
> The longest I ran barometer continuously was for like 35 minutes and no
> glitch occurred.
>
> Btw if the estimator cannot handle NaN values, probably the estimator code
> should be fixed, rather than "outlier removal" in baro code - what if the
> sensor stops working during the flight etc...
>
>
> Hope it helps.
>
> M
>
> On Sat, Feb 2, 2013 at 6:08 AM, "Rolf Nöllenburg" <address@hidden>
> wrote:
>
> Hi
>
>
>
> I just discovered a severe problem (luckily on the desk) with the module
> baro_ms5611_i2c: the communication via i2c can get faulty which leeds to
> estimator_z = nan and it DOES NOT RECOVER!!!
>
>
>
> This happens not very often, approx. once in 20 min.
>
>
>
> I think that the problem is starts with a zero in D2. This leads to
> messages in the log-file like the following:
>
>
>
> 2174.155 11 ESTIMATOR 1.195065 0.513844
>
> 2174.174 11 BARO_MS5611 7803588 8440836 1001.38 38.9
>
> 2174.269 11 BARO_MS5611 7803430 0 -2230.73 -242.71
>
> 2174.369 11 BARO_MS5611 7803606 8440764 1001.38 38.89
>
> 2174.397 11 ESTIMATOR nan nan
>
> 2174.465 11 BARO_MS5611 7803424 8440874 1001.34 38.9
>
> 2174.566 11 BARO_MS5611 7803488 8440640 1001.34 38.89
>
> 2174.684 11 ESTIMATOR nan nan
>
>
>
> A pressure of -2230.73 is obviously too much (or little) for the hight
> calculation...
>
>
>
> My system:
>
> - Paparazzi version v4.2.0_stable-5-gc3a1496-dirty
>
> - YAPA 2
>
> - Drotek IMU (mpu6050, hms5883, ms5611) on i2c1
>
> - PERIODIC_FREQUENCY=AHRS_PROPAGATE_FREQUENCY=AHRS_CORRECT_FREQUENCY=60Hz
>
> - baro_ms5611_periodic=baro_ms5611_d1=baro_ms5611_d2=10Hz
>
>
>
> I am working on a fix via something like this starting in line 211 of
> baro_ms5611_i2c.c:
>
>
>
>       /* avoid glitches in d2
>
>       if (ms5611_d2 < 1000000) {
>
>         ms5611_d2 = ms5611_d2_prev;
>
>       } else {
>
>         ms5611_d2_prev = ms5611_d2;
>
>       }
>
>
>
> I tried this with a fixed replacement-value of 7000000 instead of
> ms5611_d2_prev and it looks promising (estimator_z jumps to about 200m and recovers
> within 1 second). I just need some testing ...
>
>
>
> _______________________________________________
>
> Paparazzi-devel mailing list
>
> address@hidden
>
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
>
>
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel