Hi Brian, of course I noticed the terminal messages. A couple of times telling me "switch". I coded a calibration routine for the 9250 as well - quite dumb with instructions how to position the sensor. I suspected in your calibration must be some magic that does the calibration without positioning the sensor. Have the impression just switching the light on and off does the trick. (please don't take my comment too serious).
By the way - why six times ? x-axis positive/negative etc ? I did three measurements - one for each axis, positive or negative did not matter.
To what extent does the accuracy of calibrateAccel depend on how well/accurately I position the IMU relative to the true vertical, and for each of the 6 axis positions? This strikes me as the achilles heel, but maybe your routine is smarter than I realise.
9.807*sin(angle, rad)
(min + max) / 2
9.807/((abs(min) + abs(max)) / 2)
Eventually, I'd like to do something like a gauss newton sphere fitting model, but I was running into other error sources for that, so for now I'm just using the min and max values measured in each axis.
mjs513 / brtaylor:
To get my onehorse bottom mounted i2c MPU9250 to work on T_3.6 it uses Wire and works with: MPU9250 IMU(Wire,0x69, 47, 48); // Set scl=47 and sda=48 { he just restocked these so they are in production }
I edited the MPU9250 to allow this : MPU9250(TwoWire &bus,uint8_t address,uint8_t sclPin=255,uint8_t sdaPin=255);
Since that works on Wire with setSCl and setSDA I have working changes and was going to offer a pull request.
Then I saw the mjs513 fork that changes to i2c_t3 for Teensy - this likely would be better in long run.
Brian - do you anticipate altering your 'master' branch one way or another - or should I fork mjs513?
I've got the GPS PPS on interrupt giving cycle counter resolution for TIME_STAMP for GPS Serial start bit and was going to do the same for the MPU9250 i2c interrupt - now that I found my T_3.6 with the 9250 soldered on.
As long as (typically unused) cycle counter is not zeroed elsewhere - it is perhaps 99.8% in +/- 13 cpu ticks (in 55 hr run) - and the math/return is over 6X faster than micros
MPU9250 IMU(Wire,0x68);
void setup() {
Wire.setSCL(47);
Wire.setSDA(48);
IMU.begin();
}
H Brian,
First, thanks for your excellent library...
I'm finalizing a wireless system ( teensy 3.6 / esp8266 combo ) for medical study (ergonomics / fatigue) that has besides a 9250 a whole bunch of other sensors. Currently I'm looking into methods to prevent magnetic jamming.
( quite a bit of devices with magnets around )
Got some questions.
Do you have any plans to incorporate a magnetic anti jamming filter?
> mjs513 suggested a UKF filter > relevant thread here: https://forum.pjrc.com/threads/33902-Prop-Shield-NXPSensorFusion-observations
more reading : Accurate Orientation Estimation Using AHRS under Conditions of Magnetic Distortion / Unscented Kalman Filter and Magnetic Angular Rate Update (MARU) for an Improved Pedestrian Dead-Reckoning
> macaba has a working anti jamming filter > forked from Paul's MadgwickAHRS > https://github.com/macaba/MadgwickAHRS
I've made a couple of modifications to your library, that allows it to
A.) compile it for an esp8266
B.) disable SPI dependencies entirely, > I'm using SPI slave mode on the teensy...
What I'm actually doing is, using a bunch of esp8266's to gather data send it to another esp8266 that offloads it to a teensy over SPI for number crunching.
Forking your library will just add Yet Another 9250 lib tm , become obsolete etc... while it's really just a couple of defines, maybe you can commit them yourself, I'll contact you on github for that...
Thanks
...........With me opening up the library to Arduino devices other than Teensy, I'm seeing a lot of the little differences and non-standard things that different boards are doing. The more fixes I can incorporate for these different boards, the better it is for everyone......
exactly....
Give me a couple of days to review your latest commits > got some test subjects over ... hence no coding for me today.
WRT = ?
Question: T_3.6 Compiled beyond 'FAST' my i2c MPU9250 only works (fails init) at 240 MHz when I hacked the core F_BUS from 60 to 120 MHZ (noted here). Is anyone else running at 240 MHz with i2c MPU?
It may be my onehorse unit - or it's use of ALT i2c pins. I can see perhaps SPI in any case would not be affected the same.
[and that I've been using 240 MHz no issues since T_3.6 beta, and often changing to F_BUS 120 with good effect]
Question: T_3.6 Compiled beyond 'FAST' my i2c MPU9250 only works (fails init) at 240 MHz when I hacked the core F_BUS from 60 to 120 MHZ (noted here). Is anyone else running at 240 MHz with i2c MPU?
It may be my onehorse unit - or it's use of ALT i2c pins. I can see perhaps SPI in any case would not be affected the same.
[and that I've been using 240 MHz no issues since T_3.6 beta, and often changing to F_BUS 120 with good effect]
Whoa, I can reproduce that issue with the emsensor breakout board and the default I2C Wire pins (18 and 19). Like you said, works great except for:
CPU speed set to 240 MHz
default F_BUS (60 MHz)
optimization of faster or faster with LTO
I'm getting a return code of -5, which means it's failing the WHOAMI check.
#define IMU_SPD 1000000
status = Imu.begin();
if ( 0 != IMU_SPD ) Wire.setClock(IMU_SPD);
Weird, I just tried this with i2c_t3 instead of the standard Wire library and, no issues.
Good to know. We'd have to write a short test to WHO_AM_I that can run on either Wire or i2c_t3 and post for Paul to resolve. I suppose you are using default pins, not an ALT like me? May be something off in the pin config in Wire?
#include "MPU9250.h"
#define IMU_ADDR 0x69 // 0x68
#define IMU_SCL 0 // 47 // 0x255 to use default
#define IMU_SDA 0 // 48 // 0x255 to use default
#define IMU_SPD 0 // 1000000 // 0==NULL or other
// an MPU9250 object with the MPU-9250 sensor on I2C bus 0 with address IMU_ADDR
MPU9250 IMU(Wire, IMU_ADDR);
int status;
void setup() {
Serial.begin(115200);
while (!Serial) {}
Serial.println("\n"__FILE__" "__DATE__" "__TIME__);
Serial.print("F_CPU >> ");
Serial.print(F_CPU);
Serial.print(" F_BUS >> ");
Serial.println(F_BUS);
// start communication with IMU
if ( 255 != IMU_SCL ) Wire.setSCL(IMU_SCL);
if ( 255 != IMU_SDA ) Wire.setSDA(IMU_SDA);
status = IMU.begin();
if ( 0 != IMU_SPD ) {
Wire.setClock(IMU_SPD);
Serial.print("Wire Speed setClock ");
Serial.println(IMU_SPD);
} else Serial.println("Default Wire Speed");
if (status < 0) {
Serial.println("IMU initialization unsuccessful");
Serial.println("Check IMU wiring or try cycling power");
Serial.print("Status: ");
Serial.println(status);
while (1) {}
}
}
void loop() {
IMU.readSensor();
Serial.print("TEMP == ");
Serial.println(IMU.getTemperature_C(), 6);
Serial.println("\n IT WORKED !!");
delay(100);
while (1) {}
}
>>> COMPILED FAST
T:\tCode\Temp\T_i2c_Fail\T_i2c_Fail.ino Jan 25 2018 23:32:56
F_CPU >> 240000000 F_BUS >> 60000000
Default Wire Speed
TEMP == 35.266033
IT WORKED !!
>>> COMPILED FASTEST
T:\tCode\Temp\T_i2c_Fail\T_i2c_Fail.ino Jan 25 2018 23:34:54
F_CPU >> 240000000 F_BUS >> 60000000
Default Wire Speed
IMU initialization unsuccessful
Check IMU wiring or try cycling power
Status: -5
>>> COMPILED FASTEST
T:\tCode\Temp\T_i2c_Fail\T_i2c_Fail.ino Jan 25 2018 23:37:20
F_CPU >> 240000000 F_BUS >> 120000000
Default Wire Speed
TEMP == 34.888641
IT WORKED !!