Forum Rule: Always post complete source code & details to reproduce any issue!
Page 4 of 4 FirstFirst ... 2 3 4
Results 76 to 87 of 87

Thread: MPU-9250 Teensy Library

  1. #76
    Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    95
    Quote Originally Posted by ninja2 View Post
    Will your library recognise the teensy SPI libs alternate pin commands, like SPI.setSCK(14) ?
    Not the way it's currently written. That's why you can select other SPI buses and alternate sets of pins. But you can't mix and match currently. In other words, with the current library, you can select the alternate SPI0 bus of:
    MOSI: pin 7
    MISO: pin 8
    SCK: pin 14

    But you can't mix and match pins from the SPI0 bus, like:
    MOSI: pin 11
    MISO: pin 12
    SCK: pin 14

    I can look at whether I can re-arrange the code to allow it.

  2. #77
    Senior Member
    Join Date
    Dec 2016
    Posts
    293
    you didnt need to add an external led, you could of just told the mcu to assign SCK to an alternate pin and keep D13 as the led.. see SPI.setSCK(newPin); and reference newPin with the alternate SCK0 pin listed on your teensy card

  3. #78
    Senior Member ninja2's Avatar
    Join Date
    Aug 2016
    Location
    Adelaide, Australia
    Posts
    130
    Quote Originally Posted by brtaylor View Post
    I can look at whether I can re-arrange the code to allow it.
    It's not a big deal, maybe consider it when in next major update. The advantage of 11/12/14 is it frees up the LED_BUILTIN on pin 13.
    Last edited by ninja2; 02-07-2017 at 07:58 PM.

  4. #79
    Senior Member
    Join Date
    Jun 2014
    Posts
    224
    Has anyone tried implementing the wake-on-interrupt feature?

    http://www.invensense.com/wp-content...0A-01-v1.1.pdf page 30/31

    6.1 Wake-on-Motion Interrupt
    The MPU-9250 provides motion detection capability. A qualifying motion sample is one where the high passed sample from any axis has an absolute value exceeding a user-programmable threshold. The following flowchart explains how to configure the Wake-on-Motion Interrupt. For further details on individual registers, please refer to the MPU-9250 Registers Map and Registers Description document.
    In order to properly enable motion interrupts, the INT pin should be connected to a GPIO on the system processor that is capable of waking up the system processor.
    This would allow very low power applications, eg. deep sleeping the processor and waking by movement.

  5. #80
    Junior Member
    Join Date
    Sep 2016
    Posts
    19
    Nice clear language in this topic.

  6. #81
    Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    95
    Quote Originally Posted by Fyod View Post
    Has anyone tried implementing the wake-on-interrupt feature?

    http://www.invensense.com/wp-content...0A-01-v1.1.pdf page 30/31



    This would allow very low power applications, eg. deep sleeping the processor and waking by movement.
    Hi Fyod, I haven't had a need to implement the wake on interrupt yet. If there's a need for it, I may be able to roll it into the next library update.

  7. #82
    Quote Originally Posted by brtaylor View Post
    Aircraft in a long steady bank are actually a good way to "break" an AHRS and a reason why EKF's may offer better performance in high dynamic environments.

    Brian
    Brian,

    This particular comment stands out for me. I have been testing an AHRS device (an EFIS) in flight that currently uses a BNO055 IMU. Today was in a Searey, We've also tested in a Beech, and a Super Drifter. Indeed, long descents, ascents, and banks do seem to result in temporary, but significant drift in the indication provided by the IMU. Do you know if this is a property of the fusion/filtering firmware?

    I ask because I'm starting to feel convinced that the BNO055 is not meant for moving platforms having slowly changing orientations. As such I'm removing the BNO and going to try an MPU9250, in hopes that the driftiness can be resolved. Even if it means tinkering with the fusion and filtering.

    Robb

  8. #83
    Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    95
    Quote Originally Posted by RobbSalzmann View Post
    Brian,

    This particular comment stands out for me. I have been testing an AHRS device (an EFIS) in flight that currently uses a BNO055 IMU. Today was in a Searey, We've also tested in a Beech, and a Super Drifter. Indeed, long descents, ascents, and banks do seem to result in temporary, but significant drift in the indication provided by the IMU. Do you know if this is a property of the fusion/filtering firmware?

    I ask because I'm starting to feel convinced that the BNO055 is not meant for moving platforms having slowly changing orientations. As such I'm removing the BNO and going to try an MPU9250, in hopes that the driftiness can be resolved. Even if it means tinkering with the fusion and filtering.

    Robb
    Hi Robb,

    That sounds like AHRS fusion/filtering. I would try an EKF with IMU and GPS, regardless of the IMU sensor that you use. I think it would help during climbs/descents and steady banks.

    Brian

  9. #84
    Senior Member ninja2's Avatar
    Join Date
    Aug 2016
    Location
    Adelaide, Australia
    Posts
    130
    Very interesting. From everything I read it seems the Extended Kalman Filter is superior to AHRS in all aspects, except it is more demending on processing power. If I've understood that right, and if teensy is powerful enough, why don't we see discussion of need for an EKF (with IMU and GPS) library for teensy?

  10. #85
    Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    95
    I think that EKF filters are better for UAV's and aircraft where the forces in a long steady bank or long climb / descent can look to an IMU like it's not in motion. The EKF filter does require an additional sensor (GPS) and good data from that sensor. We've had bad GPS data corrupt our EKF solution on a rare occasion in the past; however, that's not anything that can't be worked around (i.e. checking for valid data before passing to the sensor). As a starting point, here's a very rough port of our 15 state EKF:
    https://github.com/bolderflight/EKF15

    I've had it working on a Teensy 3.6, but it crashes on a Teensy 3.2 at this time and I haven't had a chance yet to investigate why. Could use quite a lot of cleanup and optimization, especially to take advantage of the single precision floating point unit.

    Brian

  11. #86
    Quote Originally Posted by brtaylor View Post
    Hi Robb,

    That sounds like AHRS fusion/filtering. I would try an EKF with IMU and GPS, regardless of the IMU sensor that you use. I think it would help during climbs/descents and steady banks.

    Brian
    Brian,

    Do you mean take the BNO055 out of fusion mode and apply EKF to the raw data? I think if I have to do that, then perhaps its more economical to use something like an MPU-9250 vs paying for the unused fusion FW & MCU included with the BNO055. What are your thoughts?

    Regarding your EKF15 library: Would you lose much precision if you were to refactor your doubles to floats? I think Paul S has mentioned that on the Teensy double is 64 bit and float is 32 bit and the Teensy FPU is 32 bit.

    I found some doubles in my own code a while back. When I refactored to 32 bit floats, my math intensive processes sped up appreciably.

    Robb
    Last edited by RobbSalzmann; 03-14-2017 at 04:35 PM.

  12. #87
    Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    95
    Quote Originally Posted by RobbSalzmann View Post
    Brian,

    Do you mean take the BNO055 out of fusion mode and apply EKF to the raw data? I think if I have to do that, then perhaps its more economical to use something like an MPU-9250 vs paying for the unused fusion FW & MCU included with the BNO055. What are your thoughts?

    Regarding your EKF15 library: Would you lose much precision if you were to refactor your doubles to floats? I think Paul S has mentioned that on the Teensy double is 64 bit and float is 32 bit and the Teensy FPU is 32 bit.

    I found some doubles in my own code a while back. When I refactored to 32 bit floats, my math intensive processes sped up appreciably.

    Robb
    Yes, I mean applying the EKF to the raw IMU data.

    I think single precision floating point would work great, other than math involving the GPS latitude and longitude where the decreased precision may be noticed. At the University, we've considered some different approaches to maximize the use of single precision math, including the use of NED (North East Down) coordinates instead of LLA (Latitude, Longitude, Altitude).

    Brian

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •