Project

General

Profile

Actions

Bug #339

closed

Impossible to calibrate mikrokopter using rotorcraft 3.2

Added by Martin Jacquet about 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal

Description

We are not able to calibrate the IMU of the mk board using the latest release of rotorcraft.

During the calibration procedure, rotorcraft struggles to acquire the successive poses. It usually takes much longer to acquire them, and at some point the acquisition times out and the calibration aborts.

I had the same problem with 2 different boards, and Dario and Antonio Enrique also faced it.


Files

calib.log.tar.gz (2.5 MB) calib.log.tar.gz Martin Jacquet, 2021-11-26 17:01
Actions #1

Updated by Anthony Mallet about 3 years ago

Did you try to increase the motion detection threshold with
set_calibration_params?

By default it's "10", so you can try with 25 or 50. It's a tradeoff
between precision and tolerance.
If it works better with different setting, I can set the default to
what works best.

If it still does not work with 50, then there is likely another issue.

Actions #2

Updated by Martin Jacquet about 3 years ago

I did try when I first had the issue and noticed this service, though I forgot to raise the issue then. I didn't manage to calibration back then.

I retried just now with higher values (40 and 50). With both I still get some poses that are hard to acquire (way less with 50 than 40).
However I tried several times and each time the calibration failed at some point. For some reason, it happened several times when acquiring the 6th pose, but I din't see a pattern for when it fails (I'm using 2 seconds for tstill and 10 poses acquisition).

Antonio Enrique told me that he never had issues when calibration the paparazzis. Could it be that the mk IMU is much worse? The calibration were "easy" to acquire with the previous releases of rotorcraft. What was the equalivalent value of the calibration_param before you introduced it?

I'm also not able to record logs, passing a path (even absolute) but no file is created.

Actions #3

Updated by Anthony Mallet about 3 years ago

Yes, with mikrokopter flight controller, it's much worse.
In release 3.1, the hardcoded "motion detector" was tuned at "100".
Can you try with that setting?

Actions #4

Updated by Martin Jacquet about 3 years ago

I'm getting similar results with 100. I managed to acquire a couple of poses, then it aborted.

Actions #5

Updated by Anthony Mallet about 3 years ago

Can you test with dd42846 and generate a log file?

Actions #6

Updated by Martin Jacquet about 3 years ago

I checked out that commit and managed to calibrate using 100 as calibration parameter, without any issue.
I retried using 40, and it got stuck when acquiring pose 6. But I retried a couple of times with 40, and I managed to calibrate each time.
Attached is a log file for a succesful calibration (I don't have any log for the failed one unfortunately and I didn't manage to reproduce it).

Actions #7

Updated by Martin Jacquet about 3 years ago

I will do a couple more tries during the weekend and hopefully get you a log file where it fails.

Actions #8

Updated by Anthony Mallet about 3 years ago

Thanks for the log.

In this log, it appears that the motion detection (moq_*) is always
below 20, so I don't see why it would not work with 40 or 50.

Let's see with failing logs, then.

Actions #9

Updated by Martin Jacquet about 3 years ago

I made a couple more tries today (~8 or 10).

There is definitely 2 types of failures:
  • the component is not able to acquire the pose. It prompts acquiring next position, stay still a lot before the calibration aborts. This happens more with smaller values of the parameter.
  • the component does nothing (or at least prints nothing) until it aborts. There is no prompt asking to stay still. This happens randomly among the 10 poses, and regardless of the value of the parameter. It happen often enough to prevent almost every calibration to be successful.

I uploaded 2 logfiles corresponding to these 2 cases on https://cloud.laas.fr/index.php/s/9tnC4tyCrZ6XbwC

It seems overall to be pretty random. Using twice the same value of the parameter in a row (I used almost always 40), it might fall in the first failure case or not. I don't know what happened on Friday evening when I did the few successful tests, now it seems that I'm not able to calibrate properly.

Actions #10

Updated by Anthony Mallet about 3 years ago

I notice that in the last logs, the Y axis of the accelerometer is
incredibly steady. Compared with the first (working) log file, there
is almost no noise.

Usually, the accelerometer oscillate between two values. If you did
not add filtering, then it might be that you are by chance on a exact
discretization value?

Anyway, this might affect the computation of the std deviation which
probably tends to zero. Since there is later a division by that, it
might diverge. I'll try a fix.

Actions #11

Updated by Anthony Mallet about 3 years ago

Could you try with 53bea7cb ?

I would be interested in seing the log (even if it works by chance) :)

Actions #12

Updated by Martin Jacquet about 3 years ago

Sorry, I didn't have time to try in the past few days. I will make more tests using that commit later today or sometime during the week-end.

Actions #13

Updated by Joudy Nader almost 3 years ago

I had the same problem with `rotorcraft 3.2`.
I fixed the threshold value to 30 and the calibration is working pretty fine on 3 different mikrokopter flight controllers.

Actions #14

Updated by Anthony Mallet over 2 years ago

  • Status changed from New to Closed

Seems to be fixed

Actions

Also available in: Atom PDF