Capture stops in tunnel

Mobile apps Android
1

Of course, capture stops in tunnel due to lack of GPS signal… but I’m using RTK GNSS + IMU (ublock F9R) and I still get a good estimated position in the tunnel:

image
image707×984 151 KB

For one way, I got pictures all along the tunnel but it was interrupted in the backward way. You can check it there:

I imagine that the estimated accuracy was too high although one can see that the track is good. In earlier versions (android), it was possible to enable acquisition with poor accuracy. I would appreciate such an option or, may be, a more relaxed constraint when fix is “estimated” i.e. using IMU only.

1 Like
2

Yeah, this one is a stick with two ends, and hard to find a right balance of quality/freedom. @boris what do you think?

BR, Yaro

1 Like
3

Interesting - does the RTK GNSS + IMU you’re using have an option to be paired with your Android phone? Then the accuracy could be high and everything would just work?

4

It is already paired with my Android Phone. I’m using Lefebure RTK software that is getting corrections from a RTK caster and send them with BT to the GNSS receiver. The receiver send back position through NMEA sentences. Then, Lefebure send it to other applications with Virtual Location (developper option).

Indeed, accuracy is not very good along the track. There should be something wrong with synchronization.

5

So, you mean that because this device produces a better GPS the tunnel was captured successfully one way but failed to capture on the way back (same tunnel I assume). And by lifting GPS quality requirements a bit will help to get images with ok-ish GPS to mapillary. Am I correct here, @Eric_S?

BR,
Yaro

6

In fact, while driving in the tunnel, I can see in Lefebure that the estimated uncertainty is increasing to meters (but I didn’t watched carefully values).

Indeed, while checking NMEA logs, I don’t know where it get accuracy. Sample at tunnel exit (GSV sentences removed for clarity):

$GNGLL,4412.0837477,N,00556.7948333,E,134507.00,A,E*7B
$GNGST,134507.00,0.0000,20,7.9,154,7.5,4.6,3.2*40
$GNTHS,328.02,E*16
$GNRMC,134508.00,A,4412.0974116,N,00556.7827365,E,58.187,326.75,020324,2.31,E,E,V*6C
$GNVTG,326.75,T,324.44,M,58.187,N,107.763,K,E*0E
$GNGGA,134508.00,4412.0974116,N,00556.7827365,E,6,00,99.99,472.411,M,47.505,M,,*7B
$GNGSA,A,2,,,,,,,,,,,,,99.99,99.99,99.99,1*30
$GNGSA,A,2,,,,,,,,,,,,,99.99,99.99,99.99,2*33
$GNGSA,A,2,,,,,,,,,,,,,99.99,99.99,99.99,3*32
$GNGSA,A,2,,,,,,,,,,,,,99.99,99.99,99.99,4*35
$GNGSA,A,2,,,,,,,,,,,,,99.99,99.99,99.99,5*34
...
$GNGLL,4412.0974116,N,00556.7827365,E,134508.00,A,E*7B
$GNGST,134508.00,0.0000,23,8.5,153,8.3,5.1,3.4*41
$GNTHS,326.75,E*18
$GNRMC,134509.00,A,4412.1123090,N,00556.7698725,E,58.700,324.84,020324,2.31,E,D,V*67
$GNVTG,324.84,T,322.53,M,58.700,N,108.712,K,D*03
$GNGGA,134509.00,4412.1123090,N,00556.7698725,E,2,12,0.75,472.204,M,47.505,M,1.0,0000*6C
$GNGSA,A,3,28,18,16,29,26,31,,,,,,,1.55,0.75,1.35,1*0C
$GNGSA,A,3,78,77,88,87,,,,,,,,,1.55,0.75,1.35,2*06
$GNGSA,A,3,34,36,02,27,30,,,,,,,,1.55,0.75,1.35,3*01
$GNGSA,A,3,13,24,08,26,25,,,,,,,,1.55,0.75,1.35,4*0F
$GNGSA,A,3,,,,,,,,,,,,,1.55,0.75,1.35,5*01
...
$GNGLL,4412.1123090,N,00556.7698725,E,134509.00,A,D*75
$GNGST,134509.00,89,8.1,5.6,162,3.2,2.4,2.1*79
$GNTHS,324.84,A*10
$GNRMC,134510.00,A,4412.1255542,N,00556.7565310,E,58.653,322.32,020324,2.31,E,F,V*6A
$GNVTG,322.32,T,320.01,M,58.653,N,108.626,K,D*0C
$GNGGA,134510.00,4412.1255542,N,00556.7565310,E,5,12,0.67,472.365,M,47.505,M,1.0,0000*6D
7

@Eric_S I’m not sure how to read all the values in here, but I think that’s not needed. Based on your answers you are using this approach to share the location with the phone (i.e. mock provider Lefebure). I didn’t use this application itself, but used mock providers in general and they work correctly with the app. So, I am pretty sure the root cause of the missing images is the accuracy.

To give more details, Mapillary app considers GPS good when the accuracy is less than 30 meters (see the accuracy definition above).

The perfect solution here is to use structure from motion (or similar) to detect the position from the last successful GPS, but that’s not the part of the app. I don’t see any half solution except lifting the lower bound, but that will cause more problem when app starts to capture with yet too bad GPS.

cc @boris

BR,
Yaro

1 Like
8

Yes, I use the approach mentioned.

I will check next time that I cross a long tunnel what is going one with accuracy and if it reaches 30 m.

1 Like
9

Thanks @Eric_S. There is even a chance that these 2 are connected.

PS the second.

BR,
Yaro