paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] AR.Drone vertical velocity without SONAR


From: Eric Poppe
Subject: Re: [Paparazzi-devel] AR.Drone vertical velocity without SONAR
Date: Fri, 23 May 2014 11:55:06 +0000

Hi,

Thanks for the calibration suggestion, somehow I forgot to do that. Now I did calibrate it but it doesn't solve the current problem.

Before I was using version v5.1.0_testing-24-gf3d4b4e-dirty, now I fetched master and used v5.1.1_testing-4-g3fb9dd7-dirty. I attached a new log with VFF and VFF_EXTENDED (12_36_42). Again after moving the drone up and down several times I hold it still while rotating it around. As you can see at first no bias develops but after a while it does. Also, at the end of the log I place the drone on a flat table and the pitch and roll show a significant error (8 degrees and 27 degrees) that is slowly eliminated. I found similar behavior while using another AR.Drone.

I think the cause of the problem must be sought in the attitude estimation. The attitude estimate is sometimes wrong with more than 20 degrees when placed on a flat surface, also with other AR.Drones. It makes sense that this can cause the errors in the velocity estimate as the gravity vector will also be wrongly placed.

I thought a fast changing bias in the accelerometers might cause the attitude error but when I read the raw accelero meters I don't see a change in bias at all. I added another log (13_20_58) with sometimes raw_sensor and sometimes default telemetry. It's a bit hard to analyse due to the switches in telemetry but every time I place the drone on a flat surface ax, ay and az read 2052 and 2080 and 1565 almost exactly, while the attitude has errors up to 15 degrees.

Any other suggestions for the cause of the rather large attitude errors and vertical velocity issues?

Thanks for the help so far!

Kind regards,

Eric


Date: Wed, 21 May 2014 22:50:06 +0200
From: address@hidden
To: address@hidden
Subject: Re: [Paparazzi-devel] AR.Drone vertical velocity without SONAR

Also you should try to make a proper IMU calibration instead of using the default values, maybe it will help a little.
http://wiki.paparazziuav.org/wiki/ImuCalibration#Calibrating_the_Accelerometers

Gautier

Le 21/05/2014 13:47, Eric Poppe a √©crit :
Hi Felix,

Thanks for your answer and sorry for my late reply, I didn't have the AR.Drone with me for a while.

I just tested it without the type="extended" and it gives similar results as before. I attached two log files, one with "extended" (13:09:54) and one without (13:11:33). In the logs I move the AR.Drone up and down several times after which I hold it steady in altitude while rotating around the pitch and roll axes.

Without "extended" a little less bias develops in the vertical velocity but it is still there.

I would like to fly indoors without the sonar as I am aiming on high tilt angle flights so both INS_USE_GPS and USE_SONAR are not an option. Also, I have a separate vertical velocity loop in my controller so the vertical velocity estimation has to be accurate for my controller to work properly.

Kind regards,

Eric




Date: Fri, 16 May 2014 16:14:45 +0200
From: address@hidden
To: address@hidden
Subject: Re: [Paparazzi-devel] AR.Drone vertical velocity without SONAR

Hi Eric,

this is of course not supposed to happen. It would probably help to have the VFF_EXTENDED message as well (add it to your telemetry file).

However the ins extended was especially meant to be used with baro and sonar (or gps alt update).
If you don't want to use the sonar (or INS_USE_GPS_ALT), can you try again with <subsystem name="ins"/> instead of <subsystem name="ins" type="extended"/>?

Maybe someone actually using this (@Gautier, @TUDelft) can shed a bit more light on this.

Cheers, Felix


On Wed, May 14, 2014 at 3:26 PM, Eric Poppe <address@hidden> wrote:
Hi all,

During some tests using an airframe file similar to ardrone_raw.xml without USE_SONAR running on the AR.Drone 2 I noticed 2 issues with the vertical velocity. I attached some log files recorded while holding the AR.Drone in my hand.

In the first log (14:31:40) I hold the AR.Drone in a constant position, vertically and horizontally, while rotating it around the pitch and roll axis. In the log file from 20 to 60 seconds you can see that the vertical velocity develops a large bias while rotating around the roll axis, and the bias goes the other way around while rotating back to zero.
Somehow the vertical velocity is influenced by the tilt angle even though all velocities are supposed to be zero.

In the second log (14:39:33) I hold the AR.Drone in a horizontal attitude and fixed position from 0 to 45 seconds. From 45 seconds to the end I keep it horizontal while moving it up and down. As you can see in the log files during the up and down movement the vertical velocity is 90 degrees out of phase with the vertical position (when the position goes through 0 the velocity is large) as expected. However, if you look at the noise effects in the first part of the log the position and velocity follow each other almost exactly except for a bias.
Somehow the influence of the noise on the vertical position is the same as on the vertical velocity.

Can anyone tell whether these two effects are supposed to happen and if so why?

Kind regards,

Eric

_______________________________________________
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


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

Attachment: 14_05_23__12_36_42.log
Description: Text document

Attachment: 14_05_23__12_36_42.data
Description: Binary data

Attachment: 14_05_23__13_20_58.log
Description: Text document

Attachment: 14_05_23__13_20_58.data
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]