Comparison of currently available low-cost magnetometers and optimal placement

Other Hardware Sensors
1

I am an engineering student and in order to improve my control system skills I want to take a RC helicopter (T-Rex 600) and place an ESP-6050 on it and then command references to the helicopter which are tracked by carefully designed controllers. That is, I don't really want to control the robot "by hand". Currently I'm trying to figure out which sensors to use. I have a very strong mathematical background and I'd like to implement tilt-compensation/Kalman filters etc. myself. However, I have no experience whatsoever with magnetometer modules. I saw that there are a couple of options for low-cost magnetometers, some of which aren't even manufactured anymore (HMC5883L?).

My question is now the following. Which low-cost magnetometers that are currently available are the most accurate? Apart from being accurate, which of these magnetometers do also offer fast update rates in comparison to their competitors? I also have a question about the placement of these sensors. It is my current understanding that these magnetometers are rather sensitive with respect to metallic object being close to them. Do you think it is a smart idea to use for example two identical magnetometers which are placed far apart from the center of the of the helicopter (for example by putting them on sticks or the like which are mounted such that the sensors are far out on the left and right side of the helicopter) and then try to combine these measurements? Assuming independent measurement noise, this should decrease the variance of the measurement errors, but as I said I don't have any experience with these devices so I am very much interested to hear your opinion on this!

Best,

Felix Crazzolara

2

New magnetometer chips appear often and they are steadily improving. Study the data sheets carefully to compare sensitivity and noise figures. Pololu has a good selection of magnetometer breakout boards.

Magnetometers must be carefully calibrated for use as a compass, and the calibration process itself can remove the effects of nearby magnetic materials or external magnetic fields (called hard and soft iron correction).

This tutorial provides an excellent overview of the calibration process.

3

Once a calibrated magnetometer is moved, the calibration is no longer valid. You'll have to figure out a way to keep the magnetometers calibrated when your device moves.

If one was to buy 10 magnetometers and go through each one noting the raw readings, 2 very similar magnetometers can be found. It is important to place each magnetometer under test in the same physical position.

If the 2 magnetometers are mounted so that each axis is 180 out of phase with the corresponding axis, then, when the readings are summed together, you get auto-correction that works as the magnetometers move.

4

You don't need a magnetometer, because the MPU-6050 is the problem. It is noisy and outdated. Buy a 9DoF or 10DoF module with recent chips. Also have a look at the AHRS filter.

The filter will combine the sensors, so they all benefit from each other.
Try to find a sweet spot for the magnetometer (that means the whole 9DoF module). Combining two magnetometers is solving a problem with another problem.

I suggest to use a Arduino board with a ARM M0+ processor, for example a MKR board. They run at 3.3V, so you have no trouble to connect 3.3V sensors to it.
When you want to use a Arduino Uno or a Arduino Mega then you have to use I2C level shifters. They are sometimes already on the module. You can use that for testing, but a M0+ processor will be a better choice for the final version.

5

Why not tell us what you actually want to do?

You could start by explaining what this phrase means:

then command references to the helicopter which are tracked by carefully designed controllers

6

I suggest you take a look at betaflight project, they are doing something very similar (primarily with gyro, but accelerometer can be added to achieve semi-stabilised flight): GitHub - betaflight/betaflight: Open Source Flight Controller Firmware

The thing is though that they are using way more powerful board than Arduino, mostly because all the filtering and motor control needed. Minimal supported CPU is STM32F4, bunch of the BF boards is using STM32F7/H7, which is either Cortex M4 or Contex M7 + M5. Also those CPUs have significantly higher clock speed compared to current Arduinos (STM32F405 which is a good starting point is a 168MHz chip).

There's another thread here asking a question you will have to ask yourself very soon as well: "How to filter the gyro data?": LSM9DS1 datasheet unclarity - Sensors - Arduino Forum. And that's the reason why all the compute power. When you attach these boards to a shaky thing like a heli or quad, the amount of noise will be significant. AFAIK removing the noise with a decent latency is the most important issue for a flight controller, and these guys are working years on a decent solution. Last iteration employs 32 very narrow notch filters moving up and down frequency spectrum with the RPMs of the motors received over very fast telemetry protocol between ESCs and the FC.

So doing this right is a kind of tricky ;-).

What I'm trying to do is a similar thing, but mounted on car. So I need to solve pretty much the same stuff, just my problem is a bit simpler. Right now I have Arduino nano 33 BLE, which is also Cortex M4, but slower. So ultimately I'm planning to move to Portenta H7, and program it in mbed directly. That should give me enough power and flexibility.

As for the IMU sensor, I still haven't decided which one.

There are ones that do AHRS internally (Bosch BNO055, CEVA BNO080/BNO085 and FSM-9, Redshift Labs UM7), but my biggest struggle with these sensors is whether they can provide data fast enough for this application. Betafligh typically samples gyro in 8kHz loop, and controls the quad in 4kHz loop. And the AHRS chips mentioned earlier often don't provide data faster than 100Hz (please someone correct me if I'm wrong). Should these chips be of any use, then NEED to provide data at least at 1kHz rate I believe. Because of that, I'm thinking about connecting separate gyro/accel and mag board (because of placement - gyro/accel into the center of mass, mag far from possible interference), and doing AHRS in software (perhaps use M4 chip on Portenta to run it, and do the rest on M7).

7

Many thanks for all of your answers, I found them very helpful!!!

jremington:
Why not tell us what you actually want to do?

You could start by explaining what this phrase means:

First of all I should maybe mention that I don't want to use an Arduino. As @hapIm pointed out already many commercially available flight controllers use relatively powerful u-controllers. I plan on using a board with an STM32H7 such as the one here:
https://www.st.com/en/evaluation-tools/nucleo-h743zi.html
It has a maximum clock frequency of 480MHz, which I hope should be enough to solve for example quadratic programs or the like also reasonably fast. My idea is then to mount the Nucleo and an ESP8266 on the helicopter. The ESP8266 would then simply serve as a wireless interface between the helicopter and my laptop, such as to plot data in realtime or the like. My ultimate goal is play with different types of controllers LQR/PID/H-Infinity/H-2 etc. However, all of these controllers rely on measurements, so I'd first need to select some sensors, install them on the robot and figure out how to fuse all of the raw measurements to get something useful out of it.

@Koepel Do you know how these AHRS filters are usually implemented? I skimmed over the Wikipedia article and it appeared to me as it being a relatively general term rather than a specific type of filter.

@haplm What you mentioned about the gyro seems rather scary! Do you know how these frequency domain methods perform in comparison with Kalman filters that include a model of the robot? This is at least the reason why I want to design the Kalman filter myself, since this incorporates information (from your model) which angular velocities actually make sense. Obviously the boards which fuse all measurements already don't know on what kind of device they are later being mounted and cannot exploit that information. What is your opinion about that?

8

You can find an excellent, very technical review of popular, open source AHRS fusion filters here.

Obviously the boards which fuse all measurements already don't know on what kind of device they are later being mounted and cannot exploit that information.

Provably, the best you can do is to write a Kalman filter specifically for your physical system, as that way you can include sensible estimates of noise sources. How to do that is very clearly described in the textbook "Optimal State Estimation" by Dan Simon. Kalman fusion filters require significantly more computational power than the non-specific approximations discussed in the review linked above, and are universally employed in aerospace applications.

On the other hand, consumer grade sensors are so noisy that such advanced filters aren't worth the computational cost.

9

Not sure how big is your helicopter, @felixcra, but nucleo h743zi seems to be a monstrozity. If your heli can accommodate that board, then it will be perfectly suitable to chops people's heads off :-)).

I've been thinking about reusing one of those betaflight boards for my project. I believe it should be perfectly possible, one just needs to figure out how to use betafliight bootloader (which is in ROM) to start your own code ;-). Plus you would have to figure out the layout, but each board has its own profile in GitHub, so it should be doable.

Theoretically, one could fork Betaflight, and extend it with whatever you like. It is not based on any RTOS, it is pure GNU Arm Toolchain (soo it is fairly easy to compile it). Which is a nice and ugly thing at the same moment. I took a look, and they pretty much re-implemented a RTOS. Just with no documentation. So it would be some reverse engineering to understand how it works. The benefit would be that you have all the base functionality there. You can think about it as about a "platform for controlling UAV".

It is sad that there's no lightweight framework that would help with PWM, UARTs, gyros, accelerators, etc. Looking around on this forum, everybody is trying to work with this, everybody is writing their more or less imperfect piece of software, while stripping down something like BF of iNav and documenting it a bit would be such a help for all of us...

Filters - the BF guys experimented with Kalman a lot, and ultimately abandoned it in favour of simple PT1 or BIQUAD. It was never proven that Kalman produces better results (with comparable latency) than those two. Lately, they do a lot of nice things with RPM filters...