Hi,
I integrated a GPS on my ROV and can see in real time the position in QGC. When diving I lost the GPS position (of course) and it adjust when I go to the surface again. This is fine.
Now, as the topic title suggest, Is there a way to see/record a trace of my previous ROV position in QGC?
If not, what are the real-time options? I means not downloading the ublox log files at the end of the day?
Someone have done this already?
thanks
Hi Charles,
You can get the GPS coordinates from tlog file. Also a csv file will be there in your telemetry folder if you enable the CSV file save option. You can also replay the tlog file in your QGround Control.
Please let me know any doubt regarding this.
Thank you.
Hi @sudheeshk
I indeed find the log file in the telemetry folder. I didnāt know about this and this is a good starting point. Thanks!
Can we use the source data of those file to draw a live trace while flying the ROV in the field? I will try with a third party software but would like to see it directly in QGC. They certainly have this option in a branch or the other of ardupilot (copter, roverā¦). Could we think of implementing it in QGC Ardusub version?
thank you
Charles
Hi @Charles,
I donāt have much experience using a GPS with ArduSub, so Iāll need to run some simulations next week and see what the interface is like with location data enabled.
I did a (very) brief search and only found images of path-planning with waypoints (user-defined ahead of time) and trajectories during post-analysis/replays. It would be helpful if you could link to an example of QGC showing a live trajectory, otherwise Iāll try to find one when Iām testing next week 
Hi @EliotBR
If everything goes has planned, I will fly my GPS-ROV this weekend and report monday with print screen and log file. This could be a good starting point to begin with.
I also ask about the track feature in QGC section of the PX4 forum : Track in QGC?
Maybe we are lucky and it is easy to move what already exist in other QGC branch about this?
If not, a very basic approach could be the following:
1- find in QGC code where the ROV actual position is obtained and refreshed. I assume that upon refreshing the position, it ādelete/replaceā the previous one?
2- modify this sequence and record the previous position before refreshing to a new one.
3- Then allocate a new visual icon (a dot for example) to this previous position and keep it visible on the map?
4- Putting this into a conditionnal statement like below could allow us to select the length of the track (here 20 positions).
i = 0;
while (i < 20)
Previous position_i = Actual position
Actual position = get newest position()
i ++
Plot position()
return
I wish I could do it myself, but for now I can only code in arduino while I just started with python and C++. The learning curve is steep!
edit: I found this on youtube live trace . Around 3min47 they arm the vehicule and we can see the red track. Later some ācameraā icon are draw where pictures are taken. This is ardupilot version of QGC.
in any case thank you for your help
Charles
I spoke with our software team and was told QGC should display the live trace by default. There are apparently some caveats to that, in that the moved distance between plotted track points is apparently hardcoded (which I think means to change it to a shorter distance would require building QGC, Iāll need to confirm that next week), and the trace will only appear for movements while the vehicle is armed.
That would likely be helpful. Iād suggest trying to go across the surface for a bit to see if a trace appears (Iām unsure whether it would connect two traces if there was a long period without GPS data between them).
QGC supports multiple vehicle types - it tailors the UI to the connected vehicle. There arenāt really other ābranchesā, but some vehicles support some different window types depending on their functionality. From what I understand the āFlyā view is the same for all the vehicles, whereas the the Vehicle Setup pages (e.g. āMotorsā, āFrameā, etc) are specifically tailored to ArduSub when an ArduSub firmware is connected.
That functionality is reliant on the vehicle/camera supporting taking pictures via mavlink. At this point we only support recording a video stream, which is currently handled entirely by Companion and isnāt related to or linked with mavlink.
Hi @EliotBR , you are correct. A red trace became to show when I armed the vƩhicule. Something I did not do in my backyard test while setting up the GPS. Distance between trace point seem to be around 2m. I will see what this give in real life this weekend.
More on this next week.
Charles
Following on this.
The weekend was fun. The GPS worked well and traces were draw while flying the ROV. It clearly help to navigate around/through obstacle in the lake while the ROV was far from sight.
The antenna work well up to 10 cm below the surface. Deeper than this the GPS started to output garbage data. A lot of info are recorded in the log csv file and can be accessed for futher analysis. . This is very cool! Among other we have the GPS status, Sat number and depth of the ROV. This will be interesting to look into.
There is one down side that could require some more playing in QGC code. When the GPS loose the 3D lock and start outputting garbage, the data are still integrated in the trace thus the ROV suddenly move out of the lake! When the GPS signal is completely lost, then the trace do not update anymore until the signal come back. When back, the trace continu were it was and gradually move from garbage data to more precise lock. This do not create a gap in the trace. Thus extensive data cleaning will be required at the end of the day. Out of the lake data, not enough satelitte data etc.
o crapā¦ The Tlog file is 60 meg. I canāt upload it. If interested, I can send it by mail 
Charles
Great to hear
Huh, cool
Hmm, I wonder if thereās some kind of confidence threshold that can be set, or perhaps we could add some kind of āsurface GPSā mode in ArduSub that ignores GPS signals once the vehicle goes below a certain depthā¦
Iāll ask the software team what they think.
Fair enough. Agreed that it would be good to reduce the garbage data if possible, and even better if it could try to switch to IMU-based motion tracking that corrects itself once the GPS signal is regained, although thatās likely easiest to do in post-processing.
If you want to share it you can upload it to cloud storage (Google Drive, OneDrive, Dropbox, etc) and post a sharing link to it
Hi,
I put the log file here : Tlog
and the .csv file here: CSV log
Hi hope it will work?
I looked into the .csv data and with respect to filtering, a robust way should probably include both the depth sensor and the GPS lock message. I did not use RTK this weekend, only the onboard GPS. Thus when the signal was good, the GPS lock message was ā4ā ā GPS 3D lock. And it gradually fall to ā0ā ā no lock.
Below are 2 figures. The first one show the GPS lock msg (0 to 4) at various depth (depth in orange, GPS in blue). The other figure show the number of satellite (blue) vs depth of the ROV (orange). The Lock message and Sat count both drop when I dive but it is gradual.
25 satellites or more seems to be correlated to GPS lock 4 and ROV at the surface. Thus good signal. This could be a filtering starting point. Filtering with depth, as you suggest, might also work but not alone because there is a lag in signal degradation while diving and returning back at the surface. Another parameter that could be interesting for filtering is the Horizontal dilution of precision ā HDOP. Above say 2m, the signal become unreliable and could/should be remove. But this is to use with caution since sometime 5m HDOP is all you can obtain because of clouds or canopy and it could be good enough for some situation? Maybe a HDOP user adjustable filter/slider?
Edit: hdop is not in meter and although it work in my data set, GPS pro say to not use this parameter.
@EliotBR :
Fair enough. Agreed that it would be good to reduce the garbage data if possible, and even better if it could try to switch to IMU-based motion tracking that corrects itself once the GPS signal is regained, although thatās likely easiest to do in post-processing.
I looked a bit into the Cerulean DVL75. Apparently it do just that. Dead reckoning while underwater and repositionning when the GPS input is good/better accuracy than the DVL error. I ask them about RTK management but they did not answer yet.
I can access them without issues
That likely depends somewhat on where you are in the world (not everywhere has the same satellite coverage).
The water blocks/distorts the signal, so if the ROV knows āIām diving, therefore donāt trust new GPS readingsā that should be a good way of avoiding those incorrect readings. The lag in lost GPS satellites is likely a timeout thing rather than an actual continued connection, and the lag in position estimate is likely from the EKF doing a good job of filtering garbage to start with (and because itās already doing IMU positioning between GPS position estimates, so it continues to do that and just ends up not getting another good estimate).
Then on the return to surface I expect it should be fine to just wait for returned GPS lock
Thereās a big difference between purely IMU-based position estimation (which quickly gains reasonably significant drift) vs dead-reckoning using velocity measurements from a DVL. Beyond that, Ceruleanās DVL-75 takes in a GPS signal directly. It can maintain some amount of reliability because it acts as a filter to the GPS signal before it gets to the ROVās flight controller, and also includes functionality to intentionally suppress the GPS signal (e.g. when diving starts) in order to ignore incorrect readings from below the water surface.
At the moment ArduSub accepts whatever GPS signal itās given, whereas if we made some kind of āSurface GPSā mode/option it could potentially do that kind of filtering/rejection itself
I played a bit more with the data in google earth.
I filtered the data using the sat number field from the .csv file.
See: Google_earth_kmz file
In my case, Sat count of 26 and above return a realistic view of the ROV at the surface has I remember flying it. I flyed to a floating platform toward the north of the lake. Also toward a rock at the west end of the lake and finally to a thermistor chain I installed on a buoy in the south part of the lake.
With the kmz file, it is possible to add / remove data from the image by selecting/unselecting the different folder corresponding to the sat count number. Adding the 10-20 sat count folder show some data going out of the lake. Adding the < 10 folder show the worst (unusable) scenario.
Each data point also include the depth of the ROV (rel altitude) but to have my antenna out of the water, the base of the ROV was around -0.2m. By the way, the depth is not very accurate because of number rounding. It would be nice to see one more digit like -0.16m for example.
Finally I builded 2 sizes antenna pole. A short one of 10cm and a longer one of 25 cm. From what I obtained, the shorty is good and give less drag and is also less prone to entangle my tether. In wavy condition, the longer antenna migth be required? Usage will tell.
Charles
Interesting stuff. You may also want to try the Log Viewer, which lets you visualise tlog files directly. I donāt believe it supports filtering the displayed path by values within the logviewer though, so if you wanted to test that youād need to do something like process the tlog (e.g. with pymavlink) to remove the data you wanted to filter out and then analyse/view the result
Your recorded data is quite a bit more precise than the display shows while youāre operating. QGC rounds to the nearest 10cm for the display, which I assume is to avoid the number taking up unnecessary space, especially since when youāre operating a vehicle over a scale of 10s to 100s of meters vertically, showing more precision than 0.1m is generally unhelpful.
Whether the longer one is necessary would depend on the size of the swells, as well as where the antenna is placed on the ROV. Given the focus of an ROV is generally the diving part, itās probably best to stick with the shorter antenna unless the longer one is absolutely required
In the .csv file automatically recorded by QGC. there is only 1 digit. I see more in AUV log viewer but I canāt access those (at least no easely). Is there a way we can increase the digit number in the csv ? I just spend a hour in QGC build file and did not find where the csv log file is created and the data format involved 
Is there C++ function about significant digit? If we fix this to say 3 or 4 significant digits you would have 1.000 m , 10.10 m and 100.1 m. Always 4 characters. Problem solved for every depth.
Actually 1.000m is wrong. The sensor do not have this resolution. But only 3 characters would not work above 999m.
thank you @EliotBR for your helpfull comments and guidance
Hey guys,
I know Iām late to the party, but hereās some info:
This is why the trail updates only in two meter intervals: qgroundcontrol/TrajectoryPoints.h at master Ā· mavlink/qgroundcontrol Ā· GitHub
This is where the decimal places for depth are set:
altitudeRelative gets renamed to ādepthā when QGC detects a Sub.
If you want you can make your own .csv from the .tlog file, using the mavlogdump tool that comes with Pymavlink, or using my mavlogparse.py.
Thanks for the info links @williangalvani, saves me a bunch of time finding it!
Hi Charles,
Could you please share the name of the GPS used? And if possible, please let us know how you integrated into the BleuROV2.
Many thanks
Following up on this, Iāve just realised the GPS signal could likely be suppressed using a pymavlink script running on Companion that just sets the EKF?_GPS_TYPE parameter to disable the GPS whenever the depth goes below a certain value, and re-enable it whenever the vehicle reaches the surface again. It would likely still be better/easier to have a āSurface GPSā option built into ArduSub, but a quite simple Pymavlink script should be able to serve that purpose in the interimā¦
@EliotBR
This is interesting! I will certainly give it a try. Here itās winter so I must say that the ROV is on a bench waiting for ice-free lakes. I am not ready yet to put it under ice (even if It surely would be a ton of fun).
Itās a ublox ZED-F9P but you probably donāt need this unit unless you eventually plan to do RTK positionning. Cheaper GPS will also do and I strongly suggest you buy one that also have a compass. The Compass in the Pixhawk is prone to interference at least in my case. The compass on the external antenna is a more accurate and trouble free option imho.
To integrate the GPS, I cut the antenna cable and made a custom pass-through connector from bluerobotic connector. Inside, the GPS is powered from a 5v converter and is connected directly to the Pixhawk port. I think it is the GPS one but I am not 100% certain. There is quite some playing around in the GPS ublox utility to make it work. This information i found it on google and sparkfun.
I fix the antenna on a ground plate and waterproof the whole thing in 3M potting compound with only a thin layer of potting on the antenna top. this antenna
After that QGC did most of the work with little configuration. I was able to 1. have the ROV position, 2. have the ROV position corrected with RTMC data from a second GPS on the shore.
Iāve just spoken a bit internally with our software team, and @williangalvani has said heās interested in taking a look at some approaches for handling this once BlueOS Beta gets a full release. Weāll have to see who ends up trying things out first
If youāre interested in that kind of thing, have a read of this post