Sensor calibration, PID optimization

Here is the place for all your dsPic or autopilot questions.

Moderator: lukasz

Sensor calibration, PID optimization

Postby penguin » Fri Sep 28, 2012 3:51 pm

Hi Tom,

I've read the hole wiki and hope I didn't fail to see the answers to my following questions.

1. How many Servo Channels are parsed by Gluonpilot using PPM?
2. Is it possible to change/optimize P-, (I-), (D-)Values using RC-Transmitter during flight?
3. How often must the ACC-Sensors be calibrated? In field it's difficult to level the plane exactly, isn't it?
4. Can the calibration procedure be initiated by RC-Transmitter? ACC and Gyro by different function/switch?

I would like to calibrate ACC at home on workbench and only calibrate Gyro at field and at any inclination angle. OK, temp-drift would be a problem but could be trimmed in flight, couldn't it?

Many thanks in advance,
Rainer
penguin
 
Posts: 31
Joined: Sun Sep 02, 2012 9:15 pm

Re: Sensor calibration, PID optimization

Postby Tom » Fri Sep 28, 2012 4:33 pm

Hello,

1. There are 6 PWM-input possible. If you need more, use PPM
2. Nope, only using XBee's
3. Not often, I do it twice a year :-)
4. No, but I intend to make it optional to automatically calibrate the gyro's at startup (when the module is still). A similar approach as you suggested. Feel free to look at the code, the "still" detection routine is at http://code.google.com/p/gluonpilot/sou ... sors.c#148
But not yet being used...

On the other hand: I calibrate the gyro's only every month or so...
User avatar
Tom
Site Admin
 
Posts: 1016
Joined: Fri Nov 13, 2009 6:27 pm
Location: Belgium

Re: Sensor calibration, PID optimization

Postby penguin » Sat Sep 29, 2012 1:24 pm

Hi Tom,

1. In ppm_in.c are 8 variables for RC-channels. I will try using one for P-gain roll and one for pitch in order to change P-value inflight using rc-channel in optimization phase. Must I take care of something special (RTOS, etc)?
3. OK, great! I flew mikrokopter several years now and had to cal. more often.
4. I will try same procedure like '1.' if necessary

5. One little disadvantage: GP sets too early GPS homeposition. In my experiance it is not enough to wait for x-sats but it's necessary to utilize the HDOP or PDOP-value because the number of sats says nothing about the system accuracy. In my own projects (and it's the same with GP) I had differences between system-HP and real HP of sometimes hundreds meters. And so it'll be necessary to set HP manually if safety function like coming home is needed.
6. Do you enable WAAS i.e. EGNOS in GPS settings?

Last days I did some tests on my desk. Between MTK-GPS and the sky are still one floor and the roof but nevertheless MTK receives 7-9 sats after few minutes - amazing and MUCH better than the mikrokopter ones (I think, you know them ;) )

With Gluonpilot you did a really good job, congratulation! I hope you'll stay tuned... (where is the shoulder knocking smiley :) )

Many thanks,
Rainer
penguin
 
Posts: 31
Joined: Sun Sep 02, 2012 9:15 pm

Re: Sensor calibration, PID optimization

Postby Tom » Mon Oct 01, 2012 7:44 am

Hello Rainer,

1. This should be simple to adapt for your personal use.
5. Hmm this would be yet another GPS sentence to parse. I never did it because for fixed wing UAVs I never felt the need. Home = circle home with a radius of about 100 meters, so 10 meters off isn't such a big issue. I never experienced it was more than 10 or 20 meters off. Do you have bad experiences with this?
6. Nop, at startup I change the GPS baudrate to 115200 and select only the RMC and GGA NMEA-sentences. I never had time to experiment with that, did you?
User avatar
Tom
Site Admin
 
Posts: 1016
Joined: Fri Nov 13, 2009 6:27 pm
Location: Belgium

Re: Sensor calibration, PID optimization

Postby penguin » Mon Oct 01, 2012 3:33 pm

Hi Tom,

5. Yesterday I had with my second GP ~400m difference to true HP displayed in GrounStation Software (same HP at last power on some weeks ago). The longer a GPS is switched on, the more precise are the position calculations (estimates of almanac). I simulated five cycles 20 minutes each with interruptions of half an hour each and the deviation finally reduced to 'normal', i.e. ~20 m but dependend on the number of sats at power on. This is the reason, why I also evaluated HDOP in my OSD-Software. My goal is only, fly and (if required) calibrate without Notebook at the field. I don't want to seem petty!
6. I made good experiences with MK-Copters at position-hold. The control behavior is smoother and position more exact. With my OSD the position repeatability was better (nice to have but not necessary for homevector only) but the GPS-altitude was significantly better.

useful MTK-Tool (settings, test, etc.):
http://www.pololu.com/file/0J350/MiniGPS_1.4.zip


Image

Image

I will add following in gps.c line 126 and play with it ;-)
Code: Select all
        // DGPS data source mode
        // ‘0’: No DGPS source
        // ‘1’: RTCM
        // ‘2’: WAAS
        microcontroller_delay_ms(10);
        uart2_puts("$PMTK301,2*2E\r\n");

        // Enable to search a SBAS satellite or not
        // ‘0’ = Disable
        // ‘1’ = Enable
        microcontroller_delay_ms(10);
        uart2_puts("$PMTK313,1*2E\r\n");
penguin
 
Posts: 31
Joined: Sun Sep 02, 2012 9:15 pm

Re: Sensor calibration, PID optimization

Postby Tom » Tue Oct 02, 2012 6:05 pm

It would be great if you could share the WAAS & SBAS results! If it works well I can include it in the main code. Why would you not enable it by default? Does it have a downside?

My results with GPS vs barometric altitude where better than yours (with 8 or more satellites)... I guess it depends on a lot of factors.
http://diydrones.ning.com/profiles/blog ... ccuracy-vs

HDOP is in GGA so it should be easy to parse. How would you suggest to wait for it? For example: Flying with less than 6 satellites is not done, so how would you translate that to HDOP? Feedback to the user? Is this predictable or are there bad HDOP-days?
User avatar
Tom
Site Admin
 
Posts: 1016
Joined: Fri Nov 13, 2009 6:27 pm
Location: Belgium

Re: Sensor calibration, PID optimization

Postby penguin » Thu Oct 04, 2012 8:27 pm

Since 01.10.2009 EGNOS works regular. Depending on flying location and height it should work now reliable.
There shouldn't be no more cons as in the testphase. We'll see, if my experiences are worth to be shared...

My suggestion is setting HP is done with sats >5 and HDOP <3. It would be appropriate to make these values changeable in the settings depending on individual requirements and circumstances (and waiting time after power-on). A HDOP-Value in GCS would be great.
To my knowledge there are no bad days or not bader than anyway capture a certain number of sats data.
We therefore will need no full moon and no bats-blood (I hope) ;-)
penguin
 
Posts: 31
Joined: Sun Sep 02, 2012 9:15 pm

Re: Sensor calibration, PID optimization

Postby penguin » Tue Oct 09, 2012 9:31 pm

Egnos test on my balcony. Homeposition was set by GP with activated GPS-SBAS. Deviation is less than one meter!
The yellow line began wandering after entering my living room (7 m above HP).

Image
penguin
 
Posts: 31
Joined: Sun Sep 02, 2012 9:15 pm

Re: Sensor calibration, PID optimization

Postby Tom » Wed Oct 10, 2012 10:01 pm

I will do some tests myself... I could add an option "enable EGNOS" in gluon config.

Some reasons not to enable it by default (true?):
http://www.gps-forums.net/disadvantages ... 14457.html
User avatar
Tom
Site Admin
 
Posts: 1016
Joined: Fri Nov 13, 2009 6:27 pm
Location: Belgium

Re: Sensor calibration, PID optimization

Postby penguin » Thu Oct 11, 2012 1:56 pm

I could add an option "enable EGNOS" in gluon config

That would be great!
Perhaps, you could also display the status in GCS:
EGNOS/NO EGNOS like in the received NMEA-sentence (GGA: NO=0, GPS=1, DGPS=2)

The EGNOS-status can be viewed here (but only one day later):
http://egnos-user-support.essp-sas.eu/egnos_ops/public_upcm

IN GSA (you remember HDOP) are also the sats PRN-numbers.
Numbers >32 are reserved for EGNOS (current: PRN 120, PRN 124, PRN 126)
That provides a additional possibility to display, if EGNOS sat(s) is/are in sight.

Some reasons not to enable it by default (true?):

I think and my experience is 'no'.
- We use no navigation device in a car on the ground but move in height without obstacles (EGNOS-sats are in direction south with 16°-35° from horizon).
- the described problems were years ago. menwhile egnos sends regular and gps-modules firmware was improved.
- the disadvantages at first with activated egnos and not receiving egnos-data from sat and therefore greater positional errors is fixed.

In my opinion only limitation is that egnos will not be received everywhere (obstacles such as mountains between EGNOS-sat and GPS-rx). Then accuracy is 'only normal', i.e. as with disabled egnos.
penguin
 
Posts: 31
Joined: Sun Sep 02, 2012 9:15 pm

Next

Return to Firmware

Who is online

Users browsing this forum: No registered users and 5 guests

cron