GPS sensor

nigelsheffield · Post by **nigelsheffield** » Thu Feb 04, 2016 7:50 pm

Great thanks, I will look into why opentx changes values but for now I will fix it with your sensor fix in osx out.
Could get confusing though if opentx has fixed this in newer version, I am on 2.0.17

kalle123 · Post by **kalle123** » Fri Feb 05, 2016 7:58 am

Let me bring one point up here. About the MPU6050 sensor (accelerometer/gyro)

From my experience with multiwii I know that sensor orientation is a critical point and the multiwii sketch holds two lines for adjustment

/* enforce your individual sensor orientation - even overrides board specific defaults */
//#define FORCE_ACC_ORIENTATION(X, Y, Z) {imu.accADC[ROLL] = Y; imu.accADC[PITCH] = -X; imu.accADC[YAW] = Z;}
//#define FORCE_GYRO_ORIENTATION(X, Y, Z) {imu.gyroADC[ROLL] = -Y; imu.gyroADC[PITCH] = X; imu.gyroADC[YAW] = Z;}

which is to be checked and if necessary adjusted by performing those actions.

How should be the sensor axis directions
TILT the MULTI to the RIGHT (left side up):
MAG_ROLL, ACC_ROLL and GYRO_ROLL goes up
MAG_Z and ACC_Z goes down
TILT the MULTI forward (tail up):
MAG_PITCH, ACC_PITCH and GYRO_PITCH goes up
MAG_Z and ACC_Z goes down
Rotating the copter clockwise (YAW):
GYRO_YAW goes up
The copter stays level:
MAG_Z is positive ; ACC_Z is positive

In oXs_config_description.h I find those lines here

in this case it is important that oXs device is mounted in a fix position and is aligned with the plane axis.
* Only one IMU sensor is supported : the mpu6050.

and

* In order to get best results from IMU, it is required to calibrate the accelerometer offsets. To do so, please :
* - upload a version of oXs firmware whith the line #define DISPLAY_ACC_OFFSET is uncommented
* - let oXs runs while connected to the PC (via USB serial interface = FTDI)
* - open Arduino IDE terminal (press CTRL + SHIFT + M simultaniously)
* - take care to set the baud rate to 115200 (or 38400 if GPS is activated too)
* - after startup, terminal should, every 2 or 3 sec, display Acc followed by 3 numbers being respectively AccX, AccY and AccZ. Please note that those numbers change when mpu6050 moves.
* - ensure that the mpu6050 (GY86) is perfectly horizontal and does not move (e.g. put on a table)
* - notice the 2 first numbers ( = AccX and AccY ) ; Don't take care of the 3rd number because when the sensor is in this position, it will reflect the gravity and will be around 16384.
* - rotate mpu6050 in order to get X or Y axis perfectly vertical and do not move. Now, the 3rd number would become much lower (because it does not measure gravity anymore)
* - notice the 3rd number ( = Accz )
* - update oXs_config.h file filling the 3 numbers in lines #define ACC_OFFSET_X , #define ACC_OFFSET_Y and #define ACC_OFFSET_Z
* - set line #define DISPLAY_ACC_OFFSET as comment (adding "//" in front)
* - upload again oXs firmware in arduino

So, to make it short. I am missing some words on sensor orientation here .... Or is that not necessary

br KH

mstrens · Post by **mstrens** » Fri Feb 05, 2016 9:56 am

oXs can use IMU for different purposes. I expect that depending on the purpose, sensor orientation is important or not.

My initial purpose adding IMU to oXs was to test if it was possible to reduce reaction time of the vario.
To do so, oXs uses the IMU just to get the vertical acceleration regarding Earth.
This acceleration is not provided as is by IMU and there is some complex algorithm that merges acceleration and gyro data in order to provide it even when the sensor rotates.
So just for this purpose, I expect that sensor orientation in the plane does not matter.
NOte : writting this text now, I have some doubts how could this works if the plane/glider flies back over a long time. Should be tested.

On the other side, having an IMU allows oXs to calculate pitch and roll too. If you want to collect/use those informations, then orientation of the sensor is for sure important (otherwise the returned values will not be representative of the orientation of the plane).

In multiwii, the software uses pitch and roll to stabilise the plane (or quadcopter) and so orientation is for sure important.

Note : even when oXs is used only for vario purpose, it is better to calibrate acceleration offsets because those offsets are used by the algorithm that calculates the vertical acceleration.

kalle123 · Post by **kalle123** » Fri Feb 05, 2016 11:15 am

Hi mstrens.

Was not sure about that aspect. And as I can not track sensor behavior in your sketch, only wanted to mention that point ...

br KH

nigelsheffield · Post by **nigelsheffield** » Fri Feb 05, 2016 11:21 am

I will do some long tests once I get it working as I like , I have IMU heading working now on the script, now I just need to look at Calibrating it from GPS heading.
In don't think pitch roll levels will drift as we are using gravity which calibrates the levels right?
This comes at the expense of inverted flight is not show but I will know if I'm upside down by the reaction of pitch, and I'm not intending to do airobatics using instruments lol.

kalle123 · Post by **kalle123** » Fri Feb 05, 2016 11:32 am

A short sketch for verifying sensor orientation could come handy ...

nigelsheffield · Post by **nigelsheffield** » Fri Feb 05, 2016 11:37 am

whilst browsing i noticed this in frsky out.cpp
is this a typo, 6th line down there is accz

// accY
#if defined(ACCY_SOURCE) && ( ACCY_SOURCE == TEST_1)
SendValue( FRSKY_USERDATA_ACC_Y , (int16_t) test1.value) ;
#elif defined(ACCY_SOURCE) && ( ACCY_SOURCE == TEST_2)
SendValue( FRSKY_USERDATA_ACC_Y , (int16_t) test2.value) ;
#elif defined(ACCY_SOURCE) && ( ACCY_SOURCE == TEST_3)
SendValue( FRSKY_USERDATA_ACC_Z , (int16_t) test3.value) ;
#elif defined(ACCY_SOURCE) && ( ACCY_SOURCE == GLIDER_RATIO) && defined(VARIO) && defined(GLIDER_RATIO_CALCULATED_AFTER_X_SEC)
SendValue( FRSKY_USERDATA_ACC_Y , (int16_t) gliderRatio.value) ;
#elif defined(ACCY_SOURCE) && ( ACCY_SOURCE == SECONDS_SINCE_T0 ) && defined(VARIO) && defined(GLIDER_RATIO_CALCULATED_AFTER_X_SEC)
SendValue( FRSKY_USERDATA_ACC_Y , (int16_t) secFromT0.value) ;
#elif defined(ACCY_SOURCE) && ( ACCY_SOURCE == AVERAGE_VSPEED_SINCE_TO ) && defined(VARIO) && defined(GLIDER_RATIO_CALCULATED_AFTER_X_SEC)
SendValue( FRSKY_USERDATA_ACC_Y , (int16_t) averageVspeedSinceT0.value) ;
#endif

nigelsheffield · Post by **nigelsheffield** » Fri Feb 05, 2016 11:47 am

kalle123 wrote:A short sketch for verifying sensor orientation could come handy ...

my usage so far on arduino is 83% of storage and 53% of dynamic memory. I only have gps and imu and ms5611, no current or volts or air speed.
So question is do I make the arduino do the calibrating of imu heading or do it in the taranis in a lua script?
for me with a taranis its no problem to do it in the lua script but maybe others might like to have the feature who dont have taranis?
it all depends on memory available in the arduino for each person as to how much they have left i guess..

nigelsheffield · Post by **nigelsheffield** » Fri Feb 05, 2016 11:50 am

mstrens wrote:
nigelsheffield wrote:its working but i notice a difference between hub reading and d16 reading when sending over accx or accz, the d16 goes to 1.7 where the hub goes to .17 max so out by a decimal place.
if i send over t1 or t2 the reading the same.
I expect that the difference between the 2 protocols is generated by openTx because in oXs I send the same value in both protocols.
Still it should be possible to fix it in oXs.
In order to get the same value, you could multiply the value by 10 in Hub protocol.
This can be done in lines like the next one (in oXs_out_frsky.cpp
Code: Select all
#if defined(ACCX_SOURCE) && ( ACCX_SOURCE == TEST_1)
   SendValue( FRSKY_USERDATA_ACC_X , (int16_t) test1.value) ; // could become SendValue( FRSKY_USERDATA_ACC_X , (int16_t) test1.value * 10 ) ;

this fixed my problem thanks, ive asked on opentx about the discrepancy....

kalle123 · Post by **kalle123** » Fri Feb 05, 2016 12:01 pm

Just tested this sketch here http://www.i2cdevlib.com/forums/topic/9 ... 0-offsets/

Send any character to start sketch.

MPU6050 Calibration Sketch

Your MPU6050 should be placed in horizontal position, with package letters facing up.
Don't touch it until you see a finish message.

MPU6050 connection successful

Reading sensors for first time...

Calculating offsets...
...
...
...
...
...
...
...
...
...
...
...
...

FINISHED!

Sensor readings with offsets: 0 -6 16370 0 0 0
Your offsets: 1006 -567 1255 106 -38 2

Data is printed as: acelX acelY acelZ giroX giroY giroZ
Check that your sensor readings are close to 0 0 16384 0 0 0
If calibration was succesful write down your offsets so you can set them in your projects using something similar to mpu.setXAccelOffset(youroffset)

nigelsheffield · Post by **nigelsheffield** » Fri Feb 05, 2016 12:30 pm

Kalle123 I think I looked at that too for once off Calibrating the sensor , this can be done with a separate sketch from openxsensor and no need to be included in the code. I think we are talking about different things , I am simply thinking getting heading from GPS to calibrate the heading from IMU, because this drifts over time but is useful in that it updates fast and mostly useful because it still works when stationary maybe in heavy wind,
If this would be useful to other users of openxsensor who don't have a taranis it could be done in openxsensor , if not then I can do it in the taranis lua script.
Probably easier to do it in taranis lua script for me as I'm more used to lua script now and don't want to impact on openxsensor memory for people who don't want or need that feature. But it would probably work better from the openxsensor as it would be using faster IMU and GPS data..

kalle123 · Post by **kalle123** » Fri Feb 05, 2016 12:59 pm

Was not aimed to you, Nigel. It is more a question to mstrens.

Is oXs overwriting those values, when calibration has been done by that external sketch?

And again my other question

Writing to top, but it does not matter, where the x and y axis goes? Or even those two axis even don't have to match the aircrafts axis?

br KH

mstrens · Post by **mstrens** » Fri Feb 05, 2016 1:52 pm

nigelsheffield wrote:whilst browsing i noticed this in frsky out.cpp
is this a typo, 6th line down there is accz

// accY
#if defined(ACCY_SOURCE) && ( ACCY_SOURCE == TEST_1)
SendValue( FRSKY_USERDATA_ACC_Y , (int16_t) test1.value) ;
#elif defined(ACCY_SOURCE) && ( ACCY_SOURCE == TEST_2)
SendValue( FRSKY_USERDATA_ACC_Y , (int16_t) test2.value) ;
#elif defined(ACCY_SOURCE) && ( ACCY_SOURCE == TEST_3)
SendValue( FRSKY_USERDATA_ACC_Z , (int16_t) test3.value) ;
#elif defined(ACCY_SOURCE) && ( ACCY_SOURCE == GLIDER_RATIO) && defined(VARIO) && defined(GLIDER_RATIO_CALCULATED_AFTER_X_SEC)
SendValue( FRSKY_USERDATA_ACC_Y , (int16_t) gliderRatio.value) ;
#elif defined(ACCY_SOURCE) && ( ACCY_SOURCE == SECONDS_SINCE_T0 ) && defined(VARIO) && defined(GLIDER_RATIO_CALCULATED_AFTER_X_SEC)
SendValue( FRSKY_USERDATA_ACC_Y , (int16_t) secFromT0.value) ;
#elif defined(ACCY_SOURCE) && ( ACCY_SOURCE == AVERAGE_VSPEED_SINCE_TO ) && defined(VARIO) && defined(GLIDER_RATIO_CALCULATED_AFTER_X_SEC)
SendValue( FRSKY_USERDATA_ACC_Y , (int16_t) averageVspeedSinceT0.value) ;
#endif

Indeed , it is a typo.
It will be fixed in next upload on github

mstrens · Post by **mstrens** » Fri Feb 05, 2016 2:02 pm

nigelsheffield wrote:
kalle123 wrote:A short sketch for verifying sensor orientation could come handy ...

my usage so far on arduino is 83% of storage and 53% of dynamic memory. I only have gps and imu and ms5611, no current or volts or air speed.
So question is do I make the arduino do the calibrating of imu heading or do it in the taranis in a lua script?
for me with a taranis its no problem to do it in the lua script but maybe others might like to have the feature who dont have taranis?
it all depends on memory available in the arduino for each person as to how much they have left i guess..

I presume that calibration of acc is only done once.
So, it is not an issue to add code inside Arduino because
- other sensors (like voltage, current, MS5611) can be disabled in the config when calibration is performed
- code for calibration can be disabled after calibration.
When code is disabled, it does not use any memory.

mstrens · Post by **mstrens** » Fri Feb 05, 2016 2:27 pm

You can use another sketch to find the acceleration offsets but in fact oXs contains already code for this purpose.

The procedure is explained in the file oXs_config_description.h
* In order to get best results from IMU, it is required to calibrate the accelerometer offsets. To do so, please :
* - upload a version of oXs firmware whith the line #define DISPLAY_ACC_OFFSET is uncommented
* - let oXs runs while connected to the PC (via USB serial interface = FTDI)
* - open Arduino IDE terminal (press CTRL + SHIFT + M simultaniously)
* - take care to set the baud rate to 115200 (or 38400 if GPS is activated too)
* - after startup, terminal should, every 2 or 3 sec, display Acc followed by 3 numbers being respectively AccX, AccY and AccZ. Please note that those numbers change when mpu6050 moves.
* - ensure that the mpu6050 (GY86) is perfectly horizontal and does not move (e.g. put on a table)
* - notice the 2 first numbers ( = AccX and AccY ) ; Don't take care of the 3rd number because when the sensor is in this position, it will reflect the gravity and will be around 16384.
* - rotate mpu6050 in order to get X or Y axis perfectly vertical and do not move. Now, the 3rd number would become much lower (because it does not measure gravity anymore)
* - notice the 3rd number ( = Accz )
* - update oXs_config.h file filling the 3 numbers in lines #define ACC_OFFSET_X , #define ACC_OFFSET_Y and #define ACC_OFFSET_Z
* - set line #define DISPLAY_ACC_OFFSET as comment (adding "//" in front)
* - upload again oXs firmware in arduino

If it is not clear or does not work, I can adapt it.

There is no need to calibrate the gyro because this task is performed automatically by the software (using the DMP inside 6050)

kalle123 · Post by **kalle123** » Fri Feb 05, 2016 4:09 pm

Thank you mstrens. I am used to read through oXs_config_description.h BEFORE asking

I was just curious, because when I was active with building my multiwii fc with sensor components it was a big issue found in discussions, that sensor orientation was not ok.

But now you buy those fc's with all sensors ready on a stamp size shield.

Just tested your v7.0 on my "testbench" and I think, I will modify one of the oXs varios oXs v5.0 with an additional connector for gps and skip adding a MPU 6050. .... Unless Nigel is willing to post the LUA script for his display

br KH

nigelsheffield · Post by **nigelsheffield** » Fri Feb 05, 2016 6:59 pm

Of course I will post the lua script for you, its no secret lol, not really mine but I'm just fiddling with it , tested a simple calibration today in the lua script
Simply based on speed, so it calculated and offset by GPS heading minus IMU heading when speed over 5 - and only used the calibrated IMU when speed was under 2, just so I could walk round garden to see if it worked.
Seemed OK so seeing as GPS heading will be used mostly I may just leave it at thawt. Very small code and could easily fit on the openxsensor if needed but I can think about it later.
Downside is my other scripts won't work at same time so I need to go through the script and see if I can thin it down, auther has used get value("") everywhere instead of getfieldinfo at start ..
Will post script in a moment when I fire up the laptop!

nigelsheffield · Post by **nigelsheffield** » Fri Feb 05, 2016 7:09 pm

telem2.lua: (14.89 KiB) Downloaded 326 times

here is script so far,
requires temp1 and temp2 for pitch roll, and accz ( accz on hub protocol needs times by10 in openxsensor as advised by mstrens)
working as far as navigating around my garden lol, for flying change the if speed >= parts near the end

kalle123 · Post by **kalle123** » Fri Feb 05, 2016 8:18 pm

Thank you Nigel. I'll give it a try.
Just changed over from 2.0.18 to 2.1.7

br KH

nigelsheffield · Post by **nigelsheffield** » Fri Feb 05, 2016 8:57 pm

The script is running on 2.0.17, probably OK on 2.0.18 but for 2.1.7 it will need some changing as will my other scripts, and this is why I'm still on 2.0.17 lol..

One day I will go for it and move to 2.1.7 and redo all my scripts and telemetry settings on all my models......

kalle123 · Post by **kalle123** » Sat Feb 06, 2016 7:27 am

Realized that, Nigel.

Could revert to 2.0.x for a test ....

nigelsheffield · Post by **nigelsheffield** » Sat Feb 06, 2016 8:03 am

Converting script to 2.1 should not be too hard now, I think it's just a case of renaming the sensors in the get value statements to match what you see in the telemetry info

nigelsheffield · Post by **nigelsheffield** » Sat Feb 06, 2016 10:59 am

Regarding testing over time with the IMU,
I just set up a servo on a loop to move the sensor around whilst monitoring the pitch roll, left to running for an hour or so and the levels were always working and correct.
I was worried before because testing in garden as telemetry locked up for a few minutes at one point but I think this was probably down to swamping of signals as I was carrying the tx in one hand and RX in the other .
This was with x6r in d16 mode.
Was calm enough to fly this morning but raining of course lol.....

mstrens · Post by **mstrens** » Sat Feb 06, 2016 2:11 pm

Thanks for the feedback.

I expect that pith and roll would remain ok over time when the sensor does not move because the DMP algorithm running in 6050 realigns it self on gravity retrieved from accelerometers.
It could be that this realigment becomes wrong if the plane is circling (because there would be a centrifuge force added to gravity).

nigelsheffield · Post by **nigelsheffield** » Sat Feb 06, 2016 2:31 pm

I did wonder about that, centrifugal forces may well have an impact.
Guess I need to spin round and round to test it, may be getting dizzy soon lol...

nigelsheffield · Post by **nigelsheffield** » Sat Feb 06, 2016 3:51 pm

Ok I must be bored lol

I tried spinning round and I don't think it will be a problem in flight, both levels and vario tones seem unaffected in any way that I could see.
I feel sick now !!!!

nigelsheffield · Post by **nigelsheffield** » Sun Feb 07, 2016 2:38 pm

flight display calibrated when level.lua: (14.88 KiB) Downloaded 251 times

I altered the lua script to only calibrate the imu heading with gps heading when roll is near level and speed is over 10,
then display the imu heading instead of gps heading when speed is under 5 or roll angle is over 20.
Very short bit of code and would easily fit on openxsensor.
still windy so cant fly but altering number to allow me to simulate in the garden it seemed to work.

Post by **jhsa** » Mon Feb 08, 2016 6:56 am

nigelsheffield wrote:Ok I must be bored lol

I tried spinning round and I don't think it will be a problem in flight......
...I feel sick now !!!!

Sorry, couldn't help it

João

nigelsheffield · Post by **nigelsheffield** » Mon Feb 08, 2016 10:12 am

jhsa wrote:
nigelsheffield wrote:Ok I must be bored lol

I tried spinning round and I don't think it will be a problem in flight......
...I feel sick now !!!!
Sorry, couldn't help it

João

I'm suprized it took you so long lol, I started to think that you were not following this thread ...
I must be getting old though, I only spun round a few of times and nearly lost my balance , hadn't even had any alcohol

Post by **jhsa** » Mon Feb 08, 2016 10:17 am

nigelsheffield wrote:

I'm suprized it took you so long lol, I started to think that you were not following this thread ...

I do my best

I answered as soon as I woke up

I do follow all threads. We always learn something even if we don't use the features..

João

openrcforums

GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: GPS sensor

Re: RE: Re: GPS sensor

Re: RE: Re: GPS sensor

Re: RE: Re: RE: Re: GPS sensor