In conjunction with the removal of acquisition options (Android version), it seems that you implemented a smart algorithm to calculate the distance between consecutive pictures. Indeed, during a recent travel, I encountered quite inhomogeneous spacing like the following gap:
130 m while driving around 50 km/h.
Any explanation?
Hi @Eric_S - yes, the new smart spacing is designed to capture at 20 meter intervals for highways (defined as driving 50km/h or higher). The idea here is that highways are sufficiently sparse that more frequent capture doesn’t make sense. As you slow down to pass through cities, capture rate should increase again to 3 meters automatically so that the rich details of the cities (storefronts, street signs, house numbers, etc are more densely captured).
Doing this variable capture helps save space on your phone and makes uploads faster as well. GPS isn’t always perfectly accurate, so sometimes you’ll see an instance where this doesn’t work perfectly, but overall that should be the behavior you see.
Cheers!
Well, I’m using RTK GPS and I’m pretty sure it has centimeter accuracy at that moment. It looks more like there was some kind of freeze in the acquisition process.
Thanks for the additional info - I’m not sure if I have any other ideas, I think that perhaps even with RTK GPS there will be rare occasions (like this one) where the GPS signal is lost for a little bit of time, or perhaps the phone had some issue that prevented it from reading the GPS signal at that time? If you notice a reproducible pattern, please do let us know, otherwise your sequence looks great. Beautiful ride!
That’s quite common. Sometime, I see that acquisition is staled for a couple of seconds but can’t take a note while driving:
@Yaro - could this be due to speeding up and slowing down (though the images don’t seem to have traffic, etc), or GPS delays, or Android delays?
Hi @Eric_S, I have checked the attached sequences and have tried to recognise a fail-pattern. GPS looks good (sometimes better than aligned image):
Indeed there’s a few places where clear inconsistencies are present.
I would guess those are exactly at the place where GPS is, for any reason, not so reliable. At least the values we receive from the OS. We do not approximate GPS values in the app and only use raw GPS signals (so if for some reason the signal is not good enough, we might skip the image capture).
If you’re sure that at this given point (of a gap) the GPS signal was strong enough, please let me know and I will look deeper and will try to reproduce this.
BR, Yaro
As I’m using an external GNSS receiver in conjunction with “Mock location” option in Android, I can’t guarantee that positioning data are coming to Mapillary app in a smooth way. Signal was good for sure. I will investigate this point closer, may be by recording in parallel GNSS data inside the phone with another application.
New test. Ublox F9R (RTK GNSS+IMU) connected with BT to my smartphone (Android Samsung J7@2016). Lefebure NTRIP client running on it with Mock location activated and logging GPS coordinates. Mapillary app recording pictures. You can see a gap:
The log file opened in JOSM (top track):
No gap.
Thanks for the example. Just to check, can you determine your speed here based on the timing/distance between GPS points? Just curious if that could gap could be due to Mapillary using 20 meter intervals for highways (defined as driving 50km/h or higher).
The sequence is here:
Looking at distance between points on track, I would say that speed is around 40 km/h.
I think you’re right, I looked at the distance in GPS coordinates and the timestamps between the two images and the result was that you’re traveling at about 36 km/h.
I don’t have the exact reason for why there is a gap. The rest of the sequence looks great, so I think this could be attributed to some edge cases like Android processing delays (sometimes the Android operating system is busy doing something in the background and the phone may not take an image even though it is requested to do so).
Also to confirm, this capture used the external GPS device for both Android (Mapillary) and the logging you showed in JOSM, is that correct?
It is:
[ublox F9P/F9R] — BT —> [Lefebure client (log)] — mock location —> [Mapillary]
With OpenCamera, I get regular picture acquisition but it is just timelapse. It don’t rely on GPS position. So, the limiting step may be the mock location transmission. But, I agree that, overall, Android is not a realtime OS and it is hard to be sure of anything.
Thank you for confirming. Sorry that we couldn’t quite get to the bottom of this one. We will be looking at trying to reduce CPU load during capture in the future, and that might help ensure that images are always captured reliably.
Can you share what device are You using? I mean the bluetooth Ublox thing? Any link? Have You made it yourself?
@boris Could you look at the spacing in this sequence?
Something definitely is wrong there - image 894291545540453 seq IhY1SUFqQGmvt6TMawipDe
I’m not seeing a spacing issue, but it looks like the route line doesn’t match the position of the images: Mapillary
@adalvit - any ideas why?
SfM going berserk, I don’t think we can fix it in the short term.
