@siddharth has done some really cool work with the T2 feature on the Here+, this allows you to use the hot shoe to tell the GPS when you took the photo… the GPS then reports the exact GPS time that the trigger occurred.
The Here2 has these pins exposed, so this should improve this capability dramatically
Where can I find more about that?
Hi, the way we are trying to solve this is by combining our receiver (Argonaut), which is capable of logging events (it has an input pin that you can connect to a hotshoe or Micasense). These events are then referred to the actual GPS time (with nanosecond accuracy). Our PPK service (Jason) computes the PPK solution and interpolates the CAM events.
Have a look if you want and check if this can be of help for your case. If you have any questions do not hesitate to contact us.
I understand that there are numerous companies offering standalone PPK solutions (like Emlid Reach). I don’t care, and that’s not what this thread is about. I was looking for something integrated/working with arudupilot. It sounds like the Here2 may offer ardupilot PPK functionality, so once the code supports it, we’ll move forward.
Hi, is there anyone who is using Pixhawk 2.1 with GPS Here + in RTK mode to geotag photos with cm level accuracy ? To achieve that I think some kind of PPK solution must be used ???
I feel like I have all necessary hardware but there is no info how to do it step by step in software.
This is my idea how it should be done but I can be wrong and I don’t have detailed info 
I have octocopter with camera which should be connected via hotshoe to pixhawk 2.1
(same info about connection here)
So time and position of taken of every picture will be saved in a log of pixhawk.
Copter (rover) is flying with RTK base station (windows notebook with Mission Planner) connected via 433mhz telemetry. (http://ardupilot.org/copter/docs/common-here-plus-gps.html Internal accuracy between photos is cm level, external (geographic) accuracy with standard settings is about 2m.
Geotag photos via Mission Planner with CAM Message method
(http://ardupilot.org/copter/docs/common-geotagging-images-with-mission-planner.html)
PPK solution used to improve external accuracy (2m) ??? What are the solutions ??? Are there any free solutions ?
Agisoft software to create orthomozaics and Digital Surface Models.
Is that good idea ??? Where I can have problems ???
Same more info here but still no a proof that you can get PPK with Here+
https://discuss.ardupilot.org/t/rtk-here-geotagging/28805
@norim PPK requires you to log the raw GPS data while you are flying (and doesn’t require an RTK base at all). GPS_RAW_DATA 1 should log this for you. You then have to extract the data from the dataflash log (MP used to be able to do this, I haven’t tried it in several years). Once you’ve extracted the RINEX data you need to run it through a GPS processing suite (there are a number of commercial suites for this, RTKLib is free and should be capable of doing it, however I’ve personally found it to be a hassle to get anything useful out of it). To do this you will also need log data from a reference station with a known position. You may have a free one close enough that you can use, otherwise you will have to also acquire this set of RINEX files yourself) Once you have a corrected GPS solution you need to tag your photos against this output file (match up timestamps on camera feedback, and interpolate the GPS data for the best position match). You can choose to do vehicle offset corrections at this time as well, or you can leave that to the photogrammetry suite if you are feeding one. I’m not aware of any published scripts or programs that will do this last step for you, you will either have to manually do it (which given the number of photos in mapping sounds terrible), or find someone interested in implementing a solution.
There are softwares out there that do the vehicle offset corrections, etc. That’s how most of the multi-million dollar manned aircraft sensors operate. Everything is done in post with GPS-IMU logging systems.
I think it would be really neat to re-insert the PPK corrected GPS messages back into an EKF to have a highly accurate position-orientation model of the aircraft. Then that could be used for geotagging with orientation as well as position. The more accurate the camera’s position is, the less overlap is needed for accurate 3D reconstruction. That’s part of the reason why large aircraft often fly at only 20% sidelap.
Hi,
Hope U found a solution to your problem.
i’m working on something similar to your work & i need your help,
so my question is : How did U made the .obs file using mission planner ?
Dataflash Log tab, “Generate KML + GPX” button in Mission Planner
Thank’s for your time
i already knew it before, my question in other way
How did U convert the kml (or gpx) file to a obs one !
i did try that using RTKCONV ver.2.4.3 b29, & it wont work, with the error “file format can not be reconized”
i think because the input should be a RTCM, RCV RAW or RINEX OBS file.
The KML+GPX button should also produce another file that has an extension such as .o .obs or .18o
Use that file, not the gpx or kml.
Good Afternoon,
i know i’m bothering U, i do apologies.
i did try your solution, so on the RTKCONV i pressed Process… which opened the RTKPOST window i found the KML/GPX… you mentioned & i cklicked on it, then i got the last window the KML/GPX Converter then i loaded the files & cklicked on Convert, &the result as U see in the image. it wont work
For those interested the two PR’s to improve this has been merged to master
sounds like good news!
ty
I tested with both PR’s, and I had excellent results with the timestamps improving, however I am still unable to get down to the accuracy of the Emlid Reach. Part of it is because the Here+ GPS appears to receive about 2dB less on GPS signals. I haven’t actually gotten a good FIX for the RTKLIB processing yet.
In addition, the new PR uses the internal clock for the timestamps, and that clock drifts slightly from the GPS time. It drifed at a rate of about 145ms per hour. It’s technically a separate issue, but the results were posted here: https://github.com/ArduPilot/ardupilot/pull/8409#issuecomment-443925409
@me_As
Here is how you do PPK (Post-Processed Kinematics).
Set parameter ‘GPS_RAW_DATA 1’
Download the log after the flight, go to mission planer “Data flash logs” tab and click “Create KML + gpx” and click. Select the *.bin file that you downloaded from your copter.
In the same directory where your log was, you will find KML, gpx and .obs file.
*.obs file is actually RINEX file that contains GNSS observations of the copter GNSS (rover).
Get your base station data, whether from your physical base station, your national CORS (Continiously Operating Reference Station) or VRS (Virtual Reference Station). I personally use national VRS. I prefer data in the RINEX 3.02 format (fi you are using HERE+ base station convert *.ubx data to RINEX). You will get the data with the extension such as *.17o and such as *.17n or *.17g.
*.17o is observation file, *.17n and *.17g files are satellite navigation files (*.17n for GPS and *.17g for GLONASS).
Now you have the data needed for the processing.
I am using RTKLIB demo5.b31 version (http://rtkexplorer.com/downloads/rtklib-code/) since I had least problems with it.
Set up the parameters such as on this two screenshots.
I use Static Start since it is basically Kinematics with the static start. Also setting up the frequency to L1 should make no difference in this case because HERE+ records only L1 data. Regarding the filter type, test and find out what works the best for your specific case.
Here is some literature - https://rtklibexplorer.wordpress.com/2018/11/27/updated-guide-to-the-rtklib-configuration-file/
Very important to set up Base station coordinate to RINEX header position
@Naterater
Thank you, it is nice to see some progress on this subject! Commercial solutions are a bit ahead of the open source at the moment and it is nice to see that somebody is working on this!
Cheers!
Luka
Thank you for providing the RTKLIB instructions. Unfortunately this process only works for determining the path of your rover - NOT the interpolated GPS positions. You will need a 2nd process for that still (excel or a custom program) to interpolate between GPS log points. That’s the whole reason accurate Hotshoe timestamps are needed.
Besides the final details of assigning photo positions, your tutorial is correct! Great job!
Thanks!
Yes, I did not mention the photo position - I did not come to that part of the processing yet!
I know that REACH version of RTKLIB does calculate the exact position of the camera during the exposure time. However, it is possible since REACH has the solution where HOTSHOE is connected directly to the GNSS receiver and it logs the exact moment of the exposure in the *.ubx message. i.e. you can see the message in RINEX file later.
The same solution is implemented in the rtklibexplorer version of the RTKLIB (demo5.b31 - https://rtklibexplorer.wordpress.com/2018/10/26/event-logging-with-rtklib-and-the-u-blox-m8t-receiver/).
HERE+ does not have an option of connecting HOTSHOE to the GNSS directly, but to autopilot, which logs the message in the *.bin log so it can’t be processed in the RTKLIB, but has to be calculated manually.
I think I read here on this topic that new HERE2 has this pins that you can connect HOTSHOE to exposed, is that correct? If yes, that would make the automatic calculation possible!
It is also a bit unfortunate that we do not have a solution to make use of the IMU and PPK data fusion for the precise geotagging of the images. Soley IMU data (relative position between the subsequent images) is also very useful for e.g. mapping purposes.
Luka
Thank you Luka Jurjevic and Nathan for all the effort in this matter.
