So I want to run ARcore on hickey board, I am currently running Android 9.0 AOSP on it. Is it possible to run an AR application on hickey board with an external USB camera? do I need a specific camera or is there anything else I need in order to run AR applications on hickey board? or hickey even supports the AR core? if you could answer this it would really help me.
Thank you.
ARCore has some minimum system requirements including sensors, cameras etc.
I don't believe there is an official minimum requirements set published openly at this point but there is a list of supported devices: https://developers.google.com/ar/discover/supported-devices
Google actually test and certify these devices so I don't think you will find 'official' support for you set up - they say:
To certify each device, we check the quality of the camera, motion sensors, and the design architecture to ensure it performs as expected. Also, the device needs to have a powerful enough CPU that integrates with the hardware design to ensure good performance and effective real-time calculations.
Related
Does release of ARcore means that there will be no updates on TangoSDK?
There was no update TangoSDK for few months but on the other hand, if I unzip Google Constructor APK, I see it is built with SDK none other than Google has.
The answer is a clear no because ARcore really is Tango. As in, installing the ARCore preview apk gives you a 'Tango Core' service which you can see on your non-Tango phone (I use a Pixel XL).
Clay Bavor has even confirmed this in an interview: "“There’s a lot of things that need to happen to make it successful though,” Bavor admits. “We’ve always known that it’s got to work at scale, so we’ve been investing in software-only solutions like ARCore, building on all of the Tango technology, just without the additional sensors. ..."
However, if you're asking whether the (previously required) hardware stack for Tango (fisheye cam & IR depth sensor) is 'dead', we're in the realm of speculation. My guess is that ARcore might actually save the hardware stack. With ARcore, >100 million devices will soon run Tango, which means that there will finally be a strong incentive for developers to release high quality apps and games. Then there's a really good reason for device manufacturers to offer specialized Tango hardware, because such hardware will result in a better AR experience (better tracking, additional features etc). But this hardware will probably be more varied than the previous Tango hardware stack.
To help confirm Wendelin's answer, I found running the that if you forget to install the arcore-preview.apk to your device you will see an error of
E/Tango: Java version of Tango Service not found, falling back to tangoservice_d.
E/art: No implementation found for int com.google.atap.tango.TangoJNINative.Initialize(android.content.Context) (tried Java_com_google_atap_tango_TangoJNINative_Initialize and Java_com_google_atap_tango_TangoJNINative_Initialize__Landroid_content_Context_2)
com.google.ar.core.examples.java.helloar D/AndroidRuntime: Shutting down VM
com.google.ar.core.examples.java.helloar E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.google.ar.core.examples.java.helloar, PID: 21663
java.lang.UnsatisfiedLinkError: No implementation found for int com.google.atap.tango.TangoJNINative.Initialize(android.content.Context) (tried Java_com_google_atap_tango_TangoJNINative_Initialize and Java_com_google_atap_tango_TangoJNINative_Initialize__Landroid_content_Context_2)
Which I feel shows that they just took the Tango software stack and integrated it to a form that doesn't require the depth camera. I mean a lot of the Tango SDK revolved around it getting you point clouds, finding planes with those points, and creating area description files with it, etc. I feel "Tango" is only dead if OEM's just stop trying to add more hardware to phones and sticking with the RGB camera. Also I speculate the reason for no new Tango release is Apple dropping the ball on ARKit and Google needing to make move as well.
Google announced that they will stop supporting Tango on March 1, 2018. They will be focusing all their AR efforts into ARCore.
https://twitter.com/projecttango/status/941730801791549440
I live in a building where the laundry machine is a bit far away from my suite. There is only one machine there so only one person can use it at a time. Quite often I take my laundry there just to realize that the machine is in use so I have to go back defeated and try again later. I want to build a doodad that can detect when the machine is in use and broadcast that information throughout the building so that I know that the machine will be available before I go there.
This question is not about how to build the detector. I am planning on using a raspberry pi somehow. This question is about what do I do when I detect that the machine is in use. How do I broadcast that information mainly to myself or potentially to anyone in the building?
I need a cheap solution (< $100). It has to be wireless. The signal has to travel approximately 30 meters in one direction. The broadcast should be readable on any laptop or cell phone (not a requirement but nice to have).
I was considering making an android app using WiFi direct. I'm sure others in the building would be interested in this app and I can use them as peers to extend the range of the broadcast. But I don't like this solution because I know that wifi direct doesn't work with iOS devices. Also this solution will require others to side-load an apk which they might not know how to do.
Please let me know if you can come up with something a bit less reliant on p2p and more platform independent.
I need to know how to get which kind of video card is using in directX, because some features in my program are not supported in amd video card and cause crash.
So, I need to get which card the computer is using(some computer may have more than one video card).
So before you throw ATI/AMD under the bus here, make sure that the problem is not actually due to your application. For Direct3D 10/11, be sure to enable the debug device and ensure you do not have any CORRUPTION or ERRORS, and look at all WARNINGS.
Next, see if there is a newer driver available for the repro case. If there is, then just tell your users to update their drivers. If not, and it seems to be a legitimate crash inside the driver then report that as a bug to ATI/AMD (or NVidia or Intel as the case may be).
Test your app on more than one video card/driver combination from each vendor. For indies this can be challenging, but it's an important part of making sure your application works on a broad set of hardware. For Direct3D 11, you need to try various Direct3D hardware feature level devices to ensure good coverage.
Real games do have some extra warnings tied to detecting specific hardware IDs when dealing with wide-spread driver bugs and unofficial vendor-specific extensions). There is an example of doing this detection here based on the vendorid/deviceid combination in DXGI_ADAPTER_DESC or D3DADAPTER_IDENTIFIER9. Locking out all cards from a specific vendor is overkill and likely to just annoy your customers.
With the push towards multimedia enabled mobile devices this seems like a logical way to boost performance on these platforms, while keeping general purpose software power efficient. I've been interested in the IPad hardware as a developement platform for UI and data display / entry usage. But am curious of how much processing capability the device itself is capable of. OpenCL would make it a JUICY hardware platform to develop on, even though the licensing seems like it kinda stinks.
OpenCL is not yet part of iOS.
However, the newer iPhones, iPod touches, and the iPad all have GPUs that support OpenGL ES 2.0. 2.0 lets you create your own programmable shaders to run on the GPU, which would let you do high-performance parallel calculations. While not as elegant as OpenCL, you might be able to solve many of the same problems.
Additionally, iOS 4.0 brought with it the Accelerate framework which gives you access to many common vector-based operations for high-performance computing on the CPU. See Session 202 - The Accelerate framework for iPhone OS in the WWDC 2010 videos for more on this.
Caution! This question is ranked as 2nd result by google. However most answers here (including mine) are out-of-date. People interested in OpenCL on iOS should visit more update-to-date entries like this -- https://stackoverflow.com/a/18847804/443016.
http://www.macrumors.com/2011/01/14/ios-4-3-beta-hints-at-opencl-capable-sgx543-gpu-in-future-devices/
iPad2's GPU, PowerVR SGX543 is capable of OpenCL.
Let's wait and see which iOS release will bring OpenCL APIs to us.:)
Following from nacho4d:
There is indeed an OpenCL.framework in iOS5s private frameworks directory, so I would suppose iOS6 is the one to watch for OpenCL.
Actually, I've seen it in OpenGL-related crash logs for my iPad 1, although that could just be CPU (implementing parts of the graphics stack perhaps, like on OSX).
You can compile and run OpenCL code on iOS using the private OpenCL framework, but you probably don't get a project into the App Store (Apple doesn't want you to use private frameworks).
Here is how to do it:
https://github.com/linusyang/opencl-test-ios
OpenCL ? No yet.
A good way of guessing next Public Frameworks in iOSs is by looking at Private Frameworks Directory.
If you see there what you are looking for, then there are chances.
If not, then wait for the next release and look again in the Private stuff.
I guess CoreImage is coming first because OpenCL is too low level ;)
Anyway, this is just a guess
i am new to Blackberry apps development, and see that there are lot of different resolutions of display on different Blackberry types.
is there some survey which types are most used ? which resolutions is good to support ? thanks
You probably don't need to worry so much about which specific devices you will support (unless you need specific features like touch capability). However, you do want to consider which OS version(s) to target to get the right combination of audience and feature set.
RIM provides "Choosing a target OS" with lots of good data to at least get you started.
You dont have to worry about the resolution of the blackberry Mobile Screens... We can programmitically give the resolution by checking the series of the blackberry devices...
Do you want the java code to find out the series of the blackberry mobile devices
The link that #Scott W provided is a good start in deciding which OS to support. Let me dig into this a little further, assuming you are creating an app for consumption by non-Enterprise users (delivery through App World);
As of March, devices running pre-5.0 OSs make up less than 20% of the total, and for paid apps, this figure is 10%.
By percentage, paid apps are consumed by those with newer devices than for free apps, for every OS across the board.
Keeping all this in mind, I recommend the following to you;
Don't consider targeting pre-5.0 devices, it's a waste of your time (I know, I've done this before).
Consider the time it will take you to create an app and release it (anywhere between 2 to 6 months) and imagine what the BB OS market share will look like (OS 7 will be released by then).
Start developing targeting BB OS 5.0, and if you encounter an issue whereby OS 6 provides functionality you need that is not available in 5.0 (you'll have to implement your own solution), seriously consider dropping 5.0 support or not including such feature in your 5.0 build.
If your core competencies are in Java, stick with that, otherwise, seriously consider developing in WebWorks, as that has the advantage of running on PlayBook and you'll have reusable code if you're building a mobile website.
As for devices, the Curve series is easily the most popular amongst BlackBerry's devices (as it's cheap to buy). However, if you write your UI code to be mindful of container sizes, your interface could look the same on all devices (if you want it to be).