This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Free 3D RealTime graphic AHRS for SensorHub + DCM Algorithm validation

RECOMMENDATION: TI Sensorhub Boosterpack is not working properly as a reliable IMU device because of TI library. So if you planned to work with it, I would wait until somebody fix it.


Hello all.

I have started to play with my recently arrived BOOSTXL-SENSHUB,I have been running the examples and trying to understand the data that the 9-axis Motion Sensor MPU-9150 provides.

In specific I have been using the airmouse example and the compdcm_mpu9150 example. Both are a great way to get the data but I find it not very intuitive for a fresh starter.

So, I decided to get some info and stuck some Processing sketches and try to build a simple AHRS ( http://en.wikipedia.org/wiki/Attitude_and_heading_reference_system ) for the Sensor Hub and sharing it.

The result is something like this:

.............................................

Thanks to the decision of TI of not supporting this device and my effort + time....I decided to not provide that information in this forum.

Sorry about any inconvenience.

SENSORHUB_3D_SKETCH.rar
  • I am seeing different behaviour with two different sensor hubs made in the same LOT??

    Is there any calibration procedure? Any test I could do to check the data from the sensor is correct?

    Thanks

  • Should your requested calibration data/procedure not be readily provided - might the full data sheets from sensor vendors provide such detail - or link to clarifying Ap Notes etc?  

    Your report confirms the value of "most always" procuring two (or more) of a new device - which enables "A-B" testing.  Minus that comparative test - you'd have been unlikely to note the discrepancy you report.

    Having two systems suggests that you may be able to harvest valid data & relationships - when/where the "A-B" data overlaps/aligns.  Via this examination you may be able to identify the trouble-source via, "process of elimination."

    Many reasonably sophisticated such sensors do provide the set-up & calibration data you seek.  May have been "bit much detail" for kit inclusion - the originating source often provides more detailed guidance...

  • cb1_mobile said:

    Should your requested calibration data/procedure not be readily provided - might the full data sheets from sensor vendors provide such detail - or link to clarifying Ap Notes etc?  

    Your report confirms the value of "most always" procuring two (or more) of a new device - which enables "A-B" testing.  Minus that comparative test - you'd have been unlikely to note the discrepancy you report.

    Having two systems suggests that you may be able to harvest valid data & relationships - when/where the "A-B" data overlaps/aligns.  Via this examination you may be able to identify the trouble-source via, "process of elimination."

    Many reasonably sophisticated such sensors do provide the set-up & calibration data you seek.  May have been "bit much detail" for kit inclusion - the originating source often provides more detailed guidance...

    Agree with you, but wouldn't TI, which is the vendor I bought the Sensor Hub, may provide a way to test (and calibrate if needed) this hardware?

    I am still waiting some answer from them!!

    Thank you.

  • Bump!!

    The sketch working iwth the Tiva Launchpad is very similar to this video:

    VIDEO of IMU Razor 9DOF AHRS

  • Ok.

    I realized that Roll and Pitch data are ok. The problem comes with the Yaw axis.... any idea??

  • My Yaw only varies over about 15-20% of the range and is sinusoidal rather that linear over the range.  I have a rotary platform with protractor that I use for calibration. Did you or anyone ever have any luck with theirs?

  • I'm sorry but we don't have a solution for calibration yet.  We're working on it, but I don't have a timeline for you.

  • Eric Ocasio said:

    I'm sorry but we don't have a solution for calibration yet.  We're working on it, but I don't have a timeline for you.

    Then TI is selling someting that does not work as TI claims.... I would like to get my money back.  it working!!!

  • I cannot stand with having a non working hardware hardware because of a vendor library I need the SensorHub working to get finished a prototype before production.

    COuld you please give an estimation on time about this fix?

    Thank you

  • Anything new on this issue?

  • Unfortunately no.  This isn't on the top of the list right now, so my guess is that it's probably a few months out.  

  • I got the same problem with this fusion result !

    Yaw is always connected with Roll & Pitch no matter what I static the Z-axis...

    Any master or TI fix it yet? 

  • JackRose Kuo said:

    I got the same problem with this fusion result !

    Yaw is always connected with Roll & Pitch no matter what I static the Z-axis...

    Any master or TI fix it yet? 

    Since TI is not providing any help here, I have opened a post in Invensense forum (you need to register to read it).

    http://www.invensense.com/developers/forum/viewtopic.php?f=3&t=895

    It seems that TI copied an implemetation of the the complementary DCM code made by William Premerlani, who was not aware of the standard used in the aviation industry, so Roll, Yaw and Pitch are referenced to the ground, not the device axis. So the results are different from many other libraries which get the work done perfectly and simple.

    We are going to compare the data provided by the IMU against the Eurles/Quatertions TI's library output data.

    Besides, Quaternions data from Eulers is slightly different (scrambled) from what it should be.


    Actually, I don't know what happens in this forum lasly, but I see few to no help provided by TI members. I am aware that probably these guys are loaded with tons of work, and it is not their fault, but this is not the way to go.

    Many members are expressing the same in other posts within this forum, i.e. some people asking for CMSIS after some months, another asking for some TM4C129X info, or this post!!!

    As   has told me (many times), probably is not wise "to bite the hand that feeds you" as in not getting tech support from TI staff when a hard issue arrives, but I think this is a two way road....our hands also feed their sales/bank account balances, synergy on their forums, knowledge and community.

    As someone said yesterday:

     "...certain something that contributes in turning a potentially dry vendor support forum into a living and breathing online community"

    Nailed it!!


  • Perhaps deserves mention - this reporter "suggested" (i.e. hounded) friend PAk SY (privately) into, "going directly to the sensor source - when "intermediate" is not fully responsive."  And - data gleaned/presented here - appears to validate that suggestion...

    No forum is perfect - yet this one long stands, "atop the mount" in terms of skilled, caring vendor support...

    Developing quick, efficient means - to find and utilize needed data - is a valuable skill.  When a pipeline, "clogs" - redirection to a suitable one, nearby - often restores, "flow."  

  • cb1_mobile said:
    Perhaps deserves mention - this reporter "suggested" (i.e. hounded) friend PAk SY (privately) into, "going directly to the sensor source - when "intermediate" is not fully responsive."  And - data gleaned/presented here - appears to validate that suggestion...

    As you can seee, I followed your suggestion. It is worth to say that sensor vendor, has not answered yet, but some member of that forum willing to help, ala cb1_mobile in this forum   ;-) .

    cb1_mobile said:
    No forum is perfect - yet this one long stands, "atop the mount" in terms of skilled, caring vendor support...

    No doubt, but, at least in Europe, the forum is the only tech help we can get from TI. I tried several times contact with them and I have always been refered to USA TI support....so it is kind of a circle of no support.

    cb1_mobile said:
    Developing quick, efficient means - to find and utilize needed data - is a valuable skill.  When a pipeline, "clogs" - redirection to a suitable one, nearby - often restores, "flow." 

    Probably the owner of the wheel could push a little to easy the flow!!


    Thanks again for your support and interest cb1. Pleasure to have people like you in this forum.

  • Please make the following changes to the dcm_comp.c code and report SensorHub performance:

    CompDCMStart(tCompDCM *psDCM)
    {....
        // The accelerometer reading forms the initial K vector, pointing down.
       //  Note that pfAccel[2] is negative in level flight
        pfK[0] = - psDCM->pfAccel[0];
        pfK[1] = - psDCM->pfAccel[1];
        pfK[2] = - psDCM->pfAccel[2];
    CompDCMUpdate(tCompDCM *psDCM)
    {........
        // The accelerometer reading forms the new Ka vector, pointing down.
        // ]Note that pfAccel[2] is negative in level flight
        pfK[0] = - psDCM->pfAccel[0];
        pfK[1] = - psDCM->pfAccel[1];
        pfK[2] = - psDCM->pfAccel[2];

    [cleanup, 11/26/2013] and lines 384/38

        VectorAdd(psDCM->ppfDCM[0], psDCM->ppfDCM[0], pfI);//corrected, was pfK
        VectorAdd(psDCM->ppfDCM[2], psDCM->ppfDCM[2], pfK);//corrected, was pfI

    Explanation for sign changes: The algorithm originator (W. Premerian) chose Zenith(Up) for the positive K vector direction with both body Z axis and accelerometer Z axis initially aligned with Zenith, so he defined K=-A. TI tried to implement the conventional aircraft coordinates with K pointing down; however, the accelerometer is also pointing down so the net result is unchanged and K=-A for conventional aircraft coordinates as well.

    The code was tested for sensor axes aligned with body axes;magnetometer axes may need to be transformedfrom sensor axes to body axes per InvenSense MPU9150 Product Spec. (Magx->Magy,Magy->Magx,Magz->-Magz) In level flight with zero roll, pitch and yaw angles SensorHub board will need to be upside down with x-axis pointing North and z-axis pointing down.

    I have no SensorHub and have only tested the code (translated to Python) for prescribed values for pfData. The DCM algorithm, Eulers and Quaternions were checked based on these refs.

    http://www.starlino.com/wp-content/uploads/data/dcm_tutorial/Starlino_DCM_Tutorial_01.pdf

    http://forums.robotstudio.com/discussion/8031/convert-euler-angles-to-quaternions

    Thanks

  • @ Anthony,

    What a job - much appreciated - many thank you!

    Suspect that you're allied w/near sensor supplier.  I often suggested to poster PAk SY that directing his detailed use/info request, "closer to the real source" may yield quicker results.  Appears to (once again) have worked...

    Not only did you answer - your descriptions & application guidance appear of great value and provide much comfort.  Again thanks for making the time/effort to enhance the usability of this product for many here...

  • No problem. I have the InvenSense SDK5.1 with TI MSP430 but have not yet invested in the full CCS to customize it; I might even investigate the purchase of a SensorHub if someone can confirm my findings.

  • Great job Anthony!! Thank you for your effort.

    I am using library version 1.1 (don't have v2 installed yet).

    I have made the changes you suggested and I found these measures. I am assuming you wanted to change both CompDCMStart and CompDCMUpdate in your code

    Anthony Challoner said:
    CompDCMUPDATE(tCompDCM *psDCM) {.... // The accelerometer reading forms the initial K vector, pointing down. // Note that pfAccel[2] is negative in level flight pfK[0] = - psDCM->pfAccel[0]; pfK[1] = - psDCM->pfAccel[1]; pfK[2] = - psDCM->pfAccel[2];

    - If I let the sensor stand on a flat surface finding the 0 of yaw:

    - If I  put the sensor standing on a flat surface, pointing the X axis to the screen:

    - If I  put the sensor standing on a flat surface, pointing the Y axis to the screen:

    - If I  put the sensor standing on a flat surface, pointing the Z axis to the screen and X to the floor:

    - If I  put the sensor standing on a flat surface, pointing the Z axis to the screen and Y to the ceiling!!:

    I haven't changed weights or any other data (as you said in the invensense forum thread).

    If I use the sketch, the board is drawn with erratic move.

    Note: I have corrected the original compdcm_mpu9150.c filein the first answer of this post. It was not working with the sketch, now it should.

    Note2: This is my final C:\TivaWare_C_Series-1.1\sensorlib\comp_dcm.c file

    ........

    Thanks to the decision of TI of not supporting this device and my effort + time....I decided to not provide that information in this forum.

    Sorry about any inconvenience.

  • To show the drift I am seeing here are some videos with poor quality:

    - X pointing to screen:

    http://youtu.be/mffsWtfMavE

    - Y pointing to screen:

    http://youtu.be/-9HI317abOs

    - Z pointing to screen, X to floor:

    http://youtu.be/TobjG_10QCE

    - Z pointing to screen, X to ceiling:

    http://youtu.be/Alh_tyNyYSM

  • You are correct. I meant to paste in the same code correction for CompDCMUpdate() as well as CompDCMStart. It is important that both be updated.

    Thanks for the measurements with non-zero gyro weighting. I will review and get back to you. There is the issue of magnetometer hard and soft iron calibration and practical performance of this type of algorithm with dynamics and gyro updating. One step at a time is desirable.

    Meanwhile to help build confidence see if your static hardware results with zero gyro weighting lock to the following code test result. (Your screen format has the information needed; try to arrange (or else force) similar magnetometer(X,Y) and accel Z values. Repeat the Yaw zero case if needed to get oriented.)

    Forced raw sensor values:
    Psi, theta, phi(deg):  90 , 0 , 0  CCW rotation about aircraft yaw axis
    Mag   (tesla):  [0.0, -3e-05, 5e-05]  Earth field in body after yaw rotation, Psi
    Accel (m/s^2):  [0.0, 0.0, -9.8]  Raw accel output in level flight
    fDeltaT=0.02;pfScaleA=0.5;pfScaleM=0.5;pfScaleG=0; 
    
    After executiion of CompDCMInit,CompDCMStart,CompDCMUpdate:
    DCM: 
    [0.000, -1.000, 0.000]
    [1.000, 0.000, -0.000]
    [0.000, 0.000, 1.000]
    
    Confirming 3264.compdcm_mpu9150.c Eulers,Quaternions & print outs:
    Accel
    0.0
    0.0
    -9.800
    Gyro
    0.0
    0.0
    0.0
    Mag
    0.0
    -30.0
    50.0
    Eulers
    0.0
    0.0
    90.0
    Quaternions
    0.707
    0.0
    0.0
    0.707
  • just can't got similar result as static hardware with zero gyro weighting lock ...

    I modified the CompDCMUpdate() as well as CompDCMStart for Accel data, and CompDCMMagnetoUpdate(&g_sCompDCMInst, pfMagY, pfMagX, -pfMagZ); shows the rotation here.

    You can see, the rotation is terrible and shake after several movements...

    if I change this code back the original, the shake won't happen...roll, pitch won't drift.

    http://youtu.be/84mTcW-IrQU

    1
    2
    VectorAdd(psDCM->ppfDCM[0], psDCM->ppfDCM[0], pfI);//corrected, was pfK
    VectorAdd(psDCM->ppfDCM[2], psDCM->ppfDCM[2], pfK);//corrected, was pfI


  • Anthony Challoner said:

    Meanwhile to help build confidence see if your static hardware results with zero gyro weighting lock to the following code test result. (Your screen format has the information needed; try to arrange (or else force) similar magnetometer(X,Y) and accel Z values. Repeat the Yaw zero case if needed to get oriented.)

    Forced raw sensor values:
    Psi, theta, phi(deg):  90 , 0 , 0  CCW rotation about aircraft yaw axis
    Mag   (tesla):  [0.0, -3e-05, 5e-05]  Earth field in body after yaw rotation, Psi
    Accel (m/s^2):  [0.0, 0.0, -9.8]  Raw accel output in level flight
    fDeltaT=0.02;pfScaleA=0.5;pfScaleM=0.5;pfScaleG=0; 

    If I do that, [plus:   CompDCMInit(&g_sCompDCMInst, 1.0f / 50.0f, 0.5f, 0.0f, 0.5f); ],

    I get this:

    Accel, gyro and Mag values are changing, but Eulers and Q are fixed. This is because I am calling MPU9150DataMagnetoGetFloat, MPU9150DataGyroGetFloat and MPU9150DataAccelGetFloat, and after that, I call:

    	    CompDCMMagnetoUpdate(&g_sCompDCMInst, 0.0, -3e-05, 5e-05);
    	    CompDCMAccelUpdate(&g_sCompDCMInst, 0, 0, -9.8);
    	    CompDCMGyroUpdate(&g_sCompDCMInst, 90, 0, 0);
    

    NOTE:  If I do (before calling MPU9150DataMagnetoGetFloat, MPU9150DataGyroGetFloat and MPU9150DataAccelGetFloat) :

    	pfData[0]=0;
    	pfData[1]=0;
    	pfData[2]=-9.8;
    
    	pfData[3]=90;
    	pfData[4]=0;
    	pfData[5]=0;
    
    	pfData[6]=0;
    	pfData[7]= -3e-05;
    	pfData[8]=5e-05;

    I can't get the Euler and Q fixed.

    Is there something wrong in that?

    If I remove those (MPU9150DataMagnetoGetFloat, etc...) calls I get:

    Note 2: I think gyro should be printed as 

    Gyro
    90.0  0.0   0.0 
    from your values: Psi, theta, phi(deg):  90 , 0 , 0  CCW rotation about aircraft yaw axis
  • Thanks for all of your responses. The video and screen feedback is good and well worth the effort. I do get that we all have different viewpoints on what is wrong. Especially, me because I have to fly this wobbly plane with your help via "ground control".The oscillatory or erratic behavior is very disconcerting I agree, but I know it will go away once we attend to the basics.Now that we have confidence in the algorithm implementation we need to check signal polarity (MSB) and noise (LSB's) end to end for each sensor and each axis. You have been dropped into a fairly complex integrated system without needed confidence that the key pieces are individually working as expected.

    A few comments on what we have so far.

    1) My purpose in getting the static picture correct including all magnitudes polarities is that oscillatory behavior can be the result of incorrect polarity or inconsistent polarity between the gyro and magnetometer for instance. For the static case the gyro output is essentially zero - it measures rotation rate, not orientation - so we will need a defined rotation to check its polarity. That will come. So to answer PakSy , the last screen shot was great but the gyro output should be 0 not 90.

    2)There is more to digest with PakSy's different screen shot conditions about upstream issues with sensor update routines. I will get back to you.

    3) Compass calibration: you all should find your building on Google and identify the North-South wall in your building. I did this and with full zoom I believe two of my walls are aligned N-S within less than a few degrees - likely well within compass accuracy..So I will flip on my SDK/MPS430 and report what I find. I will also note the noise and project what that would mean for display heading variation.  Also since TI work on compass calibration for hard and soft iron is even referenced by InvenSense I am amazed it is not built in to this code. It should be added, but I can't yet see that causing an unstable static display as witnessed by the videos.

    4) I don't have videos of the InvenSense SDK/MPS430 Python cube display but it is much smoother and consistent with individual sensor performance. I have modified the Python client to get an oscilloscope display of magnetometer, gyro, accelerometer or heading outputs via Bluetooth with the fixed InvenSense build. I'll see if I can demo the DCM algorithm online or certainly offline. Unfortunately the 16-bit MPS430 is firm-coded and the limited CCS demo version I have is only good for viewing code. The 32-bit SensorHub and TI library certainly looks much more attractive for AHRS or navigation development.

    So there is a bit more work ahead, for me at least, so I appreciate your continued interest and support.

  • Thanks again Anthony, outstanding work here.

    Anthony Challoner said:
    1) .... So to answer PakSy , the last screen shot was great but the gyro output should be 0 not 90.

    Then, why I am seing 90 degrees. Am I doing something wrong?

    Anthony Challoner said:
    4)  ... Unfortunately the 16-bit MPS430 is firm-coded and the limited CCS demo version I have is only good for viewing code. The 32-bit SensorHub and TI library certainly looks much more attractive for AHRS or navigation development.

    CCS is free for Tiva 123X devices so you can get inside the issue easily.

    I would like Texas to consider give a free Sensor Hub BoosterPack and Tiva™ C Series TM4C123G LaunchPad Bundle  to this man, for the work and results he is achieving. Probably he will save some good work to TI engineers.

    https://estore.ti.com/Sensor-Hub-BoosterPack-and-Tiva-C-Series-TM4C123G-LaunchPad-Bundle-P4538.aspx

    If TI doesn't, I would not mind to create a paypal donation and contribute to buy you one bundle.

  • Aha. So it wasn't your  finger on the 90 deg gyro display !  As I said I want to investigate your results further.

    Thanks for the suggestions. This TI plane would  likely get to its destination sooner if I could also be on board!  And there are a lot more places I we could visit from there !

  • Well, well. It seems that in the TI code (not my Python translation) pfData and the Euler and Quaternions printout is not updated by the DCM algorithm as I had thought. Yet the Eulers and Quaternions are computed from the DCM algorithm and that is what I print out. So in the screen print I believe you are getting the Eulers and Quaternions computed on board the InvenSense MPU9150 ? A bit confusing to say the least. Now I have to wonder what is driving your displays.[Late note: This understanding is wrong. pfData, pfAccel,...pfQuaternion should be the same data and this Tiva code is not accessing on-chip Quaternions]

    So when you set pfData[0]=90 in the main loop of  3264_compdcm... it stuck through to the printout. And when you update the sensors it overwrites the earlier values prescribed by you.[Need to review this explanation]

    If in fact you are getting screen prints of raw MPU9150 data that will aid in the individual sensor checkout for both polarity and noise. With the SensorHub sitting upside down with say accel/gyro X axis pointing north (level flight, yaw 0)could someone write about 10 minutes of data to file instead of to screen along with a time stamp and post. I will do the same with my SDK and EVB MPU9150.[Done & posted below for EVB/SDK, awiating Tiva report. Need to find a point in the Tiva stream where accel, gyro and mag data is stable and understandable for a fixed hub orientation]

  • For reference here are results for an MPU9150EVB/ARM. I aligned X with North using a wall reference but didn't think and left the Z axis pointing up instead of down. (Air mouse configuration, I guess). The mean values of the data were put into my Python SensorHub code translation and it reported the airplane had been rotated 130deg in Yaw a small few degrees in Pitch and a complete 180 deg in Roll. I also re-ran the calculation with the magnetometer axes re-aligned per spec and only the Yaw was changed by 90 deg to 320 deg. All was as expected except for the large Yaw error since I believe Google knows North better than the magnetometer. Was there 60 degrees of iron pulling on magnetometer--maybe. Moving it to the middle of the room will be the next experiment.

    In summary there is certainly no basis for attitude oscillation in this raw data. In fact the 0.7uTesla deviation of the accelerometer data is equivalent to <2 deg variation. (std(m)./|mean(m)|*pi/180=[1.9, 1.7, 1.3] deg)

    What are you seeing in the raw data collected by the SensorHub in same orientation, pfData written to file ?

    Note: MPU9150 registers were configured for 20Hz sampling, 10Hz DLPF, 250dps/2g full scale gyro/accel.

    Mag   (tesla):  [-2.308e-05, 2.6973e-05, 2.614e-05] 
    As measured original raw data with EVB X-axis -->North
    Accel (m/s^2):  [-0.501, 0.653, 9.959]  
    As measured raw data with EVB Z-axis-->UP
    fDeltaT=0.02;pfScaleA=0.5;pfScaleM=0.5;pfScaleG=0; 
    
    After executiion of CompDCMInit,CompDCMStart,CompDCMUpdate:
    DCM: 
    [-0.651, 0.755, -0.082]
    [0.758, 0.653, -0.005]
    [0.050, -0.065, -0.997]
    
    Confirming Eulers,Quaternions from above DCM (NOT from 3264.compdcm.../main) &  print outs:
    Accel
    0.501
    0.653
    9.959
    Gyro
    0.3
    0.0
    0.0
    Mag
    -23.80
    26.973
    26.140
    Eulers
    -176.248
    -2.873
    130.667
    Quaternions
    0.36
    0.416
    0.908
    0.19

    Mag   (tesla):  [2.6973e-05, -2.308e-05, -2.614e-05]  
    Re-calculation with Magx>Magy,Magy->Magx, Magz->-Magz, with EVB X-axis -->North Accel (m/s^2): [-0.501, 0.653, 9.959] As Measured with EVB Z-axis -->UP fDeltaT=0.02;pfScaleA=0.5;pfScaleM=0.5;pfScaleG=0; After executiion of CompDCMInit,CompDCMStart,CompDCMUpdate: DCM: [0.767, -0.637, 0.080] [-0.640, -0.768, 0.018] [0.050, -0.065, -0.997] Confirming Eulers,Quaternions from above DCM (NOT 3264.compdcm../main) & print outs: Accel 0.501 0.653 9.959 Gyro 0.3 0.0 0.0 Mag 26.973 -23.80 -26.140 Eulers -176.248 -2.873 320.162 Quaternions 0.22 0.939 0.339 0.34

    Attached raw data: UDL1.0 log file, register file, Octave plot script and above pdf's:

    4380.MPU9150EVB.zip

  • A follow up to my last post.

    Here is the image of the MPU9150 EVB data plots that didn't make it in inline. (also included in pdf in previous post zip file)

    7367.MPU9150EVB.pdf (still didn't make it inline?)

    I also checked out my SDKMPU9150 and found it in closer alignment with North. My guess is that it has been and continues to calibrate for hard and soft iron distortions -- and that should also be done by Sensor Hub code. Here are python calcs for the magnetometer and accel data before and after I did a "figure 8" tumble to map the local magnetic fields. Both cases are closer to North than the uncalibrated EVB and there was a change in magnitude but not a large change in yaw direction after calibration. I am not as confident in the North alignment for the SDK measurements so can't be sure which case was closer to truth. Again, however, there was no oscillatory motion or significant noise in either case for either the raw data or Pygame cube display.....

    Let me know what raw data (write pfData values to file; ignore cube display) you find for similar static SensorHub case.This will help box in the source of errors.

    BEFORE COMPASS SDK CALIBRATION:
    Mag   (tesla):  [-1.889e-05, -8.5047e-07, -1.735e-05]  Earth field in body with initial SDK
    Accel (m/s^2):  [-0.085, 0.192, 10.145]               & Raw accel output with X->North and Z->Up
    fDeltaT=0.02;pfScaleA=0.5;pfScaleM=0.5;pfScaleG=0; 
    
    After executiion of CompDCMInit,CompDCMStart,CompDCMUpdate:
    DCM: 
    [-1.000, -0.028, -0.008]
    [-0.027, 0.999, -0.019]
    [0.008, -0.019, -1.000]
    
    Confirming Eulers,Quaternions from DCM & 3263.compdcm.. print outs:
    Accel 0.85 0.192 10.145
    Gyro 0.3 0.0 0.0
    Mag -18.890 0.850 -17.350
    Eulers -178.91 0.479 181.570
    Quaternions 0.4 0.13 0.999 0.9
    
    AFTER SDK "COMPASS" CALIBRATION MANEUVER:
    
    Mag   (tesla):  [-2.895e-05, 2.92e-06, -3.926e-05]  Earth field in body with initial SDK
    Accel (m/s^2):  [-0.085, 0.192, 10.145]             & Raw accel output with X->North and Z->Up
    fDeltaT=0.02;pfScaleA=0.5;pfScaleM=0.5;pfScaleG=0; 
    
    After executiion of CompDCMInit,CompDCMStart,CompDCMUpdate:
    DCM: 
    [-0.992, 0.124, -0.011]
    [0.124, 0.992, -0.018]
    [0.008, -0.019, -1.000]
    
    Confirming Eulers,Quaternions from DCM & 3263.compdcm.. print outs:
    Accel0.85 0.192 10.145
    Gyro 0.3 0.0 0.0
    Mag -28.950 2.920 -39.260
    Eulers -178.915 0.479 172.869
    Quaternions 0.4 0.62 0.998 0.9
  • Anthony Challoner said:
    If in fact you are getting screen prints of raw MPU9150 data that will aid in the individual sensor checkout for both polarity and noise. With the SensorHub sitting upside down with say accel/gyro X axis pointing north (level flight, yaw 0)could someone write about 10 minutes of data to file instead of to screen along with a time stamp and post. I will do the same with my SDK and EVB MPU9150.

    Hi again Anthony, I am checking your data to prepare a program for Tiva.

    What do you exactly need? What is the variable you have called Temp?

    What are the units of time and temp?

    Thank you.

  • Just to confirm, I sent your the MPU9150EVB raw data with plots and plotting script. They are all in a .zip file. (There were a few delayed attempts because of difficulty inserting graphics in-line and intercept by the Forum editor). The raw data comprises the time in milliseconds, gyro, accel,compass and temperature (Temp). Temperature is available on-chip but not essential for this investigation. The  conversion from raw to engineering units can all be found in the Octave/Matlab script readMPU9150EVB.m.

    All of the reference quiescent data from from my EVB and SDK are understandable and steady and do not lead to unstable displays. I would like to be able to say the same for the Tiva implementation. So if you could provide a similar file of "sensor" data vs time for 10 minutes from Tiva, e.g. lets start with pfData,  that would be helpful. If you can log time with the data that would also be helpful and I guess you may as well log all the  pfData including Eulers and Quaternions. Log float data for now. If we see raw to float issues we can go back to pull out the raw sensor data as we have in the EVB .csv file.

    I am sorry I may have caused some confusion with an earlier statement about pfData not being the same as the elements pfAccel, etc. I gather they are the effectively references to the same data.. I ddidn't understand the C syntax.

    The  simple goal is to see a steady stream of sensor data at some point in the Tiva stream, similar to the EVB or SDK.

  • Hello Anthony. 

    I made the LOG (actually I made two). the data is in the same format you provided:

    CompDCMInit(&g_sCompDCMInst, 1.0f / 20.0f, 0.2f, 0.8f, 0.2f);
    
    .........  
    
    UARTprintf("%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d\n",(uint32_t)(cycles1_total),(int32_t)(pfGyro[0]*1000),(int32_t)(pfGyro[1]*1000),(int32_t)(pfGyro[2]*1000), (int32_t)(pfAccel[0]*1000),(int32_t)(pfAccel[1]*1000),(int32_t)(pfAccel[2]*1000),(int32_t)(pfMag[0]),(int32_t)(pfMag[1]),(int32_t)(pfMag[2]),100);

    In the first one I saw an error in the timestamp,there was a reset of the time stamp because of an overflow, so  I decided to make a second one Which you will like more.

    4760.LOG_SENSORHUB3_20131129011833.rar

    In this setup I was pointing the X axis to North (with a lot of error).

    And form your MATLAB function I get thiese graphs:

    -------------------------------------------------------------------------------------------------------------------------------------------------------------

    Anyway, I send you as well the first Log with this setup, just in case you want to compare. The Y axis was pointing North, so perpendicular to the second LOG:

    0827.LOG_SENSORHUB2_20131129005045.rar

    Regards.

    EDITED:

    Added another third log with Z down.

    0576.log4.rar

  • I took a quick look at the second log file and originally got your plot.Then I looked at your formatting and believe the variable pfGyro is in r/s, pfAccel is in m/s^2 and pfMag is in uTesla (do you agree?). The formatting of my .csv raw data was in counts so the matlab script needed to modified accordingly. I have attached the updated plot & script for you to re-run and so far it looks steady and the values all seem reasonable. I'll take a look at the rest of your data and comment further later.

    5282.MPU.zip

  • Anthony Challoner said:
    and believe the variable pfGyro is in r/s, pfAccel is in m/s^2 and pfMag is in uTesla (do you agree?)

    Yes, I do agree since:

    //
    	// Get floating point version of the Accel Data in m/s^2.
    	//
    
    	MPU9150DataAccelGetFloat(&g_sMPU9150Inst, pfAccel, pfAccel + 1, pfAccel + 2);
    
    	//
    	// Get floating point version of angular velocities in rad/sec
    	//
    
    
    	MPU9150DataGyroGetFloat(&g_sMPU9150Inst, pfGyro, pfGyro + 1, pfGyro + 2);
    
    	//
    	// Get floating point version of magnetic fields strength in tesla
    	
    
    	MPU9150DataMagnetoGetFloat(&g_sMPU9150Inst, pfMag, pfMag + 1, pfMag + 2);
    
    
    ........
    
        //
    	    // convert mag data to micro-tesla for better human interpretation.
    	    //
    	    pfMag[0] *= 1e6;
    	    pfMag[1] *= 1e6;
    	    pfMag[2] *= 1e6;
    

    Anthony Challoner said:
    I'll take a look at the rest of your data and comment further later.

    If you take anopther look, better try with the last file: 0576.log4.rar

    The other one, I think, doesn't worth the effort of formatting.

    The data seems stable....if it is right or wrong, that I don't know.

  • I looked at 0576.log4.rar and saw the accelerometer z-axis was inverted, gyro rates were about the same as expected and the magnetometer z-axis had changed from about -20 to -80uTesla. Not sure why the MagY axis didn't change sign since I assume you flipped the board keeping X pointing North and Z pointing down. I will try this on my MPU.

    Meanwhile now that raw data is starting to look stable I have a question about your Sketch. Have only taken a quick look but are you sure you are rotating the board in the yaw, pitch, roll order? I would have thought RotateZ (yaw) would be first call, then RotateY and RotateX. Perhaps you can explain?

    void drawBoard() {
      pushMatrix();
    
      rotateY(-radians(yaw - yawOffset));
      rotateX(-radians(pitch));
      rotateZ(radians(roll)); 

  • To be sure I will prepare another log

    About the rotation axis, the reference is different, is all about screen:

    http://www.varesano.net/blog/fabio/ahrs-sensor-fusion-orientation-filter-3d-graphical-rotating-cube

    It will work with your MSP430 as well!!

  • I checked out your Processing link and can see discussion of the issue I raised. I didn't trace through all the argument but it looked like my concern was covered.(I don't see any way to verify with my MSP430 which uses a python client for cube display; I also don't have Processing installed .) If you are sure you have the correct order of rotation (Yaw, then Pitch, then Roll) the instability may be downstream of the raw (gyro,accel, mag) data.

    So when you make more logs..could you add a roll, pitch, yaw column (i.e., the pfEulers). Perhaps you can place the SensorHub in one of the unstable configurations - assuming your PC can log and display videos at the same time. Perhaps we can catch the problem this way....for example can you  recreate and log this X to screen case:

    http://youtu.be/mffsWtfMavE

  • Anthony Challoner said:
    (I don't see any way to verify with my MSP430 which uses a python client for cube display; I also don't have Processing installed

    You just need to download Processing (it's free) and the sketch, and from your MSP430 just send the Euler array with the format:

    "roll,pitch,yaw!"

    as for example:

    0.162,0.207,15.625!

    The sketch will come to life with the data of your device.

    Check out for the COM port opened in the console of processing!! 

    Anthony Challoner said:
    So when you make more logs..could you add a roll, pitch, yaw column (i.e., the pfEulers). Perhaps you can place the SensorHub in one of the unstable configurations - assuming your PC can log and display videos at the same time

    Unfortunatellly, I can't log and feed the sketch at the same time for now. What do you mean with "display videos"?

    I

  • Keep in mind I have no way at the moment to modify the MSP430 code- but I can command it to send Euler data to the sketch--  I may look into this.

    For now can you set up the SensorHub in the oscillatory pitch condition and leave it there; then can you change to the log script to log data, then switch back to confirm its still oscillating ?  Most of the oscillatory issue seemed to be in pitch.

  • I have prepared a new log, with X pointing near North and Z looking down.

    I have added (after the Temp field), the data of roll, pitch and yaw + the ! delimitator.

    7587.LOGSENSORHUB5_20131130222717.log

    Regards

  • Thank you. This looks to be what I requested. I will download and comment.

    I now have an Octave script that can process any raw data set (Tiva or MSP430) into Euler angles with any sensor weighting I want. This should speed up the trouble shooting. I am finding the behavior of this DCM algorithm to be quite unexpected.  I will have more to say on this after I process your new data which will help to provide a check.

  • The Eulers in the last data looked reasonably good to me, so far. (plots attached).  I would say the DCM algorithm is running as expected   8054.rollpitch.pdf4034.yaw.pdf  and see only a small +/-1/2 deg pitch oscillation (possible quantization issue?). Can you now generate a sensor data set during a large pitch oscillation display condition? 

    Your last data including the sensor data and Tiva calculated Eulers with X->North and Z->Down proved useful. I was at first not getting agreement with my Octave-calculated Euler and then I realized the call to the pfScale.. factors was out of order in Octave. Because I had tried to set pfScaleG=0 I had pfScaleA set to 0 instead and this led to unstable behavior.  With this algorithm it is important to have non-zero weights on magnetometer and accelerometer to get stable behavior; non zero weight on the gyro helps indirectly because it reduces the update rate from the magnetometer and accelerometer variations, providing some filtering. Otherwise for static cases the gyro seems unimportant as expected and may lead to drift if bias is not calibrated. Tiva and Octave calcs are not quite the same but let's hold this for now till we get the requested large pitch oscillation data.

    A few other notes. I can see your mangetometer data is aligned per the product spec based on comparison of the Z component in the UP vs DOWN condition.  No matter where you are on Earth the magnetic field never points up; in your case it went from -17 utesla in the Z UP case to -79 utesla in the Z DOWN case. This suggests the magnetometer data is not aligned with body axes but rather with original product axes.  The transformation to body axes (MagX->Y Magy->X, MagZ-> -MagZ) could be standardized in CompDCMStart and Update as was done with the Accel. I can't see this issue resulting in oscillatory behavior, however.

    With corrected mag axes the yaw offset reduces to -30 deg from -60 deg. This is still likely larger than the field declination at your site. When the oscillatory problem is resolved the next improvement may be to add corrections for hard and soft iron magnetic effects.

  • Ok, actually I was using as weighs    CompDCMInit(&g_sCompDCMInst, 1.0f / 20.0f, 0.2f, 0.8f, 0.2f); //not fScale=0.6

    I made a new log, with some oscillation. The X now is 90 degrees to north (probably West). Z is up. Now I am using 0.2, 0.6 and 0.2 as you.

    6471.LOG_SENSHUB6_oscillation_20131202130430.rar

  • I also made some captures in video of the board with the sensorhub attached and the capture of the screen.

    The values are printed in the screen as well.

    -Sketch feed from Eulers(you can spot the oscillations at beggining):

    http://www.youtube.com/watch?v=ptL9xn5-64g

    - Sketch with Yaw=0 (in the sketch)

    http://www.youtube.com/watch?v=cffbjZ3akL8

    - Sketch with Yaw=0 and  Pitch=0 (just Roll)

    http://www.youtube.com/watch?v=CLeRfN58rcY

    - Sketch with Yaw=0 and  Roll=0 (just Pitch)

    http://www.youtube.com/watch?v=9cPk4pFKgws

    AS you can see, both axis make both Pitch and Roll vary.

  • Suggest that the original, "subject/title" of thread may deserve the same update consideration as recent name/logo of o.p.

  • Well, there is nothing remarkable in the 6471.LOG... 3678.Eulers6471.pdf  .

    The weights should add to 1.0 -- according to theory but I can't see that producing the terrible videos. So far, for quiescent cases, the Tiva code looks OK but feel free to comment.

    I will introduce simulated motion on top of the background noise from the sensors and see how robust the algorithm is in tracking the motion. That might be interesting. I could also send you the roll, pitch and yaw track for you to drive your sketch if it looks worthwhile.

    Can you do the same with your sketch ?  Bypass your serial stream and generate fixed roll, pitch and yaw combinations and make sure the display is what you expect and is stable ?

  • Anthony Challoner said:

    I will introduce simulated motion on top of the background noise from the sensors and see how robust the algorithm is in tracking the motion. That might be interesting. I could also send you the roll, pitch and yaw track for you to drive your sketch if it looks worthwhile.

    Can you do the same with your sketch ?  Bypass your serial stream and generate fixed roll, pitch and yaw combinations and make sure the display is what you expect and is stable ?

    Please tell me and will add it. It is very simple (and powerful) to use processing.

    On the other hand, making the videos, I have detected that sometimes, unexpectedly, the Yaw coordinate of the eulers is only changing between 180 degress, 360 degrees and 0 degrees. And doesn't change no matter how much I move the board!!!

    I've made you a log with this effect, maybe there is something interesting in it:

    5822.log7_sensorhub_STUCK_0_20131202170142.rar

  • Thanks. I have run the new data through Octave and plotted its Eulers along with Tiva Eulers ...7288.5822STUCK.pdf

    The DCM algorithm is happy when its in Octave but appears to be worried about pitch in Tiva - or is it on the serial ouput side ?

    Looks like the problem is now well defined, as we wanted. I will let you comment on possible cause; I don't think its the fScale weights.

    BTW my problem is not with Processing but with not being able to modify the MPS430 code. I found the current serial protocol fixed in the InvenSense SDK was tricky to handle reliably in a PC host except with the serial data processing in their Python client. So I am doing my own nav  app development at the moment by  extending one of the Python classes. I am thinking about doing it for the DCM. PC math is far from the data source, however. That's why I'd be interested in having some convenient MCU modification capability. I am planning some interesting application demos and trying to decide on my development platform;I see there are several platforms out there, all with crafted motion processing libraries.

  • Anthony Challoner said:
    Looks like the problem is now well defined, as we wanted. I will let you comment on possible cause; I don't think its the fScale weights.

    In this example I corrected the weights and I was using 0.2, 0.6 and 0.2. So that is discarded.

    Anthony Challoner said:
    BTW my problem is not with Processing but with not being able to modify the MPS430 code. I found the current serial protocol fixed in the InvenSense SDK was tricky to handle reliably in a PC host except with the serial data processing in their Python client. So I am doing my own nav  app development at the moment by  extending one of the Python classes. I am thinking about doing it for the DCM.

    Translate from python to processing is pretty straight, if you want, I can give you a hand.

    Anthony Challoner said:
    PC math is far from the data source, however. That's why I'd be interested in having some convenient MCU modification capability. I am planning some interesting application demos and trying to decide on my development platform;I see there are several platforms out there, all with crafted motion processing libraries

    Tiva in those platforms? Which else?

  • I just noticed your magnetometer data is very nonlinear.; its quantized to exactly 1 uTesla LSB via Tiva instead of about 0.3uTesla via my EVB and the MPU9150 product spec.

    This nonlinearity gets magnified in the DCM process and comes back in a highly nonlinear pitch dither or 'oscillation' . Octave's floating point DCM processing is apparently not affected but Tiva DCM processing is. Because the magnetic field levels are low in the STUCK orientation the large quantization could result in the large dither seen in pitch.

    Initially I thought  the formatting before the UARTprint statements was the culprit but I can't yet see how that would affect the DCM processing. Likewise I can't see how downstream sketch  processing can be involved.

    Could your take a look at the Tiva code to see what happened to the magnetometer; the other sensors may also  be affected but were not as critical. (I can look for some quiescent SensorHub data and do a noise comparision with EVB)

    Let's get some cleaned up SensorHub videos with your sketch first. Sketch math or python math is not my final target.