Situation is very weird, when I got it over a year ago, it was fine. I have updated the sdk, updated the windows 10, updated the firmware, all are latest.
behavior in the official "Azure Kinect Viewer" is the following:
device shown, opens fine.
if I hit start on the defaults I get a "camera failed: timed out" after a few seconds and all other sensors (depth, IR) show nothing, I think they are not the issue here (see 3)
if I de-select the color camera (after stop and start) the depth and IR are shown and getting 30fps as expected.
So, my problem is with the color camera connection, since everything runs on the same wires, I'm assuming the device is fine and that the cable works.
I have tried the color camera with and without the depth, on all options with respect to frame rate and resolution, none work at all, missing camera fails. In some cases I get an encrypted error message in the log, something with libUSB, I rarely get it so I'm not including the exact output.
When I open the "camera app" (standard windows 10) just to see if this app sees the color camera, I do get an image (Eureka!), but the refresh rate is like a frame every 5 seconds or more (!!!!), I've never seen anything like that.
I'm very puzzled with this behavior, I'm also including my device manager layout for the device perhaps that hints someone, as far as i can see, this should be a supported specification (I tried switching ports but in most cases the device was never detected or had the same color image behavior).
Any hints on how to move forward, much appreciated.
Bonus question:
If I solved this issue with the color camera, is there a way to work with the dk camera from a remote desktop session? (the microphones seem to not be detected when doing remote desktop). My USB device manager looks fine as far as I can see
ps.
I had also tried "disable streaming LED" and instead of camera failed in the dk viewer, I can get a color image but with a frame rate of about 1 frame per 4 seconds or more.
Related
I'm working on some home automation programs and one of the things I want to be able to do is detect when my 4th generation Apple TV has woken from sleep. This will generally only ever happen when someone pressed a button on its Siri remote to wake it up.
I have a PC (connected to the same TV as the Apple TV) that has a Pulse-Eight USB-CEC adapter, so naturally the first thing I tried was using CEC to determine when the Apple TV is awake. Unfortunately it's not reliable, since monitoring the Apple TV's power status to see when it wakes up produces false positives. (I should note that I do not have "Control TVs and Receivers" enabled on the Apple TV, and can't turn it on for the particular project I'm working on because I need the Apple TV to not change the TV's input.)
I'm trying to think of some other way to do this. I'm open to any possibilities, including things like:
Making use of private APIs on the Apple TV
Running an 'always on' program in the background of the Apple TV that sends a signal when the Apple TV wakes up, if that's even possible. (I suspect that it isn't.)
Monitoring the bluetooth communication between the Siri Remote and the Apple TV, if that's possible
Somehow filtering HDMI-CEC commands so that I can turn on 'Control TVs and Receivers', allow the Apple TV's CEC commands for turning on and off the TV, and exclude commands for changing the TV's input.
Any other method, no matter how hacky or ridiculous, as long as it works!
Does anyone have any suggestions? I'm running out of things to try!
I tried to post below on apple discussion / support communities but was told i don't have the right to post this content. Maybe someone in this group can succeed in doing it:
Apple TV 4 CEC integration is great when it works, but it doesn't work all the time and not with all the various equipment out there, you can do a search across forums and you will see lots of unhappy users. I would like to use a raspberry PI to detect when my AppleTV goes to sleep and wakes up and programmatically turn my tv on or off using its RS232C or custom CEC commands.
I used a bonjour services explorer and compared every single result between sleep and on states and there are no differences whatsoever. I would have expected Apple to welcome such automation projects and make this information readily available with a variable such as status: sleep or status: on.
Is there a way I could tell the two states apart via the network connection?
If not, could one build a TvOS app which runs on the background and makes this information available to clients somehow?
I finally found a method that seems to work consistently. This method is incredibly hacky and not at all the sort of way I'd prefer to do this, but it's the only one I've found so far that works consistently.
I have taken an old USB webcam and affixed it to the front of my Apple TV so that its lens is directly in front of the Apply TV's front facing light. Whenever the Apple TV is asleep, I simply check for the light turning on by taking images from the camera and analyzing their average luminosity. Since the lens is right next to the light, when it turns on it'll create a huge blown out white circle in the image that's incredibly easy to detect.
As long as the Apple TV is asleep, the light turning on seems to indicate 100% of the time that it has woken up. I have yet to find a single incident of either a false positive or false negative.
Since pressing buttons on the Siri remote causes this light to blink, this also means that I can detect buttons being pressed by looking for changes in the light while the Apple TV is awake. It's not 100% accurate, since some button presses are faster than the frame rate of my crappy old USB webcam, but it works well enough.
I would vastly prefer to find a better method of doing this, like making a request over the LAN to the Apple TV where the response clearly indicates it being awake or asleep, but so far it doesn't look like that's possible.
Here I am, six and a half years later, and I've finally found a better way to get the power state of my Apple TV.
I can simply use pyatv, which has a function named power_state that returns the Apple TV's current power state.
I just picked up the Lenovo Thinkpad Yoga 15 (20DQ001KUS) for $799. Here is a link: http://shop.lenovo.com/us/en/laptops/thinkpad/yoga-series/yoga-15/#tab-tech_specs
I'd really like to get the tablet features working in Linux Mint 17.2. I have been doing some googling and found some old scripts below:
https://github.com/admiralakber/thinkpad-yoga-scripts
https://launchpad.net/magick-rotation
With their help, I was able to put together a python script that polls my accelerometer values (found in /sys/bus/iio/devices/iio:device*) to figure out when the screen should be rotated. The difficult part seems to be detecting when the device should be in laptop or tablet mode. If I bend the lid past 180 degrees, or if I tilt the device on its side so that it is perpendicular to the ground, there is a light on my keyboard that shuts off and the keyboard itself is completely disabled. This appears to be a bios feature and indicates that there is definitely a sensor. This would be ideal, and it would solve all of my current problems.
Unfortunately, I have been unable to find any sensor readout in linux that would tell me when the computer should be in tablet mode. I need this to determine when autorotate should be turned on, when the touchpad/trackpad/keyboard should be disabled, and when I should launch or kill the onscreen keyboard app.
In the meantime, I'm using the lid's incline sensor (also found in /sys/bus/iio/devices/iio:device*). This works mostly, as It can detect tent mode and tablet mode. Unfortunately, the sensor is aligned to gravity, so it cannot tell the difference between laptop mode and stand mode (because the lid/screen is in the same orientation with respect to gravity).
The older scripts suggest that there is a special keycode in older models that is triggered when the mode changes from laptop to tablet and vice-versa. Unfortunately, I am not seeing any such keycode/scancode being thrown when I monitor xev/evtest.
In short, I'd like to be able to programmatically determine when the laptop screen/lid is opened more than 180 degrees. Can anyone help me with this?
My current script is linked below, if anyone else wants to see how I'm doing it (or if anyone else wants to make suggestions), I've only spent a day on it, so it's nowhere near finished. I'll probably publish it for GNU release at some later point in time for anyone else needing the same functionality.
https://gist.github.com/anonymous/5d2c2d2967eac8774b69
P.S. As an aside, I'm still trying to get full functionality from the ALPS touchpad. Using some psmouse DKMS installers, I have been able to get multi-touch capabilities like two-finger scroll and two/three finger tap working. However, the 3 physical buttons don't do anything (even in xev/evtest). Passing proto=imps to the psmouse module causes them to work , but breaks multi-touch functionality. If anyone would like to offer advice for that, I'd be grateful as well.
For a computer vision project that I am working on I need to grab images using a Logitech C920 webcam. I am using OpenCV's VideoCapture to do that, but the problem that I am facing is that the image that I take at a certain moment does not show the latest thing that the camera sees. That is, if I take an image at timestamp t, it shows what the camera saw at timestamp (t - delta), so to say.
I did this by writing a program that increments a counter and shows it on the screen. I pointed the camera at the screen and let it record. When the counter reached a certain value, say 10000, it would grab an image and save it with the filename "counter_value.png" (e.g. 10000.png). That way I was able to compare the current value of the counter with the current value seen by the camera. I noticed that most of the time the delay is about 4-5 frames, but it is not a fixed value.
I saw similar posts about this issue, but none of them really helped. Some people recommended putting the frame grabbing routine into a separate thread and updating a "current_frame" Mat variable. I tried that, but for some reason the issue is still present. Someone else mentioned that the camera worked well on Windows (but I need to use Linux, though). I tried running the same code on Windows and indeed the delay was only about 1 frame (which might as well be that the camera did not see the counter because the screen did not update fast enough).
I then decided to run a simple webcam viewer based only on V4L2 code, thinking that the issue might be coming from OpenCV. I again experienced the same delay, which makes me believe that the driver is using some sort of buffer to cache the images.
I am new to V4L2 and I really need to solve this problem as soon as possible, so my questions to you guys are:
Has anyone found a solution for getting the latest image using V4L2 (and maybe OpenCV)?
If there is no way to solve it using V4L2, does anyone know another alternative to fixing this issue on Linux?
Regards,
Mihai
It looks like that there will be always a delay between the VideoCapture::grab() call and when the frame is actually taken. This is because of frame buffering that is done at hardware/SO level and you cannot avoid that.
OpenCV provides the VideoCapture::get( CV_CAP_PROP_POS_MEC) ) method to give you the exact time a frame was captured, but this is only possible if the camera supports it.
Recently a problem has been discovered in V4L OpenCV implementation:
http://answers.opencv.org/question/61099/is-it-possible-to-get-frame-timestamps-for-live-streaming-video-frames-on-linux/
And a few days ago a fix has been pulled:
https://github.com/Itseez/opencv/pull/3998
In the end, if you have the right setup, you can know what is the time a frame was taken (and therefore compensate).
It is possible the problem is with the Linux UVC driver, but I have been using Microsoft LifeCam Cinemas for machine vision on Ubuntu 12.04 and 14.04 machines, and have not seen a 4-5 frame delay. I operate them in low light conditions, though, in which case they reduce the frame rate to 7.5 fps.
One other possible culprit is a delay in the webcam depending what format is used. The C920 appears to support H.264 (which few webcams do), so Logitech may have put most effort to make this work well, yet OpenCV appears not to support H.264 on Linux; see this answer for what formats it supports. The same question also has an answer with a kernel hack(!) to fix an issue with the UVC driver.
PS: to check the format actually used in my case, I added
fprintf(stderr, ">>> palette: %d\n", capture->palette);
at this line in the OpenCV code.
I cannot record audio using monitor source of sink devices,from 2 to 3 days.I have reinstalled Pulseaudio, but the problem remains. I am using ubuntu 12.04 with default pulse audio. few day ago, i had same problem but I reinstalled ubuntu so I overcame problem but now same problem...??
from my point of view, Monitor of internal audio does not seem to get any signal.because
i check Pulse Audio Volume Control (pavucontrol), in which volume bar does not shown volume level in playtab and same case in output Devices tab.However, I can hear audio,and the pavucontrol Play tab shows the name of the applications which is running.
suggest any way to overcome this problem, because my application need audio recording from speaker(from context of pulse audio from sink device).
Thanks...
I got the solution, it was a simple case of the monitor being muted. In pavucontrol go to input devices, then in the show button at the bottom switch it to All input devices. I believe it's normally set to all except monitors, so the monitor doesn't show up. In my case it was this monitor that was muted, but I could still hear sound because the internal audio wasn't muted. sorry for pasting here but lets Hope it helps someone....
I'm trying to debug a laggy machine vision camera by writing text timestamps to a terminal window and then observing how long it takes for the camera to 'detect' the screen change. My monitor has a 60hz refresh rate, so the screen is updated every ~17ms. Is there a way to determine at what point within that 17ms window the refresh timer currently is for an X11 application.
EDIT: After wrestling with the problem for nearly a day, I think the real question I should have asked was how to generate a visual signal that was sufficiently fast to test the camera images. My working hypothesis was that the camera was buffering frames before transmitting them, as the video stream seemed to lag behind other synchronised digital events (in this case, output signals to a robotic controller)
'xrefresh' is a tool which can trigger a refresh event on an X server. It does this by painting a global window of a specified color and then removing it, causing all subsequent windows to repaint. Even with this, I was still getting very inconsistent results when trying to correlate the captured frames against the monitor output, no matter what I tried to do, the video stream seemed to lag behind what I expected the monitor state to be. This could mean that either the camera was slow to capture or the monitor was slow to update. Fortunately, I eventually hit upon the idea of using the keyboard leds to verify the synchronicity of the camera frames. ('xset led' and 'xset -led'). This showed me immediately that in fact my computer monitor was slow to update, instead of the camera lagging behind.