High Accuracy Aftermarket IMU/Gyro

[sietse]

Hey @XYZEng !

I believe you’re totally in the same boat as me. I use the T500’s with the BasicESC200’s but I think either the interference comes from the high power current, or either from the T500 themselves in combination with the PWM signals.

I tried out the QMC5883L in an external enclosure. This seemed to be an improvement, but it still didn’t give me the rock solid stability I was hoping for. I’m currently experimenting with setting up a MTi NMEA Heading sensor. The integration within BlueOS went pretty smooth, but I now only need to figure out how to make sure that the Heading Sensor is seen as the primairy (and maybe also the only) yaw source in the compass system.

@tony-white any thoughts on this? I set up the Heading NMEA sensor as a GPS on Serial 3, with the NMEA protocol. GPS1 source in the compass tab is showing up correctly and being really nice and stable, but the actual EKF doesn’t really seem to do anything with the GPS1 Heading . I guess it’s due to a wrong EKF(3?) parameter setting?

I’ll keep you guys updated!

[jua123]

A question, I have the IMU away from the battery and the ESCs and everything is fine, but I want to add a second battery about 15 cm from the IMU position. The ESCs will remain far away, but although I have to do tests, I would like to know your opinion. Will the battery create magnetic interference for the IMU compass?

[sietse]

@sietse

I’m currently experimenting with setting up a MTi NMEA Heading sensor. The integration within BlueOS went pretty smooth, but I now only need to figure out how to make sure that the Heading Sensor is seen as the primairy (and maybe also the only) yaw source in the compass system.

@tony-white any thoughts on this? I set up the Heading NMEA sensor as a GPS on Serial 3, with the NMEA protocol. GPS1 source in the compass tab is showing up correctly and being really nice and stable, but the actual EKF doesn’t really seem to do anything with the GPS1 Heading . I guess it’s due to a wrong EKF(3?) parameter setting?

Hey @tony-white , I’m still trying to figure things out to have the GPS Heading as our main heading source.

In the meantime, I discovered the COMPASS_ENABLE parameter in ArduSub, which made sure that the other compasses weren’t being used at all.

Now, I’m looking to set it up so that the GPS Yaw Heading is either the priority or at least still part of the EKF, but as the first compass. Right now, it seems like the GPS Yaw Heading isn’t really participating in the EKF at all. It also can’t be dragged in the priority list, since it’s not appearing in the priority list. (It is visible and working though in the little compass visualizer)

Any ideas on what I could tweak to get this working?

Thanks again!

[tony-white]

Hi @sietse -
Below find python script and instructions that sends both GPS and heading information to the autopilot as NMEA messages. If you’re sending the same NMEA heading messages correctly, and have setup the autopilot to receive them correctly, then you should be all set! I would guess checking the parameters in step 5 should get your setup working…

The setup:

1. In BlueOS, navigate to terminal, take red-pill, and nano a new file named fake_gps_yaw.py, save (cntrl o) and exit (cntrl x).
2. chmod +X fake_gps_yaw.py
3. Edit the file (nano fake_gps_yaw.py) and on line 96, change the IP address of the vehicle to an interface it has a connection on - typically this would be 192.168.2.2 as this is the static IP on the Pi ethernet adapter by default, the example is what I used for my unit that is only connected via WiFi and received that dhcp address.
   response = requests.post(‘http://192.168.1.23:6040/mavlink’, json=payload)
4. Optionally edit the error message on line 101 to use the same IP address.
5. In autopilot parameters, verify that EK3_SRC1_POSXY, EK3_SRC1_YVELXY, EK3_SRC1_YAW, are all set to GPS. Also verify that GPS_TYPE is set to MAV.
6. Run the script. The vehicle will jump to the coordinates and heading described in the file, and update as the script runs - see the attached video.
   fake_gps_yaw.py.zip (3.2 KB)

[sietse]

Hey @tony-white!

Thank you so much! I’m definitely going to try this out!

Should the attached video be in the .zip, or here on the forum itself?

Thanks!

[tony-white]

Apologies, the steps were copied from an email, and so I hadn’t caught that a video was included. Enjoy!

[sietse]

Thank you so much @tony-white!

I was wondering if there is an easier way of getting rid of the EKF for compasses and just have a way where the Heading GPS is just ‘wired’ straight to be used as the compass for the ROV.

SO for example if you only want to use the MTi as a NMEA Heading Sensor Input as a full replacement of the other compasses. So basically for the yaw / heading, only the NMEA Data gets used instead of some sort of blend between the GPS, MMC5883 and AK09915. Would taht be possible? To get rid of the onboard compasses fully and only use the NMEA Heading?

[tony-white]

Hi @sietse -
The EKF is a requirement, but you can certainly disable the other compass sources so that only the external source is used. Simply disable those other sources at the bottom of the compass configuration page under Vehicle Setup!

[sietse]

Hey @tony-white

I attached a video where it’s visible that I disabled the use for both compasses, so only The NMEA Heading Sensor (GPS2) should participate in the Compass System.

As you can see the final Cockpit compass angle (EKF Angle), doesn’t fully match the GPS2 Angle. It seems to be off by 10(?) degrees. I also tried to set the COMPASS_ENABLE parameter to 0. This leads to the AK and MMC compass not showing up in the BlueOS Compass at all. But still, the EKF Angle doesn’t seem to fully allign with the GPS2 Angle.

[EliotBR (Eliot)]

@sietse

… I disabled the use for both compasses … But still, the EKF Angle doesn’t seem to fully align with the GPS2 Angle.

As I understand it the EKF also uses the gyroscope in its determination of attitude angles, to allow smoother, higher frequency updates than just those from the absolute orientation sensors (like a magnetometer and/or GPS setup for yaw, and an accelerometer for pitch/roll).

An EKF is a state estimator that tries to make practical sense of the measurements it’s receiving, factoring in uncertainty and changes over time. New samples contribute to its output, but it may not fully match measurements quickly (or ever) if it considers its state predictions to be within its estimate of the sensor error/inconsistency, or if the measurements are changing sporadically.

[sietse]

Hey @EliotBR !

So it’s not possible to fully (and only) use the NMEA Heading angle as the one and only input for the ROV’s Compass? I experience an offset between the final EKF and the absolut GPS2 NMEA Heading Data, which would mean that the use of 1 absolute heading source will always have an offset compared to the final heading angle shown in QGC or Cockpit (Because of the EKF System)?

The reason we’d like to use a external heading source is because we’d like to navigate as precisely as possible on the A50 DVL. I believe the ROV Position Estimate that’s ‘drawn’ in QGC and Cockpit is based on the EKF’s angles and the DVL’s velocities and then get calculated in the actual positions, right? So in order to get an as precisely as possible position estimate, we need a super precise Compass Angle all the time, right? For our system the internal compasses experienced too much distortion from the Electromagnetic fields, so we choose for an external NMEA Heading Sensor, with slightly more precise and a higher range of operating in terms of mGauss.

[EliotBR (Eliot)]

Another point of relevance - the offset you’re seeing may simply be a visualisation of the compass declination, which is typically determined by the world magnetic model built into the autopilot.

How and where this is represented isn’t well documented at the moment, so hopefully @williangalvani can confirm whether the EKF represents orientations relative to true north (versus potentially magnetic north for your external heading source). You could also temporarily turn off autodeclination to see whether this is the source of the discrepancy.

@sietse

So it’s not possible to fully (and only) use the NMEA Heading angle as the one and only input for the ROV’s Compass?

I’m unsure, although it is at least possible to deprioritise the gyroscope values by increasing its specified noise rate in the EKF, which may be worth trying.

@sietse

I believe the ROV Position Estimate that’s ‘drawn’ in QGC and Cockpit is based on the EKF’s angles and the DVL’s velocities and then get calculated in the actual positions, right?

The autopilot estimates its position by blending the sensor values and inputs it has access to / is configured to use. The visual odometry API that’s used by the Water Linked DVL BlueOS Extension provides translational velocities, which are then blended with other sensors in the autopilot’s EKF to form position estimates via dead reckoning, relative to the initial position specified in the Extension (or updated occasionally using a GPS module or similar).

The DVL is also capable of performing its own dead reckoning estimates, using its internal sensors, but that is not how it is currently integrated with BlueOS, and it’s unclear whether that would improve performance or just make the integration more complicated.

@sietse

So in order to get an as precisely as possible position estimate, we need a super precise Compass Angle all the time, right?

Dead reckoning integrates rate measurements into position estimates, so any errors in those rates get included in the integration, and any bias in the error becomes an integrated bias in the position (i.e. there is a drift between the actual and estimated positions, which increases over time).

Minimising that drift requires accurate, high frequency sensor values, with minimal latency, but there are often tradeoffs between those factors that make them difficult to achieve with any given sensor, so it can be beneficial to combine the strengths of different sensor types.

As an example, even with perfectly accurate velocity and compass measurements, the latency to communicate them to the autopilot and (more significantly) the time in between those measurements both contribute to uncertainty in the position. That can be somewhat mitigated by having high frequency inertial measurements in that time (e.g. from an accelerometer and/or gyroscope), but they have their own associated inaccuracies and imprecision, so there’s no perfect solution. That said, some information (even if somewhat noisy) in the time between more accurate and less derivative measurements from other sources is typically more accurate than just assuming linear or step changes.

@sietse

For our system the internal compasses experienced too much distortion from the Electromagnetic fields, so we choose for an external NMEA Heading Sensor, with slightly more precise and a higher range of operating in terms of mGauss.

Was this due to the ESCs/motors (which can be compensated for), or from sources of electromagnetic noise in the environment (which would require a different type of sensor to avoid)?

[sietse]

Hey @EliotBR!

Thanks you so much for the extensive reply! I appreciate it!

@EliotBR

You could also temporarily turn off autodeclination to see whether this is the source of the discrepancy.

I tried this, and even after rebooting it didn’t really seem to make a difference.

@EliotBR

Minimising that drift requires accurate, high frequency sensor values, with minimal latency, but there are often tradeoffs between those factors that make them difficult to achieve with any given sensor, so it can be beneficial to combine the strengths of different sensor types.

So in theory, you’d like to have the EKF using the GPS heading aswell as the integrated compass data? Or would you rather go for GPS, but with integrated compass fallback?

@EliotBR

That said, some information (even if somewhat noisy) in the time between more accurate and less derivative measurements from other sources is typically more accurate than just assuming linear or step changes.

I honestly didn’t think about this one! Really fair point!

@EliotBR

Was this due to the ESCs/motors (which can be compensated for), or from sources of electromagnetic noise in the environment (which would require a different type of sensor to avoid)?

Yes exactly! We’re using 4x T500 and 4x T200 Thrusters with custom batteries on 18V, limited to 90A total. We experience Compass drift when giving near full throttle. We experimented with the PSM, and had several ways of wiring the PSM. We tried out the Magfit Tool. This one measured 8000mGauss noise before using magfit and 1500mGauss after using magfit. In the meanwhile we did another revision on how we wire the PSM, so we hope to get even lower on the mGauss after using MagFit again.

The MTi would have served as a ful l replacement instead of usng the internal compasses. But Maybe we still need to use them like you said just to have some information in the time between.

My question is. If you’d just use and calibrate the two internal compasses, and you’d use the GPS2 aswell, how much is the GPS2 actually adding to the EKF?

[EliotBR (Eliot)]

@sietse

I tried this, and even after rebooting it didn’t really seem to make a difference.

Ok, probably unrelated then

@sietse

So in theory, you’d like to have the EKF using the GPS heading aswell as the integrated compass data? Or would you rather go for GPS, but with integrated compass fallback?

That depends - if it’s less accurate and slower than a compass then it’s not worth adding, but if it’s similarly or more accurate (and potentially subject to different sources of error) then including both in the EKF could make sense if parameters allow it.

Fallback is another option, and also makes sense to enable if possible - the magnetic fields may be misleading, but a compass is typically less likely to lose signal than a GPS module (because the compass itself would need to fail, instead of just losing communication).

@sietse

In the meanwhile we did another revision on how we wire the PSM, so we hope to get even lower on the mGauss after using MagFit again.

You can also use electromagnetic shielding if it’s relevant (which can be as simple as wrapping problematic wires/components in foil, albeit with some corresponding risks around accidentally contacting and shorting out other components/conductors).

@sietse

Maybe we still need to use them like you said just to have some information in the time between.

“Need” is a strong word, but if you have a couple of different options in mind it can be worth trying to test them to determine which gives you the most accurate results.

An integration test (like station-keeping or path following) can be a decent way of comparing setups that may be difficult to reason about theoretically (especially given the complexities of some real world environments and noise sources).

@sietse

If you’d just use and calibrate the two internal compasses, and you’d use the GPS2 aswell, how much is the GPS2 actually adding to the EKF?

In the ArduPilot case specifically I’m not sure, and I don’t currently have time to try to determine that from the code. There is some documentation available, but it’s not precise about contributions like this (although from what I understand only one of each sensor type is considered per lane, so it would likely only be using one compass at any given time - I’m uncertain whether/how it blends that with heading input from a GPS).

In general, an EKF is intended to use measurements and corresponding error estimates for each sensor to estimate states and corresponding uncertainties (factoring in growth over time), from which it can make predictions about the current state at any given point in time. How the measurement errors are determined depends on the implementation, but could be set manually via parameters (in which case the trust proportions can be directly tuned), or could be determined automatically using some kind of consistency/alignment metric (e.g. when there are multiple sources of similar data).

I already mentioned the user-definable noise rate of the gyroscope, but it’s possible GPS inputs instead base their noise on HDOP and accuracy values included in the GPS_INPUT MAVLink message

[XYZEng]

Hi @sietse
Your video is very interesting, you seem to have got the EKF to almost match the nmea compass,
Question, is this the exact unit you have? How do you make it ethernet connected?

Just to point out to anybody who hasn’t watched it, the black arrow (barely visible) is the GPS2 (nmea heading sensor), the light blue arrow is the EKF heading estimation.

Your NMEA heading sensor seems to be sending data at about 2Hz, and your EKF is being updated by your gyro at a much faster rate.

There is some discussion about the accuracy of the heading sensor not giving enough accuracy because it doesn’t poll quickly enough, so suggestion is to use the other sensors as a fallback.
But what you have there seems a lot better than what I usually see when operating the ROV (see below gif) and the idea of a slower or slightly delayed heading reading negatively affecting the EKF heading, I think is outweighed by how poorly my built in magnetometers are currently performing.

The ROV wasn’t moving at all when I took this, it was in the water with the thrusters on, but holding station.

I get the exact same behaviour on both of my ROVs, one uses 8x ESC500s and an aluminium enclosure (considering switching to acrylic to see if that improves things). The other is a blueROV with an acrylic enclosure.
I’m also considering putting an external ardupilot mag somewhere near the camera (further from the ESCs).

Since my last post about this
I’ve tried calibrating the magnetometers in BlueOS but it generally errors out at the end and I don’t think the values get saved. It’s quite an effort to calibrate (has to be done at home on my own), so I haven’t tried too many times. When I do I calibrate using QGC. I’ve always ensured to set up a GPS feed so the ROV knows it’s origin position.

Any suggestions would be greatly appreciated.

[sietse]

Hey all!

Thank you so much for the extensive explanation @EliotBR!

@EliotBR

“Need” is a strong word, but if you have a couple of different options in mind it can be worth trying to test them to determine which gives you the most accurate results.

This is a good one! We’ll test out some different setups. The Method with the path following could be a great way for us to compare the options.

@XYZEng

is this the exact unit you have?

Hey @XYZEng! We’re currently experimenting with a 600series MTi. We have it working over serial connection. It gives us NMEA, but over a serial connection!

@XYZEng

Your NMEA heading sensor seems to be sending data at about 2Hz, and your EKF is being updated by your gyro at a much faster rate.

To be honest, it’s has been some sort of bug during that session. After restarting the ROV, the GPS2 updated its values as fast as the other sensors. The MTi is set to give output at 10Hz. But yeah you got a fair point for the polling!

You got some interesting behaviour going on in that GIF! The T500’s / ESC’s really seem to have a lot of influence on the built in sensors. As Eliot mentioned, this could be handled by using Ardupilot’s MAGFIT Tool. Our plan is to rebuild our ROV at the moment, keep all the power cables as short as possible, get the right gauges, and perform a MAGFIT calibration / correction.

@XYZEng

(considering switching to acrylic to see if that improves things)

Please let me know what this does for you. I’m really curious on how the alluminum tube could affect those things!

@XYZEng

I’ve tried calibrating the magnetometers in BlueOS but it generally errors out at the end and I don’t think the values get saved.

I think this was only really properly configured since the ArduSub 4.5.3 / BlueOS 1.4.2 Update, so maybe in the meanwhile they got it working?

@XYZEng

I’m also considering putting an external ardupilot mag somewhere near the camera (further from the ESCs).

Last time I tried to configure an external QMC5883L to be just outside the electronics tube in a different enclosure. The calibration had to be done within QGC to get it all fully working.

[sietse]

Hey @EliotBR, @tony-white and @XYZEng ,

Just a quick update after extensive testing yesterday for a full day.
To specify my exact setup:

• ROV
• DVL A50
• Internal Stock compasses etc.
• NMEA AHRS

The NMEA AHRS is on Serial 3, as a GPS, with the GPS_TYPE set to NMEA. I’m able to view the Yaw angle in BlueOS and this exact angle hasn’t drifted over the day yesterday.

For the DVL, everything was properly set up, all the parameters etc.

We performed full accelerometer and compass calibrations in QGC. After, we calibrated the Gyro and Baro in the BlueOS Verhicle Setup Tab.

I’ve been operating the ROV for a bit to get a log file. And that logfile was processed into the ArduPilot MagFit Tool.

After loading in the Compass Offsets that we gained from the MagFit tool, our test could finally begin!

In our Compass Tab in BlueOS we saw that the GPS (NMEA AHRS) and the internal compasses were pretty much aligned. After operating the ROV for a while there was a huge drift from the internal compasses that almost caused in a 110degrees error comparing to the NMEA AHRS Angle. This NMEA AHRS Angle remained to be the correct angle.

I put the EK3_GBIAS_P_NSE parameter to the minimal value, put the EK3_YAW_M_NSE at max, put the EK3_GYRO_P_NSE at max aswell. All this to make sure the internal compasses had as tiny influence on the EKF as possible.

Allthough when looking into the BlueOS Compass tab, there was still a huge difference between the GPS arrow and the EKF arrow (about 60 degrees).

So I tried to switch off the compasses fully:
I tried to COMPASS_USEx = disabled
COMPASS_ENABLE = disabled
EK3_SRC1_YAW = GPS

This made sure that all internal compasses were fully disabled. It also showed me the following in BlueOS.

One of the lightblue arrows was the actual EKF moving. The other two seem to represent the two internal compasses which didn’t move and seemed to be fully switched off.

The EKF and the GPS2 Arrow did seem to move very nicely yogether with just a 2 degrees offset. At this point I was pretty satisfied with the results. Allthough after operating the ROV for another 10 minutes, the EKF and GPS arrow did offset way more into this:

Again the GPS2 (NMEA AHRS) angle was still giving the right angle.
I tried to use the Auto Declination, but it didn’t make any noticable difference.

One thing I also discovered was that when restarting the ROV, the EKF starts at 0 degrees and then comes a little closer to the GPS angle over time. And then after a while the EKF seems to drift away from the GPS angle again.

What we’d like to do is to fully bypass the internal compasses or atleast be able to properly put the NMEA AHRS as a very first priority for the EKF YAW. Our AHRS works awesome, but we just can’t seem to get that exact angle in BlueOS without the EKF drifting away from it and ending up with using false angles for drawing our paths together with our DVL Velocities.

[cmarq]

Hi @sietse,

One question I would have is, are you checking your gyro logs to make sure your gyroscope is functioning properly throughout the entire test? My gyro would occasionally jump to strange values on startup and if I calibrated those values out, then it would jump back to its normal values after 5-10 minutes thus rendering my EKF solution incorrect. I never dug too far into why this happened, I just always made sure to wait until my gyro reflected the “normal” readings I was used to, then calibrated. The offsets were on the order of 10, not 1000’s.

Just a thought because even if your external yaw is correct, incorrect gyro would still throw it off

[sietse]

Hey @cmarq!

Yes my gyro readings seem to be prett stable. When I calibrated it, the offsets were all between -10 and 10 if I remember correctly. After calibration, the gyro was really stable at 0, 0, 0.

I’ve been testing a little bit more today and I found out that as soon as the COMPASS_ENABLE gets disabled or the EKF_SRC1_YAW gets changed to either GPS or GPS with compass fallback, then every time the autopilot gets restarted, the EKF Arrow in the BlueOS Tab will be at 0 degrees at startup. That’s why I get random offsets allready at startup. The offset will slightly decrease over time, but it’s never stable and giving the same angle as the GPS (NMEA AHRS) does.

Is this a known bug or thing that the EKF gets set at 0 degrees when the AutoPilot is restarted (@EliotBR @tony-white)? It’s only when either COMPASS_ENABLE is disabled, or when EKF_SRC1_YAW is anything except for COMPASS.

[williangalvani]

@sietse

I’ve been testing a little bit more today and I found out that as soon as the COMPASS_ENABLE gets disabled or the EKF_SRC1_YAW gets changed to either GPS or GPS with compass fallback, then every time the autopilot gets restarted, the EKF Arrow in the BlueOS Tab will be at 0 degrees at startup. That’s why I get random offsets allready at startup. The offset will slightly decrease over time, but it’s never stable and giving the same angle as the GPS (NMEA AHRS) does.

Hi! can you share some .bin logs showing the drift? even better if you set LOG_DISARMED and LOG_REPLAY to 1 before recording it.