Comment by roymurdock | Hacker News Reader

Comment by roymurdock | Hacker News Reader

Parent Full thread

Apple's ARKit is the result of work going back to 2003 by Metaio, a leading AR SDK vendor that spun out of Volkswagen. Apple acquired Metaio in 2015 and shuttered operations, including Metaio's popular AR conference [1].

Google Tango emerged out of Google Advanced Technology and Project Group (ATAP) in 2015 after a 2 year incubation period [2].

Both do a great job of Simultaneous Localization and Mapping (SLAM) - the foundational tech needed for AR applications. ARKit is tied to development for iOS applications and form factors - all handheld at the moment. Tango is tied to development for Android applications and Asus/Lenovo phablets - all handheld at the moment. This tech isn't new, but Apple and Google and bringing it to the masses, whereas it had mainly been confined to niche advertising uses previously.

The author glossed over many of the smaller vendors that have been doing AR SDKs and cloud services for years. Also skipped over Microsoft's play in this market, which currently revolves around PTC Vuforia and Unity development of Windows 10 AR apps for Hololens.

Here's an overview of where the players in the AR development solutions market have plays: http://www.vdcresearch.com/News-events/iot-blog/images/ARKit...

[1] https://techcrunch.com/2015/05/28/apple-metaio/

[2] https://plus.google.com/+GoogleATAP/posts/c3nZ3a12NKa

You just made the same point that the article made. How many people will be able to use ARKit based apps when iOS 11 ships in September - all 64 bit iOS devices that Apple has ever sold.

What percentage of Android devices will get to use Google's AR solution? How many devices that have hardware capable of using Google's solution will ever see the OS update?

Google can shift strategy - AR for all even without tango - and I hope they can do it quickly, otherwise they are at a significant disadvantage.

What strategy could that be with the majority of phones with Android running really old OS's and lowend hardware?

Just markerless AR based on video analysis combined with gyroscope. It isn't the hardest thing. Even if it is just 30% of Android phones that is still a larger userbase than iOS.

Android's fault is over reliance on tango hardware because they are going for perfection rather than good enough.

Google has a much harder job here given that Android hardware is more diverse and that the OS images are not under their control. Apple has a significant advantage in that the lowest-end iOS 11 devices ever shipped are >100 GFLOPs with GPU, the lowest end they sell now is about 172, and they control all of the software so they can use the GPU on every device.

They have chosen to do that.

I am quite happy that one year later Android N only managed to acquire 9% and KitKat is still rocking with 18%.

Maybe now that Google sees no one gets their new shinny OS every single year, they change their attitude.

Trello is not the solution as it is only available in Android O, it still leaves to the OEMs the choice to actually make it work and with Android N at 9% one year later, who knows how many years it will take until Android O becomes relevant at all.

For a moment I was confused why Trello was being mentioned and this and the other reply are the only mentions of it on the page. Easy typo to make or autocomplete false-positive, I suppose.

I'm excited for Treble, personally. I'd like to slightly modify your statement to say that it's available for any device that supports it. Google Pixel and Pixel XL shipped with Nougat but they are using it to test the transition from a non-Treble system layer to a Treble-ized (?) one with Android O's release. So other OEMs could choose to support Treble on older devices, given that they meet the requirements and also have support from the BSP vendors like Qualcomm.

That said, I agree with you that it probably will still take some time before we see a huge impact, and it's a shame it's taken this long; better late than never, I suppose?

> Easy typo to make or autocomplete false-positive, I suppose.

Thanks for the remark, yeah my device auto-correct does funny things and I do not always notice what it did.

> So other OEMs could choose to support Treble on older devices, given that they meet the requirements and also have support from the BSP vendors like Qualcomm.

The thing is Treble is nothing new, it is just the attempt N + 1 to sort out the update situation in a technical way, where the all issue is political.

Android already has an HAL that OEMs should adhere to [1], so if they haven't adopted correct behaviours willingly, it is not now that they will start doing it.

[1] https://source.android.com/devices/

Trello causes some issues for OEMs as it will affect their carrier deals. But once we are past that I think Android updated will come faster.

How many years are you willing to wait for it to happen?

I am yet to see Android 7 devices at prices I am willing to pay, one year after its release, with 9% market worldwide.

Rooting devices is not an option for regular users.

> I am yet to see Android 7 devices at prices I am willing to pay,

Well, that only proves that people don't want to pay for security ;)

> one year after its release, with 9% market worldwide.

Android N was not released a year ago, it wasn't even announced a full year ago.

And when it was released it was so buggy OEMs had to wait until February for a fixed version.

The problem is not just device diversity, it's also about calibration. This is an issue that's been known for years now. Most Android phones are terribly calibrated and even within a single apparent model there can be component and calibration differences, especially between regions.

Good points, just wanted to point out that, according to their documentation[1], Apple ARKit doesn't do SLAM, but Visual Inertial Odometry, which is one of the (important) components of a SLAM system, whereas Tango does the full SLAM pipeline with loop closure and relocalisation, and should therefore enable more, larger scale applications and allow for persistence between device/app reboots etc.

[1] https://developer.apple.com/arkit

Apple ARKit doesn't do SLAM, but Visual Inertial Odometry, which is one of the (important) components of a SLAM system, whereas Tango does the full SLAM pipeline with loop closure and relocalisation

This is actually not as cut and dry as it sounds. Generally speaking the difference between VO and SLAM is how it handles accumulated errors to do LC/relocalization. Almost by default a robust VO system using some kind of sensor fusion does a form of relocalization but rarely loop closure.

I say this because I feel like it undercuts Apple's effort by stating it's a purely VO approach and I don't want people to get the impression that you can't do round trip SLAM without active depth (IR etc...).

I was in no way trying to undercut Apple's efforts, just stating what's written in their documentation [1], i.e they're currently only performing tracking with VIO as compared with Google's [2].

"Almost by default a robust VO system using some kind of sensor fusion does a form of relocalization but rarely loop closure." This is not true, Visual(Inertial) Odometry systems typically estimate "odometry" i.e frame to frame motion tracking hence the name, such as in [3] and [4], whereas SLAM systems, such as [5], store a map of features, and their descriptors to relocalize which isn't necessarily a typical feature of pure VO systems.

[1] https://developer.apple.com/arkit

[2] https://developers.google.com/tango/developer-overview

[3] https://github.com/uzh-rpg/rpg_svo

[4] https://github.com/ethz-asl/rovio

[5] https://github.com/raulmur/ORB_SLAM2

Sure, didn't mean it to sound accusatory.

So the reason I say that it's "almost by default" is because on really quality VO systems, if you turn in a 360 degree circle, the image descriptors and pose estimates returned are almost exactly the same. It's not of course the same, but the effect for an end user is the same and can be extended relatively easily.

This comment is spot on. Actually if you have a device with ARKit on it, you can see for a fact that they do have relocalization: cover the lens for a few seconds until tracking is lost, then return to the point of origin, you will see that the intial cube (placed at the origin) snaps back to the correct place. What they probably don't do is global mapping of the entire session.

Reply on news.ycombinator.com