Member #471855

Member Since: September 22, 2013

Country: United States

  • Product SEN-12636 | about 5 days ago

    I appreciate the info on the Kalman filters. I took a look at the library and I think I could adapt it to a simpler Pro Mini sketch. I also found a nice write up on Kalman filtering and might take a crack at constructing one from scratch. I did manage to get the MPU-9150 sketch running on a 5V 16 MHz Arduino Uno but the magnetometer data wasn’t right. Maybe the magnetometer on the MPU-9150 isn’t 5 V logic tolerant? Anyway, I noticed that the filter update speeds roughly doubled, so I take your point that processor speed likely dominates over the details of any one kind of filter.If you succeed in optimizing the Kalman filter I would like to try it.

  • Product SEN-12636 | about 5 days ago

    I was going to copy your Kalman filter to do a timing test on the Pro Mini. Are you saying it would be better to wait for a better optimized version? Is the optimization straightforward, like reducing the number of operations, or is there more to it?

  • Product SEN-12636 | about 5 days ago

    I was able to get MPU-9150 filter update rates of 1000 Hz without the magnetometer reads on the 3.3 V 8 MHz Pro Mini and 165 to 250 Hz with magnetometer reads at a 10 Hz rate. This is all with direct data register reads; i.e, without reading from the DMP, of course. I wonder how the filter update rates depend on 1) the specific filter, i.e., Kalman vs. Madgwick, and 2) the speed of the microcontroller’s processor? I measure about a 50% speed up in the filter update rate with the Mahony sensor fusion algorithm versus the Madgwick. I guess I’ll try both using the below sketch with a 16 MHz Uno and see if the times change…

  • Product SEN-11486 | about 6 days ago

    I created a simple sketch using a modification of Jeff Rowberg’s MPU6050 library that reads the MPU9150 gyroscope, accelerometer, and magnetometer data using the readAcceleration(), readRotation(), and readMag() functions checking for data updates using the data ready status register. For now it is at https://github.com/kriswiner/MPU-9150_Breakout. I hope it will soon be pulled to the Sparkfun repository. The sketch demos: * How to display output at a rate different from the sensor data update and fusion filter update rates * How to specify the accelerometer and gyro sampling and bandwidth rates * How to use the data from the MPU9150 to fuse the sensor data into a quaternion representation of the sensor frame orientation relative to a fixed Earth frame providing absolute orientation information for subsequent use. * How to use the quaternion data to generate standard aircraft orientation data in the form of Tait-Bryan angles representing the sensor yaw, pitch, and roll angles suitable for any vehicle stablization control application. Running the sketch on a 3.3 V 8 MHz Pro Mini Arduino microcontroller results in filter update rates of between 145 and 200 Hz for the open-source Madgwick and Mahony sensor fusion algorithms, respectively. This is about the same as one would get if a 9 DoF sensor fusion algorithm were functional in the on-board Digital Motion Processor, which it is not. Not too bad for the little Pro Mini!

  • Product SEN-12636 | about 2 weeks ago

    Thanks for such an easy to use library. Also, the sensor data sheet is easy to understand despite its somewhat perfunctory descriptions. I created a sketch to compute filtered quaternion representations of the sensor frame relative to the fixed Earth frame using open-source Madgwick or Mahony 9DoF sensor fusion filtering and can get filter update rates of between 125 (Madgwick) and 165 (Mahony) Hz using a 3.3 V Pro Mini operating at 8 MHz. This is not too much less than the proprietary Digital Motion Processor on-board the MPU 6050 and MPU-9150. The sketch and (slightly) modified library can be found at https://github.com/kriswiner/LSM9SD0. I am going to try the sketch with MPU-9150 accelerometer, gyro, and magnetometer DMP outputs to make a more apples-to-apples comparison. I still do not know exactly how to configure the LSM9SD0 registers to latch the gyro and accelerometer data ready interrupts via the DEN_G function. Maybe an e-mail to ST Microelectronics is in order. Lastly, can we get a version of this breakout board with a square footprint with pins on opposite sides? This would be much more convenient for protoboard mounting applications. Thanks again for a great product!

  • Product SEN-12636 | about a month ago

    Yes, that’s the line and the corresponding one for the lowest magnetometer resolution setting. Thanks for the wiki pointer; I had never seen that shorthand before, now I get it.

    Are you saying that specifying the signed integer type somehow does the two’s complement conversion automatically? That would be convenient!

  • Product LCD-10168 | about a month ago

    These are great displays. I ran into a problem using them with the nRF24L01+ radio transciever, which requires the use of the SPI bus. If one attaches both the radio and the display MOSI and SCK pins to pins 13 and 11 as instructed in the hookup guide, the SPI traffic of the other device (in this case the nRF24L01+ radio) will prevent the display from functioning. The easy solution is to move the Nokia 5110 MOSI and SCK pins to any other digital pin. This should be made clear in the hookup guide, where it says there is no choice but to use the hardware SPI pins for the display. I found out that is not true at all. I hope his helps others with the same problem. Despite the occasional bad display these carry much more information that the comparably prices 16 x 2 LCD and use fewer pins too boot. What a deal!

  • Product SEN-12636 | about a month ago

    I have been studying the library and I think there might be a couple of problems. Where is the twos-complement check (MSbyte > 0x7F) on the raw 16-bit data? Do the scale range algorithms return the correct resolution settings for aRes for +/- 16 g acceleration (10/32768 instead of 16/32768) and for mRes for 2 g scale (0/32768 instead of 2/32768)? Maybe I am mis-interpreting the syntax…

  • Product SEN-12636 | about a month ago

    Thank you Sparkfun for another 9DOF solution for the Arduino! The tutorial and library are very clear and I am looking forward to augmenting the latter for quaternion and compensated roll/pitch/yaw output for various ‘round-the-house projects. I have tried to make use of the MPU6050 but have temporarily given up in frustration. Yes, I bought cheap GY-521 breakout boards, but I keep getting -x-motion interrupts and can’t seem to consistently set the accelerometer and gyro ranges. Plus, there is the entire issue of how to use the DMP. The point is the MPU6050 is poorly documented and Invensense is, shall we say, less than forthcoming for the individual user. I hope to have a more productive experience when my LSM9DS0 arrives in a few days.The gyro has a maximum ODR of 760 Hz, plenty fast for most applications. I expect this board will work fine in a quadcopter. I’ll let you know in a few weeks. In the meantime, I have found a document that sheds some light on the DEN_G function: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/design_tip/DM00067982.pdf.

  • Product SEN-11770 | about 3 months ago

    I don’t want to spam but I cross posted this comment in the MMA8452Q Breakout Board section also.

    I was able to modify the RedBot accelerometer (MMA8462Q) CPP file to add two’s complement checking and LSB shifting ala the advanced example in the Example Code (see MMA8452Q Breakout Board). Everything works as expected EXCEPT the g values are four times too large. I checked and double checked that the scale setting is +/- 8 g, I’m in the low res mode, the logic looks fine, and I’m dividing the count by 256 for the 8 g scale and I am getting ~+4.00 g in the z-direction, not ~+1.00 g as I expect. I’m using 8 for the scale factor in constructing the divisor for the counts (1/(1<<12)/(2*SCALE)) = 1/256 for 8 g full scale, yet I am getting an extra factor of four. I checked the raw output of the concatenated z-bytes which was ~16000 unshifted = 14-bits! What gives???

    Thanks for any suggestions (other than dividing by four which I am currently doing)!

No public wish lists :(