I'm using the Java sdk. I've set my TangoConfig to have autorecovery=false, so that I can prompt the user to reset motion tracking whenever she sees fit after receiving a Tango pose data with status=invalid. Currently, whenever I get my device to fail at continuing motion tracking, I see that it stops giving me new pose datas in the listener callback, but I never get an PoseData that is invalid to signify that tracking has ceased. This all used to work for me, but recent versions of the SDK have failed to provide this callback as necessary. Anyone else experiencing something similar? Any ideas at what to look for to understand if something may be incorrect here?
I have the same issue using the Unity integration.
I also tried getPoseAtTime() with time values of 0 or Time.realTimeSinceStartup. But I never get a pose with with an invalid status.
I know of another developer who also has this bug, and says it was introduced about 3 months ago.
The support page says that Tango devs monitor this tag, so hopefully they'll read this and fix it!
The UX Framework has an exception for loss of motion tracking. So that may be a work around in the meantime.
Related
Foreword
Since this appears to be a bug in the d3d9 Emulation on the Windows side, this would probably best addressed to Microsoft. If you know where I could get into contact with the DirectX Team, please tell me.
For the time being, I'm assuming that the only real chance we have is working around the bug.
What
We're investigating an inresponsiveness found in the Game Test Drive Unlimited 2.
Only when opening the Map and only when having an "RTX" Card (I think the most precise we got is GDDR6, because AMD also seems affected).
After long debugging, we found out, that it's not a simple fault of the game, but instead Present returning D3DERR_DEVICELOST even when having the game in Windowed Mode.
When the Game is in Fullscreen Mode, it properly does the required roundtrip over TestCooperativeLevel and Reset, but after the next frame is rendered, Present has lost the device again, causing the Hangup.
Now I'm looking for pointers on how to solve this issue. While it's probably some internal state corruption of some sorts, it's definitely triggered by an API Call only present when rendering the Map in that Game.
We will try to dig into d3d9.dll, but my suspicion is that the error code just comes from some Kernel/Driver Call, where our knowledge and tooling ends.
Ideally I'd like to fuzzy-find the drawcall by just hooking everything and omitting random apicalls, but I guess it's just not so easy and causes a lot more errors in most conditions.
Also note that an APITrace we did, showed D3D_OK for every single call including EndScene, up until Present, so it's not as simple as checking the return codes.
Trying to use Direct X 9 in Debug/Diagnostic Mode is also not really possible on Windows 10 anymore apparently, even when installing the SDK from June 2010
Thanks in Advance for any idea and maybe addresses to direct this problem to.
It appears that a large fraction of Tango users are experiencing issues since Leibniz was pushed out. I found this post in another thread and thought it might be why I am seeing so much instability in my app after the update:
This is from: TangoService_connectOnFrameAvailable() gets stuck or crashes using Google Tango Leibniz Release 1.10
"Apologies, that you are experiencing problems. Is this still happening? I am asking this because, there was a bit of leeway in timing between when the TangoCore was updated on PlayStore and when the OTA went out (which can potentially cause this issue, if OTA and TangoCore are mismatched). I just want to make sure that you are are updated on both TangoCore and OTA before diagnosing it. Also, make sure you have permissions for camera in the android manifestl." – r4ravi2008
I am pretty sure that the reason I am having problems is because I do have the mismatch described above. I have Tango Core updated through Google Play, but if I got to "About Tablet" I see:
Build number: KOT49H.150320
Also, my Kernel version has an updated date of Friday March 20th.
This build number is exactly the build number referenced here: https://developers.google.com/project-tango/hardware/depth-test
However, on this page it says that this build is for Kalman (not Leibniz). When I try the suggested step of going to "System Updates" and clicking "Check for Update" the system says that it is up to date (even though apparently it did not receive the latest OTA).
Two questions:
Am I correct in that Kernel (OTA) and project tango core are mismatched?
If so, how do I fix this?
Thanks in advance...
Apologies in advance as this is rather a comment than an answer to Voxel Scanner Voxxlr's post... But as I don't have 50 reputation points I cannot leave comments...
Well, like Mark I reset the device to factory settings and carefully updated everything (PlayStore, System Update)... Then, I made super sure that the correct tango_client_api.h/.so is used in my project... Et voila, suddenly it worked... Generally, it seems to be a good idea to spend as little time in the callbacks as possible... Otherwise you can observe these "hiccups" Mark is reporting... After considerable rearrangements in my code everything runs smoothly again... I can also confirm that the color frames are OK... If you are interested in my converter code: I posted it here link
My solution was to use a blunt instrument - force the Tango to do a full factory reset and let it start all over again- I can say that Explorer seems to work fine and the unity pointcloud and tracking samples work, but I'm just getting started and absolutely nothing in this statement should be misconstrued as an endorsement - remember, YMMV :-)
Yeah, no. The Unity Point Cloud sample hiccups all the time with respect to displaying point clouds, and crashes after a minute or two :-(
I believe so, I had similar problems where point cloud and motion tracking would get lost every couple seconds and eventually the app would crash. But just yesterday, my device said there was an update, while previous manual system checks kept saying it was up to date. After updating, the build number lists KOT49H.150414 (Kernel date is April 14, 2015), so that seems to be the actual Leibniz release on the device (not just the Core and SDK), and things are much more stable now.
Also just got the color data and displaying it like an AR image, but it's still in YUV format so everything is red. Working on converting it to RGB, but things seem to be working much better now.
Not sure if this technically qualifies as an answer, but I received this message from Google tango support:
Hi there,
What you are experiencing is a known bug that we have found fix too. Please stay tuned to our next OTA update that will fix this issue. We hope to push this update as soon as possible and thanks for your patience.
Best,
Monty
Project Tango Support
I am honestly not quite sure how to interpret this. What exactly is the bug? That my device won't download the latest OTA? Based on Brian's post, it really does seem that I have a mismatch between Tango Core and the kernel that needs to be remedied to get acceptable performance.
See Google+ Tango Page for info on the issue - there was an OTA update issue - it is being corrected
So I ran into the dreaded 'unfortunately....has stopped working' issue where art loads 2 classes and the debugger promptly tanks out - see this
So, in utter desperation, I switched from ART to Dalvik, half dreading a long session with ADB if the tablet got sour about the switch. Seemed to work. Tango works, albeit with a whole new set of head scratchers (flakier about getting XyzIj, flash is running, surface binding working, hell I can see the camera flashes in the surface showing the camera view - and if I try again and again, I do get tango point data :-)
Can I assume all the tango issues are of my own doing and keep using Dalvik, or must I switch back to ART and try to do all of my debugging through logcat ?
The answer to the question in title: Can we use Dalvik with Tango?
You should always use ART instead of Delvik on Tango, Delvik will work but NOT stable on Tango device, it might cause the issue you experienced like depth out-of-sync.
Same problem here,
What helps is switching to Dalvik for debugging non tango-related issues, but this really slows development process down, as all apps have to be optimized for each switch between debugging and testing session.
I'm currently writing an OpenGL renderer on my 2011 13" MacBook Pro with a Sandybridge graphics chip.
I'm finding that I'm encountering a lot of kernel panics and reboots when developing OpenGL code. Frequently, whenever I have an error, my system just reboots, rather than gives me chance to catch the error and retrieve an error code.
I know that it is related to the graphics driver as the resultant problem reporting app displayed at reboot identifies it as the entity that crashed.
The specific issue seems closely related to texture creation. Clearly there is some bug in my code, but regardless, this really shouldn't be rebooting the OS under a high-level API like OpenGL.
Does OS X have any kind of debug mode functionality that I might enable, similar to that of D3D, so that I can catch the error earlier, rather than have to use russian roulette debugging?
(I'm aware of the OpenGL profiler, Driver Monitor and so on, yet have had little success with using these tools to catch these sorts of problems)
As you mention, OpenGL Profiler is the tool to use. You should check the box marked, "Break on VAR error" and "break on thread error," at least. If you have trouble with it, let me know and I might be able to help. (I'm no expert but have had some luck with it.)
Beyond that, the crashes you're seeing are probably related to you giving a pointer to OpenGL, and it attempting to read or write memory from that pointer, but the pointer is bad (or the length of the data is wrong). If it's texture related, then perhaps you're attempting to upload or download a texture and passing the wrong width and height, or have the wrong format. I've seen this happen when passing an incorrect number of elements to glDrawElements(). I was confused about whether an "element" was a vertex or an actual object (like a QUAD or TRIANGLE) when it happened to me. The VAR error reporting helped me find that issue.
Just to come back to this for anyone looking... it turns out, that the problem was entirely related to failing to set the current context as different threads begun issuing OpenGL commands.
So, each thread needed to lock a mutex, set the open gl context, and then begin its work. It would then release the context and then the lock, guaranteeing non-simultaneous access to the one OpenGL context.
So, no deeply unknown behaviour here really, just an inexperienced newbie not fully implementing the guidelines out there. :-)
Others have responded with potential workarounds. But note that your application should never be able to cause the machine to panic (which these days simply reboots the machine and presents a dialog to submit the report to Apple).
At a minimum, you should send the report to Apple. Additionally, you should file a bug report at http://bugreport.apple.com including the panic log, a system profiler report, and any details you can provide about how to reproduce (ideally, a sample app binary and/or source code). Filing your own bug report will help in many ways -- prioritizing your bug (dupes bump priority), providing reproduction steps in case the problem & fix aren't obvious from the backtrace in the panic report, and opening a channel between you and Apple in case they need more information from you to track it down.
I'm currently porting a 3D C++ game from iOS to Android using NDK. The rendering is done with GLES2. When I finished rewriting all the platform specific stuff and ran the full game for the first time I noticed rendering bugs - sometimes only parts of the geometry would render, sometimes huge triangles would flicker across the screen, and so on and so on...
I tested it on a Galaxy Nexus running 4.1.2. glGetError() returned nothing. Also, the game ran beautifully on all iOS devices. I started suspecting a driver bug and after hunting for many hours I found out that using VAOs (GL_OES_vertex_array_object) caused the trouble. The same renderer worked fine without VAOs and produced rubbish with VAOs.
I found this bug report at Google Code. Also I saw the same report at IMG forums and a staff member confirmed that it's indeed a driver bug.
All this made me think - how do I handle cases of confirmed driver bugs? I see 2 options:
Not using VAOs on Android devices.
Blacklisting specific devices and driver revisions, and not using VAOs on these devices.
I don't like both options.
Option number 1 will punish all users who have a good driver. VAOs really boost performance and I think it's a really bad thing to ignore them because one device has a bug.
Option number 2 is pretty hard to do right. I can't test every Android device for broken drivers and I expect the list to constantly change, making it hard to keep up.
Any suggestions? Is there perhaps a way to detect such driver bugs at runtime without testing every device manually?
Bugs in OpenGL ES drivers on Android is a well-known thing, so it is entirely possible to have a bug in a driver. Especially if you are using some advanced (not-so-well-tested) features like GL extensions.
In a large Android project we usually fight this issues using the following checklist:
Test and debug our own code thoroughly and check against OpenGL specifications to make sure we are not doing any API-misuses.
Google for the problem (!!!)
Contact the chip-set vendor (usually they have a form on their website to submit bugs from developers, but once you have submitted 2-3 real bugs successfully you will know the direct emails of people who can help) and show them your code. Sometimes they find bugs in the driver, sometimes they find API-misuse...
If the feature doesn't work on a couple of devices, just create a workaround or fallback to a traditional rendering path.
If the feature is not supported by the majority of the top-notch devices - just don't use it, you will be able to add it later once the market is ready for it.