As there is actually no binary available for usb camera drivers for Kinetic, i recommend to force the release of http://wiki.ros.org/usb_cam.
There was a ticket opened on the repository four month ago and the maintainer said to do some testing, but it was not finished right now.
1 Like
I also need usb camera driver on ROS kinetic and would like to move this discussion forward.
As we can see http://wiki.ros.org/Sensors/Cameras#Monocular_Cameras, there are many usb camera driver package. Among them, it seems libuvc_camera is recommended and I remember there are huge discussion and effort to make āofficialā ROS USB camera driver. So best solution seems to release libuvc_camera to kinetic and continue using as an āofficialā ROS USB camera driver.
http://ros-users.122217.n3.nabble.com/call-for-an-official-ROS-USB-camera-package-td2116581.html
http://ros-users.122217.n3.nabble.com/USB-camera-UVC-driver-API-review-td3754584.html#a3756967
However, there are device file permission issue like http://answers.ros.org/question/219886/libuvc-launch-get-permission-denied-opening-usb-error/ (if some one know clean solution , let me know), so I had test other packages on kinetic.
https://github.com/bosch-ros-pkg/usb_cam/
https://github.com/ktossell/libuvc_ros/
https://github.com/ktossell/camera_umd/
https://github.com/ros-drivers/video_stream_opencv/
, with 4 different usb camera
Bus 003 Device 003: ID 04f2:b39a Chicony Electronics Co., Ltd
Bus 003 Device 014: ID 056e:700e Elecom Co., Ltd
Bus 003 Device 015: ID 046d:0825 Logitech, Inc. Webcam C270
Bus 003 Device 016: ID 0ac8:0336 Z-Star Microelectronics Corp. Elecom UCAM-DLQ30
and all working well. 
this is good news.
Unfortunately, camera_umd seems deprecated, usb_cam and libuvc_cam seems inactive, so last resort is video_stream_opencv, @awesomebytes can you release this to kinetic?
https://groups.google.com/forum/#!searchin/ros-sig-drivers/usb|sort:relevance/ros-sig-drivers/OjFCL_0QkcI/yesQ-3fw_jEJ
This also means we will going to use video_stream_opencv as an āofficialā driver, which I feel not so popular until new, (Iād like to hear @joq opinion, for example)
Other possibility is force transfer/move usb_cam and usb_cam-release (or libuvc_camera if we can fix the problem) to ros-driver repository and keep release on kinetic, give maintainer ownership to someone in this list, (if nobody I can). @wjwwood, @dirk-thomas, @tfoote
This might be off-topic but It was surprising for me that fundamental package such as USB camera driver is not released on kinetic which was launched a year ago.
I think will have more orphaned package in coming years, since people use these package because it is well matured and stable, this also means original developer is satisfied and their interest moved to next project.
I know that it is common style to keep repository small and independent as discussed
Joystick_drivers package and https://github.com/ros-visualization/rqt_common_plugins/pull/442#issuecomment-285243913. But I think one way to keep package maintaind, at the lowest level such as releasing to new distro, is to create repository containing multiple packages, and if someone want to release one package in that repo, then he/she have to release other packages too, eventhough he/she is not interested in that package. Otherwise, each package requires someone with enough resources (skill, time, motivation, responsibilityā¦) .
So based on my theory, weāll make ros-drivers/camera_drivers package that contains all of camera packages (I know this is very dangerousā¦) or put opencv based image publisher like video_strem_opencv into https://github.com/ros-perception/image_pipeline.
I would propose to put fundamental packages such as USB camera driver should hosted on in NOT a personal repository but osrf-related organization repository or repository with several responsible ownership. Of course maintainers who could not keep working are recommended to give a ownership to as an final project, but we rarely see this happens. So if a package is hosted at osrf-related repository, we can assume that someone in osrf will find new maintainer and give him/her permissions,
Or at least, move *-release repository to under team control and enable to release in new distro, if it runs without any changes.
1 Like
You are addressing quite a number of different thing in this post, but to me the interesting bits are the ones regarding forking to take control of the ROS releases away from the current maintainers. Sorry if that means Iām ignoring the practical bits about using USB cameras.
I donāt think this is needed as general policy, and I think it is quite disrespectful to the original authors and harmful for development if done simply for the reason to host everything under control of OSRF. If done because development or maintenance of an important package seems to have stopped (as may be the case now), then I see no problem in forking the project.
Before reaching that conclusion though, enough effort should have been spent trying to raise the issue with the current maintainer(s). In the case of usb_cam, this seems to have been done [1].
[1] Add usb_cam to ROS Kinetic main repository Ā· Issue #53 Ā· ros-drivers/usb_cam Ā· GitHub
It does not seem to me that OSRF necessarily has to be the one to maintain the fork though. Anyone with sufficient motivation and time is free to maintain a fork and try to get his fork released into Kinetic.
I think this is a very bad idea. Merging issue trackers and coupling version numbers and release cycle (bloom does not allow different version for different packages in one repository) of unrelated packages does not make maintenance or development easier. It just makes things harder.
Besides, if a package goes unmaintained for a long period of time without anybody forking it, then apparently nobody really needs the package. Maybe it should disappear from the ecosystem then.
In short: to me, the correct way to solve a problem with an unmaintained package that you need is to fork it, patch it, and try to get the patch back to upstream. If that fails and the upstream maintainers seem to have abandoned the project, you can try to get your fork released in under the original name in the ROS ecosystem.
In short: to me, the correct way to solve a problem with an unmaintained package that you need is to fork it, patch it, and try to get the patch back to upstream. If that fails and the upstream maintainers seem to have abandoned the project, you can try to get your fork released in under the original name in the ROS ecosystem.
I totally agree your point, in general.
But whatās happens today is, although there is a huge request on releasing but it not happens. Why? because I think kinetic did not have usb camera support because it is too important/fundamental package thatās why potential maintainer reluctant/hesitate to fork and release from their own repo.
What happens here is;
- A lot of people need usb camera drivers, specially beginners, because this is the most spread sensor and this is a good starting point. But they do not know how to solve this situation, may be they do not know or they hesitate to compile from source. Thatās ok. Thatās why ROS is distributed via binary package.
- Expert people knows how to solve this problem and they realized there is an issue ticket on current maintainer repository. So theyāre kindly waiting for responseā¦ They can fork original release repo to thier own, but they respect original author and politely waitingā¦ It is not critical for them because they can solve the problem because they know how to compile, build deb by them selves, or may be they have better sensors.
So for me,if the package is too important specially for beginner useres, then it will be located within in gap between users and current/potential maintainers, it is dead-locked. And Iām afraid weāll have this problem on every year 2016(Kinetic), 2017(Lunar), 2018(M). So question here is can we start thinking any way to solve this? Try to find a way that can help back to the correct path?
If you have the time, how would you feel about maintaining a fork of usb_cam and guide it into Kinetic? I think that would pretty much solve the problem.
This is a standard problem almost all software distributions face over the years.
At some point the current upstream project maintainers do not respond anymore or quit the project.
The distribution still wants to ship the package though and is left with āthe lastā official release (and usually many patches over the years).
They donāt want to take over maintainership, because itās just one package of the huge distribution and nobody has the resources to maintain individual packages and the infrastructure. Especially if the package has to be tested on hardware.
I believe OSRF should not try to maintain such packages.
Most users on the other hand do not consider becoming a maintainer (which never is as spectacular as it sounds) either because in their opinion they donāt know the frameworks/the release process/the project well enough to do so,
or because they deliberately want to stay users because they work on higher-level stuff.
Guess what? Without a solid foundation it can become arbitrary hard to build on top of itā¦
In my opinion, the latter group is best qualified to resolve these issues.
By contacting the previous maintainers - maybe even by phone, if they donāt respond to mails -, by helping out with maintenance, by taking over the release process or by forking the project altogether.
Iām working on releasing as we speak 
@k-okada
Edit: Itās on the process of releasing, currently pending PR here https://github.com/ros/rosdistro/pull/14296 from using bloom. So I think itās a matter of time the package is available.
Ok, I still believe we need community-wide efforts to release existing packages into new release, instead of depending on individual efforts, but I have released https://github.com/ros/rosdistro/pull/14870, https://github.com/ros/rosdistro/pull/14867, https://github.com/ros/rosdistro/pull/14862.
So now we have usb_cam, libuvc_ros, camera_umd, video_stream_opencv (@awesomebytes), cv_camera (@OTL) on Kinetic. Now I think we have enough set of usb camera drivers for now.
I hope I did not create situation that is ready for issues like http://ros-users.122217.n3.nabble.com/call-for-an-official-ROS-USB-camera-package-td2116581.html againā¦
1 Like
+1 for overall community effort.
-1 for forking devel repos and making release without even trying to get an access to the original repos, particularly for those that are under certain organizations such as ros-* where supervisors other than maintainers of each repo are very attentive.
Why not ask for write access first?
- Why not ask for write access first?
The reason we had these abandoned packages, because no one can take maintainerās responsibility with āNormalā process. So my proposal here is we need to find novel way of maintaining abandoned (but still useful) packages.
@Patrick, finally we have usb_cam driver on kinetic
ros-kinetic-camera-umd: 0.2.5-0
ros-kinetic-gscam: 0.2.0-0
ros-kinetic-libuvc-ros: 0.0.9-0
ros-kinetic-usb-cam: 0.3.5-0
1 Like
Awesome! Thanks for all your effort.