Arkit Session Paused and Not Resuming

ARKit Session Paused and Not Resuming

Not sure why your session isn't resuming, but... this generally isn't a situation you want to be in anyway.

Notice in the readme that ships with Apple's ARKit sample code (attached to the WWDC17 session on ARKit):

Avoid interrupting the AR experience. If the user transitions to another fullscreen UI in your app, the AR view might not be an expected state when coming back.

Use the popover presentation (even on iPhone) for auxiliary view controllers to keep the user in the AR experience while adjusting settings or making a modal selection. In this example, the SettingsViewController and VirtualObjectSelectionViewController classes use popover presentation.

To go into a bit more detail: if you pause the session, it won't be tracking the world while your user is away in a different fullscreen view controller. That means that when you resume, any virtual content placed in the scene won't be in the positions (relative to the camera) where you left it.

Swift ARKit How do you fully kill an ARSession?

Officially, right now, you can't.

However, there is a work-around: you make the ARSCNView disposable.

On leaving AR, first pause the ARSession. Then deallocate the entire ARSCNView hierarchy & set ARSCNView to nil for good measure. Rebuild the entire ARSCNView hierarchy and start a new session whenever you need to go back to AR.

var ARview: ARSCNView?

func punchTheClown() {

    ARView?.session.pause()
    ARView?.removeFromSuperview()
    ARView = nil

}

Other non-AR areas of your app would typically be in a separate view hierarchy at the same sibling level as your ARSCNView. I look forward to Apple providing an actual stopSession() function, so we can all stop having to punchTheClown in the meantime.

Do ARKit anchors persist after pause and run again?

ARKit has two or three ways to lose tracking (depending on how you think of them); each has a different effect on anchors.

1. TemporARy tracking quality issues

(I honestly fumbled caps lock in the middle of that word. My keyboard is making the puns for me!)

In the first situation you mention, and similar cases — pointing at a blank wall, giving the phone a sudden jostle, moving from a darkened area into bright light or vice versa — your app will get notified of changes to ARKit’s tracking state that effect the quality of camera pose tracking.

When the tracking state is limited, ARKit’s idea of where the world is might be out of sync with the real world, but it still has enough information to be able to relocalize when the situation passes. That includes anchors. (Try for yourself; run one of Apple’s ARKit sample code projects, and cover the camera lens for a bit while moving the phone.)

If whatever situation is affecting the tracking state persists for a long time, relocalization is unlikely to succeed. It can help to track how long you’ve been in limited tracking and offer the user a way to restart the session if things get too out of whack.

2 and 3. Session interruption and resume or restart

If something happens that interrupts ARKit’s ability to receive camera and motion data — like the incoming phone call screen on iPhone, or the user responding to an interactive notification, your app gets a sessionWasInterrupted message. There’s nothing you can do in this case (as far as session management is concerned) other than wait for a corresponding sessionInterruptionEnded message.

If the interruption was brief and the device hasn’t moved much since, there’s a chance of automatic relocalization. Of course, you can’t tell how much the device has been moved because motion tracking was off... you can make an educated guess based on the duration of interruption and how sensitive your AR experience is to tracking precision, and decide accordingly whether to restart the session. (For example, a game that has space invaders floating in the air is less affected than an app that lets the user trace out a floor plan by marking walls.)

Aside: Traditional iOS UI patterns like modal view controllers, tab views, and navigation controllers can push the view hosting an AR session away, interrupting the session and losing tracking. Like Apple’s Human Interface Guidelines for AR suggest, it can be good to use things like popover views instead, so that you keep the AR experience onscreen and the session running.

When/if you do restart your AR session, you have a choice of whether to keep anchors or reset tracking. If you’ve already lost localization, what this really means is whether you keep track of anchors in arbitrary coordinate space they’re defined in (even though that space doesn’t line up with the real world anymore), or just lose all the anchors.

Short of restarting the session, though, there’s nothing that’ll cause anchors to be removed. And if you lose tracking temporarily enough to get relocalization, anchors that track real-world objects (that is, plane anchors, as opposed to the ones you manually create) should adjust back to realistic positions even if the coordinate systems doesn’t quite line up the way it used to.

What should an ARKit app do when the user leaves the current screen?

You should not pause the session when the user leaves the app to the background, as sessionWasInterrupted delegate automatically handles that:

An interruption is equivalent to manually pausing the session. Do not
call pause() in response to this callback, as that prevents your app
from being notified when the interruption ends.

And if the user stays on your app, but leaves the AR experience section, it depends on what your app does and its logic. You could pause and resume the session, or stop the session, save the world map and restore the session the next time user enters AR section later (even after terminating the app), just like how it was before the user left, including virtual contents that have been added before, or just start a new session.

ARKit is processor intensive and performs heavy processes on each frame the app is running, so the battery usage is heavy as well.

---

Related Topics