Aerial Robotics Testbed » telekyb3 » rotorcraft-genom3

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.

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.

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?

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

Can you test with dd42846 and generate a log file?

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

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.

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

• 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.

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.

Could you try with 53bea7cb ?

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

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.

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.