Page 1 of 1

GPS Distance covered

Posted: Sat Jun 18, 2016 2:21 pm
by renes
Hello,

I've a taranis and GPS V2 sensor up and running.

Want I want to do is to show the distance that the quadcopter actually has been flying so e.g. Total Distance covered: 2.3KM

The distance function that is build in just shows the acutally distance between the radio and the model.

How is that possible?

best regards

rene

Re: GPS Distance covered

Posted: Sat Jun 18, 2016 6:39 pm
by Kilrah
It isn't at this point. Someone could maybe write a lua script, could even already exist with a bit of luck.

Re: GPS Distance covered

Posted: Fri Jul 01, 2016 6:16 am
by rcdiy
I'm going to be writing one but have having problem with generating logs which I will then use while programming and testing.

Does anyone have GPS logs to give me to use while I figure out why I can't get my own logs?

Re: GPS Distance covered

Posted: Fri Jul 01, 2016 11:06 am
by bob195558
Hi rcdiy,
I have been trying to use the FrSky GPS (V2) Sensor with erSky9x on Taranis and have found with the altitude readings to be very slow
and very inaccurate most of the time.
See here for more about it: (viewtopic.php?f=95&t=8922).

There is this youtube video promoting it, BUT I find the FrSky GPS (V2) Sensor dose not work properly and therefore is a junk product.
The data is slow in coming and is greatly not accurate most of the time: (https://www.youtube.com/watch?v=8VcVhcDNOBo).
If a firmware upgrade could fix it (make it work), that would be great.

Bob B.

Re: GPS Distance covered

Posted: Fri Jul 01, 2016 6:26 pm
by rcdiy
Yup, I agree Bob, just something for me to do:) When the technology/implementation catches up the script will be ready. I'm also looking at calculating directions back home which will be good enough to bring the model back into visual range/sight.

Re: GPS Distance covered

Posted: Sun Jul 10, 2016 4:49 pm
by rcdiy
I've implemented a GPS script with heading, direction home, direction to model, direction to turn to come home, distance to/from model, distance covered. Displays all, option to speak heading and turn to come home (switch optional as well), option to write all to OpenTx Global variables.
Code and supporting files available
http://rcdiy.ca/gps-directions-home/

Re: GPS Distance covered

Posted: Sun Jul 10, 2016 5:31 pm
by Carbo
rcdiy wrote:I've implemented a GPS script with heading...........
Looks good! I will try it with one of my openXsensor GPS with 5Hz update-rate. The oXs-GPS transmits heading itself (Hdg), will it be better, to use it, or do you think, there is no difference?
Heading.png
(2.68 KiB) Not downloaded yet

Re: GPS Distance covered

Posted: Sun Jul 10, 2016 5:40 pm
by rcdiy
The script depends on an OpenTx Lua call getValue(sensor). The code relies on values being returned in a particular format. Before I go into too much detail knowing your level of programming would be helpful.

One simple way to know if it may work is to produce a log file and send it to me.

Here is my log file.

Re: GPS Distance covered

Posted: Sun Jul 10, 2016 6:16 pm
by Carbo
rcdiy wrote: Before I go into too much detail knowing your level of programming would be helpful.
I would call myself a user. Changing your heading calculation against the native heading should be possible for me at best (if useful), but that´s all, to be honest.
rcdiy wrote: One simple way to know if it may work is to produce a log file and send it to me.
Here is a short testfligt with the oXs GPS:
Stratos_E-2015-10-31.zip
(49.81 KiB) Downloaded 327 times

Re: GPS Distance covered

Posted: Sun Jul 10, 2016 6:43 pm
by rcdiy
Since I relied on web resources that allowed me to test data back and forth between the resource and my own data in theory the heading provided by the OpenTx calculated sensor and the script calculations should be identical.

My thoughts are to leave the script as is however I'd be willing to make a modification to use the Heading sensor. It may mean unnecessary additional steps for the user plus documentation to go with it.

A note on direction accuracy:
While calculations are done at full precision display and speech are reduce accuracy to 1/16 of 360 degrees.
Why? I produced individual image and sound files for directions and turns.
The data is not being used to control anything. I can't turn an RC model to point exactly has directed so increments of 1/16 of 360 is good enough for me:)

In general when I write scripts I want to avoid duplicating what OpenTx already has implemented but I think I also want to balance setup complexity.

Apologies, you asked a simple question but I went off on a tangent:)