Hello guys! Did anyone ever try to use an external heading, from GPS_INPUT or ExternalNAV system, to the ardupilot? Is there a way to make the EKF to blindly follow the ExternalNav heading?
For my case, there are some drifting and offset with the ExternalNav heading overtime. Even though the offset is negligible, I just wanted to know if its possible to tell the ekf to blindly follow the ExternalNav heading?
Thanks!
Hi @jmrobsam,
This doesn’t completely make sense, because the EKF still needs to predict the heading during the time between the measurements. The other sensors are also used for comparing whether changing values are consistent with other components of the vehicle’s state and motion.
There are several noise-related (*_NSE) EKF parameters, and depending on how you adjust them (and the data sources your vehicle has available) you should be able to increase or reduce relative trust of a given input type, which then changes which ones most strongly influence the state estimates.
Hey @jmrobsam ,
I’ve asked this question multiple times on this forum, but I never got an extended answer on how we can make this work. We’ve been testing different DVL systems. These work great for their position-hold functionalities, but as far as the actual map positioning goes, the ROV will always use the DVL’s velocity (speed) over time to make a distance estimate. The specific direction (angle) is determined by the EKF. The onboard magnetometers and IMUs are often far too sensitive to power-related external influences and will drift quite quickly over time.
Due to this drift, the position estimates on the map are not reliable at all. So the use of durable DVL systems will always be somewhat limited by the EKF (onboard magnetometers, IMUs, etc.).
I’d love to find a way to at least hardwire the NMEA heading we get from our external sensor into the Cockpit Compass and make sure the map position estimates are driven by the DVL’s velocity in combination with the external NMEA heading, and not the EKF heading. Are there any ways to change the actual variable inputs to the Cockpit Compass Widget and the Map Position Estimate? (@EliotBR @tony-white @williangalvani)
These were some topics I was active in, but it never lead to a proper solution (I was even left on read for most of them):
Ideally these can be minimised by keeping the flight controller away from any asymmetrically variable magnetic fields, like the DC currents from the battery, and through the power wires.
That aside, it may be possible to compensate for this in software, at least to some extent. I’m aware ArduPilot has a feature for it, but I’m yet to properly determine whether ArduSub actually makes use of it.
I’m in the process of enabling some other motor compensation functionality that ArduSub has had parameters for for years without actually supporting the functionality, and I think I may have seen in some of the related code that this could also be where that compass motor compensation gets applied.
Not currently, but having selectable data sources (for all the widgets) is definitely where Cockpit’s data-lake functionality is headed.
That said, I’m curious what value it would provide for Cockpit to have more correct displays in its widgets than the autopilot is reporting? That seems likely to cause confusion, and be difficult to make use of, but I’m also not aware how you currently engage with data from your vehicles - curious what your needs and desires are there.
If it’s relevant, it is already possible to control which variables get recorded in the video recording telemetry files, but I suspect that’s mostly helpful for locating imagery during video playback, rather than any kind of more detailed data analysis / processing.
Sorry about that - we’ve followed up on the one that seems most relevant.
We admittedly don’t have robust processes at the moment for keeping on top of longstanding issues raised in the forums, especially if they end up spread across different threads, are waiting on different people, and/or involve topics that are hard to track down / test, or that we don’t have a super thorough understanding of. There are definitely some that slip through the cracks, which never feels good for anyone.
I enabled the “Mark unread” option for forum topics a while ago, hoping to help with that, but that’s still reliant on us filtering through our unread posts every once in a while (to find ones that should get attention vs ones we just thought were interesting / wanted to read again), which is an exercise we rarely have time for.
GitHub Issues are what our software team’s investigative and development efforts are prioritised around. While we try to raise them for anything that seems important to our user base and isn’t being immediately fixed, that doesn’t always happen, especially when it’s unclear whether a problem under investigation could be a configuration/usage issue, vs being a bug, or a feature that is yet to be implemented.
I would note that it’s especially helpful if we have a clear understanding of what an issue is preventing you (and others) from doing, and/or the value resolving it would provide. That helps us understand how important it is, and suggest potential workarounds if we can think of any.
If you feel an issue you’re having is in a limbo state but isn’t getting attention, I’d encourage you to reach out for an update, or raise a GitHub Issue if you feel like you have sufficient information to do so. If we’re intending to work on it but are struggling to find time, or we decide we can’t dedicate resources to it at the time, then we can at least communicate that, and if it’s something that got lost then it can spur us to return to it / put it back on our task list.
Hey @EliotBR,
First of all, thank you so much for the reply. I really appreciate it!
I’ve been looking into the Power Compensation info that you provided. With that being said, I’ve been experimenting in the past with the MagFit Tool aswell. It looked like it gave us a more stable outcome, but there still seemed to be some drift. I’m looking forward for the Bi-Directional Slew features for that compensation.
That sounds amazing! I tried to get the GPS Yaw from the Datalake and feed it into my DIY Compass widget. I believe I got that working at the time, but due to not being able to change the input variable for yaw for the Map Positioning estimation, I didn’t further experiment with it.
Thank you so much, I really appreciate it! 
Some drift is inherent to using a DVL (or any integrated positioning sensor). That said, I understand it may be hard to determine whether the drift you’re experiencing is inherent to the device you’re using, or is caused by integration with autopilot’s sensors / algorithms.
Indeed - I don’t imagine displaying a different compass heading in Cockpit to be particularly meaningful if it’s not also being used in the autopilot’s position estimation.
It’s quite possible we’ll have a way of indicating other object positions and headings on the map before it’s possible to change the main vehicle’s details, so I suppose if you’re doing your own dead reckoning with just the data you want to you could potentially use that to compare to the autopilot’s ones.