Which is better to use for ESP32 and Sparkfun 9250 breakout? #17
Comments
|
What's wrong with this
<https://github.com/kriswiner/ESP32/tree/master/MPU9250_MS5637> one?
…On Fri, Sep 7, 2018 at 12:03 PM MiloMindbender ***@***.***> wrote:
@kriswiner <https://github.com/kriswiner> I'm a little confused looking
at your ESP32 repository and your MPU9250 repository.
I'm using a Sparkfun 9250 breakout (
https://www.sparkfun.com/products/13762) and an Adafruit Feather ESP32
board.
Between these two repositories you have a number of MPU9250 sketches and
I'm a bit confused about which one is most appropriate for the setup I'm
running. I'm looking to get sensor fusion for a balancing robot.
My robot runs it's main loop every 10ms and I want to get/fuse "latest"
data from the sensor at the top of the loop.
I've tried sparkfun's 9250 repositories but theirs all seem broken in some
way.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qp7JI_6FL-Hsr6tSsazDnA82hb7uks5uYsMcgaJpZM4WfU5t>
.
|
|
It's not building for me, MadgwickQuaternionUpdate not declared in this scope. Did I miss a library/file I need to get from someplace else? Didn't see anything in a readme. |
|
Add the filter file to your sketch using the tab...
…On Fri, Sep 7, 2018 at 1:46 PM MiloMindbender ***@***.***> wrote:
It's not building for me, MadgwickQuaternionUpdate not declared in this
scope.
Did I miss a library/file I need to get from someplace else? Didn't see
anything in a readme.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qkIeLoqW8VxkxqtKnb2i8nUkZRQeks5uYtsygaJpZM4WfU5t>
.
|
|
Sorry to be such a dummy, but now I'm getting errors in the wire.h include file. In file included from C:\Users\gcorson\Downloads\ESP32-master\ESP32-master\MPU9250_MS5637\MPU9250_MS5637_AHRS\MPU9250_MS5637_AHRS.ino:29:0: C:\Users\gcorson\Documents\Arduino\hardware\espressif\esp32\libraries\Wire\src/Wire.h: In function 'uint8_t readByte(uint8_t, uint8_t)': C:\Users\gcorson\Documents\Arduino\hardware\espressif\esp32\libraries\Wire\src/Wire.h:99:13: note: candidate 1: uint8_t TwoWire::requestFrom(int, int) C:\Users\gcorson\Documents\Arduino\hardware\espressif\esp32\libraries\Wire\src/Wire.h:97:13: note: candidate 2: uint8_t TwoWire::requestFrom(uint8_t, uint8_t) Archiving built core (caching) in: C:\Users\gcorson\AppData\Local\Temp\arduino_cache_78456\core\core_espressif_esp32_featheresp32_FlashFreq_80,UploadSpeed_921600,DebugLevel_verbose_69dfa191d1244698fa99bf793b8c9f27.a |
|
@kriswiner Sorry, apparently it still built, but when I run it doesn't connect to my MPU9250 [V][esp32-hal-i2c.c:1436] i2cInit(): num=0 sda=21 scl=22 freq=400000 MPU9250 9-axis motion sensor... |
|
Looks like pins 21 and 22 are not the SDA and SCL pins on my ESP32. Changed to Wire.begin() Now it finds the chip, but the output I get for the sensors never changes. [V][esp32-hal-i2c.c:1436] i2cInit(): num=0 sda=23 scl=22 freq=0 MPU9250 9-axis motion sensor... |
|
Do you have the interrupt pin properly specified?
…On Fri, Sep 7, 2018 at 2:32 PM MiloMindbender ***@***.***> wrote:
Reopened #17 <#17>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qtrWd5WNY-P8hK7soX5hf-55QCaoks5uYuYJgaJpZM4WfU5t>
.
|
|
I just noticed this, your hookup guide in the comments didn't mention the interrupt pin at all so I missed it. Is there a sketch that doesn't need the interrupt pin? None of sparkfun's stuff requires it so the int pin isn't tied to the breadboard right now.... |
|
I should say, thanks very much for all your work, it is really appreciated. I've been having so much trouble ferriting out stuff that works. Sparkfun has 3 repositories for this board, all out of date, two with serious bugs. They have hacked some of your code, mention using interrupts but they have changed the code to not use them (but leaving comments/code about interrupts in) so getting this 9250 working has been very confusing! Also, the Invensense DMP stuff furthers the confusion by talking about having 9dof fusion on-chip when they really only have 6 (the mag stuff is done in the MCU). Anyway, I think I can use sparkfun's method for not using interrupts The robot I'm working on has a precise timed main loop every 10ms, so I really want to get the sensor data at the top of that loop every time. Do you have any recommendation for keeping in sync with the 9250? |
|
Use the interrupt...
…On Fri, Sep 7, 2018 at 2:55 PM MiloMindbender ***@***.***> wrote:
I should say, thanks very much for all your work, it is really
appreciated. I've been having so much trouble ferriting out stuff that
works. Sparkfun has 3 repositories for this board, all out of date, two
with serious bugs. They have hacked some of your code, mention using
interrupts but they have changed the code to not use them (but leaving
comments/code about interrupts in) so getting this 9250 working has been
very confusing!
Also, the Invensense DMP stuff furthers the confusion by talking about
having 9dof fusion on-chip when they really only have 6 (the mag stuff is
done in the MCU).
Anyway, I think I can use sparkfun's method for not using interrupts
if (myIMU.readByte(MPU9250_ADDRESS, INT_STATUS) & 0x01)
The robot I'm working on has a precise timed main loop every 10ms, so I
really want to get the sensor data at the top of that loop every time. Do
you have any recommendation for keeping in sync with the 9250?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qkXZCvYgcVJspuBSHO9mUvmQnci8ks5uYuttgaJpZM4WfU5t>
.
|
|
My issue (and maybe this isn't really an issue) is if my main loop is 100hz and I set the IMU to 100hz they will gradually drift out of sync and the data available at the top of the loop could potentially be almost 10 ms old. If I turn the IMU to 200hz, then I only get a sample representative of the last 5ms and not the whole 10ms loop time. I could set the IMU to 100hz and sync the main loop to the interrupt but if I have more than one sensor that needs to be synced up, that doesn't work either. Maybe this doesn't matter to, I'm not sure. I'm just trying not to do anything stupid because getting a smooth balancing robot seems to have a lot to do with not having variable latency or jitter in your sensor data. Thanks for your help. |
|
Set the gyro and accel sample rates to 1 kHz. You might need to use
something better than a poky AVR MCU...
…On Fri, Sep 7, 2018 at 4:32 PM MiloMindbender ***@***.***> wrote:
My issue (and maybe this isn't really an issue) is if my main loop is
100hz and I set the IMU to 100hz they will gradually drift out of sync and
the data available at the top of the loop could potentially be almost 10 ms
old. If I turn the IMU to 200hz, then I only get a sample representative of
the last 5ms and not the whole 10ms loop time.
I could set the IMU to 100hz and sync the main loop to the interrupt but
if I have more than one sensor that needs to be synced up, that doesn't
work either.
Maybe this doesn't matter to, I'm not sure. I'm just trying not to do
anything stupid because getting a smooth balancing robot seems to have a
lot to do with not having variable latency or jitter in your sensor data.
Thanks for your help.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qma_NiHiH4nkYJ-LN9bgwRnir1ycks5uYwITgaJpZM4WfU5t>
.
|
|
Set the gyro and accel rates to 1 kHz and simply read both plus mag data
(100 Hz) at the top of the loop. The important one is the gyro, this way
the PID loop sees the freshest daya available, no interrupt or status
register polling needed.
On Fri, Sep 7, 2018 at 4:37 PM Tlera Corporation <tleracorp@gmail.com>
wrote:
… Set the gyro and accel sample rates to 1 kHz. You might need to use
something better than a poky AVR MCU...
On Fri, Sep 7, 2018 at 4:32 PM MiloMindbender ***@***.***>
wrote:
> My issue (and maybe this isn't really an issue) is if my main loop is
> 100hz and I set the IMU to 100hz they will gradually drift out of sync and
> the data available at the top of the loop could potentially be almost 10 ms
> old. If I turn the IMU to 200hz, then I only get a sample representative of
> the last 5ms and not the whole 10ms loop time.
>
> I could set the IMU to 100hz and sync the main loop to the interrupt but
> if I have more than one sensor that needs to be synced up, that doesn't
> work either.
>
> Maybe this doesn't matter to, I'm not sure. I'm just trying not to do
> anything stupid because getting a smooth balancing robot seems to have a
> lot to do with not having variable latency or jitter in your sensor data.
>
> Thanks for your help.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#17 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGY1qma_NiHiH4nkYJ-LN9bgwRnir1ycks5uYwITgaJpZM4WfU5t>
> .
>
|
|
This <https://www.tindie.com/products/TleraCorp/ladybug-flight-controller/>
would make a better choice for robot controller.
On Fri, Sep 7, 2018 at 4:45 PM Tlera Corporation <tleracorp@gmail.com>
wrote:
… Set the gyro and accel rates to 1 kHz and simply read both plus mag data
(100 Hz) at the top of the loop. The important one is the gyro, this way
the PID loop sees the freshest daya available, no interrupt or status
register polling needed.
On Fri, Sep 7, 2018 at 4:37 PM Tlera Corporation ***@***.***>
wrote:
> Set the gyro and accel sample rates to 1 kHz. You might need to use
> something better than a poky AVR MCU...
>
> On Fri, Sep 7, 2018 at 4:32 PM MiloMindbender ***@***.***>
> wrote:
>
>> My issue (and maybe this isn't really an issue) is if my main loop is
>> 100hz and I set the IMU to 100hz they will gradually drift out of sync and
>> the data available at the top of the loop could potentially be almost 10 ms
>> old. If I turn the IMU to 200hz, then I only get a sample representative of
>> the last 5ms and not the whole 10ms loop time.
>>
>> I could set the IMU to 100hz and sync the main loop to the interrupt but
>> if I have more than one sensor that needs to be synced up, that doesn't
>> work either.
>>
>> Maybe this doesn't matter to, I'm not sure. I'm just trying not to do
>> anything stupid because getting a smooth balancing robot seems to have a
>> lot to do with not having variable latency or jitter in your sensor data.
>>
>> Thanks for your help.
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <#17 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AGY1qma_NiHiH4nkYJ-LN9bgwRnir1ycks5uYwITgaJpZM4WfU5t>
>> .
>>
>
|
|
Or this
<https://www.tindie.com/products/onehorse/superfly-hackable-esp8266-flight-controller/>
...
On Fri, Sep 7, 2018 at 4:51 PM Tlera Corporation <tleracorp@gmail.com>
wrote:
… This
<https://www.tindie.com/products/TleraCorp/ladybug-flight-controller/>
would make a better choice for robot controller.
On Fri, Sep 7, 2018 at 4:45 PM Tlera Corporation ***@***.***>
wrote:
> Set the gyro and accel rates to 1 kHz and simply read both plus mag data
> (100 Hz) at the top of the loop. The important one is the gyro, this way
> the PID loop sees the freshest daya available, no interrupt or status
> register polling needed.
>
> On Fri, Sep 7, 2018 at 4:37 PM Tlera Corporation ***@***.***>
> wrote:
>
>> Set the gyro and accel sample rates to 1 kHz. You might need to use
>> something better than a poky AVR MCU...
>>
>> On Fri, Sep 7, 2018 at 4:32 PM MiloMindbender ***@***.***>
>> wrote:
>>
>>> My issue (and maybe this isn't really an issue) is if my main loop is
>>> 100hz and I set the IMU to 100hz they will gradually drift out of sync and
>>> the data available at the top of the loop could potentially be almost 10 ms
>>> old. If I turn the IMU to 200hz, then I only get a sample representative of
>>> the last 5ms and not the whole 10ms loop time.
>>>
>>> I could set the IMU to 100hz and sync the main loop to the interrupt
>>> but if I have more than one sensor that needs to be synced up, that doesn't
>>> work either.
>>>
>>> Maybe this doesn't matter to, I'm not sure. I'm just trying not to do
>>> anything stupid because getting a smooth balancing robot seems to have a
>>> lot to do with not having variable latency or jitter in your sensor data.
>>>
>>> Thanks for your help.
>>>
>>> —
>>> You are receiving this because you were mentioned.
>>> Reply to this email directly, view it on GitHub
>>> <#17 (comment)>,
>>> or mute the thread
>>> <https://github.com/notifications/unsubscribe-auth/AGY1qma_NiHiH4nkYJ-LN9bgwRnir1ycks5uYwITgaJpZM4WfU5t>
>>> .
>>>
>>
|
|
@kriswiner don't know if I was clear earlier, I'm using an ESP32 microcontroller 240hz dual core. Should be much faster than an AVR or 8266. I got your MPU9250_MS5637_AHRS code running on it but am having an issue with YAW similar to what I had with Sparkfun's code. I orient the board so the YAW reads 0, then rotate the board 90 degrees right and I get yaw 75, rotate 180 and I get 112, reorient the board the way it was and I go back to zero. pitch and roll both seem ok, turn them +- 90 and I get +- 90 on the output. Also, when I rotate the board in yaw, it seems to take several seconds to "settle" to a new stationary value. Pitch and roll seem to stop immediately when the board stops moving. Quaternions seem to be doing the same thing. Am I doing something wrong? Below is a sample before and after a 180 degree yaw.
|
|
Are you calibrating the sensors? How?
Are you feeding the sensor data into the fusion filter in NED order?
…On Mon, Sep 10, 2018 at 9:55 AM MiloMindbender ***@***.***> wrote:
@kriswiner <https://github.com/kriswiner> don't know if I was clear
earlier, I'm using an ESP32 microcontroller 240hz dual core. Should be much
faster than an AVR or 8266.
I got your MPU9250_MS5637_AHRS code running on it but am having an issue
with YAW similar to what I had with Sparkfun's code.
I orient the board so the YAW reads 0, then rotate the board 90 degrees
right and I get yaw 75, rotate 180 and I get 112, reorient the board the
way it was and I go back to zero.
pitch and roll both seem ok, turn them +- 90 and I get +- 90 on the output.
Also, when I rotate the board in yaw, it seems to take several seconds to
"settle" to a new stationary value. Pitch and roll seem to stop immediately
when the board stops moving.
Quaternions seem to be doing the same thing.
Am I doing something wrong?
Below is a sample before and after a 180 degree yaw.
ax = 0.92 ay = -3.48 az = 995.42 mg gx = -0.02 gy = 0.18 gz = -0.13 deg/s
mx = -27 my = 142 mz = 29 mG q0 = 0.99 qx = -0.00 qy = -0.00 qz = -0.13
Gyro temperature is 34.7 degrees C Digital temperature value = -827.59 C
Digital temperature value = -1457.66 F Digital pressure value = 31118.61
mbar Altitude = -133550.08 feet Yaw, Pitch, Roll: 358.37, -0.10, -0.26
Grav_x, Grav_y, Grav_z: 4.48, -1.77, 999.99 mg Lin_ax, Lin_ay, Lin_az:
-3.57, -1.71, -4.57 mg sumCount = 1010 sum = 0.54 rate = 1856.52 Hz
After 180 degree rotation
ax = -21.97 ay = -26.25 az = 994.38 mg gx = 0.05 gy = 0.14 gz = -0.08
deg/s mx = 589 my = -61 mz = 48 mG q0 = 0.64 qx = 0.00 qy = -0.02 qz = 0.76
Gyro temperature is 34.9 degrees C Digital temperature value = -826.46 C
Digital temperature value = -1455.63 F Digital pressure value = 30847.15
mbar Altitude = -133085.45 feet Yaw, Pitch, Roll: 113.53, -1.80, -1.64
Grav_x, Grav_y, Grav_z: 28.54, -31.41, 999.10 mg Lin_ax, Lin_ay, Lin_az:
-50.51, 5.17, -4.71 mg sumCount = 1000 sum = 0.54 rate = 1834.88 Hz
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qj1Xr_NXXXmmHgz-mpieR9inmw19ks5uZpl1gaJpZM4WfU5t>
.
|
|
I'm just running your MPU9250_MS5637_AHRS code and doing the mag calibration that's included. I haven't changed anything else. Do I need to do separate accel/gyro calibration? I'm not looking for perfect true-north accuracy. |
|
The sketches are not black boxes, you need to calibrate your sensors and
know what you are doing...
And the sensor data order in the fusion filter? This is likely wrong.
…On Mon, Sep 10, 2018 at 10:06 AM MiloMindbender ***@***.***> wrote:
I'm just running your MPU9250_MS5637_AHRS code and doing the mag
calibration that's included. I haven't changed anything else.
Do I need to do separate accel/gyro calibration? I'm not looking for
perfect true-north accuracy.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qgVzTGPoZX58j8HTdceVC9n6NEflks5uZpwggaJpZM4WfU5t>
.
|
|
Honestly sorry if I'm being a pain. I was under the impression that the sketch was basic example of doing it correctly but you seem to be saying sensor data order is wrong and I shouldn't expect correct results? I'll do some more reading, maybe I can figure it out. By the way, my setup has the chip oriented flat on the board with the z axis pointed up. I thought that would match your sketch. Also not sure what you mean by NED order? |
|
You'll need to calibrate your sensors well to have any hope of getting
accurate results. How do you know when the sensors are calibrated?
https://github.com/kriswiner/MPU6050/wiki/Simple-and-Effective-Magnetometer-Calibration
The Madgwick or Mahony filters expect to receive the sensor data in North,
East. Down order. Choose which direction is to be North for your board.
Which accel axis is aligned with board North? East? Down? Now same for gyro
and mag, this is the order to feed the fusion filter, AN, AE, AD, GN, GE,
GD, MN, ME, MD.
Poor calibration and incorrect sensor order cover 99% of the causes of poor
absolute orientation results.
If your yaw is laggy, and the calibration and sensor order are correct, I
would increase the accel/gyro sample rates to 1 kHz and make sure the
fusion filter is iterated at least 10 times for each new data sample.
…On Mon, Sep 10, 2018 at 10:33 AM MiloMindbender ***@***.***> wrote:
Honestly sorry if I'm being a pain. I was under the impression that the
sketch was basic example of doing it correctly but you seem to be saying
sensor data order is wrong and I shouldn't expect correct results?
I'll do some more reading, maybe I can figure it out.
By the way, my setup has the chip oriented flat on the board with the z
axis pointed up. I thought that would match your sketch. Also not sure what
you mean by NED order?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qm2TK7cKaIyDz00n6o725mlfUWccks5uZqJLgaJpZM4WfU5t>
.
|
|
Thanks @kriswiner I understand your terms now, but not why it isn't working.... According to my PCB stencil I am in NED order X north, Y east, Z down. I'm double checking the signs of the data but at least the axis is correct (unless the stencil on the board is wrong) and that's the way your MPU9250_MS5637_AHRS (from this repo) sample seems to be feeding them into MadgwickQuaternionUpdate. Your sample also seems to iterate MadgwickQuaternionUpdate 10 times on each read of the IMU and it calls your magcalMPU9250 to calibrate the magnetometer at the start of the sketch by waving the board in figure 8 patterns. Your sketch has mmode set to 0x06 (100hz) for the mag and while I'm not entirely certain, it looks like the gyro/accel are set to 1khz . So does this sound like things are setup as you described above? With the board x pointed at magnetic north, the yaw reads 73 degrees. Every time I re-do the mag calibration the bias numbers are significantly different while the scales are about the same. The accel and gyro biases are always pretty close. I could understand north not reading as yaw 0, I don't understand a 180 degree rotation reading as 130 degrees. Have I missed a step? If I understand you right this sample is calibrating the mag and doing the other stuff right. MPU9250 9-axis motion sensor... |
|
mx = -48 my = 81 mz = -128 mG
this cannot be correct. Average magnetic field at Earth's surface is 0.5
Gauss...
I dont think you are roperly calibrating the mag. Check the calibration by
plotting Mx vs My, Mx vs. Mz, and My vs, Mz measured while moving the
sensor in a figure eight. Are they circular clouds centered on the origin?
By the way, figure eight means all aroubnd evry which way in all three
dimensions.
…On Mon, Sep 10, 2018 at 11:52 AM MiloMindbender ***@***.***> wrote:
Thanks @kriswiner <https://github.com/kriswiner> I understand your terms
now, but not why it isn't working....
According to my PCB stencil I am in NED order X north, Y east, Z down. I'm
double checking the signs of the data but at least the axis is correct
(unless the stencil on the board is wrong) and that's the way your
MPU9250_MS5637_AHRS (from this repo) sample seems to be feeding them into
MadgwickQuaternionUpdate.
Your sample also seems to iterate MadgwickQuaternionUpdate 10 times on
each read of the IMU and it calls your magcalMPU9250 to calibrate the
magnetometer at the start of the sketch by waving the board in figure 8
patterns.
Your sketch has mmode set to 0x06 (100hz) for the mag and while I'm not
entirely certain, it looks like the gyro/accel are set to 1khz .
So does this sound like things are setup as you described above?
With the board x pointed at magnetic north, the yaw reads 73 degrees.
Every time I re-do the mag calibration the bias numbers are significantly
different while the scales are about the same. The accel and gyro biases
are always pretty close.
I could understand north not reading as yaw 0, I don't understand a 180
degree rotation reading as 130 degrees.
Have I missed a step? If I understand you right this sample is calibrating
the mag and doing the other stuff right.
MPU9250 9-axis motion sensor...
MPU9250 I AM 71 I should be 71
MPU9250 is online...
x-axis self test: acceleration trim within : 1.0% of factory value
y-axis self test: acceleration trim within : 0.1% of factory value
z-axis self test: acceleration trim within : 1.8% of factory value
x-axis self test: gyration trim within : -4.1% of factory value
y-axis self test: gyration trim within : -0.4% of factory value
z-axis self test: gyration trim within : 0.9% of factory value
Calibrate gyro and accel
accel biases (mg)
35.16
0.92
22.40
gyro biases (dps)
-1.81
1.92
-0.54
MPU9250 initialized for active data mode....
AK8963 I AM 48 I should be 48
AK8963 initialized for active data mode....
Mag Calibration: Wave device in a figure eight until done!
Mag Calibration done!
AK8963 mag biases (mG)
-94.41
-10.89
47.44
AK8963 mag scale (mG)
1.57
0.71
1.04
X-Axis sensitivity adjustment value 1.21
Y-Axis sensitivity adjustment value 1.21
Z-Axis sensitivity adjustment value 1.17
MS5637 pressure sensor reset...
PROM dta read:
C0 = 50431
C1 = 50431
C2 = 50431
C3 = 50431
C4 = 50431
C5 = 50431
C6 = 50431
Checksum = 4 , should be 12
ax = 4.21 ay = 1.22 az = 990.54 mg
gx = 0.18 gy = 0.13 gz = -0.07 deg/s
mx = -48 my = 81 mz = -128 mG
q0 = 0.40 qx = -0.71 qy = -0.20 qz = -0.54
Gyro temperature is 33.9 degrees C
Digital temperature value = -689.91 C
Digital temperature value = -1209.83 F
Digital pressure value = 22063.12 mbar
Altitude = -115882.60 feet
Yaw, Pitch, Roll: 348.74, -68.06, -103.77
Grav_x, Grav_y, Grav_z: 362.85, -927.60, -88.91 mg
Lin_ax, Lin_ay, Lin_az: -358.64, 928.82, 1079.45 mg
sumCount = 10
sum = 38.31
rate = 0.26 Hz
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qrsGFmIPGWKzyxxGx61cjgw_C--Kks5uZrUIgaJpZM4WfU5t>
.
|
|
That comment may have solved the problem, I just noticed that when I point the thing north (and it reads 41 deg yaw) and then raise it about 3 feet off my desk. The yaw goes to zero, it takes a few seconds, but it goes. Also, the mx value goes from about 124 on the desk to -60 3 foot above while Y and Z stay about the same. My desk is all wood, but it seems there is a magnetic anomaly there somewhere. If I plot a vector from the mx/my/mz would it be pointing in the direction of the strongest magnetic field (or north)? (so I could use it to track down the anomaly). Is there a range of mx,my,mz or calibration values that would definitely be out of the normal range? |
|
Check the expected value of MX, MY, MZ for your area from the USGS or
equivalent
…On Mon, Sep 10, 2018 at 1:23 PM MiloMindbender ***@***.***> wrote:
That comment may have solved the problem, I just noticed that when I point
the thing north (and it reads 41 deg yaw) and then raise it about 3 feet
off my desk. The yaw goes to zero, it takes a few seconds, but it goes.
Also, the mx value goes from about 124 on the desk to -60 3 foot above
while Y and Z stay about the same.
My desk is all wood, but it seems there is a magnetic anomaly there
somewhere.
If I plot a vector from the mx/my/mz would it be pointing in the direction
of the strongest magnetic field (or north)? (so I could use it to track
down the anomaly).
Is there a range of mx,my,mz or calibration values that would definitely
be out of the normal range?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qkeNtum1-bR8r_-vGNDs39fLZ7_iks5uZspVgaJpZM4WfU5t>
.
|
@kriswiner I'm a little confused looking at your ESP32 repository and your MPU9250 repository.
I'm using a Sparkfun 9250 breakout (https://www.sparkfun.com/products/13762) and an Adafruit Feather ESP32 board.
Between these two repositories you have a number of MPU9250 sketches and I'm a bit confused about which one is most appropriate for the setup I'm running. I'm looking to get sensor fusion for a balancing robot.
My robot runs it's main loop every 10ms and I want to get/fuse "latest" data from the sensor at the top of the loop.
I've tried sparkfun's 9250 repositories but theirs all seem broken in some way.
The text was updated successfully, but these errors were encountered: