Structure SDK (for iOS) 0.10.2: Battery life improvement and stability patch

#1

Today we are releasing Structure SDK (for iOS) 0.10.2. This update fixes an issue where Mark II units would incorrectly report that the battery needed charging at 60% charge, as well as including stability updates to reduce situations where the applications would freeze on sensor disconnect.

Please note – this update is a targeted patch on top of the Structure SDK (for iOS) 0.10.1 release. If you’re upgrading from an earlier version (0.10 or earlier) be sure to read the 0.10.1 notes on the HERE. Special steps are required for apps built on 0.10.1 and above when submitting to the app store.

MARK II BATTERY CHARGE NOW CORRECTLY REPORTING
Structure SDK (for iOS) 0.10.2 now accurate handles battery state checking on Structure Sensor Mark II. The SDK no longer incorrectly reports that the battery needs charging when your Mark II battery is at 60% or below. This update will significantly extend the battery life on Mark II sensors.

APP FREEZING DUE TO sensorDidDisconnect BUG RESOLVED
This update resolves an issue where sensorDidDisconnect was not being properly signalled in both the STSensorController and STCaptureSession with Structure Sensor Mark II. This bug would cause applications to freeze or crash when the sensor disconnected. Now apps will be properly signalled when a Structure Sensor Mark II device disconnects from the host iOS device.

STDepthFrame API CHANGES
Structure SDK (for iOS) 0.10.2 adds a new API to STDepthFrame, namely iOSColorFromDepthExtrinsics. Deprecated colorCameraPoseInDepthCoordinateFrame: in STDepthFrame and colorCameraPoseInSensorCoordinateFrame: in STSensorController. While these methods will be supported for the time being (as they are required in configurations that use hardware registered depth, which has been deprecated for some time), in future versions of the SDK we plan to remove them along with hardware registered depth configurations. We hope this new API helps developers by making the current color from depth extrinsics clearer.

REMOVED CoreBluetooth AS A DEPENDENCY
Certain apps built on 0.10.1 were rejected during the App Store submission process due to Missing Purpose String in Info.plist. We have removed CoreBluetooth as a dependency, and apps build on 0.10.2 will no longer trigger auto trigger rejections from the App Store for this reason.

Do not hesitate to reach out to us at developers@occipital.com if there is any confusion with regards to moving over. We have likewise updated our sample apps to accommodate these new changes.

SDK 0.6 Fix the Cube at a certain distance from the user
#2

@JacobErvin

Low level scanner sample worked out of the box, high level sample doesn’t scan even though the Start button is enabled.

-jim

#3

@JacobErvin

Note that link in second paragraph to 0.10.1 notes is broken, and should be pointing here. (Looks like the embedded link includes a spurious period at the end.)

#4

@JacobErvin @jim_selikoff

The 0.10.2 SDK still seems to have issues with disconnecting Mark II hardware.

This is a small test app that calls all the hardware properties, using both STSensorController and STCaptureSession, in both ObjectiveC and Swift.

With the 0.10.1 SDK, unplugging Mark II hardware has no effect at all; the mode doesn’t change. Assume this is the sensorDidDisconnect bug.

With the 0.10.2 SDK, and Mark II hardware, the mode is changed, but the app crashes as getBatteryChargePercentage call triggers EXC_BAD_ACCESS. Despite the hardware being unplugged, it looks like isConnected still returns true, and all the other hardware properties return outdated values.

Mark I hardware is fine with both SDKs, across STSensorController and STCaptureSession.

Note that STCaptureSession.sensorName still doesn’t return any value, regardless of hardware version, SDK or language. This looks like a different bug, related to the SDK 0.10.1 fixes for firmwareRevision and hardwareRevision.

  • Andy Warwick
#5

Seeing the same issue here with the Scanner sample app.

#6

Email to developers@structure.io returns “Address not found”

#7

Thanks for the reports Jim and Andy - we’re looking into both issues this morning and will have an update ASAP.

The original post has also been updated with the link fixes.

#8

Actually I spoke too soon: sometimes the low level sample works. Other times it seems the sensor hasn’t been initialized properly, indicated by the absence of depth data in the scanning volume during cube placement.

#9

@jim_selikoff, I’ve been able to reproduce the high level scanner sample issue - but I haven’t seen the low level problem you’re reporting. Would you be able to generate an OCC (or even a screen recording) of this behaviour?

#10

I am a totally foreign to this… How do I patch my device???

#11

I’ll try and get a clean repro for you, it’s a bit random.

#12

Mike,

The patch is for the SDK so it would benefit someone developing an application.

-jim

#13

Change line 64 in SwiftViewController.swift from:
“return captureSession.sensorMode.rawValue >= STCaptureSessionSensorMode.notConnected.rawValue”
to:
“return captureSession.sensorMode.rawValue > STCaptureSessionSensorMode.notConnected.rawValue”

That will return that the sensor is connected when mode is notConnected, so when you test the battery level you’ll get the exception.

#15

Hey @n6xej (@JacobErvin)

Thanks for that. Think I’m too close to the wood to see the trees. :slight_smile:

Have tweaked project and think I’ve got the logic correct now; and added some console logging for state at each stage.

That said, still seeing a crash with Mark II hardware, which AFAICT doesn’t report it’s connection state correctly. Mark I sensor runs as expected.

If you (or anyone else) can confirm that would be great. (Or point out any stupid errors on my part.)

-Andy W

#16

I have seen crashes when I’ve built under Xcode 11. I’ve reverted to building only under Xcode 10 for now and it seems to fix whatever was causing my crashes. I’d be interested to know if that works for you as well.

#17

Attached test app will only work under Xcode 11/iOS 13, so can’t test that unfortunately. But have tried the sample Scanner app, in both versions of Xcode, and don’t see any appreciable difference.

-Andy W

#18

@JacobErvin,

I haven’t seen the behavior with the absence of depth data in the placement cube that I reported in the low level scanner sample again, however I do see the following consistently. Scan an object, just something you can capture in a few seconds. Don’t colorize, just finish the scan and go back and repeat. The video frame rate consistently slows down after a few repetitions, and finally locks completely. To be clear, I’m referring to the preview video frame rate during cube placement. It becomes progressively sluggish, then finally freezes altogether. I’ve seen this from the earliest Mark II releases. It seems to have improved with newer releases, but it’s still there.

  • Jim
#19

Thanks for the report Jim. This sounds similar to one or two other situations we’ve found that can cause app slowdown over time. I’ve logged it into our short term roadmap, and will post an update here as soon as we have any updates.

#20

@jim_selikoff,

After multiple tests I’m unable to reproduce the issue on 0.10.2 with the steps you provided above. Can you confirm that you’re still seeing it? If so, please provide:

  1. A screen recording
  2. Device info (iPad model, sensor model, OS version etc.)

Thanks!

#21

I’ll get you something tomorrow, thanks for looking into it!

-jim