Hi guys,
We are looking to upgrade the position estimation of the blueROV2. We plan to order a Waterlinked DVL soon and want to also upgrade the IMU/gyro onboard.
What is the highest precision IMU/gyro sensor available that has been tested and verified with the blueROV2? Want to try and get something that will pose minimal integration issues
Let’s say our budget tops out at around $3-5k.
Hi @cmarq,
I’ve asked about this internally and will get back to you if there are any in particular that we know about or have tried.
I’m told we have an xsense mti that we tried to integrate as an external AHRS during Navigator testing, but ran out of time to get fully working.
For minimal integration work you’ll likely want a sensor that’s already supported in the ArduPilot codebase, in which case I recommend starting by checking the AP_InertialSensor library 
Hi Eliot,
That is useful info. What would be the process for integrating an external IMU if it is included in the AP_InertialSensor library?
I was assuming it would be auto-detected once connected to an appropriate port, but that may not be the case. I’ve since been told
We have apparently previously tried to integrate an “xsense mti” during Navigator testing, but ran out of time to get it fully working. “yost” and “PNI” are other potentially relevant suppliers, but I don’t believe either has an existing integration with ArduPilot.
Hi Eliot,
Per your last response, we went ahead and purchased an ADIS16475 IMU to integrate into the blueROV2. This IMU has a driver written for it already in AP_InertialSensor.
Are you saying that there is not going to be any hope to integrate this IMU into the system even with the driver already existing in Ardupilot?
If that is the case, we are within our return window, so we could return it and go for a vectornav AHRS system that has driver in AP_ExternalAHRS. Am I correct in understanding that even with the AHRS, there are no examples of someone successfully integrating an external AHRS into the blueROV?
After some reasonably extensive internal discussion, my latest understanding is:
AP_InertialSensor libraries can only be used by autopilot boards
AP_ExternalAHRS libraries support External AHRS systems, which can be used to completely replace the AHRS, or to replace some inputs to ArduPilot’s EKF
It’s not so much “no hope of integrating” as “integration would require some firmware changes, so you can’t just plug it in and set some parameters to get it working”.
We’re not aware of any examples of it. That said, the one we were trying to integrate wasn’t already supported by ArduPilot - it should be simpler to set up an external AHRS that already has firmware support, and that will have been done successfully with other vehicle types (otherwise the option wouldn’t already be available).
Hi Eliot,
Everything you said there makes sense. I guess I would prefer to integrate the IMU into the system since we already have it. I found in AP_InertialSensor.cpp around line 1000, there’s a switch statement with different board types and each type calls one or two of the existing InertialSensor drivers. Could you not just change out the Pixhawk IMU for the ADIS1647x?
If this may be difficult and an external AHRS would be much easier, just say the word and we will opt to go that route, but I’m willing to change some firmware around to make the ADIS1647x work if anyone there has an idea of what path to take
Hi Eliot,
Do you have any suggestions on how to adjust the firmware to accommodate the external IMU?
I have added lines to probe for the ADIS1647x IMU. My issues are that I am unsure how to determine the last argument of probe, which is drdy_gpio (data ready gpio). My understanding is that this is the GPIO of the SPI port on Pixhawk that will be connected to Data Ready pin of sensor.
If this understanding is correct, I can go ahead and hook up the IMU to the SPI port and run the generic_INS example located at /ardupilot/libraries/AP_InertialSensor/examples/
I asked about this to confirm, and was told
As a couple of additional points,
INS_POS* parameter descriptions:
The IMU should be located as close to the vehicle c.g. as practical … Failure to do so can result in noisy navigation velocity measurements due to vibration and IMU gyro noise.
Not beyond those I’ve already provided. This isn’t something I’ve had to do before.
That interpretation seems reasonable to me. I can ask about it if you want, but it may be simpler to try it and look further into it if it doesn’t work as expected.
Discussion this far into the weeds of the ArduPilot codebase may be more fruitful in the ArduPilot developer chat.
I expect if it’s working correctly it should also show up in the “Sensors” section of QGC’s Vehicle Setup/Summary page
Dear Eliot!
Recently I saw your post about integrating the xsense MTi.
We’ve been having issues with our internal compasses due to interferences of high current devices within our enclosure.
Due to the compass issues, our map position (which is determinated by the combination of our DVL’s velocity and our compass’ axis) is almost unusable.
The idea is to use a MTi3 (we have one laying around) as a external AHRS to improve our yaw accuracy. I’ve been trying to setup a serial connection via UART, but I couldn’t get it fully working.
I set the Serial3_protocol to AHRS and I set the EK3_SRC1_YAW to ExternalNav. I also tried setting the Serial Protocol to GPS and then selected ExternalAHRS as GPS type. For one second I thought it worked, but when in the verhicle setup tab, I got a MAV Fail error which didn’t let me calibrate any of the compasses.
I also tried to set things up using I2C, but I couldnb’t configure anything properly with I2C on the Navigator.
What would your reccomendations be regarding external AHRS / IMU / Magnetometers to improve Yaw Accuracy?
Hi Sietse,
I was the one who originally asked Eliot about this issue. Since then, I have successfully integrated an external compass without vehicle and it has completely alleviated any position estimation errors we were having.
I utilized BlueTrail Engineering connectors, a QMC5883L magnetometer and a custom 3d printed enclosure to add the compass to the exterior of the vehicle.
I did not have to do any significant changes, the compass was detected over i2c and I can calibrate it just as the other compasses on board.
If you would like any more info/cad files/etc, let me know
Hi @sietse -
The MTi3 is likely not a supported compass by ArduSub, as the QMC5883L is - it isn’t present in this listing at least!
It may be possible to get it working, but you would need to correctly configure the device interface (i2c may be better?) and then modify ArduSub firmware to support it… therefore it may be easier to use an already supported device!
Hey @tony-white and @cmarq,
Thank you so much for your replies! I’m gonna try out the QMC5883L myself!
I saw the QMC5883L mainly works on I2C. Will it gonna be a plug-and-play situation by just connecting the QMC5883L over I2C and it will pop up on the compass tab itself?
I’ll probably set the QMC5883L as the first compass or even fully ditch the onboard compasses. Since I’m also using a DVL, I’m expecting a EKF3 wouldn’t be working if the QMC5883 is added to the system? Is it better to setup EKF2 (DVL + QMC5883L)?
I’m curious what your suggestion would be!
Hi @sietse -
It should indeed be plug and play, via I2C. There is no reason to touch the EKF settings - the values from it will automatically be used by the appropriate EKF. If you don’t want to use other compasses, simply disable them in the Vehicle Setup page, under configure, compass.
Hey @tony-white and @cmarq.
I’ve been trying to integrate a QMC5883L module into out system over I2C, but I stumbled upon some issues.
I’m able to view the QMC5883L into the BlueOS Compass tab. I tried to set the compass as a external compass, but I could not get the right orientation so that the module worked properly in it’s yaw axis. I also trid to use the ForcedExternal mode, but I wasn’t sure what this mode really means.
I have the module hooked up to a spare RBPi with a spare navigator just for development purposes, but trying to do a full calibration using GeoIP (indoors) really got me a full red bar for the QMC5883L module. I guess this is due to the fact that BlueOS isn’t reading the right axis from the QMC5883L?
FYI if I point the module towards the nose of the navigator then the pitch axis of the QMC5883L does control the Compass. I assumed that I needed to choose Roll90 in order to get the right axis, but this didn’t work or changed anything. I also tried multiple other orientations.
Am I looking over a detail right here? 
Hi Sietse,
I had to try a few things before getting the orientation to work correctly as well. A couple of thoughts
Another note, after you change anything in these settings, I would always do a quick restart of the autopilot just to be safe and make sure it takes effect
My suspicion is that you have your compass orient set with respect to the roll90 axis and not the vehicle axes so yaw motion of the compass equals pitch motion and vice versa
@tony-white, feel free to jump in and correct anything that I am mistaken on
Regards,
Cody
Hey @cmarq ,
Thank you so much for these advices!
Like you mentioned, I have my Navigator setup as Roll90 aswell. I thought the QMC5883L must be set with respect to the navigator axis.
I tried to orient my QMC5883L with its X-axis pointing to the back of the ROV, and set the YAW180 orientation, but without succes.
I do restart the ArduPilot with every parameter change, allthough it seems like the compass in BlueOS does not register the right axis.
I tried changing the physical orientation of theQMC5883L aswell, but without the right results.
FYI: this is the model I got
Also during compass calibration, the standard two compasses are calibrating well, but when those are calibrated after reaching the 100% bar in BlueOS, the bar goes back to around 40% and gets stuck. This way the QMC5883L isn’t able to get full calibration. This is probably due to the fact that the right axis isn’t used.
@tony-white Am I missing some steps in the process?
Thanks a lot!
Hi Sietse,
Sorry you’re still having issues. That is the exact module that I am using as well. Are you able to look at the magnetometer readings in QGroundControl? you should be able to see what number your compass is set to (1, 2, 3) then look at the magnetometer readings to make sure it is outputting data
If that is working, my recommendation would be to check your parameters with some important ones that I have set
COMPASS_EXTERN2 0
COMPASS_EXTERN3 0
COMPASS_EXTERNAL 1
COMPASS_OPTIONS 0
COMPASS_ORIENT 12
COMPASS_ORIENT2 0
COMPASS_ORIENT3 0
COMPASS_TYPEMASK 0
COMPASS_USE 1
COMPASS_USE2 0
COMPASS_USE3 0
Additionally, in BlueOS on the vehicle setup->compass page, if the QMC5883L is being recognized, make sure you drag it to the first compass and make sure it is enabled.
Finally, I have never been able to get the magnetometer calibration to work properly on the BlueOS side. I always do it from the QGC sensors page, I would recommend trying that
Hey Cody,
Thanks you so much! My issue was that I was trying to calibrate it within BlueOS, not QGC. It’s fully working now and I saw that ArduPilot has set te compass orientation to the right parameter itself! after full calibration!
Additionally I set the ORIGIN_LON and ORIGIN_LAT parameters aswell (using ArduSub 4.5.0).
Thank you so much again!
