Navigation pyskin - Board Design RFC

[blmorris]

@Turbinenreiter: That's a drag, but don't despair. As Damien said, a hot air gun is one option; I have a temperature controlled one intended for PCB reworking similar to what Damien described that was bought for under $100. There are other options as well- I actually do most of my in-house prototyping and small run manufacturing with a modified toaster oven controlled by a Temp-Tell Reflow controller, but if you are careful you might be able to get away with an uncontrolled toaster oven - just be sure to watch it very carefully!
There is also the "skillet method" described by SparkFun back when they were just a cash-strapped startup.

The problem here is that the pads of the BMP180 are completely hidden under the metal package cover. The MPU9150 is small, but it is possible to solder it with a fine-tip soldering iron, a good pair of tweezers, a magnifier and some solder wick (not to mention a bit of patience) but with the BMP180 you are just out of luck - direct contact isn't an option, so you need a non-contact way to get the heat to the solder.

Good luck!
-Bryan

[Turbinenreiter]

Thanks for the tips!

[blmorris]

Video demonstration of IMU sensor fusion using the MPU-9150 on my navigation board:

http://youtu.be/cNhyGunj3gA

IMU_video.jpg (150.36 KiB) Viewed 6730 times

Sorry to say that there is no Micro Python at work here; the visualization software is RTHostIMUGL and the hardware bridge from the MPU-9150 to USB is provided by an Arduino clone running RTArduLinkIMU
Many thanks to richards-tech for the software!

-Bryan

[Damien]

Looks good! Did you fix/calibrate the magnetometer?

I see that the RTIMULib https://github.com/richards-tech/RTIMULib is MIT licensed (and even has CPython bindings!). I doubt it could be ported to pure Python and still run at a high framerate, so we could think about importing it as a C library into uPy. This would be an ideal candidate for loadable C modules https://github.com/micropython/micropython/issues/583.

[blmorris]

Looks good! Did you fix/calibrate the magnetometer?

Yes. The RTIMULib software provides two methods for compass calibration. The first is a simple min/max measurement on each compass axis, which assumes that the midpoint between min and max is the zero point for each axis. The second method is to take a bunch of measurements in all orientations and fit an ellipsoid to the readings; this provides a more accurate zero as well as sensitivity compensation for each axis. There is a calibration routine written for Octave (GPL-free Matlab-like language) to do the ellipsoid fitting, I used this method for that video.

I found that without the magnetometer calibration, there was often a disagreement between the rotation calculated by the gyros and that measured by the compass and accelerometers. This would manifest as a smooth and quick rotation in the display in response to the gyro measurements, followed by a slow drift to a new position as the measured orientation caught up to the compass reading.
When the compass measurements were disabled, (leaving just the gyro and accelerometers) the rotations were very smooth and stable and seemed to be accurate, while the compass-measured orientations seemed to be off-center until I did the ellipsoid calibration. Also, any measurements that I did at work showed a lot of noise in the compass reading; my office is in a large steel-reinforced concrete building, and I had the impression that the magnetic fields were actually oscillating. It is also possible that the magnetic field was just variable with position; with just the gyros, I could move the system laterally without seeing much change in the measured orientation, but with the compass turned on, a small position change could show as an orientation change if the magnetic field changed in direction.

I see that the RTIMULib https://github.com/richards-tech/RTIMULib is MIT licensed (and even has CPython bindings!). I doubt it could be ported to pure Python and still run at a high framerate, so we could think about importing it as a C library into uPy. This would be an ideal candidate for loadable C modules https://github.com/micropython/micropython/issues/583.

You did say that the quadcopter was an opportunity to push micropython development with a real-world application, so if this provides motivation for loadable modules then mission accomplished
Is it a problem that RTIMULib is written in C++? Honest question, I have no idea. From what I understand it was developed explicitly to be embedded in other projects. I should note that in the video above all sensor fusion computation is being done on the host system (my mac), and that the Arduino is just collecting raw sensor data from the IMU and forwarding that to the host. (And if I try to say anything more about RTIMULib I will probably just mis-state things that would otherwise be fairly obvious to Damien, pfalcon, and all the other actual software developers here.)
-Bryan

[dhylands]

I read this article this morning and thought it might be relevant:
http://ozzmaker.com/2015/01/23/compass3/#more-3311

[blmorris]

I read this article this morning and thought it might be relevant:
http://ozzmaker.com/2015/01/23/compass3/#more-3311

Good article, simple and concise explanation of the issues around magnetometer/compass calibration. There is a very nice description of 'hard iron' and 'soft iron' distortion and a clear explanation of how to correct them.
The article provides a calibration process for a 2-axis compass, with center-bias (hard iron) and ellipse (soft iron) compensation. The RTIMULib that I have been using provides utilities to do full 3D 'ellipsoid' compensation with the ellipsoid fitting routine written in Octave. I did need to jump through some hoops to use it because some of the data collection code was Linux specific and my only current Linux machine is my Raspberry Pi (I did get it to work.)
Earlier I wrote that I had a brief panic when I realized that I put the MPU9150 just millimeters from the GPS receiver and that the receiver shielding is substantially ferromagnetic. It seems that this is not a problem as the magnetic bias introduced by the GPS unit can be calibrated away. If I do a redesign, though, I will put a bit more space between them

My current news is that I have written the uPy code to stream the raw 9-axis IMU data (actually not quite raw; I am sending the floating point data provided by @turbinenreiter's MPU9150 library) to the sensor fusion and visualization program shown in the video above. No more Arduino, I can now do the same demo with the navigation pyskin sitting on a pyboard where it belongs. I'll try to get another video up soon and post the code once it is a little less hacky.

-Bryan