paparazzi-devel
[Top][All Lists]
Advanced

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

Re: [Paparazzi-devel] Another day at the flying field...


From: Stephen Dwyer
Subject: Re: [Paparazzi-devel] Another day at the flying field...
Date: Wed, 27 Feb 2013 18:32:29 -0700

Hi Gerard,

Did you make sure you either manually enabled throttle or entered a flightplan block that enabled the throttle before switching to auto1? If you don't enable the throttle (throttle in strip is red when disabled), you will see that behaviour (happened to me the first time I went into auto1 as well).

I assume by "good settings for how the control surfaces react to offsets in roll/pitch" you mean a well tuned inner stabilization loop? Note that default settings were probably from a Microjet, which is very agile and probably doesn't need such aggressive gains. We had to bump ours to double default with a big Telemaster. I find a good method for tuning the gains is similar to what is described on the tuning page. Plot in realtime and watch the overshoot and time constant, and adjust using typical PID tuning methods similar to those described in the Wikipedia page. An example of data before and after tuning the roll loop can be seen at the end of this video. A second person to operate the GCS while the first flies is very useful for tuning.

Thanks,
-Stephen Dwyer


On Wed, Feb 27, 2013 at 2:32 PM, Felix Ruess <address@hidden> wrote:
Hi Gerard,

which ./paparazzi_version were you using when you had problems with kill?

3. The GPS course for the skytraq is still off. I'm again investigating this. The course at 90 deg. east seems to be 0 and when actually moving
    counterclockwise has the course increasing. Unfortunately I can't see what values come out of the ned_of_ecef_vect_i   calculation.
    I may have to debug this on my spare lisa and walk around the block here to see this in more detail.

I think I got to the bottom of it. It's confusion about which parameter in the NED structure is north. I assumed this would've been Y
and X would be east, but apparently x/y/z is just the order of parameters n/e/d.  Confirmed?

Yes.

The current code used for testing was  (x assumed east, y assumed north ):

      gps.course = (atan2f( (float)gps.ned_vel.x, (float)gps.ned_vel.y )) * 1e7;

So just switching them around should do the trick. I tested this in python and for a couple of test vectors it produced correct results.

      gps.course = (atan2f( (float)gps.ned_vel.y, (float)gps.ned_vel.x )) * 1e7;

As I already wrote in the answer to your previous mail about this, I think it should be:
gps.course = atan2f((float)gps.ned_vel.x, -(float)gps.ned_vel.y) * 1e7; 

1. Is the course 0-360 deg (in rad *1e7), or is this [-180,180]?

It should be [-pi,pi], but if it doesn't handle [0,2*pi] then there is some code that doesn't wrap the value to be sure it takes what it expects.
In any case that needs to be added to the doxygen comment...

2. The plane in the GCS also points in a very strange direction and not even close to the erroneous direction.
    How is the rotation of the plane in the GCS determined?

From the heading angle (psi) of the aircraft, or what do you mean?
Same that is displayed in the attitude message.

Hope that helps.
Cheers, Felix

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



reply via email to

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