Hi Magnus. Unfortunately, the position estimate from the internal sensors is not accurate. I have one video, where I briefly demonstrate that the rov reacts appropriately when trying to hold its position. This test had two purposes, to find out whether or not the autopilot could hold its position with only the onboard sensors (it can’t), and second to translate the roll and pitch outputs from the navigation controller to forward an lateral outputs in ardusub. The video I posted demonstrates that the second point works, and I took that clip when the autopilot was behaving nicely for a few seconds and drift was not great. What the video does not show is the much longer amount of time I spent resetting the origin over and over only for the rov to immediately zoom off in a random direction. In general, I found that the circle of error grows so quickly that the position estimate is unusable in a matter of seconds after resetting the origin.
In order to enable the position hold mode I had to make some pretty hefty hacks and disable several checks like ekf.position_ok() which will always return false with no gps or optical flow sensor attached. I did not attempt to actually see what the relative position output of the autopilot was at this point, so I dont know if the calls you mentioned would change once forced into a gps enabled mode with no gps attached. One thing you can look at for now is the output of one of the GPS_LOCATION fields. These always have a vx and vz representing the velocity estimate in the global NED frame. Mine usually shows a velocity of at least 10 cm/s while it is sitting still.
There may be room for improvement in this way of things, but I have not looked in to it as I plan on having a gps for my application.
If you would like to know more about how to do these kinds of tests, please join in the conversation on gitter.
-Jacob