Wikitude

It appears possible, under the iOS 6.1 javascript SDK to get the InstantTracker into the TRACKING state while still showing the initialization crosshairs on the InstantTrackable

You can get the SDKExample 3d Model on Plane into this state by pointing the camera at a surface that is likely very hard to track e.g. a flat white ceiling and pressing the play button

My questions are

1) Is this a bug or expected behavior ?

2) Is there a way of detecting this state in order to transition my InstantTracker immediately back to the INITIALIZING state ?

Hi Eva,

To reproduce,

1) Run the SDKExamples that come with the iOS JS SDK . 

2) Launch the "3d Model on Plane" example

3) Point at a hard to track surface like a blank white piece of paper

4) Press the play button

Instead of the crosshairs turning blue, sometimes they stay red which means (I believe) that we've transitioned the InstantTracker to the TRACKING state, but the InstantTrackable is still showing the initialization crosshairs and we're not actually tracking. I don't think augmentations can be added to the instant trackable in this state ... they cannot in the examples at least.

I would like to be able to detect this condition so I can immediately return the InstantTracker to the Initialization state and re-enable the play button. 

Hi Andreas. 

So I log out to the console various state changes from both the InstantTracker and the InstantTrackable. What I see is in my logs is

2017-04-11 09:22:42.746668 ARDemo[5179:1785322] ### Wikitude event: state changed to 1

2017-04-11 09:22:42.752689 ARDemo[5179:1785322] ### Wikitude event: tracking stopped

The first message comes from the onChangedState method from the InstantTracker

The second message comes from the onTrackingStopped method from the InstantTrackable

I am currently monitoring onChangedState, onDisabled, and onError from my InstantTracker and onTrackingStarted and onTrackingStopped from my InstantTrackable. There are no other messages logged from any of these

Note the InstantTrackable.onTrackingStopped fires within about 1/100th of a second from when the InstantTracker starts tracking.

I will probably try to use this as an indicator of the scene being untrackable and reset the tracking back to the initialization state manually when I see this but it also sort of seems like a bug because of the way the initialization crosshairs stay permanently stuck on the scene when this occurs (video attached)

So the workaround I'm testing for this is

1) I keep track of the state change coming from the InstantTrackable in a local variable so I know at all times whether the scene is tracked according to the InstantTrackable

2) When the user presses play causing my InstantTracker to change state from INITIALIZING to TRACKING I set a timer to fire 0.3 seconds in the future

3) If by that time my InstantTrackable hasn't called its onTrackingStarted function I assume the user has pointed at a location that is effectively untrackable (I've been testing with the palm of my hand covering the camera). I then alert the user to re-point his camera and I reset the InstantTracker to its INITIALIZING state

Does this seem like an appropriate workaround ? Are there any issues you notice that I might run into with it ?

Heheh, sure, this is in the 6.1.0 Javascript sdk

I also have similar issue. It seems that when we start tracking (set state to TRACKING), if the camera closes to a surface (put it in the table but not hand over for example), the application will be crashed.

I'm using Wikitude SDK 6.1 (Android with Javascript API). Could you confirm it's the issue of Wikitude SDK or do I make something wrong?

I'll try. Thanks!