I just set up an Emlid M2 with ArduCopter and everything works fine, I get a stable RTK position, but I see a huge offset in the altitudes of what the M2 and what ArduCopter reports, in my case it is about 47 meters! Why is this? Does Arducopter convert GPS altitude to a different datum? Can this be disabled?
The Here2 and the Emlid both show around 744m in the ArduCopter logs and telemetry.
The Emlid onboard logs and Emlid GUI show a value of around 791m.
I also tested different GPS receivers and they all show around 740-760. So my “issue” is probably with Emlid. I´ll see what I can find on the Emlid forums…
I had the same issue 4 years ago. The solution was to patch Ardupilot`s code because of the Emlid bug. At the time their reference was different from other GPSs, and that made it hard to use two different GPS brands in Ardupilot.
But update the EMlid FW, it might have been fixed now.
I am on the latest FW. For ArduCopter it is probably better, that Emlid also reports the same altitude than other GPSs. But I want to do some live altitude measurements and for that I would need the altitude, that Emlid logs. Here is another short test now without RTK corrections:
I got a response from Emlid and it seems that the difference comes from the NMEA standard. In the GGA messages there are two fileds, that are relevant:
Orthometric height (MSL reference)
Geoid separation
These should be summed up to get the ellipsoidal height (what we want). ArduCopter only uses the orthometric height. Unfortunately ArduCopter doesn´t do anything with the geoid separation data (so it´s not transmitted via telemetry).
I don´t think it´s that easy, certainly exceeds my capabilities. Every type of GPS driver would have to be adapted, as far as I understand. The NMEA one is straight forward, but what about the others, do they even report the geoid separation or the already the correct geoid altitude?
You just need to fix the emlid binary GPS device driver, all the others are fine.
I fixed it a while ago by adding a constant 55m, but that was harcoded to a specific location here I was operating. Now I no longer use Emlid products, so I do not need that hack anymore.
Well, that´s the thing. All other GPS types also report the same height as Emlid (which should be the case for GPS switching and blending). And besides I´m using NMEA, since ERB is depreciated according to Emlid.
So either all or none should be changed to retain compatibility between different GNSS receivers.
when I tested it ERB height was different from UBLOX and from Septentrio. How di you test your theory? When did you test it? With which systems did you test it.
If I read the NMEA output of a GNSS receiver, the geoid separation value in the GGA sentences is exactly the difference, that I am observing.
Arducopter always shows about the same GPS altitude (probably the ellipsoid height) between different devices. I see this on a standard nmea, ublox, emlid(nmea) and UAVCAN devices.
But for my application I would need the other height information (the same one, that is displayed in ReachView and is used for surveys). I have found a workaround, that works in most cases, I simply save the difference from when the copter is on the ground and just subtract the difference.
@Hoehenarbeit,
Welcome to the club…
These kind of discussions usually end up to nothing.
We (surveyors), usually need “clean” elipsoid heights or above geoid to make use of the ekf interpolation of pos estimates end deliver our data in a local/projected datum.
Though I tried a lot, there seems to be a hard coded use of EGM96 in exported/used altitudes, thus rendering impossible to properly transform the heights. That’s why (even after L1/L2 capable receivers like F9P) everybody is using third party stand alone RTK like emlid or septentrio etc. to georeference their RTK survey data.
If you log the RAW GPS data you will see desired alts.Then again, you want be able to match it with trigger pos estimates.
Hopefully a dev could explain what is what and we could leverage some potential.
I have the same problem than you using a reach M2 rover + RS2 RTK base and mission planner log for USV single beam bathymetric surveys. What we cannot explain is that when we started using the USV, the height output in the MP log was fine but we started having an unusable orthometric height from a mission mid-2021. I cannot tell if this is related to an update on emlid side (they say that it is not) or on mission planner side.
Emlid told me that they use an EGM96 grid but when I look for the EGM96 value of my survey area on a web tool, the values do not match. The only temporary solution we have for now is to log the NMEA log from the M2, check the mean geoid height in the area and apply the offset to the survey results. This is nonetheless only valid for a small survey area where the EGM96 variation is smaller than 1cm, otherwise the survey accuracy is altered.
I also asked emlid if they could add the option in reachview to consider the output of a geoid separation equal to 0 as the EGM96 is useless in both the ERB and NMEA messages, most other manufacturers have this option (septentrio, leica etc) but they refuse to do so.
We are looking at the option of modifying the Ardurover code to read the ellipsoidal height instead of the orthometric one and patch our own mission planner version. Nonetheless, this is quite a time-consuming and costly job. Has someone found another solution since?
I fixed the altitude of the ERB code a couple of years ago, and can already tell you that what you need is a small change in the Emlid firmware, not in the ardupilot firmware.
Take a look at the Emlid repository, you shoul easily find the fix I did years ago, and modify it slightly to fit your needs.
I modified the firmware that runs on the Emlid GPS unit. The PR got merged in the Emlid git repository
I did not modify ArduCopter.
I did not modify mission Planner.
Just for everyone’s knowledge, Emlid confirmed me that their repositories have been closed for a couple of years so that solution is not applicable anymore.
I have asked again Emlid to get the option in reachview to enter a fix geoid separation value, I hope they will accept to develop that because all other manufacturers (Leica, Septentrio, Trimble) have such option.
