alternatives to kinect?

[vinot]

Hi all,

I'm looking for another device than kinect, and since primsense cameras are no longer avaiable (my first choice :(  I find these alternatives:

http://duo3d.com/

and http://structure.io/

any suggestion? I don't care to work inside, I'm looking for quality of acquisition and usb powered.

thanks

toni ventura

btw: I don't think that the acquisition of primsense will stop the develop of new devices and applications, as disscused in a previous post, structure sensor could be a good example.

[Joshua Blake]

You say you're looking for devices besides Kinect because PrimeSense cameras are not available. Kinect is still available and unaffected by the PrimeSense acquisition. Is there something wrong with Kinect?

The structure sensor is a small company and used the PrimeSense chipset. I'm not sure whether they or other PrimeSense-based sensor startups will be able to continue using PrimeSense chips. Microsoft has a lot more pull so Kinect v1 wouldn't affected the same way.

Josh

--
You received this message because you are subscribed to the Google Groups "OpenKinect" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openkinect+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lorne Covington]

Kinect is 1) big, and 2) requires a power supply.  It is not a good replacement for the Primesense/Xtion in many applications.  Try wearing a Rift with a Kinect on it vs. a Carmine 1.09, particularly in a wireless setup*!  Or installing depth cameras in the air in science museums where the additional weight and cabling would be a pain.

And then there's 3) the totally brain-dead tilt mechanism you have to deal with on the Kinect: try pointing it down and it tries to tilt back up, because the tilt command appears to be from gravity-detected level, not base-relative.  This adds greatly to mounting complexity because you have to attach directly to the camera body to keep the "intelligence" from screwing up your positioning.

The Kinect v1 is great for some things, but I sorely miss the Primesense cameras for their size and simplicity.  Haven't had a chance yet to try the K2.  The whole Kinect SDK is marred by the assumption it will always be used level (not tilted or rotated), underneath a screen with the users back at a distance - hopefully they have realized for the K2 there are far more opportunities for it out there.

Cheers!

- Lorne

P.S. - Toni: for nearer distances, there is the Intel/Creative camera:

    http://us.creative.com/p/web-cameras/creative-senz3d

And who knows what Apple will do with Primesense; Apple is never the first to do something, they come in later with a usually well-though-out system vs. a single product.

* - http://www.youtube.com/watch?v=UeNdoI-5l10 - The cam on the Rift is actually a Primesense 1.09, not an Intel as Dan says.  The people are being tracked by a PS 1.08, but for that part a Kinect would work OK.

http://noirflux.com

[Lorne Covington]

Oh, and 4) the Primesense can run at 60fps in QVGA, really great for some applications.  Did K2 fix that omission?  30fps is just too slow for good interactivity once you factor in the rest of the pipeline.  What the Oculus folks realized is that low-latency 60fps is a MINIMUM for true reality-like response.

Ciao!

- Lorne

http://noirflux.com

[Γιάννης Γράβεζας]

Well there are some tricks one can do to hide latency, like motion prediction but yeah 60hz is pretty nice to have

Yannis Gravezas

Founder@Intrael

Athens, Greece

+30 6947931815

[Lorne Covington]

Motion prediction only helps during motion, not at the start and end of it - where it really counts.  Like when you want to trigger sounds or visual actions by hand gestures.

For user interaction up at the screen/wall/surface, which is what I mostly do, latency becomes VERY apparent.  If tablets had the same latency on their touchscreens as the Kinect, one would find them very frustrating.  Child of Eden, while beautiful, was too irritating to play for this reason.

I expect the skeleton tracking latency with the Kinect is one (of several) reasons the dominant user interaction model is "hover for a period of time" rather than true gesture.

Ciao!

- Lorne

http://noirflux.com

[Joshua Blake]

The dominant user interaction model moved on from hover-to-click over a year ago. Kinect SDK 1.7 released March 2013 added  Kinect Interactions with grip and push gestures. They work much better and are very responsive. I've used them in several production Kinect apps with no complaints about responsiveness or latency.

I agree on supporting alternate mounting options and continue to provide that feedback. Kinect v2 has a tripod screw mount, although there is still a friction joint in they're. More stable the v1 motor gear slop though.

On the FPS question, of course 60 fps is more desirable than 30 fps, but the system and middleware latency is usually the dominating factor. Kinect v1 with skeleton tracking had a end-to-end latency of around 90 ms. The Kinect v2 has reduced this to 60 ms, a 30 ms improvement.

Going from 30 fps (33.3 ms/frame) to 60 fps (16.6 ms/frame) will only save you 16.6 ms.

Again, I'm not saying that I prefer 30 fps over 60 fps, but the pipeline latency in the K4W v2 sensor and SDK are nearly twice as good as if you had a 60 fps mode with Kinect v1.

I don't know what the latency numbers are for Xtion plus the NITE skeleton stack, but I always found NITE's skeleton tracking to be slower than Kinect SDK v1. Kinect v2 30 fps + KSDK v2 should be on par or better than Xtion 60 fps + NITE.

Josh

---

From: Lorne Covington
Sent: ‎5/‎30/‎2014 4:19 PM
To: openk...@googlegroups.com
Subject: Re: [OpenKinect] alternatives to kinect?

[Γιάννης Γράβεζας]

"For user interaction up at the screen/wall/surface, which is what I mostly do, latency becomes VERY apparent."

Motion prediction is still applicable in this case. You can track the user's hand before it reaches the range where you register a touch event and do some guessing.

"Kinect v1 with skeleton tracking had a end-to-end latency of around 90 ms. The Kinect v2 has reduced this to 60 ms, a 30 ms improvement."

on a  modern desktop or the xbox one, maybe. For use in embedded systems, right now, the K2 has 100s of ms of latency which is actually a huge regression from the first Kinect which works smootly and is thus useful on, almost a decade old, arm cortexes. Things can get even better if you opt out of triple buffering and track from the same buffer the usb writes on. You can get good results even with tearing as long as you average small volumes around your final coordinates.

[Lorne Covington]

And is that grip and push used for selecting interface buttons, or playing drums? (;^})

And the K2 is not an option yet, and I'm having to spec projects with the K1 because there is no delivery date or pre-ordering on the K2.  And also since I have not had the opportunity to try one, much less two together to check for interference.

16.7 mS is ALWAYS a win, even more so as other factors make it a greater percentage of the overall.  Maybe not for someone "clicking" buttons or swipe-scrolling, but for fast-gesture real-time interactivity it is noticeable.  For many years people thought VR "worked" at 15-20fps (67-50mS) but when they got in a Rift at 60fps with corresponding latency it was "holy sh*t this is real!".

And to be honest, I am very dubious that you get a real 60mS motion-to-photons time.  Given 33mS for image capture, and 16.7mS for a 60Hz display, leaves you only 10.3mS for all internal processing and pipeline - with that extra 16.7mS suddenly you would have over double the processing time.  I guess if GPUs are doing the heavy lifting it's possible.

Admittedly, my applications where someone is standing very close to a large screen are more sensitive to this than say a shopping kiosk or a living room game; the imagery fills so much more of the user's field of view, so there is a much greater perceived visual angle to the late motion.

All this is why I am only using skeleton tracking in one application; everything else I do with direct processing of the point cloud.  With a Primesense at 60fps, with my own code on an i7 with a GTX770 and BenQ SH910 projector I get a real 50mS average motion-to-image latency.  I'm moving a lot of my code to DX11 compute shaders, we'll see how much can be trimmed - not much if any probably, but I'll be able to do a whole lot more in that time!

But really, the fact that K2 does not do 60pfs seems to indicate MS is still locked in their living-room/kiosk thinking.  Can the K2 SDK still do skeleton tracking with the K2 turned on its side for a vertical frame?  Looking down at 60 degree angle?  These cameras can do incredible things when you get away from that "stand five feet away in front of it" model.

Cheers!

- Lorne

http://noirflux.com

[Lorne Covington]

On 5/30/2014 5:33 PM, Γιάννης Γράβεζας wrote:

"For user interaction up at the screen/wall/surface, which is what I mostly do, latency becomes VERY apparent."

Motion prediction is still applicable in this case. You can track the user's hand before it reaches the range where you register a touch event and do some guessing.

True, but not what I'm talking about, which is direct image manipulation - when the user starts moving their hand sideways, there is a noticeable delay before what they are controlling starts to move.  Yes, you can catch up with it using motion prediction, but then when the hand stops, there is lag/overshoot before the tracking object stops.  REALLY noticeable if this is being done to music due to our brains exquisite sensitivity to sync.

Ciao!

- Lorne

"Kinect v1 with skeleton tracking had a end-to-end latency of around 90 ms. The Kinect v2 has reduced this to 60 ms, a 30 ms improvement."

on a  modern desktop or the xbox one, maybe. For use in embedded systems, right now, the K2 has 100s of ms of latency which is actually a huge regression from the first Kinect which works smootly and is thus useful on, almost a decade old, arm cortexes. Things can get even better if you opt out of triple buffering and track from the same buffer the usb writes on. You can get good results even with tearing as long as you average small volumes around your final coordinates.

--
Yannis Gravezas

Founder@Intrael

Athens, Greece

+30 6947931815

[vinot]

Hi,

thank you for all the answers!

yes, size of camera and power are big disaventages. I'm still using kinect v1, and sometimes is really hard to handle. Nothing to say if I must scan in backcountry... two batteries to ensure enough power to kinect and laptop

In my case its not important to work at 30 or 60 hz, actually with 3 frames for me its enough, but obviously it's important to improve it! for fast mocap ie.

also it is important for me to have linux support: I don't care to work with win, linux or whatever if I can do the job. With linux I'm sure I can get what I want. And let me say that since few day I'm using skanect (win), just because its simplicity and preformance, but before I used rgbdemo and kinfu, so for future needings I'm sure I will back again at linux. btw, is creative zen linux compatible?

and overall, accuracy!!! so anything that preforms it, will be a goal. More ir resolution, more ir points... it doesn't matter how, but for scanning only purposes, this is the key.

thank you all

toni ventura

[rickypetit]

Hi

Camboard from pmdtec is another alternative, and tof cameras in general seem a good option when they gain resolution. Also, they seem to perform better outdoor than kinect v1.

Best regards,

Ricard