GPS sensor

Development & General Chat for the superb openxvario project.

Moderator: rainer

Post Reply
kcaldwel
Posts: 40
Joined: Wed Mar 12, 2014 7:49 pm
Country: Canada

Re: GPS sensor

Post by kcaldwel » Fri Dec 04, 2015 9:56 pm

I finally got it, on about the 14th attempt. Yep, shows 124 degrees 58W now, which is much closer to home!

Perhaps this change needs to be fed back to the GPS stream, which has a few less things in it? I expect a few more people interested in triangle racing will be primarily interested in the higher frequency GPS. The possibility of vario compensation via IMU rather than an airspeed probe is interesting, but likely to be very difficult.

Thanks!


Carbo
Posts: 437
Joined: Fri Aug 02, 2013 6:55 pm
Country: Germany
Location: Freinsheim RP

Re: GPS sensor

Post by Carbo » Sat Dec 05, 2015 9:15 am

Carbo wrote:Maybe there is an easy solution:
If you want to optimize the plane performance, you have to use an airspeed sensor. If you want to calculate tactical flight tasks, you will use GPS. Both speeds will normally not be available. If no airspeed is configured, oXs could be switched to use GPS-Speed.

What do you think, Michel?
Meanwhile i realized, that this proposal can not work. oXs checks speed, to detect constant flight phases. Then oXs calculates glider performance. Every perturbation of speed (thermal, elevator) will cancel the measurement and start from beginning.

With GPS speed you can only evaluate flights in a constant direction, because every turn will change the windcompenent on GPS speed and cancel the measurement. Still you do not know, how much the wind influences the measurement. Even in very calm conditions there was a big influence from windspeed.

So oXs is perfect for optimizing your glider performance, but a LUA-script will be the better alternative to calculate tactical flight tasks.

Carbo
Posts: 437
Joined: Fri Aug 02, 2013 6:55 pm
Country: Germany
Location: Freinsheim RP

Re: GPS sensor

Post by Carbo » Sat Dec 05, 2015 3:34 pm

mstrens wrote:When mpu6050 and first VARIO are installed, oXs calculates another vertical speed.
This new measurement is named VERTICAL_SPEED_I.
The old one still exist (and is named VERTICAL_SPEED).
In the config.h file you can select which of the 2 measurements has to be sent as VSpeed. You can also sent the other one in a field like T1 or T2 in order to get it on screen and in a log. So you can compare.
There is a faster reaction time of nearly 0,4s when you compare both. oXs was already a fast vario, now it is presumably the fastest! Great work again from mstrens!
IMU1.png

nigelsheffield
Posts: 308
Joined: Fri Nov 08, 2013 9:56 pm
Country: -

Re: GPS sensor

Post by nigelsheffield » Sat Dec 05, 2015 3:41 pm

Yep, great work, can't be any faster I don't think.
I see you are using outputing world linear acceleration z for test on gitbhub .... Is this for more tuning?

User avatar
jhsa
Posts: 19247
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: GPS sensor

Post by jhsa » Sat Dec 05, 2015 3:43 pm

Of course it could be faster :o
It could report the thermals 20 meters ahead ;) :mrgreen:

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW


nigelsheffield
Posts: 308
Joined: Fri Nov 08, 2013 9:56 pm
Country: -

Re: GPS sensor

Post by nigelsheffield » Sat Dec 05, 2015 3:44 pm

Would be heavy though with that crystal ball.

mstrens
Posts: 1369
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: GPS sensor

Post by mstrens » Sat Dec 05, 2015 4:00 pm

nigelsheffield wrote:Yep, great work, can't be any faster I don't think.
I see you are using outputing world linear acceleration z for test on gitbhub .... Is this for more tuning?
world linear acceleration z is the vertical acceleration (in reference to Earth) without gravity.
This is the value used to fill the Kalman filter (toegether with altitude);
During test, it could be usefull to look at this value in order to evaluate the delay/smoothing introduced by the Kalman filter.
Output of the Kalman filter is the VERTICAL_SPEED_I (it means vertical speed using Imu).

In the current version on Github, world linear acceleration z is filled in TEST3 and so it can be transmitted to TX if you want.

Don't be confuse, world linear acceleration z is not the same as linear acceleration z. This last one is in reference to the plane it self and not to Earth.

kcaldwel
Posts: 40
Joined: Wed Mar 12, 2014 7:49 pm
Country: Canada

Re: GPS sensor

Post by kcaldwel » Sat Dec 05, 2015 5:05 pm

I agree with Carbo. We are almost always flying in a wind gradient with height with an RC glider. Even in straight flight descending downwind into the gradient should show increasing total energy with an airspeed probe compensated vario, and descending upwind into the gradient should should show an energy loss. I can't see how you can capture that with GPS and IMU readings, without measuring the airspeed somehow.

Even gusts should show up as energy gains or losses. They will have no immediate affect on the acceleration of plane (particularly with near neutral pitch stability), or the GPS speed, but should register as energy gain or loss on a total energy compensated vario.

I'm not sure why tactical glide over-ground calculations are better done in a LUA, but I'm fine with that too. I just thought it would take some of the load off the Taranis if it was done on the Arduino.

Why do you want the vario to react so fast? Most full-size varios are purposely damped to quiet them down and avoid reading every momentary unusable bump. I usually purposely slowed my varios down, so they only really reacted to lift I could use, or sink that was lasting long enough it was worth speeding up for. I don't find a vario in an RC glider particularly useful in any case. The firm ground reference to detect airplane movement from seems far better than any vario I've tried so far. I have lots of time listening to varios from in the airplane, where they are invaluable, but I rarely turn mine on in my RC glider. I need to try a decent TE compensated vario in an RC glider. I do find an occasional altitude call-out useful.

Thanks again for all the help getting my oXs and GPS working! I am very happy with it.

Kevin
Attachments
Typical wind gradients.png

Carbo
Posts: 437
Joined: Fri Aug 02, 2013 6:55 pm
Country: Germany
Location: Freinsheim RP

Re: GPS sensor

Post by Carbo » Sat Dec 05, 2015 5:45 pm

kcaldwel wrote:Why do you want the vario to react so fast?
Because we can!

No, but seriously: You can adjust the sensitivity of the vario with PPM, you can switch between IMU-vario and traditional vario. I agree to select useable thermals with lowered sensitivity, but when centering the thermal you want shortest reaction time. You can fly in cruise mode with low sensivity and switch with thermal flightmode to IMU-vario. It needs some testflights to confirm the advantage for the pilot (no doubt for me).

If you have a permanent airspeed-sensor on board (in the vertical fin for example), you would search for thermals in energy compensated mode. Then switch to IMU-mode to center and achieve a constant climb. With the energy compensated vario you do not hear the phygoids the plane trys to fly when circling.

Also there is a chance with the acceleration sensor to brag in the pub: how much g-stress can your plane survive (or not) :D

advancefly
Posts: 9
Joined: Sun Jan 24, 2016 9:45 am
Country: -

Re: GPS sensor

Post by advancefly » Tue Jan 26, 2016 9:21 pm

IS MPU6050 and GPS working in version 6 for Multiplex?

mstrens
Posts: 1369
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: GPS sensor

Post by mstrens » Tue Jan 26, 2016 10:21 pm

Please note that current version on github is V7.0.
It does not yet support MPU6050 and GPS.

I can try to add it but I can't test it.
I need some one to test it.

User avatar
kalle123
Posts: 788
Joined: Sat Mar 29, 2014 10:59 am
Country: -
Location: Moenchengladbach

Re: GPS sensor

Post by kalle123 » Wed Jan 27, 2016 7:19 am

Hi Michel.
Found a new fan of oXs in German forum. ;)
He reported some errors with v7.0 in combination with BMP180.
Advised to step back to v5.0 and he is now happy, but asked him to report here, so you can have a look into possible errors.
br KH

Starting at post #253

http://www.rclineforum.de/forum/board49 ... dex13.html

advancefly
Posts: 9
Joined: Sun Jan 24, 2016 9:45 am
Country: -

Re: GPS sensor

Post by advancefly » Wed Jan 27, 2016 9:01 am

Hey i am the new fan...hehe
I can do some multiplex tests have an MPU6050 and a Venus GPS available MS5611 will arrive this days i hope :)
My working solution is now based on V5.0 but V7.0 not working with Multiplex
Thanks and greetings

nigelsheffield
Posts: 308
Joined: Fri Nov 08, 2013 9:56 pm
Country: -

Re: GPS sensor

Post by nigelsheffield » Wed Jan 27, 2016 10:23 am

Hi again,
Tested v7 on hub protocol and GPS is only changing once every second.
On s.port it changes more like 5hz.
All data for GPS seems to change at the same time on hub where s.port it changes different data at different times.
Is this correct?
I wondered if GPS was not getting configured for 10hz when hub mode selected or maybe something else ?

mstrens
Posts: 1369
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: GPS sensor

Post by mstrens » Wed Jan 27, 2016 10:36 am

Fine,
I will try to solve the issue with BMP180 and to add support for imu and gps with Multiplex.
Still please note that Venus GPS will probably not work. Currently oXs has only code to support Neo 6, Neo7 GPS.
In order to reduce CPU load, oXs does not decode standard NMEA messages from GPS but sent some commands to the GPS during set up to let it transmit UBLOX messages. I think it is possible to find some nice small GPS for about 10 €
Here a link (there are many others)
http://fr.aliexpress.com/item/New-Ublox ... fb27ff3169

mstrens
Posts: 1369
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: GPS sensor

Post by mstrens » Wed Jan 27, 2016 11:07 am

nigelsheffield wrote:Hi again,
Tested v7 on hub protocol and GPS is only changing once every second.
On s.port it changes more like 5hz.
All data for GPS seems to change at the same time on hub where s.port it changes different data at different times.
Is this correct?
I wondered if GPS was not getting configured for 10hz when hub mode selected or maybe something else ?
You are right but this is related to the protocols.
in fact, GPS can produce data faster than Frsky can transmit them.

First SPORT protocol uses a higher baudrate (57600 instead of 9600 for Hub). This allows to transmit more data per sec.
In Sport, the tempo is given by the RX. The Rx send a polling code to the SPORT sensors (e.g. oXs) and the sensor replies sending only one data. Even if all GPS data are available simultanously, they are transmitted one by one. If only GPS data have to be sent, interval between 2 data would be about 22 msec. There are probably 5 GPS data (not checked), so all GPS data can be sent in about 110 msec. Still when oXs has to sent other data too, the interval between 2 polling from RX for GPS data increases and so, througput is less.
For each GPS data, oXs sent always the latest data received from GPS sensor. As GPS sensor delivers data faster that oXS can transmit, it can be data (received by Tx) change at different times.

For Hub protocol (D receiver), the sensor (oXs) does not get a polling from Rx and it has to send a frame at regular interval.
There must be some delay between 2 frames.
A frame contains several data (e.g. all GPS data).
So currently, oXs generates 2 types of frame: one for GPS and one for all others.
oXs sent currently GPS data every 1 sec and others data every 200msec.
Those parameters are defined in file oxs_out_frsky.h in lines
#define INTERVAL_FRAME1 200
#define INTERVAL_FRAME2 1000 // used by GPS
You can try to change (reduce) those parameters. Still I presume you will not be able to get the same rate as with the Sport protocol.
The minimum values that you can use depends probably of the number of data being present in the frames.

nigelsheffield
Posts: 308
Joined: Fri Nov 08, 2013 9:56 pm
Country: -

Re: GPS sensor

Post by nigelsheffield » Wed Jan 27, 2016 12:39 pm

Ok thanks for clearing that up!
So hub has a much slower speed, I did not know that( or more likely I forgot lol)
I will experiment with some different values and report back!
If I can get twice a second then it will be great.
Very windy and wet here now so won't be able to test though....
Thanks.

mstrens
Posts: 1369
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: GPS sensor

Post by mstrens » Wed Jan 27, 2016 12:53 pm

I expect that if you use this set up, you will get the data twice a second.
#define INTERVAL_FRAME1 200
#define INTERVAL_FRAME2 400 // used by GPS

This should send each 200 msec a frame (frame 1 and 2 alternating)

Perhaps you can even reduce a little like
#define INTERVAL_FRAME1 150
#define INTERVAL_FRAME2 300 // used by GPS

nigelsheffield
Posts: 308
Joined: Fri Nov 08, 2013 9:56 pm
Country: -

Re: GPS sensor

Post by nigelsheffield » Wed Jan 27, 2016 1:47 pm

#define INTERVAL_FRAME1 150
#define INTERVAL_FRAME2 300 // used by GPS

I tried this and it appears to work OK for me at least just using GPS and vario.
I am getting GPS data roughly every 400 to 500 ms. And vario data seems OK.
Thanks.

mstrens
Posts: 1369
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: GPS sensor

Post by mstrens » Wed Jan 27, 2016 2:17 pm

advancefly wrote:Hey i am the new fan...hehe
I can do some multiplex tests have an MPU6050 and a Venus GPS available MS5611 will arrive this days i hope :)
My working solution is now based on V5.0 but V7.0 not working with Multiplex
Thanks and greetings
I can't reproduce the issue in V7 because I have nor a BMP180 nor a Multiplex TX/RX.

First, I would like to know if the issue is related to the config, is specific to BMP180 or to Multiplex protocol.

Could you send me the config file that you used when you tried the V7.0?
Are you able to measure at least one voltage with oXs (beside using the BMP180). If so, with V7.0, did you get the voltage on the voltage on the Multiplex (meaning that the issue would be "only" with the code for the BMP180 sensor and not with the Multiplex protocol).
If you normally measure a voltage with oXs but do not get it with v7.0, it means that the issue is probably in the code that handle the Multiplex protocol and not in the BMP180.

advancefly
Posts: 9
Joined: Sun Jan 24, 2016 9:45 am
Country: -

Re: GPS sensor

Post by advancefly » Wed Jan 27, 2016 2:29 pm

Hey mstrens here is my whole zipfile from last test with only BMP180
openXsensor_mpx_aktuell-160126a.zip
(208.45 KiB) Downloaded 54 times

My values are always move :?


PS: Tested again and voltage from Receiver and Linkquality is transmitted seems like The BMP180 is the Problem. :cry:

mstrens
Posts: 1369
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: GPS sensor

Post by mstrens » Wed Jan 27, 2016 3:20 pm

Thanks for feedback.
I see in you config that you have:
//#define PIN_VOLTAGE 0 , 1 , 2 , 8 , 8 , 8

This means that oXs does not measure (and does not send) a voltage.
So I expect that what you see on Tx is a voltage measured by the Rx it self (and not by oXs).

The values sent by oXs should be Altitude (on line 3 of your display) , the relative altitude (on line 5) and the vertical speed (on line 6).

It is good to know that you get some values from oXs but that the values are always moving.
Therefore, I expect that the issue is in the protocol. Probably that oXs does not respect the required timing for sending the data.
I made some changes in this domain some time ago in order to solve an issue with Frsky Hub protocol.
I had expected that it would also be better to apply those changes for Multiplex protocol. I probably made a mistake.

So, I will first look around this.

To help me finding the issue, could you say if you are using an Arduino 5Volt running at 16 mhz or an Arduino 3.3Volt running at 8 Mhz?

advancefly
Posts: 9
Joined: Sun Jan 24, 2016 9:45 am
Country: -

Re: GPS sensor

Post by advancefly » Wed Jan 27, 2016 3:25 pm

Im use the Pro Mini 328 3.3 Volt 8 Mhz

advancefly
Posts: 9
Joined: Sun Jan 24, 2016 9:45 am
Country: -

Re: GPS sensor

Post by advancefly » Fri Jan 29, 2016 1:51 pm

Today my MS5611 Sensors arrived :P
Neo 6 Gps still on delivery :(
But i can Do some more Tests
Mstrens did you go further with THE issue?
Cheers Tom

mstrens
Posts: 1369
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: GPS sensor

Post by mstrens » Fri Jan 29, 2016 2:36 pm

Yes, I worked on it.
As said, I expected an issue in the timing when oXs generates the signal to the Rx.
As I have no Multiplex rx, I add some code in oXs to force oXs to generate his signal even if there is no incoming polling.
I tested it, and I saw that the signal was 100% ok.
Still this test is not completely meaningfull for your device because you are running at 8 mhz and my arduino is running at 16 mhz.

I presume that you do not have a logic analyser to capture and visualize the signal from oXs.
If you had such a device, you could run the same test as me and it would be possible to confirm if the issue is related to the timing or not.

As I expect, this is not possible for you, I am currently adding some code in order to let oXs discard the values received from the baro sensor and force oXs to send always one specific value as Vertical speed.
Using such a version would let us know if the issue is related to BMP180 or not.
I will send you this version to day with a private mail.

advancefly
Posts: 9
Joined: Sun Jan 24, 2016 9:45 am
Country: -

Re: GPS sensor

Post by advancefly » Sat Jan 30, 2016 7:33 am

Okay will wait for PN

mstrens
Posts: 1369
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: GPS sensor

Post by mstrens » Sat Jan 30, 2016 10:44 am

advancefly wrote:IS MPU6050 and GPS working in version 6 for Multiplex?
I put on github (in master branch) a new version where most GPS data and vertical speed based on imu + baro sensor should be supported.

In this version,glider ratio and Acceleration are not (yet) implemented in Multiplex protocol.

I did not test it.

Let me know if you you got issues.

advancefly
Posts: 9
Joined: Sun Jan 24, 2016 9:45 am
Country: -

Re: GPS sensor

Post by advancefly » Sun Jan 31, 2016 11:25 am

Hey mstrens today i passed some Multiplex tests with the BMP180.
Tested last master version from you and comment out vertical 123 in multiplex Protocol ( it was also activated on GitHub) and get normal values :)
But the calculation from the values after start to get stable values last 5 sec :( Is it possible to do this faster? Where so i can test it out?

And also today i finished my first MS5611 with Pro Mini 5 V and 16MHz (only vario) :D

The calculation is faster and my altitude here measured is only 12 m from my real altitude ....Great !!!!! :)
20160131_121744.jpg

Compared with BMP180 values are drifting,altitude calculation 40-50 m from my home altitude (cheap but s***!!!)


Fly test will be done if weather changed to stable conditions

mstrens
Posts: 1369
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: GPS sensor

Post by mstrens » Sun Jan 31, 2016 12:50 pm

Fine that it works with the new version.
Still here some remarks:
On Github, I see this line
//#define DEBUG_FORCE_VSPEED_TO 123
As it begin with "//" it is just considered as a comment by the compiler.
So, even the version on github should discard the "dummy" value and should use the calculations based on BMP180.
I do not know what you had to comment out (?)

About the 5 sec before getting stable values.
The BMP180 sensor (and also the MS5611) is quite sensitive to their internal temperature.
In theory there have calibration parameters that allow to compensate the impact of temperature.
Still, it seems that this compensation is not always 100% OK.
As sensor temperature rises when sensor is read, I added a kind of temporisation before using a first altitude as reference to calculate the relative altitude. This reduce altitude drift over time.
This temporisation is provided by this line in the OXS_BMP180::setup() function.
nextAltMillis = 5000 ;
You can reduce the value 5000 if you want (5000 means 5000 msec).

About the accuracy of the altitude, please note that the absolute altitude depends a lot of the atmospheric pressure. So depending on the weather, you can probably get a difference of more than 100 m compared to the real altitude of your location.
Absolute altitude provided by oXs is normally not used.
Therefore oXs (or some Tx) calculates a relative altitude. This is simply the difference between the current altitude and the first altitude being available just after the temporisation.

It quite common that relative altitude drift over time (even when the sensor does not move). I suspect that (over a short time) this is mainly the result of uncompensated temperature drift and (over longer time) of changes in the atmospheric pressure.

nigelsheffield
Posts: 308
Joined: Fri Nov 08, 2013 9:56 pm
Country: -

Re: GPS sensor

Post by nigelsheffield » Sun Jan 31, 2016 1:16 pm

Hi,
I just thought I'd update you on my attempt at getting artificial horizon on the pro mini and gy521.
I used the frsky s.port telemetry library and the i2cdevlib, https://github.com/jrowberg/i2cdevlib
Mixed in the 6050 with dmp demo( the one with tea pot demo) and had that output pitch and roll to temp 1 and 2, with no other sensors on that particular arduino., calling the telemetry.send from within the interupt sensing while loop I get really good fast results, does not show when airoplanes inverted though but not a huge deal.
This used 19.9 kb out of 30 so I presume there would not be enough room for GPS and vario code on same pro mini, I think I remember you saying this would not fit.
So I put the openxsensor GPS and IMU on the same s.port input as this and got it to work fully together.
Very pleased with results but still wondering if it would be possible to fit it all on one pro mini.... Down side is I can only use on s.port and not on hub along with the GPS etc which would have been nice to have because as I said before I like the d8r in particular...

Now I just need some flying weather to test all this stuff out, I have not even flown with the GPS or IMU based vario yet.....
Thanks mstrens....


Post Reply

Return to “OpenXVario - an open source vario supported by the open source firmwares!!”