Recently I've started porting my older Unity code with an earlier version of the Tango / Unity SDK to the latest version. Overall, it's working great. Faster frame rate, less drift, everything seems pretty good....Until: BLAM... Sudden crash. So, I tried paring down my app to the essentials to see if I could reproduce the crash and what I've found is that if I follow the AR Unity example in the docs to the letter, no problem. But, if I add a 'FindPlane' call within the Update() function so I place a sphere at the planeCenter of whatever is at 960,600 (middle of screen), after a few minutes the app will crash. So my suspicion is that this is what's causing the crash in my larger app (with many more moving parts, so to speak).
My question is two part:
1) can anyone suggest some debugging processes to help me identify exactly what the problem is here, in case it isn't the FindPlane function after all?
2) does anyone know why the FindPlane function might cause an error? Even if it doesn't successfully find a point it should still return Vector3.zero and a new/default Plane object, neither of which should result in a crash.
Thank you for your thoughts on this perplexing issue.
EDIT: I tried installing and activating Tango-Debug-Overlay recently and it shows a bit of diagnostic info. The problem appears to be thermal, and from what I can tell, related to the depth sensor. So now I'm trying to set a very low FPS, as a test, and disabling the depth sensor between frames, to see if that has any impact. I will post updates as I find out info.
I'm trying to get started with Google Tango for Unity by following this tutorial: https://developers.google.com/project-tango/apis/unity/unity-prefab-motion-tracking
But when I build and run my project, the gyroscope doesn't seem to work and the camera doesn't respond.
I'm using Unity 4.6.7.
Any suggestions?
All of the samples have worked for me without issue in unity 5.1.3f1 personal.
you could try connecting adb logcat and observe for errors during execution.
find ADB.exe in the android SDK directory
from a command prompt run it with the parameters 'adb.exe logcat -c' to clear the logfile, then again without the -c and watch for errors.
In Unity, the gyroscope on some Android devices is disabled by default, assuming the device has one. So you might need to enable it when the app starts up to make sure it is being used, by using Input.gyro.enabled = true;
It also might be that the app is for whatever reason not asking for permissions, which is then resulting in the app being automatically denied access to the gyroscope and camera by the device.
There might also be some other logic that is interfering or altering the gyro data in some way. It's very unlikely, but possible, so it might be worth looking into if all other suggestions fail.
Hope you find a solution soon.
I've done a decent amount of reading about how to profile iPod applications using Shark, and all works well until I try to click "Start" (and nothing happens). I've tried profiling an individual process (app), all processes, and it doesn't seem to Start. This tutorial is one place that I used to set it up (so I think I'm following all the steps):
http://rudifa.wordpress.com/2009/09/16/profiling-an-iphone-application-with-shark/
(I've also rebooted my mac and iPod)
Anyone have any ideas on what to try next?
Shark support has been dropped on iOS 4. Official Apple position can be seen here:
https://devforums.apple.com/message/243237
They expect you to use Instruments and Time Profiler instead.
Have you tried the Time Profiler instrument? Apple seems to be moving in that direction.
I have set up my DDMS to work with the emulator and display the processes running etc. but in the Dev Tools of my emulator it firstly wont let me tick the Show CPU Usage box, and secondly I do not seem to have an option to display the FPS which apparently, according to sources on the internet, is possible to do.
Has anyone had this trouble and know how I can solve it and display CPU usage and FPS as my android game is running?
Thanks
To get an idea of what CPU speed your emulator is emulating try this:
1) start a shell session (adb shell),
2) then run "cat /proc/cpuinfo" to get the BogoMIPS.
Here’s more information on this.
Has anybody had any success ever attaching a debugger to a tethered device? I am able to debug my j2me application in the emulator, but have a lot of trouble sorting out phone-specific problems when they come up. The phone I'm using is a Nokia N95, but ideally the debug process would work on any phone.
Is this possible? If so does anyone have steps they've used to set it up?
Sony Ericsson supports debugging on ebery phone at least since K700, this is done by using KDWP. UIQ 3 communicators also can be debugged the same way.
By the way, it the latest phones by SE it is even possible to monitor memory consumption and CPU profiling. So if you wanna debug your apps on real phones, I would suggest also using SE phones, they are really good at it. I use Netbeans, and it works without any problems with any SE phone.
Motorola phones support a debugging interface called KDWP(Motodev registration required).Their MIDway tool can also be useful for getting debug trace information from a midlet running on a device.
As other stated, on device debug is something that strictly depends on manufacturer's will and often it's nearly impossible. However, i can address you to Gear Java Mobile Framework that gives you the opportunity to use an on-device debug console to print your messages and thus read phone specific issues. If you need some explanation on how to use it, take a look to this tutorial
Unfortunately this is not generally possible. Some makers (like Sony-Erricson) support this on some of their phones but not all. I am not sure if there is on-device-debugging tool for N95 but you can use Nokia's emulator which should be pretty close to the device. The new Java ME SDK comes with promise of real ODD in near future. But it still very much depends on OEM cooperation.
I find a good debugging method is to control a string value which gets painted on top of everything else when it is not null. This will work anywhere, though obviously isn't ideal, but can be used to catch Exceptions, print values etc. Of course you're limited to the small screen, but in theory you could even code some scrolling functionality.
Some people use RMS logging but personally I could never be bothered.
As others have said here, Motorola have Midway which I think is great.
Others are correct here in that on-device debugging is very much device specific. I haven't done anything with Series 60, but at least on Series 40 phones, I had to open up a CommConnection and write out to it in order to see much of anything going on. The device emulators are again a mixed bag, but you usually can get 90% of the way to your application working on them and can usually get your debugger connected to them. If you aren't making use of any of the hardware on the phone, that should get you most of the way there.
I've used the Blackberry tools on occasion to debug J2ME applications (without using RIM APIs) but it is very slow and still is only emulation, not the actual device (but it sometimes does help to shake the odd thing out). I agree it is frustrating when you have something running on an emulator only to find that it doesn't run on the hardware.
You can not debug step by step like android or other SDK.
In J2ME you can trace the error by adding the log statement in the code and add another midlet and display that log screen in that midlet.
Example: add Log.p("Log statement.....");
LogMidlet.java
// Add the following line in the startup method of this midlet.
Log.getInstance().showLog();
This way you can somehow track the error in j2me.
I think it is possible to add additional debugging information on preprocess step. Like this:
public void myMethod() {
Debug.traceMethod("myMethod");
int var = 1;
Debug.newLine();
var++;
Debug.newLine();
...
}