I'm currently attempting to use multiple Kinect v2.0s as part of my dissertation. I've looked around on the subject and I'm aware of the issue with usb bandwidth so the two Kinects I'm currently using are on different usb controllers.
The issue I'm having is that as part of the GetDefault() function (2.0 SDK) it, as the name suggests, simply gets the default Kinect. Is there a way of either determining which Kinect to 'get' or determining which Kinect is the 'default'? (I know the SDK only allows for one but I'm exploring the idea of having a separate application handling each Kinect).
Thanks in advance for any input.
Using the Microsoft SDK you don't have a chance to use multiple Kinect2 on one PC:
Sensor Acquisition and Startup
Kinect for Windows supports one sensor, which is called the default sensor. The KinectSensor Class has static members to help configure the Kinect sensor and access sensor data.
Kinect API Overview
We tried similar things, but in the end we settled with a client/server-Solution where additional Kinects are connected to client PCs. But, even here you need to be careful if those Kinects are used in the same room - the sensors might pick up light from the other emitters! (see here e.g.: Interference between multiple Kinects).
Another thing you need to keep in mind when working on an client/server-solution - the Kinect does not handle Remote Desktop Connections very well:
Remote Desktop
If you are accessing the Kinect using Remote Desktop, You must change the remote desktop audio settings to "play on remote machine". If you do not do this, the runtime will not be able to see the audio device, and may disallow connection to the Kinect. (2.0 SDK and Developer Known Issues)
Another way you could choose, is use OpenKinect, which is supposed to support multiple cameras (here, here, here, ...) but all this seems not so easy to achieve too. Also, during our tests we noticed that the depth values are different when using the official Microsoft SDK or the open source library, since there is a lot of black-box-magic happening in the official SDK.
Have you considered running a virtual machine in parallel on your machine? Just have the virtual machine ignore the USB port that one of the kinects is on so the virtual machine is forced to use the other one.
This may require way more processing power than just plugging them in, but it should work, especially if you are trying to use them for two different programs.
Kinect for windows are only supported for virtual machines, (not including kinect for xbox one and kinect for 360 with adapters)
Related
I am working on using a Raspberry Pi in an embedded project that will utilize wifi to communicate with external devices. The device should be able to act either as a standalone wifi hotspot that devices can connect to or in the case of the presence of an existing wifi network it should connect to that network so that the user does not have to give up his internet connection in order to connect to the device. I plan on making the device start up in hotspot mode, the user can then use the web interface to enter the details of a network that he wants the device to connect to, whenever the specified parameters fails to establish a connection then it defaults back to hotspot mode.
Now the technical stuff I am struggling with is that I want to implement the control software in C# running with Mono on Arch Linux on the Rapsberry Pi. I am struggling the find the Apis or libraries needed to manage the Linux wifi connection. On Windows it seems as if managedwifi.codeplex.com can be used but it does not seem to be compatible with Linux.
My last resort would obviously be to execute shell commands and then parse their outputs, but considering how crude and possibly unreliable that would be this is obviously my last resort.
Any ideas regarding what I should do?
PS. Another thing I might consider before using shell scripts, if it makes a difference is to use Raspbian or some other distro instead.
Actually calling shell commands from a managed code is not a very bad idea. They are reliable, very well tested and mostly lightweight and sometimes just a wrapper around kernel or other modules function. This is also seems to be the same method Node.js modules use when they want to access something lowlevel or related to networking. For example see this source code: node-wireless/node_modules/wireless/index.js
If you don't like it this way there is always "Interop". The same way that you can DllImport() libraries in Windows, you can do in Linux. See here: http://www.mono-project.com/Interop_with_Native_Libraries
IMHO the second solution doesn't worth the effort. Calling shell commands is elegant and neat enough.
my pi is starting into wlan0 as AP with hostapd, when a AP also a lighttpd is starting and give a web interface do change the settings. the web interface verify and write the input in a sqlite3. a second script is doing the canges according to my changes. (like add, edit or remove wifis in wpa_supplicant, reset wlan0 to be a part of an existing wlan like set to dhcp, tell wpa_supplicants...)
except the lighttpd and sqlite3 all components are already on the Raspery. you dont need any mono or c-libraries
for writing the scripts i use python but also perl is working (even php for the frontend)
I'm looking for a way to use OpenCV (or specifically emguCV in C#) to capture video from the same firewire on 2 different programs simultaneously. Some posts here said that it can't be done since the source driver would be locked into one application at a time.
I found some answers here suggesting the use of SplitCam, but it seems to only work with Webcam. Also I don't like the ads on SplitCam (but I can't complain since it's a freeware).
SplitCam seems to be using the source signal and creates a virtual driver for other programs to use. Is there a way to do the same thing as SplitCam does using OpenCV? OpenCV can access firewire camera and I have no issue using it in emguCV with a single program running.
After searching for a while, I found 2 different solutions.
1) Implement DirectShow Virtual Video Capture Source Filter. This project has been documented quite well over at CodeProject. This method takes a bit of a learning curve since I don't know much about DirectShow.
2) Use a 3rd Party component. I found one from e2esoft that works like SplitCam but it's an SDK that you can use in your own project. They already have a CSharp example. I did have a little bit of issue (Error 80040154) using the COM object provided with this example since it's a 32-bit COM object but I'm running a 64-bit Windows 7. I found a work around here using the registry hack.
I ended up going with solution #2 since it's easy to implement quickly. I use the component to create a virtual device that grabs the video from the main firewire camera device. After that my program that uses the emguCV to grab frame can just grab from the virtual device. The virtual device can be used by multiple sources and so far I have 3 instances of my program grabbing from the virtual device and I don't see any lag in frame rates (granted that this firewire camera is only running 15FPS max). The downside to this solution is that I would have to pay for the license to get rid of the water mark on the video. I'll update this when I found out how much it is since they don't post the price of SDK on the website. If it's really expensive, I'll have to go to the first solution and learn to implement the DirectShow filter.
Edit 1-16-2013: The price of the VCam SDK is $699.
I need to write VoIP/SIP Soft Phone in C# using WPF interface with Audio support only.
I need to have call transfer, call conference, and recording of conversations in mp3.
I've looked at VoIP SDK from ABTO LLC, but it is slow at application startup (30 seconds to start application, I think it's related to loading activex part of this sdk).
I've also looked at SIP.Net, but it's only for SIP and doesn't contain components for voice data transfer.
I have very limited time only 2 months from zero to fully working app.
What SDK can I use to accomplish this task?
Windows 7 must be supported.
We have done this using SipekSDK. It's written on top of famous pjSIP open source SIPClient project. It does all the operations you have mentioned in the question.
https://sites.google.com/site/sipekvoip/
What is the Sip server you are going to use ? If its not asterisk, you can have a look of microsoft's Lync here.
You can download the Lync SDK and start exploring. Not just the audio call, Microsoft Lync has features like video call, chat, presence, conference etc.... and ofcourse connectivity to landline/pstn through voip providers
Another interesting article explaining the different SDKs for unified communications can be found here
Edit: If its for Asterisk, Sipek is the only available free opensource but we had lot of problems in installing in clients system like
C folder access
Poor device
support
Port conflict- If any
other voip app like qutecom runs on
5060, then Sipek wont run as the
port is being used already.
I struggled with this exact issue and eventually came across ABTO LLC.
They have an SDK available that supports Win 7, Win XP and can be used in WPF.
We did ask them though to build a separate SDK example for us as we are using ClickOnce for our deployments and so registering external libraries is impossible, but they graciously did it and i think have integrated into their SDK, if not then ask them to give it to you.
We are using a FreeSwitch SIP Server combined with ABTO's library and it is working like a dream. We are doing VoIP, Video and Conferencing and have had no issues at all.
The application I added the VoIP functionality to is a WPF 4 app.
I am planning to verify the user input for my application using the biometric input. I did some research on net and came up with following options of biometric input:
Fingerprint
Facial Recognition
Retinal Scan
Iris Scan
Voice Recognition
Signature Verification
Out of which I felt the fingerprint as most suitable options. But the problem with this is the API of the fingerprint device will vary with its hardware. So most probably I think I will need to code against the multiple devices API, which I don't find friendly.
I intend to do the programming stuffs in C#. Is there any way out of this. As I am new to this I'm clueless. What is the way to attack this problem and how vast is the project scope and what should be my approach for this project.
The problem is not unique to fingerprint readers, it will apply to all other options in your list and many other peripherals. In fact a standard API is the exception.
So you will have to look for somebody selling a library for this or writing your own (COM and/or Interop). And rolling your own will usually not be small or simple project.
Your program will have a list of supported devices, excluding the rest.
A colleague of mine was tasked with building a biometric based staff clock-in system for the company we both worked for. We, IT, choose Fingerprints as the biometric source. He researched and used this library from Bayometric - Griaule Fingerprint SDK along with some cheap MS print readers. From what he showed me and talked about at the time, does lead me to believe that this .net library had a nice API and was easy to work with.
The biometric system is still being used today, some 5 years later.
I work in the biometric field, and I use C# for a lot of the fingerprint stuff I do. My company had to develop a fingerprint device abstraction library for this very reason. Consider that all fingerprint scanners only REALLY need one call: getImage. Knowing this, my company wrote a library which initializes and sets up each device, creates a generic wrapper, assigns a unique ID, and throws it into a big list that you can enumerate over.
Then from the C# side all you have to do is "pick" a device (all you have to go on is a unique ID and maybe a manufacturer) and then use it. The image data that comes back has to be decided on in advance so that you know what you're going to get every time
The main problem with this approach is that a lot of devices these days have various gimmicks (e.g. programmable flashing lights), and by abstracting the devices away you lost the ability to access these special abilities. Furthermore, some devices actually return multiple channels of data (various spectrums of light for example) and you have to throw away all but one channel so that the application can remain device agnostic, which is a hard decision.
Finally keep this in mind: if you do minutiae extraction, the device you use unfortunately WILL impact which minutiae are detected. Some devices are "tuned" for certain algorithms, and so enrolling with device A and matching with device B may not work at all despite having picture-perfect fingerprints.
There is a similar question here: finger print reader for .net windows forms / WPF or silverlight client
Check the links in the answers
I am hoping to receive some general guidance on accomplishing a seemingly simple goal. I have a DSLR camera (Canon EOS 50D) and need to write an application that will tell the camera to take a picture. I also need to transfer the picture to the computer and possibly delete it from the camera's storage. A bonus would be to get a live preview from the camera in my application. My environment will be Windows (either XP Pro or Vista Enterprise) and .Net 3.5 (C#).
I have done some research and found a couple of options. One I know will work, but limits me to using only Canon cameras in the future. I have found and downloaded an SDK from Canon that provides a lot of this functionality. I've looked over the SDK and while it's extensive and written in C it does have C# wrappers that will speed up development a bit.
Another option I've found is called Windows Portable Devices. Apparently, it is an API that will talk to devices that implement PTP and MTP standards. It is COM based and as far as I can tell it has no .Net wrappers. This is not however a show stopper. I could P/Invoke the functionality I need or write a Managed C++ DLL to use in my application to talk to the camera.
I am looking for anyone with experience with WPD to give me pointers. I've perused the documentation and seen references to transferring images and deleting images. I have not, however, seen mention of commands to take a picture, get a preview image, or say focus/auto-focus.
The WPD api provides the command WPD_COMMAND_STILL_IMAGE_CAPTURE_INITIATE
I am not sure whether your camera supports it but it should be simple enough to find out. If you can get the "wpdinfo" tool from the driver development kit and start it with your camera connected then send it a WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_COMMANDS command and see if it supports the still image capture command. IF so then you could give that a try.
The comment from TallGanglyGuy is incorrect. ptp does allow you to trigger new images and change exposure, etc. Some cameras have firmware that only exposes some of the ptp commands.
PTP supports common device controls, such as taking a picture, so that
the user could take advantage of the PC/camera combination in new and
different ways again, without requiring additional software.
quoted from http://msdn.microsoft.com/en-us/windows/hardware/gg463507.aspx#EXC
try my Eos Framework: https://github.com/esskar/Canon.Eos.Framework
IMHO it's a better alternative then the .cs file that comes with the SDK.
PTP and MTP are both protocols for transferring files from a digital still camera (DSC). The protocols provide no functionality for triggering new images, or setting exposure control. You will be stuck using the camera specific SDK. If you want multiple vendor support Nikon has an SDK that provides similar support as the Canon SDK for their cameras.
More info on PTP and MTP can be found here:
http://en.wikipedia.org/wiki/Picture_Transfer_Protocol
and
http://en.wikipedia.org/wiki/Media_Transfer_Protocol
EDIT
I forgot to mention that WIA may be interesting to you, assuming your camera's driver provides a WIA interface.
This is really generic, but it may help.
I had to write an application that used two different bar code scanners from two different vendors with different SDK's. I created an interface that defined the methods and events that I wanted to code for, and then wrote adapter classes that implemented my interface.
This worked well in my case, and switching from one to the other was pretty seamless. If you took the same approach, you wouldn't be totally dependent upon one SDK.