How to get the Pixy camera working on ROS ?
I'm trying to get the Pixy camera working with ROS (Hydro) on Ubuntu 12.04 x64.
Overview
If you haven't heard about the Pixy yet, it's a camera with embedded vision processing that does mainly fast blob tracking.
It is provided with a software and a GUI written in C++ and Qt, called PixyMon. So I thought it could be great to convert it to a ROS package ! Of course I could connect the Pixy to an Arduino and get some data from a serial link, but I'd like to use the direct USB link to the Pixy, no arduino, and have all the capability of PixyMon within ROS. PixyMon allows you to interact with the Pixy, change its parameters (lightness, contrast...), get the camera image, detected blobs position/size, record new colors...so I'd like to have a ROS wrapper for all of this.
Explanation of the issue
So far I can build and link and execute PixyMon as a ROS package, it detects my Pixy but cannot connect to it, PixyMon terminal shows :
Pixy detected.
error: Unable to connect to device.
and the terminal from where I execute the node shows :
libusb_bulk_write -7
libusb_bulk_write -7
interpreter finished
destroying interpreter...
done
libusb_bulk_write -7
libusb_bulk_write -7
And they all repeat. A click on Parameters button give a segmentation fault and crash. So somewhere something is not using the right libraries, or not the right Qt version, or the different parts of the project are not linked properly I suspect.
Here are the steps I followed to convert PixyMon into a ROS package
So I basically created an empty Qt package, and paste PixyMon (that means common and host folders) inside src folder. My package.xml contains this for Qt project :
<buildtool_depend>catkin</buildtool_depend>
<build_depend>qt_build</build_depend>
<build_depend>roscpp</build_depend>
<build_depend>libqt4-dev</build_depend>
<run_depend>qt_build</run_depend>
<run_depend>roscpp</run_depend>
<run_depend>libqt4-dev</run_depend>
My CMakeLists.xml is as follow (I removed all comments) :
cmake_minimum_required(VERSION 2.8.9)
project(pixymon)
find_package(catkin REQUIRED COMPONENTS qt_build roscpp)
find_package(Qt4 COMPONENTS QtCore QtGui QtWidgets)
include_directories(
${catkin_INCLUDE_DIRS}
src/common
src/host/pixymon
/usr/include/libusb-1.0)
link_directories(
src/common
src/host/pixymon)
catkin_package()
file(GLOB QT_FORMS RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} src/host/pixymon/*.ui)
file(GLOB QT_RESOURCES RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} src/host/pixymon/*.qrc)
file(GLOB_RECURSE QT_MOC RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} FOLLOW_SYMLINKS src/host/pixymon/*.h)
QT4_ADD_RESOURCES(QT_RESOURCES_CPP ${QT_RESOURCES})
QT4_WRAP_UI(QT_FORMS_HPP ${QT_FORMS})
QT4_WRAP_CPP(QT_MOC_HPP ${QT_MOC})
file(GLOB_RECURSE QT_SOURCES RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} FOLLOW_SYMLINKS src/common/*.cpp)
file(GLOB_RECURSE QT_SOURCES RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} FOLLOW_SYMLINKS src/host/pixymon/*.cpp)
add_executable(pixymon ${QT_SOURCES} ${QT_RESOURCES_CPP} ${QT_FORMS_HPP} ${QT_MOC_HPP})
add_library(chirp src/common/chirp.cpp)
add_library(qqueue src/common/qqueue.cpp)
add_library(blob src/common/blob.cpp)
add_library(blobs src/common/blobs.cpp)
target_link_libraries(blobs blob)
target_link_libraries(pixymon ${QT_LIBRARIES} ${catkin_LIBRARIES} chirp qqueue blobs /usr/lib/x86_64-linux-gnu/libusb-1.0.so)
install(TARGETS pixymon RUNTIME DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION})
I can build and execute the normal Pixymon project provided for the Pixy and it workd well, it is building using Qt5 with the .pro file. But it seems ...
This looks sort of reasonable. Without hacking on it a lot, it's hard to say for sure. I suspect most of your build process is fine, or you would have symbol errors at link time or at startup. Have you tried running your node in gdb? Does it have a debug mode that you can enable?
Thank you for your reply. Yes I agree the build process should be ok. I tried to run the node in gdb but it doesn't give me more information. Actually, all the error written in the terminal are written by qDebug calls. The error "libusb_bulk_write -7" cause the problem, I'll try to trace it back.