Since it took me quite some time to figure out how to get Xtion (Primesense) to work on VMware I thought to share it here with you. (with Kinect I have a problem to let ROS see the device even though VMware has successfully connected it).
roslaunch openni2_launch openni2.launch
Running the above command gave me the error:
Warning: USB events thread - failed to set priority. This might cause loss of data...
I either got a single frame or no frame when running "rviz" and Add --> Image --> Image topic --> /camera/rgb/image_raw
So how do I get video frames in Ubuntu from a Primesense device while using a Virtual Machine (VMware)?
My specs
Windows 7 running VMware 10.0.4 build-2249910
Ubuntu 12.04.5 Precise in VMware
ROS Hydro
The following question pointed me in the right direction: http://answers.ros.org/question/77651/asus-xtion-on-usb-30-ros-hydro-ubuntu-1210/?answer=143206#post-id-143206
In the answer of blizzardroi (not selected answer) he/she mentions that USBInterface should be 0. I reasoned that since my main Machine is Windows, I should set UsbInterface to 1, which indeed solved it.
Solution
Go to /etc/openni2/ (from system folder, not Home) and open PS1080.ini with administrator rights (e.g. sudo gedit PS1080.ini). Search for UsbInterface, remove the ; and change the value to 1. It should look like below:
; USB interface to be used. 0 - FW Default, 1 - ISO endpoints (default on Windows), 2 - BULK endpoints (default on Linux/Mac/Android machines)
UsbInterface=1
Additional
From previous experience it may also be related that your Windows system may need the kinect drivers as well. If the above not works, try to install the following:
(Kinect SDK) https://www.microsoft.com/en-us/download/details.aspx?id=34808
(OpenNI2 Windows) http://structure.io/openni
p.s. Don't forget your drivers for Ubuntu (replace hydro with your ROS version)
sudo apt-get install ros-hydro-openni*
Important
It doesn't solve the error below, but rviz returns video, which means that we can read the data the Primesense device publishes!
Warning: USB events thread - failed to set priority. This might cause loss of data...
Got the same warning from opennni (issued at start by a binary located at Tools/PSLinkConsole) with another sensor.
Solved by starting process as sudo - my guess: to set priority to USB event threads you need root access. :)
Related
I have an ETTUS Research N210 software defined radio (SDR) connected to my laptop. The device is recognized under macos and also under an Ubuntu on top of a virtual box. These commands:
uhd_usrp_probe --args=addr=192.168.10.2
and
uhd_find_devices --args=addr=192.168.10.2
and even
rx_ascii_art_dft --args=addr=192.168.10.2 --freq 92000000 --gain 30 --rate 8000000 --frame-rate 15 --ref-lvl -50 --dyn-rng 70
work perfectly and deliver results. But whenever I start the gnuradio-companion with a simple flow graph, I get the following error (BOTH directly under macos and on top of VirtualBox Ubuntu):
[ERROR] [UHD] Device discovery error: unknown key format 192.168.10.2
Runtime
RuntimeError: LookupError: KeyError: No devices found for ----->
Device Address: 192.168.10.2
In the flow graph, I put the device address in the properties window of "USRP Source--> General --> Device Address".
Any ideas what I am doing wrong?
I finally found the solution in one of the replies in ETTUS forum. So I put it here in the hope it can be useful for others facing the same problem. The device address field of the USRP source in gnuradio-companion should not be filled with just "192.168.10.2" but with "addr=192.168.10.2". This solved the problem for me.
I try to install Proxmox using a USB, and when I click to install, I see the next error:
testing cdrom /dev/sr0
umount: can't umount /mnt: Invalid argument
testing again in 5 seconds
Finally:
no cdrom found - unable to continue (type exit or CTRL-D to reboot)
I prepare the USB using ImageUSB in Windows, and it does have the previous fail, then I try to prepare in Ubuntu using dd if=pve-cd.iso of=/dev/XYZ bs=1M, I don't know where is the problem.
For someone out there still having similar issue, use below method to create the installation media. That should help.
Instructions for Windows
Download Etcher from https://etcher.io , select the ISO and your USB Drive.
If this doesn’t work, alternatively use the OSForensics USB installer from http://www.osforensics.com/portability.html
Instructions for GNU/Linux
You can simply use dd on UNIX like systems. First download the ISO image, then plug in the USB stick. You need to find out what device name gets assigned to the USB stick (see below). Then run:
dd if=proxmox-ve_*.iso of=/dev/XYZ bs=1M
Note: Be sure to replace /dev/XYZ with the correct device name.
Caution: Be very careful, and do not overwrite the hard disk!
Instructions from: https://pve.proxmox.com/wiki/Install_from_USB_Stick
I'm working on a small OS X app that connects to an FTDI device. I've configured my project according to the answer in this question (I've added the .dylib file as a framework, and I added the ftd2xx.h, WinTypes.h, and ftd2xx.cfg files to my project).
I'm currently able to detect if/when the FTDI device is connected over USB:
DWORD deviceCount = 0;
FT_STATUS ftdiPortStatus = FT_ListDevices(&deviceCount, NULL, FT_LIST_NUMBER_ONLY)
if (ftdiPortStatus == FT_OK) {
// The debugger tells me the deviceCount is now 1
...
}
However, if I try to open a connection to the device using either of the following techniques:
ftdiPortStatus = FT_OpenEx("FT232R USB UART",FT_OPEN_BY_DESCRIPTION,deviceHandle);
// OR
ftdiPortStatus = FT_Open(0, deviceHandle);
the returned ftdiPortStatus is always 3 (FT_DEVICE_NOT_OPENED).
The answer here indicates that the problem might be a new driver that Apple added in OSX 10.9, however, if I attempt to unload that kext:
sudo kextunload -b com.apple.driver.AppleUSBFTDI
the OS indicates that no such kext was found. I'm on OSX 10.10, so maybe Apple repented of their ways and removed that driver from Yosemite(?) Either way, I'm still not able to connect... Does anyone have any idea what might be preventing the connection or have ideas for how I might track down the problem (the returned FT_STATUS isn't very helpful...)?
UPDATE:
The answer, below, solved the problem for me. If you are unsure as to whether you might have a second, non-Apple VCP driver installed, you can find the other drivers by running the following command in a terminal:
kextstat | grep FTDI
which will output something like this:
154 0 0xffffff7f831ee000 0x8000 0x8000 com.FTDI.driver.FTDIUSBSerialDriver (2.2.18) <96 16 5 4 3 1>
155 0 0xffffff7f831f6000 0x7000 0x7000 com.apple.driver.AppleUSBFTDI (1.0.1b12) <96 16 5 4 3>
No, that driver is still there on Yosemite. Running
sudo kextunload -b com.apple.driver.AppleUSBFTDI
still removes the relevant kext and frees the device for access via the D2XX library on this Yosemite system I just tested. The kext may be missing if you haven't yet connected your FTDI device to the system.
It may also be blocked by another virtual comm port driver. If you've installed FTDI's virtual comm port driver, that will also take control of the port and block the D2XX library from connecting. Certain Arduino dev kits also use virtual comm port drivers for the FTDI chips they use, so they may have installed their own driver. Check for that.
Finally, the device name of "FT232R USB UART" that I use in my example code may not be the name of your device. There are many FTDI variants, and you'd need to make sure you're using the name of your specific type of device. This can be obtained from the FT_ListDevices() command with the FT_LIST_BY_INDEX|FT_OPEN_BY_DESCRIPTION options. If you use the wrong device name, FT_OpenEx() can fail.
I have never before worked in Debian environment. I have some problem with camera, I was looking for answers but find nothing.
I am working in virtualbox, the camera is plugged through virtualbox. I am using is my laptop webcam, Lenovo EasyCamera. When I lauch program, for example cheese, I get this message :
jakub#debian:~$ cheese
OpenGL Warning: crPixelCopy3D: simply crMemcpy'ing from srcPtr to dstPtr
(cheese:3368): Gtk-WARNING **: Attempting to add a widget with type GtkImage to a GtkToggleButton, but as a GtkBin subclass a GtkToggleButton can only contain one widget at a time; it already contains a widget of type GtkLabel
libv4l2: error turning on stream: Brak miejsca na urządzeniu
** (cheese:3368): WARNING **: Error starting streaming on device '/dev/video0'.
** (cheese:3368): WARNING **: Could not negotiate format
When cheese is working, the diode from the cam is on, so camera is working, but why Debian cannot show me the image.
I hope you will know what to do. I appreciate your help.
It appears to be the same as this issue:
libv4l2: error turning on stream: No space left on device
You probably need to enable USB 2.0 in your virtual machine and pass the device into your guest OS using a high-speed USB host controller (EHCI).
You may need the VirtualBox Extension Pack, I remember it being required for USB 2.0 in the past. I can't find any current information about that, though, perhaps EHCI support is now included already.
I installed Fedora 19 in windows 8 hyper-v and its working fine but there is one small problem with the display setting, as fedora 19 display setting not providing 1366x768, but i need to set the display to 1366x768 to view full screen, so any suggestions??
Open a Terminal (Ctrl-Alt-T)
Run
sudo vi /etc/default/grub
Find the line starting with GRUB_CMDLINE_LINUX, and add
video=hyperv_fb:[the resolution you want]
If the resolution I want is 1280×720 then my line ends up looking like this:
GRUB_CMDLINE_LINUX="… quiet splash video=hyperv_fb:1280×720"
Write the changes and quit vi by hitting ESC and typing
:wq
Run:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
or when installed in EFI mode
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Reboot the virtual machine
(Note: this is just an over-sized reply.)
I'm using Windows 10 and Fedora 26. Basically what Daniel said still holds, with some modifications:
The file /boot/grub2/grub.cfg doesn't exist on fresh install Fedora 26, and creating the file doesn't affect booting parameters at all (verified with /proc/cmdline). The correct file is /boot/efi/EFI/fedora/grub.cfg (I get the path from Fedora Wiki).
Not every resolution is supported: 1920x1080 is, 2560x1080 is not. Unsupported resolution is simply ignored. I ended up setting it 1920 although my monitor is 2560.
And finally an advice: back up everything you edit. You'll need it some day.
Update: still works in Fedora 27.
I think it's a limitation from Microsoft.
Here's the link http://social.technet.microsoft.com/Forums/windowsserver/en-US/19f32070-46c7-4dec-8824-9942f7fc5a2c/hyperv-and-display-resolution?forum=winserverhyperv
Your only option is RDP.