awesomebytes
commented
4 years ago Hello @dejongyeong. I'm going to quote here a bit of extra info you sent me privately by email (please keep the conversations on this repository so other authors and users can help, and maybe the outcomes of this conversation may be useful for others):
I also tried executing the command: rosrun image_view image_view image:=/camera/image_raw camera:=/camera, it gave an error of "Segmentation fault (core dumped)". I would like to know how could I fix this issue?
I would also like to inquire about the buffer queue size. I noticed that there is a delay/lag in the image view (through rviz) when I walk in-front of the camera. Does the delayed or lagged due to the buffer queue size?
Seems like the image_view node is crashing. Which is not a problem of this driver (I would think). You could get more information about why it's crashing by running image_view in gdb.
But I'd first check what kind of images you are getting. Maybe there is something wrong in the image in the interpretation of image_view.
I propose to just do a
rostopic echo /camera/image_raw -n 1 > one_image.txtAnd check that the header makes sense, probably upload here the file as an attachment so we can see if we find anything that looks obviously wrong.
I also see you are able to see the images in Rviz, this may mean that the Rviz code is more lenient, or better implemented, to deal with some issue of the format of the images you are receiving. You could also try rqt_image_view as I believe has yet another implementation.
About the buffer queue size, if you set it to 1 you will have no delay, but if there are issues related to not being able to process it fast enough at some side of the computation you may be losing frames. The buffer itself should only delay if there is another issue that's making that delay happen.
About the delay in the rtsp stream, there was this other issue: https://github.com/ros-drivers/video_stream_opencv/issues/56 where they reported the same behaviour. I personally didn't see any noticeable difference when I tried it many years ago with a local networked camera (compared to a native driver that existed for that camera), but it may have had a different compression type.
You should also test at which rate your image topic is publishing (rostopiz hz /camera/image_raw).
You could also check if the latency comes from your network configuration itself.
You could try other drivers for rtsp, a quick search gave me:
- https://github.com/afdaniele/rtsp-ros-driver even thought it's Python calling OpenCV2 just as the testing script found in this repo, in any case it should have worse delay than the C++ version here
- https://github.com/CircusMonkey/ros_rtsp which mainly makes use of Gstreamer... so you may be better off using the well tested next option
- http://wiki.ros.org/gscam there is also a thread of someone getting gscam to work with a rtsp stream https://answers.ros.org/question/39026/gscam-issues-with-ip-camera/
- https://github.com/robotics-in-concert/rocon_devices/tree/develop/rocon_rtsp_camera_relay but... it's very old, hasn't been touched in 5 years and it implements its backend with OpenCV just like us
I personally would try to see what happens with plain gstreamer to get the stream. If it has better results than this driver, try gscam with the configuration line you used for gstreamer. If it doesn't work or you get the same results, maybe checking ros_rtsp is worth it.
Be warned that if you look for another solution different of a Gstreamer or a OpenCV backend... You'll probably find ffmpeg but OpenCV is actually using ffmpeg so I doubt you'll get any benefits. On a side note... there is some way to make OpenCV backend to use Gstreamer... but I never made it work, but that was at least 5 or 6 years ago.
Good luck!
dejongyeong
Error occurs when the visualization is set to TRUE. How could I resolve this? Thanks for the help.
I'm using ROS Melodic with Python 3 and OpenCV2 vers. 3.2.0.