Re: [Paparazzi-devel] Lisa/M2 field test

[Felix Ruess]

Hi Gerard,

thanks a lot for the gps skytraq fixes! Should be in master now (with some additional cleanup), please test :-)

Also closed issue #167... we can re-open if necessary.

Cheers, Felix

On Mon, Feb 18, 2013 at 7:41 PM, Gerard Toonstra <address@hidden> wrote:

Some preliminary info, I'm now checking up on the lock and the IMU behavior.

On Mon, Feb 18, 2013 at 3:08 PM, Felix Ruess <address@hidden> wrote:

Hi Gerard,

I finally have a proper location where I can do some field testing. I'm using a recent (2 weeks) master branch with
venus skytraq GPS and eagletree airspeed sensor.

Could you please provide the exact paparazzi_version?

I've just updated the whole lot, so can't relay this. On a 'git pull' nothing came up, so it would have been up to 4-5 days ago?

 

1. At one point in time, the control surfaces locked and there was no response whatsoever. Unfortunately I did not
   look at the PFD at this point. Switching to manual worked and control surfaces responded correctly and timely in that mode.
   I repowered up and then stabilized mode was reasonable again.

What mode were you in, etc..? Do you have the logs to check this?

Yes, should have the logs and I'm going to re-verify that point.
 

2. Does the IMU initialize at the start?  I had the aircraft leaning on one wing and the PFD showed a 10 degree roll
   to that side. I repowered up with the aircraft level and this disappeared. Basically, must the aircraft be completely level
   at startup?

At startup the ahrs_aligner runs and takes the low-passed gyro values as initial bias. By default no accelerometer bias is done for exactly that reason.

So it only shouldn't move during initialization (although there is some basic check so that it will only run the aligner if the movement/noise is low enough).

Ok, good to know. I know it only takes 2 seconds, so will pay close attention.
 

3. I eventually aborted the takeoff when I noticed that yawing the plane around in a plane parallel to the ground, the
   discrepancy in roll moved to the pitch, then back to roll (other side) and back to pitch. This sort of behavior *can* be produced
   if the yawing plane is not parallel to the ground, but I paid very close attention to this process. I would expect the discrepancy
   in roll to move along during the yaw motion, but this did not happen.

What imu exactly are you using, which ahrs algorithm? Are you using the mag, is it calibrated?

Can you please post at least the firmware section of your config?

(Or do you have it on github? Or maybe put it on pastebin...)

relevant AHRS bits in airframe file:

http://pastebin.com/h6K1TQvT

I'm verifying the local magnetic field, but I'm guessing that's only useful if all axes are updated by the magn. compass.

What's the recommended AHRS to use for a fixed wing with energy control?  int_cmpl_quat?

4. I'm also getting the famous "Invalid argument "latlong_of_utm""  error when the GPS is 3D locked (actually, after 30 seconds or so). 
    The "utm_zone" should be 25, but it switches to 96 (which does not exist), even though I'm roughly at 8S, 35W.  
    I think there's a serious error with units in that subsystem. Velocities and ground speeds seem to work ok, as well as vertical speeds.
   Binary command set is here: http://www.sparkfun.com/datasheets/GPS/Modules/AN0003_v1.4.14_FlashOnly.pdf 
    (NAVIGATION DATA MESSAGE).
   I have "GPS_USE_LATLONG" defined and it does indeed come up in the make settings of the compiled binary.

Are you aware of the limitations of the skytraq binary protocol?

See https://github.com/paparazzi/paparazzi/issues/167

You can compute the missing information yourself, but this is not done so far.

Afaik the skytraq was only used for rotorcrafts quite a while ago, you might be the first one using it for fixedwings...

(I even wanted to buy one, but the documentation on those is so bad and the navilock GPS with skytraq chip doesn't have a binary mode at all...) 

I've just pushed a pull request to fix the issue with skytraq lat/lon (when either is negative, so may not have been seen on
boards at N/E). The altitude was factor 100 off, it divided by 10 when it should have been a multiplication.

The #167 issue had already been pushed some time ago, so is fixed in the current master.

I'm using the one from sparkfun with external antenna. They seem to work pretty well for me, but it's probably easier to get the UBlox chips next time.

 

6. The alt also seems a bit off. I did a manual flight of around 12-20 meters altitude, but the altitude never reported anything higher
    than a meter. I'm guessing it's off by a 100.  What is the scale for UBX altitude?

The scale is millimeters, see the generic GPS interface (see sw/airborne/subsystems/gps.h or the generated doc link above).

Also pushed in the pull request...

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