0

I am using ARKit ARSession; the first time around I use an ARSession, everything works perfectly. It is fully responsive. Then I pause the ARSession; set it to to NULL so that it gets dealloced and create a second time around sometime later.

The second time around it gets stuck with trackingState as ARTrackingStateLimited, with the reason being ARTrackingStateReasonInitializing. So the currentFrame does not change, it reamins the same however long I wait. If I reset with runWithConfiguration again, it returns me a new frame, but then the currentFrame is frozen, and again the trackingState is ARTrackingStateLimited, and reason as ARTrackingStateReasonInitializing.

Is there any reason why ARSession would fail to complete its initialization the second time around. It is exactly the same lighting conditions as the first pass; so it ought to be able to detect the same features. It is not a resource problem, because if there were a resource problem , ARKit would typically show a "Resource Constraints" diagnostic message.

First Run...
[  53 ] allocARSession 0x13fe50900
[  54 ] assignARDelegate <DropPodStage: 0x13ff34450>
[  55 ] runARSession 0x13fe50900
-- perfect run here ; ARKit is fully responsive;
[  86 ] pauseARSession 0x13fe50900
[  87 ] assignARDelegate (null)
[  88 ] releaseARSession 0x13fe50900

Second Run...
[ 150 ] allocARSession 0x13fd7a3c0
[ 151 ] assignARDelegate <DropPodStage: 0x13fe63fa0>
[ 152 ] runARSession 0x13fd7a3c0
[ 161 ] ARSession: cameraDidChangeTrackingState
[ 162 ] cameraDidChangeTrackingState: ARTrackingStateLimited

[ 163 ] cameraDidChangeTrackingState: trackingStateReason: ARTrackingStateReasonInitializing
[ 164 ] AR frames frozen for 10 seconds, resetting 
[ 165 ] resetARSession
[ 166 ] ARTrackingStateLimited
[ 167 ] trackingStateReason: ARTrackingStateReasonInitializing
[ 168 ] AR frames frozen for 10 seconds, resetting 
[ 169 ] resetARSession
[ 170 ] ARTrackingStateLimited
[ 171 ] trackingStateReason: ARTrackingStateReasonInitializing

Thanks for any responses on this;

Andy Jazz
  • 49,178
  • 17
  • 136
  • 220
nishant
  • 736
  • 1
  • 12
  • 22
  • I also had frozen sessions, check if compass calibration is disabled in the privacy / location services / system services section. ( https://stackoverflow.com/questions/14121145/what-does-core-motion-error-102-mean ) – Peter de Vries Jan 12 '18 at 07:49
  • Thanks! I checked the location services has compass calibration enabled. Somehow pause/delete followed by runWithConfiguration:options seems to be causing it to freeze. It seems some kind of deadlock, where it is waiting on a resource that was not freed by the earlier ARSession. – nishant Jan 12 '18 at 17:48
  • I put a solution to my frozen issues on: https://forums.developer.apple.com/thread/94273, if that works I'll put it below as an answer. – Peter de Vries Jan 12 '18 at 19:50
  • @PeterdeVries My session is failing to initialize for a long time, 10 seconds, 30 seconds, and if I reset it I get a single new camera frame. But nowhere does it throw me the session:didFailWithError: callback. So I am not able to use the workaround suggested in the forum. – nishant Jan 12 '18 at 20:33

1 Answers1

0

After a lot of diagnostics, I was able to isolate the problem. I am using the YUV buffer which is in the captureImage of the currentFrame. This buffer was being used to generate an RGB texture, which was then rendered to the screen as the cameraImage. The problem was that I was not following it up with a glFlush() call which is the suggested behaviour while using CVOpenGLESTextureCacheCreateTextureFromImage. This somehow was causing ARKit to be locked up the next time around. It's not clear why how these are correlated but I am offering up this answer in cases others land into a similar situation.

nishant
  • 736
  • 1
  • 12
  • 22