I got some answers from ublox. They say, new geoid files are too big to fit on the receiver & we would need much more processing power for this to be implemented. These files are large & complex, I do not think trimble has any geiod files stored in the receiver. The files are stored in a PC or a hand held pc.
My take is EGM96 10deg grid should be removed from the ublox receiver completely. It provides worthless data. Considering that these GPS products are advertised for “surveying & mapping” some improvement is needed but they don’t seem to share my opinion.
I have thought of a solution but do not know how to program it. I sure would like any help I could get.
If we could enter the geiod height manually and the FC only took the ellipsoid height from the GGA message. This would eliminate most of the error created by estimating a 10 deg geoid grid height.
Ublox got back to me. Basically they want to know how many I will purchase per month.
I already have the 10 degree gird answer from the forum.
Now I have ask if we can get anything more refined. Is a dim hope!
To successfully advertise & create products for surveying and mapping it is a necessity…
Your company does not appear in our direct customer list. In order to provide you with additional information, we first require some basic details about your project and requirements. Could you please complete this brief online questionnaire:
I don’t intend to come off so abrupt. I am just not getting the help from ucenter needed… I have been speaking with another developer (not a surveyor) that understands this. He has helped me understand that all these calculations need to be done with software. It seems that the best answer would be to have MP to make the geoid calculation. I do not know how we can get that info to the drone with camera or lidar but… I just don’t know! @Michael_Oborne
I am thinking my next step is to attend a convention next month in Las Vegas about 15 hours from here to approach other developers to see how they are (if they are) making geoid height calculations. I expect, if I find an answer it will be expensive… I would much rather pay to have it open source.
what would you propose mission planner do to overcome this issue?
the ublox has both ecef and lat/lng/alt, using the inbuilt ellipsoid. it also provides the geoid seperation. ie the calculated vs the ellipsoid. raw vs the egm96 (Height vs MSL) what answer are you assuming is correct?
the rtcm station sending corrections to the ublox also has a coord, is this entered as an ecef number? or a specific geoid? and what elipsoide is the base station using? over the air the base send raw obs. and the base location. this location can also translate into this, as normally.
eg ftp://ftp.ga.gov.au/geodesy-outgoing/gnss/logs/alby_20190118.log
this shows in ITRF.
given that RTK is a relative position from the base station, the base station coords play a very large roll into the final output.
Have it’s own library of horizontal and vertical datums. There too much data in these library’s to fit on a receiver. A survey software program (or upgraded MP) can apply these datum files to raw GPS data and make a conversion.
Yes the vertical geiod is EGM96. Horizontal datum is selected as WGS84. Adding EGM96 to the receiver is unusual and to to this Ublox made a shortcut. The geiod is used but values are averaged on a 10deg global grid (about 600 miles) To be accurate the geoid needs to be broken down into minutes of arc angle. The programmed 10 deg EGM96 is not accurate enough for vertical data.
I think a better conversion would be taking the ellipsoid height and adding the correct geoid height or allowing a manual input of a geoid height. This could be applied to the ellipsoid height to achieve a true elevation(MSL).
WHY?
The altitude reported on my rover exactly 2 meters below my base antenna does not match the 2 meters by 7 meters. My field measurements do not match the rover output by 7 meters (the error in the 10 deg grid).
Ucenter reports the ellipsoid to geoid separation should be 23.2 meters, it is much closer to 17 meters
Although it is easier to have our GNSS receivers output geoid elevations, I do not think that this is the long-term solution. Record and save ellipsoid elevation (basically raw, unprocessed data), then use software to convert the ellipsoid elevations to geoid elevations. Even basic software like Pix4D can do this because they know many UAS GNSS receivers do not have an accurate geoid model on-board. This also “future-proofs” GNSS receivers when geoid models improve. We won’t be stuck with an old GNSS receiver with an old geoid model. Instead we will just update our post-processing software.
If we’re really doing surveying and post-processing our images, there is no reason we cannot post-process our GNSS data as well before we feed our photogrammetry software. Post-Processing GNSS data is also an excellent time for an accuracy and quality assessment. The few minutes that RTK saves is not worth it.
I agree to a point. RTK is happening so why not make it work right. I would like real time data that can easily be used. The routines of downloading, rinex converting, base station checking and post processing add up to a large part of my day/week. It’s not exactly enjoyable work either. The software is expensive too.
@Michael_Oborne
I found a few 1 degree spaced height files (.hgt) in the MP directory (ctrf F under DEM). How can I apply these? never mind (They are already used)
Also to the point of what MP can do? I would like it to be a more user friendly surveying tool. The potential is there.
Is there a way we could input our own base elevation not the ellipsoid?
Or can we turn EGM 96 off?
The general workflow is to set up a base station, then go fly. Then the following back at the office.
Post-process the static base station position as long static observations are more accurate.
Post-process the rover position using the GNSS logs (.ubx/.obs) and the accurate base-station position. Here is often where the software will allow you to choose ellipsoid or geoid elevations.
Assign those locations to the images and start photogrammetry software.
I think ardupilot or at least mission planner could handle the very mild processing power required to convert geotagged ellipsoid elevations to geoid elevations. There are also many online calculators like the following: https://geographiclib.sourceforge.io/cgi-bin/GeoidEval
I think this is really what should be automated more than expecting the on-board equipment to do it. Some programs do automate it, but yes it can take a lot of time manually opening and processing files.
Is the Here+ not capable of just outputting ellipsoid elevations? If it is, I don’t really see a problem. That’s the majority of inexpensive, lightweight, low-power GNSS receivers. I do agree that the false promise of including a 1-degree geoid is quite stupid and should be removed from UBlox’s end.
there here+ is able to output
Height above ellipsoid
and
Height above mean sea level
so the data exists. its just that its not currently logged anywhere. only the MSL is logged, and used.
Is there any hope to change this or allow users to turn off the EGM/MSL elevation?
Could RTK inject allow a MSL input for the base? This would be a good immediate fix too.
Who could I sponsor to help with this?
We discussed this today on our CubePilot Technical team call, the team have some ideas, but we will need to discuss them more. The workflow is complex at the moment, and we need to simplify it.
I would be happy to contribute to the conceptual development on this… my colleagues and I do this on a large scale for manned aircraft, and most of it is automated with the ability to fine-tune where needed. You might also consider working with emlid… there’s a lot of people over there doing similar automation, and it’s highly related.
