How can one input heading data from sources other than magnetometer?

I’ve asked our GPS guru to provide you some feedback.
Thanks, Grant.

So there are a couple of things with this. This is generally referred to as moving baseline, and is definitely on the future roadmap at some point. However what you are really getting out of this is the heading not the track over the ground. (That information is of course available as well, but not really what you are looking for here).

As far as ingesting the data, there isn’t any option for this at the moment. There aren’t any places to input the external heading information like this, and still fuse it with the onboard sensors. Unfortunately your proposal to use the VTG message won’t work as that message will simply be decoded as course over ground, rather then heading. This can start to lead to bad fusion of the data if the onboard sensors are measuring a different course because of a different in heading. (This would also give you exactly wrong information if you were ever drifting backwards).

At the moment I think you would need to get advice from @priseborough or @tridge to look at how to integrate the heading information. I’d say that adding a driver or modifying the NMEA one to understand the additional sentence is probably the easiest part, its handling the data at the AHRS level that needs to be addressed before making the data available is of use.

Thank you WS, and Grant, for your helpful attention to this thread.

Yes, I see the problem with injecting true heading (HDT) data in the place of course made good (VTG). Am I correct that, if you set COMPASS_USE = 0, so that the autopilot uses only GPS, then there is no “heading” entity, per se, used in the autopilot algorithm at all?

I still wonder why you could not use true heading data in the same way as magnetic compass heading, as long as you hacked it correctly, so to speak. (I got bogged down in I2C slave simulation when I went down that path.)

The question of VTG vis-à-vis HDT actually is the tip of a larger niggling question that I’ve had about autopilot algorithms: how importantly does heading information, as contrasted to course-made-good information, figure in an autopilot algorithm? After all, an autopilot program is by its nature an adaptive algorithm (quintessential cybernetics by the root of the word), meaning to say that it constantly corrects its response (outputs including steering and throttle) according to their effect (inputs including position, VTG or HDT, etc.). It would seem that the prescribed vehicle track vector is the ultimate aim and that to some extent it shouldn’t matter which direction, exactly, the autopilot thinks the vehicle is pointing, as long as it turns in the right direction to get back on the right track.

In fact I’ve wondered whether an aquatic rover autopilot algorithm needs to be significantly different than a land rover autopilot algorithm, in light of the greater possibility of crabbing due to current or wind.

Experimentally I’ve found that the autopilot adapts fairly well to wind and current except in turns, but I’ve found that if the compasses are not well-calibrated the autopilot can scarcely follow a mission course. Just to pursue the academic question of the importance of accurate heading, maybe I will try setting the local magnetic declination off by increments, to get a sense of autopilot adaptability…

As an advance apology for tardy acknowledgement of any feedback, my wife and I are going “walkabout” in the nearby mountains for a week.

On-water trials in September using the aforementioned Hemisphere VS-101 for position (but not for heading), while alternatively using Pixhawk on-board magnetometer for heading or using no heading at all (COMPASS_USE = 0) convinced me that the autopilot does not do well with GPS-derived CMG alone; heading data seems to be essential.

At the same time, trials alternatively enabling or disabling the Kalman filter (EK2_ENABLE = 0; I didn’t know to try AHRS_EKF_TYPE = 0) convinced me that, in the case of my small catamaran, the Extended Kalman Filter does little to improve tracking. This could perhaps be in part because the GPS used for position incorporates its own filter for its transmitted position (as well as for its transmitted heading and roll or pitch). But I wonder if the multi-parameter EKF/EK2 is really appropriate for a relatively slow-moving boat, differing from a ground-surface rover or a 3-D aircraft? Maybe there ought to be a simpler arduboat code fork…

Anyway, I’ve undertaken the daunting challenge of learning enough C++ in general and ardupilot code in particular to at least “ingest” HDT data instead of the 3-D magnetic field vector data.

I’m trying to work in a Windows environment using Eclipse and the px4 toolchain. Since the “PX4 Software Download” part of the toolchain does not seem to fetch all of the essential source code, I assembled a resource tree like this, but when I attempt to build (as yet unmodified) APMrover2 px4-v2, it fails quite quickly with this compiler/linker error report.

I guess I’m drifting out of arduboat-specific topics into developer questions, but wanted to lay out “the rest of the story” as it presently stands for me, on the topic of improved heading input options for water-borne Autonomous Surface Vehicles), with hopes of helpful feedback!

I use Linux, not windows but looks like you haven’t checked out your git repositories correctly. Did you do the following?

git clone https://github.com/ArduPilot/ardupilot
cd ardupilot
git submodule update --init --recursive

Lots of info here:

http://ardupilot.org/dev/docs/building-the-code.html
http://ardupilot.org/dev/docs/where-to-get-the-code.html

Thanks, Grant.

@gmorph, kind thanks to you, Grant: your suggestions led to a bit of a breakthrough for me; for the first time I succeeded in building APMrover2.px4 from source.

I did study (again) the two helpful pages that you just suggested, but essentially the “git clone https://github.com/ArduPilot/ardupilot” command, issued in a MINGW32 console window from my c:/pixhawk_toolchain/Firmware directory, evidently was key to obtaining the required resources in the right places so that “git submodule update --init --recursive” then completed the process successfully enough that “make px4-v2” (in the MINGW32 console from AMProver2 directory) carried through to produce the APMrover2-v2.px4 executable. When uploaded to the Pixhawk via Mission Planner, it ran as expected.

I started a sort of fork discussion in the “General” category on this general topic since I regressed from the original question concerning alternative heading input.

As said in the other discussion, I’m convinced to take up Linux as well, but for completeness I’ll say that what I did so far was in a Windows XP OS within the aforementioned MINGW32 “PX4 Console” that comes as part of the Pixhawk toolchain for Windows (whose “PX4 Software Download” tool appears not to accomplish what your three lines do accomplish!)

Now I have a Rover question that may be an Eclipse question in disguise:

With an ardupilot project set up properly, why would one see the untouched source code riddled with Eclipse IDE - detected “bugs”, for example line 317 of APMrover2.cpp,

mavlink_system.sysid = g.sysid_this_mav;

for which Eclipse says “Field ‘sysid’ could not be resolved”, or line 732 of AP_Compass.cpp,

    _declination.set(radians(

for which the function ‘radians’ could not be resolved?

Many thanks,
Pete

Is that error happening when you compile in Eclipse or is Eclipse being helpful and pointing out those errors. If its the former it will be something to do with the linking I’m gunna guess. mavlink_system is defined as an extern in GCS_Mavlink library so if the linker can’t find it your going to have that kind of error. So when you build waf knows where everything is but Eclipse does not.

Thanks, Grant.

Thank you again, Grant. I’d say the answer is the latter: Eclipse is being helpful and pointing out what it reckons are errors in the project code. The given example “bug” messages appeared on mouse-over certain Eclipse-perceived problem spots in the source code, but the specific examples with line numbers are probably unhelpful since ardupilot code is ever-changing, and I now have a whole new set of Eclipse-perceived problem spots throughout the ardupilot project, having fetched all the latest and greatest since a couple days ago sigh

In my past (limited) code-writing, I’d used simple text editors, but I decided to “get with the program”, learn to use Eclipse and avail myself of its potentially helpful capabilities, such as that of displaying the external origin of an expression on mouse-over. But if Eclipse doesn’t know where everything is, I’m kind of stuck with manual searching, trying to construct a mental map of the formidable body of code that comprises ardupilot.

Incidentally, the “CTD Build Console” pane in Eclipse indicates that it uses “make px4-v2” to initiate build, just as I had previously done (with success) from the bare MINGW32 console window. I don’t see that waf is invoked at all, but I understand little about this, even as I attentively watch verbose build progress messages!

Near the end of Eclipse build messages, I see:

fatal: not a git repository: c:/pixhawk_toolchain/Firmware/ardupilot/modules/PX4NuttX/nuttx//…/…/.git/modules/modules/PX4NuttX
Failed to get nuttx hash

I don’t even understand the odd double slashes, or multiple jumps back up, in the path expression …yet it must not have been fatal in the bigger picture, for the final message is the following:

PX4 APMrover2 Firmware is in APMrover2-v2.px4

Anyway, I guess I’ll carry on with Eclipse, with the original aim to accommodate NMEA HDT true heading input to be used instead of magnetometer for rover steering.

Thanks,
Pete

@gmorph and all interested,

I did take up trying to work with ardupilot code using Linux (and Notepad++ instead of Eclipse, via the “wine” virtual Windows environment), but alas, breadth of effort has not really afforded me greater depth of understanding.

Still wishing to do without magnetometer compass for heading, and to use heading as NMEA HDT from a dual-antenna GPS, I wonder what approach would be most in conformance with present ardupilot code development:

  • creation of a new class for such a “sensor”, even though, in the cases I would be working with, the data would be provided by the same device as that which provides position?

  • amending Compass class?

  • amending AP_GPS class?

To be honest I’m about to start from scratch because I’m drowning in the sea of ardupilot code for all possible platforms, while a boat that is equipped with a survey-grade position- and heading instrument can probably do without EKF, not to mention a host of sensors pertinent to 3-D flight with rapid 6-degree-of-freedom motion/attitude that might affect autopilot course.

Anyway, I invite fresh thought and suggestions!

ArduPilot already supports running without a compass. Make sure your using the lastest Rover beta or running from master. If you set all the COMPASS_USE parameters to 0 it will still log that compass information but will only use the GPS for heading.

NOW, unless you have a very expensive multi-antenna GPS which can do phase calculations to determine YAW when stationary the Rover will have no idea of its orientation when it first starts. It assumes its facing north when it first starts and then once it starts moving it eventually can figure out its yaw from the GPS and start navigating much better.

If your trying to integrate one of these fancy GPS units you want to create a new AP_GPS driver for it and have it have an API that says it supports stationary yaw and then the EKF can interrogate this and incorporate it into its calculation.

Hope that helps a bit.

Thanks, Grant.

Thank you again, Grant. I had done some trials in early September with all COMPASS-USE parameters set to zero and observed that ardupilot did not work well at all for my skid-steer catamaran arduboat using GPS alone.

I am indeed specifically interested in integrating heading data NOT from magnetic compass. I have (lent to me) a Hemisphere VS101 as mentioned earlier in the thread, which does calculate a static heading based on phase-ambiguity resolution with a known antenna separation and orientation with respect to vessel head. It has internal sensors and filters such that I’d like the autopilot to use its position and heading data (serial NMEA GGA and HDT) more or less directly.

Thanks for the thoughts along the line of creating a new AP_GPS driver and the part about it having an API that says it supports stationary yaw. I had been worried that it might be impractical to sever the connection between “yaw” and “compass” in the established ardupilot framework.

Cheers,
Pete

Hi all,

It may be that this proposition belongs in the “Development Team” category of discussion, but it is sequential to this thread.

I’d like to propose some sponsorship of development of the desired capability to use NMEA HDT heading input instead of magnetometer heading input. As elaborated previously, this would be for an “ArduBoat” (small skid-steer Autonomous Surface Vehicle) equipped with dual-antenna GPS heading- and position instrumentation with its own INS- and filtering aspects. Sad to say, I haven’t been able to catch up with the ArduPilot code complexity enough to be able to enjoy experimenting with substantial desired modifications myself.

Thanks,
Pete

1 Like

Hi Pete. I’ve sent you a message to discuss this further.

Thanks, Grant.

Hi Guys,

I am also interested in this topic. If you can include me in the discussion.

Jader

Hi all,

As said way back in this thread, I’m very interested in the question of the essential role of heading data in the whole autopilot algorithm, as well as the question of the essential role of EKF for the case of a water-borne rover which might employ position and heading data that are already Kalman-filtered.

So I did some test runs using 3.2.0-dev firmware, for the four cases:

  1. Using EK3 and compass (Pixhawk internal magnetometer);
  2. Using compass but no EK3;
  3. Using neither compass nor EK3;
  4. Using EK3 but no compass.

Position input was from uBlox GPS/compass but its magnetometer was not enabled.

I used 3.2.0-dev firmware because I found that there was apparently no “target heading” for the autopilot with EKF disabled in 3.1.1 firmware!

To disable EKF I would set AHRS_EKF_USE=0 as well as EK3_ENABLE=0. To disable compass I would set COMPASS_USE=0.

Coarsely-viewed, the autopilot performed remarkably well without EKF and/or without compass, as illustrated by the tracks for

  1. EK3 and Compass enabled.
  2. EK3 disabled, Compass enabled;
  3. EK3 disabled, Compass disabled;
  4. EK3 enabled, Compass disabled.

Graphs of RCout for the port (ch1) and stbd (ch2) thruster motors of this skid-steer ArduBoat better illustrate differences in the smoothness of control:

  1. EK3 and Compass enabled;
  2. EK3 disabled, Compass enabled;
  3. EK3 disabled, Compass disabled;
  4. EK3 enabled, Compass disabled.

It seems noteworthy that RCout is smoothest when both EK3 and Compass are enabled

Log files for the four cases are posted:

  1. EK3 and Compass enabled;
  2. EK3 disabled, Compass enabled;
  3. EK3 disabled, Compass disabled;
  4. EK3 enabled, Compass disabled.

I welcome any thoughts on what is essential vs. what is superfluous for this vehicle, or any thoughts on what may be happening “behind the scenes” (since the source code is very difficult for me to grasp as a whole).

Thanks to all,
Pete

Hi Martin,do you ever try to use external nmea compass like Airmar h2183?

Hi Arwah,

Yes, I have used external compasses as well as ship gyros and dual-antenna GPS which output heading data, usually available as NMEA 0183 “HDT” sentence. I have not used the Airmar H2183. To the best of my knowledge it is does not measure true heading directly but relies on an internal magnetic compass, and as such offers nothing that the Pixhawk, for example (with its onboard 3-axis magnetomer and 3-axis accelerometer and 3-axis gyro), does not already incorporate.

For some purposes, one might want to avoid reliance on magnetic sensors for heading data, or one might want greater accuracy of heading data than that offered by the so-called MEMS (Micro-electro-mechanical system) ICs upon which the Pixhawk and Airmar rely. For those purposes one might want to use a dual-antenna GNSS system, that yelds heading accuracy ~0.5° or less, or even a true ship’s gyro; not a MEMS “gyro” that might actually measure directly angular velocity, but which is not sensitive enough to measure Earth’s angular velocity, and so is not practical for deriving true heading.

Pete

2 Likes

Pete,

I would also be interested in some for of sponsorship for a solution to using NMEA HDT data instead of i2c mag data for drone heading.

Do you know if this has been solved?

Regards,

Gabriel

1 Like

Hi Gabriel,

As far as I know, this Github site would be the place to follow for the latest on merging the fork of ArduPilot code that accommodates heading data:

GPS: support yaw from GPS

Grant Morphett (@gmorph) did a lot of work on this, and I would say that yes, this has been “solved”, insofar as HDT can be “ingested” and used in the ArduPilot Extended Kalman Filter.

I’ve only proven a particular build (406bd1d1) of version 3.3.0-dev Rover for PX4-v2. I’ve given up trying to grasp the whole of ArduPilot code or even to build ArduPilot firmware from source.

I’m not sure when you say “I would also be interested in some for of sponsorship…” whether you are looking for solutions, understanding, or money. For my part, I’ve gone in a different direction with autopilot code for boats.

Pete

1 Like

Grant, when I make all of the COMPASS_USE# parameters = 0, the pixhawk appears to use more than just GPS to determine the heading. I came to this conclusion because the “GPS track” in Mission Planner did not match the “Current heading”. The GPS track seemed to be doing exactly what I expected, but the overall heading was not behaving predictably. I assume that it is also being influenced by the IMUs in the pixhawk. I would like to only use GPS for heading. Is that an EKF parameter? Thanks