Home        Store        Docs        Blog

About usb camera


(qdxiatao) #1

Hi,

My rov is ok with Raspberry pi camera module.

  1. I want to try usb camera(Logitech c270)and modify the start_video.sh's video script to "gst-launch-1.0 -v v4l2src device=/dev/video0 ! h264parse ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5600", but it did not work.
  2. if can i save the video stream to a mp4 file or similar format in Qgroundcontrol.
Thanks.

Tao Xia

 


(Rusty) #2

Hi Tao,

We haven’t tried this but other sites reference the C920 camera and this command:

gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-h264,width=1920,height=1080,framerate=24/1 ! h264parse ! rtph264pay ! udpsink host=192.168.2.1 port=5600

Please let us know if that works.

Best,

-Rusty


(qdxiatao) #3

Hi Rusty,

It is ok with this command.

Thanks

Regards,

Tao Xia


(Bent) #4

Hello,

I tried the same command, but I received a strange error:

pi@raspberrypi:~ $ gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-h264,width=1920,height=1080,framerate=24/1 ! h264parse ! rtph264pay ! udpsink host=192.168.2.2 port=5600

Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2933): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming task paused, reason not-negotiated (-4)
Execution ended after 0:00:00.124520445
Setting pipeline to PAUSED …
Setting pipeline to READY …
Setting pipeline to NULL …
Freeing pipeline …
pi@raspberrypi:~ $

Do you know why this happens?

Best regards


(Jacob) #5

The camera will work with v4l2src version 1.8 and higher (gst-inspect-1.0 v4l2src)

The latest debian image has it, or you can use our pre-configured image available in the downloads section of ardusub.com.


(Patrick José Pereira) #6

Bent,

You can also check if gst is already running in background with screen -ls before running this command.

screen -ls
There are screens on:
	829.nmearx	(14/09/17 04:00:40)	(Detached)
	819.file-manager	(14/09/17 04:00:40)	(Detached)
	806.audio	(14/09/17 04:00:40)	(Detached)
	795.commrouter	(14/09/17 04:00:40)	(Detached)
	782.webterminal	(14/09/17 04:00:40)	(Detached)
	762.webui	(14/09/17 04:00:40)	(Detached)
	748.video	(14/09/17 04:00:40)	(Detached)   <------- Video screen
7 Sockets in /var/run/screen/S-pi.

Besides that, you need to send the video to 192.168.2.1 (Ground Station Computer) and not 192.168.2.2 (Companion).


(Bent) #7

Thank for your replies, Jacob and Patrick. Managed to the camera running now with very little delay, using the code on ardusub for video with openCV and GST, in addition to running this line on the companion:

gst-launch-1.0 v4l2src device=/dev/video0 ! \
    'video/x-raw, width=352, height=288, framerate=25/1' ! videoconvert ! \
    x264enc pass=qual quantizer=20 tune=zerolatency ! rtph264pay ! \
    udpsink host=192.168.2.1 port=5600

But increasing the height and width creates a lot of delay, making it impossible to achieve anything near HD quality without having delays that are larger than 1 second. Have you had any luck with decreasing the delay for higher resolutions? I have also tried with lowering the framerate, but the delay seems to be only noticeably different when changing resolutions, regardless of framerate. For the record, I am using the new USB low-light camera (https://www.bluerobotics.com/store/electronics/cam-usb-low-light-r1/ )


(Patrick José Pereira) #8

Hi Bent,

Are you receiving the video with the python example in the ground station computer ? If yes, that explain the delay. Check if QGC have the same delay problem.


(Bent) #9

Hi Patrick,

I have attempted receiving the video with the python example in the ground station computer. I have tried both with opencv-python from this link and in QGC, which both give a higher delay depending on the resolution. This delay seem to be approximately the same for both opencv-python and QGC.


(Patrick José Pereira) #10

Hi Bent,

Have you already checked our troubleshooting guide for the poor video streaming performance ? This will help you and us to identify what is going on.


(Bent) #11

Hi Patrick,

Thank you, that gave me some insight into what could be wrong. I have some issues following the steps, but I have currently checked the following

  • Power supply is 5V with 2A
  • Using the camera at 1280x720 yields %CPU between 260 and 295 (%MEM at 2,3)
  • I tried entering 192.168.2.2:2270/network in my browser without any luck. Did I do this incorrectly? Firefox yields “unable to connect” (both while streaming camera and not streaming camera data)
  • Tried using iperf for checking data transfer rate. Here I attempted various iperf commands, both from the top side computer and the companion. When run on companion, I get

pi@raspberrypi:~ $ iperf -c 192.168.2.1 -u

Client connecting to 192.168.2.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)

[ 3] local 192.168.2.2 port 38620 connected with 192.168.2.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 32.0 GBytes 27.4 Gbits/sec
[ 3] Sent 893 datagrams
read failed: Connection refused
[ 3] WARNING: did not receive ack of last datagram after 3 tries.

So it seems that sending a lot of data from RPi to top side computer should be fine even for large amounts of data? When run from my Ubuntu 16.04 I get

bent:~ $ iperf -c 192.168.2.2 -u

Client connecting to 192.168.2.2, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 208 KByte (default)

[ 3] local 192.168.2.1 port 36798 connected with 192.168.2.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.23 MBytes 1.03 Mbits/sec
[ 3] Sent 893 datagrams
read failed: Connection refused
[ 3] WARNING: did not receive ack of last datagram after 5 tries.

And here I only have about 1.03 Mbits/sec, which seems awful. I have also tried connecting with TCP via iperf, but I always get connection refused when connecting from any side. Have tried with two different ethernet cables of approximately 2m in length with the same result.

Do you have any suggestions on what could be wrong here?


(Patrick José Pereira) #12

Hi Ben,

It’s 192.168.2.2:2770/network, 2770 is our port to access the companion website.

Can you check the Tether interface power supply, Tether interface connections and the system webpage again ?


(Bent) #13

Hi Patrick,

I tried with a clean RPi 3b and connected using ssh, but I am connecting to port 22, so I tried 192.168.2.2:22/network, but with the same result. Does this only procedure only work with the companion with the image you provide? In that case, do you know the settings that may allow for viewing this in the browser? Or do you know any other method to view the data transfer speed? I think it is weird that the USB camera is unable to transfer data when the resolution is above 352x288 at 15 Hz, even when using ssh -X (x11, forwarding) and sending the camera image directly to my main topside display. What do you think about this? And do you think there could be an issue with the camera itself?

Sending any other type of data seems to be going seamlesss and really fast


(Jacob) #14

Does this only procedure only work with the companion with the image you provide?

Yes, you should follow the installation instructions here. We cannot give you any advice on your custom installation.

Reimage the SD card according to those instructions, and things should work smoothly.


(Bent) #15

Thank you, Jacob. I will try that!

Best regards