GPS sensor

Development & General Chat for the superb openxvario project.

Moderator: rainer

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

Re: GPS sensor

Post by nigelsheffield » Sat Mar 19, 2016 1:34 pm

Pressing reset button immediately starts it working.

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

Re: GPS sensor

Post by mstrens » Sat Mar 19, 2016 1:38 pm

I just had a look at the log.
I have an entry in the log every 0.5 sec.

I compare consecutive entries in the log having the same values in Vspeed, Alt, GPS Alt, GPS speed, GPS Heading and GPS long/lat.

Over the 100 min the test was running, I found only 1 case where the values remained unchanged for 4 sec (8 identical consecutives entries)

This does not seems me so abnormal (taking into account that oXs did not move at all; it was just put on the table).
In order to avoid repetitive identical values, I could make a new version of oXs where I transmit a field TEST_1 that I increase by 1 every 100 msec (e.g.)

If I remember well, you said that your oXs was blocked for about 10 sec(?).
How do you detect It?

Can you make a test with the version I put on github about 1 hour ago (and the same config file , except the interrupt pin for IMU?

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

Re: GPS sensor

Post by jhsa » Sat Mar 19, 2016 1:38 pm

nigelsheffield wrote: Maybe I fixed it heating it up with hair dryer lol :D
nigelsheffield wrote:No , its just stopped working now lol.??
hmm, maybe it wasn't hot enough?? :mrgreen:

Joking, of course :)

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

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

Re: GPS sensor

Post by Carbo » Sat Mar 19, 2016 1:40 pm

nigelsheffield wrote:
openXsensor-master pitch roll yaw faster heading using accx y z.zip
Yesterday i used your script, it ran without issues, the actual oXs master today runs also fine (GY-86, Ublox7N32 GPS, pro micro). Next step: change the arduino? I had no problems for a long period, but recently 2 faulty pro mini.

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

Re: GPS sensor

Post by nigelsheffield » Sat Mar 19, 2016 2:13 pm

i think i have ruled out the arduino by building another sensor with a known good arduino which has been running standard vario altimeter fine and this still went wrong.
I detect the values in the opentx telemetry screen, there are stars next to sensors which are being recieved, these all dissapear when it goes wrong just as if I had unplugged the sensor, the lights are all still on when it goes wrong so its not loss of power.
the length of time it stays off varies a lot, from maybe 10 seconds to 5 minutes.
Carbo did you use the version of openxsensor I have uploaded on rcgroups or set up your own?
I will try the version on github and see what happens then!


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

Re: GPS sensor

Post by Carbo » Sat Mar 19, 2016 2:34 pm

nigelsheffield wrote:i think i have ruled out the arduino by building another sensor with a known good arduino which has been running standard vario altimeter fine and this still went wrong.
OK, did you try to run arduino + GY-86 without the gps, does the data loss still happen?
nigelsheffield wrote:Carbo did you use the version of openxsensor I have uploaded on rcgroups or set up your own?
No, i have used the one, you have posted here, see my quote above. This one worked, and the actual master worked also.

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

Re: GPS sensor

Post by mstrens » Sat Mar 19, 2016 2:38 pm

I am currently running a new test where oXs sent also Temp1 and Temp2 with a value that has to be incremented every 100msec.
This version is not currently loaded on github.
I will let it run for 1 hour and then look at the new log.

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

Re: GPS sensor

Post by nigelsheffield » Sat Mar 19, 2016 3:03 pm

Carbo wrote:
nigelsheffield wrote:i think i have ruled out the arduino by building another sensor with a known good arduino which has been running standard vario altimeter fine and this still went wrong.
OK, did you try to run arduino + GY-86 without the gps, does the data loss still happen?
nigelsheffield wrote:Carbo did you use the version of openxsensor I have uploaded on rcgroups or set up your own?
No, i have used the one, you have posted here, see my quote above. This one worked, and the actual master worked also.
Have not tried it without GPS, but watching it I noticed it does not seem related to GPS lock at all. And I have built the new sensor with a new GPS too so no components are same.

I am running the version now from github been running since 2:25pm no problems so far with sensor all wrapped up ..
Will leave it running another 25 mins or so and then perhaps look at getting ACC values working

Strange that carbo you have not had the problem and use same version as me, something very odd going on..

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

Re: GPS sensor

Post by Carbo » Sat Mar 19, 2016 3:20 pm

So we have 3 completely different sets of hardware, and the only working set is mine? Really odd! How long do i have to run the test to be sure? I will test it again later.

Running the test without gps would reduce the data to transmit a lot, maybe it is worth a try, to see if the amount of data is a possible reason for the issue? It is no concrete suspicion, but it is always a good idea, to reduce the number of components when troubleshooting.

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

Re: GPS sensor

Post by mstrens » Sat Mar 19, 2016 3:29 pm

I expect that my device is running fine.
Having no change in telemetry data for 4 sec while sensor is not moving seems not abnormal. It can be the result of GPS and vario keeping the same values and not of a telemetry lost.

Sorry but I have to rerun my the test with TEMP1 and TEMP2 increasing automatically every 100msec because I forgot to add those fileds in the log.

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

Re: GPS sensor

Post by nigelsheffield » Sat Mar 19, 2016 3:35 pm

Mstrens I thought only did things like that lol!
I must be sending my confusion over to you, sorry about that!!
Would you try the 3 acc values as that is what I will be using.
I presume I can still have all the yaw pitch and roll sent to ACC values like before or was that just a test version?
Still working now anyway so I will go look.

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

Re: GPS sensor

Post by mstrens » Sat Mar 19, 2016 3:44 pm

nigelsheffield wrote:Will leave it running another 25 mins or so and then perhaps look at getting ACC values working
Take care that if you want to send Acc with values from TEST_1, 2, 3, you have to look in the ino file in order to fill test1... with the right values.
I am not sure that the current version on github fills TEST_1, ... with the values you expect (because it happens often that I change this part).

I do not remember which values you expected.
Is it pitch, roll, yaw (in this sequence)
It could be useful to let you assign them (pitch,roll,yaw) in the config.h without having to use TEST_1,2,3 (because normally TEST values are more for development)

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

Re: GPS sensor

Post by nigelsheffield » Sat Mar 19, 2016 3:50 pm

Yes I think so , yes it would much easier to be able to assign them as yaw pitch and roll, would that be possible?
Should I just wait till its done and then try it?
Also the difference between s.port ACC values and hub values I have to remember how to do it, but I have that written down.

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

Re: GPS sensor

Post by mstrens » Sat Mar 19, 2016 3:53 pm

I need probably 1 or 2 hours to provide a version that allow to assign yaw pitch and roll directly.
It is up to you to decide to wait or not.

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

Re: GPS sensor

Post by nigelsheffield » Sat Mar 19, 2016 3:56 pm

Thanks, I am happy to wait if you are happy to do it, no rush I need to go walk the dog anyway lol.
Appreciate it!

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

Re: GPS sensor

Post by mstrens » Sat Mar 19, 2016 4:44 pm

I put on github a new version that allows to send pitch, yaw, roll in ACC fileds.
It is done for the 2 Frsky protocols (tested only for SPORT) but not 'yet) for Hott or Multiplex

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

Re: GPS sensor

Post by mstrens » Sat Mar 19, 2016 4:53 pm

Note : in the new version on Github, I fill TEST_1 and TEST_2 with a counter that is incremented every 100ms.
If you transmit those fields (e.g. as TEMP1 and TEMP2), you can easily see
- in the log if telemetry has been blocked (you would have several lines with the same values)
- if a reset occurs (counter will start again at zero).

In a run I made, I had no one telemetry issue with oXs

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

Re: GPS sensor

Post by nigelsheffield » Sat Mar 19, 2016 6:17 pm

great thanks, I just tested quickly and it all works on both hub and s.port, not sure if opentx will ever fix the discrepency between hub and s.port on the acc values because other projects have already taken this discrepency into account and kilrah says he would like to fix it but would need all the other projects to be notified and pull requests done..

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

Re: GPS sensor

Post by nigelsheffield » Sat Mar 19, 2016 6:17 pm

will do a long test now and see what happens!
thanks again!

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

Re: GPS sensor

Post by nigelsheffield » Sat Mar 19, 2016 6:40 pm

Sorry but I cant get t1 or t2 to work, on hub i get t1 but no values on it, on s.port i tried discover new sensor but nothing appeared?
Good news is so far sensor has not stopped working!

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

Re: GPS sensor

Post by mstrens » Sat Mar 19, 2016 7:06 pm

TEMP1 and TEMP2 worked in a previous version but I made a minor type fout in the version I put on Github.

In ino file, you should have
#define DEBUG_CHANGE_IN_TEST12
#if defined( DEBUG_CHANGE_IN_TEST12 ) // here, there was a typo fout having 2 "_" in CHANGE__IN_TEST12

Corrected version is now on github.

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

Re: GPS sensor

Post by nigelsheffield » Sat Mar 19, 2016 7:21 pm

Great thanks!
Still working after 50 mins testing..fingers crossed and touch wood!

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

Re: GPS sensor

Post by mstrens » Mon Mar 21, 2016 8:05 am

@nigelsheffield

Currently pitch, roll and yaw are just the values returned by the internal calculation performs in 6050 IMU.
If you feel that the values are too noisy( change too fast), I could add some filtering in oXs

Let me know if this is required.

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

Re: GPS sensor

Post by nigelsheffield » Mon Mar 21, 2016 10:14 am

Thanks , I will have another look next time I fly, won't be for a few days looking at forcast...
I think more the problem is that the levels are not exactly correct, they are definitely useable though as I proved last time I flew I could return to base with just the tx screen!
Dont know if it can be fixed but What I did notice wrong was in a turn the pulling up of the elevator to keep nose level made the nose appear to rise on the screen, I guess this is due to the gravity based sensor output? And turning would appear to do a similar thing, I think it's just that the g forces involved in the manauver as you pull on the stick to turn and pull are giving false indications ie the screen was following the stick inputs ...
There was still enough proper info to fly though so it's possible I could filter this somewhat in the lua script based on stick inputs , it was a while ago now that I looked at the imu yaw pitch roll levels but I remember there was another set of levels could be calculated which would allow inverted measurement too , would these values also be effected by the stick inputs I wonder, but I also remember there was a possible drift problem with these readings?

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

Re: GPS sensor

Post by nigelsheffield » Sat Apr 02, 2016 3:07 pm

I flew the other day and everything was fine, no loss of temetry at all.
I dont know if filtering is really needed on the levels, the taranis display showed them working well enough.
Main advantage is the fast vario tones but I will use the GPS for waypoint racing later on.
I've built another now and will install then in the next couple of weeks.
Thanks mstrens.

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

Re: GPS sensor

Post by nigelsheffield » Mon Apr 04, 2016 2:55 pm

flying some more today and its becoming obvious that the roll angles could be a LOT better, I find I am using the heading to establish if plane is flying level or turning, Ive just altered the script to calculate yaw rate from yaw data and fed this into the roll calculation, its a bit jerky but working on bench,
I will have to wait for some better weather again now to test it, if it works it would be better to calculate yaw rate in the sensor and send this down rather then calculating it in the script because of the speed of the data sent.
I also wondered about the pitch because the nose appears to point upwards in a tight turn, perhaps adding the yaw rate to the pitch angles calculation might work, ie a greater yaw rate makes for less pitch reading? this could be done in the script I think.
Could yaw rate be calculated easily on the sensor? It might be useful for other things like I was thinking of adding return to home by giving the rudder control over to the script..

lshems
Posts: 7
Joined: Tue Sep 15, 2015 5:36 pm
Country: -

Re: GPS sensor

Post by lshems » Mon Apr 04, 2016 3:04 pm

Following you, waiting for me to get some time for this one.

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

Re: GPS sensor

Post by nigelsheffield » Mon Apr 04, 2016 6:16 pm

Braved the winds in a break from the rain and tested it out, its incredibly NOISY and Jumping around due to slow data and lack of of any filtering but it seemed to work, I could fly a circle continuously and the angle was shown correctly and exiting the circle seemed OK.
I think it might work with the yaw rate calculated in the sensor.

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

Re: GPS sensor

Post by mstrens » Tue Apr 05, 2016 7:59 am

I presume the yaw rate could be calculated in the sensor.
I see 2 options;
- calculate the difference of yaw every 0.5 sec
- use the gyro values provided by the sensor (which are just rotation rates) and calculate the yaw rate taking into account the gravity vertor (giving orientation of the sensor). I expect this would be better (at least more reactive) but I do not know which formula to use to calculate the yaw rate using gravity vector. Do you know it?

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

Re: GPS sensor

Post by nigelsheffield » Tue Apr 05, 2016 8:43 am

Second option would definitely be better, I don't know the calculation, sorry..I can Google it later if it helps,
I wonder though if there might be problems again with centigugal forces with that?

If first option is easier and could be calcuted and sent maybe 5 times a second it might be enough..

Post Reply

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

Who is online

Users browsing this forum: No registered users and 1 guest