Part Two: Here is the original picture of the finished product:


This is the second part of a 2-part series on 'How to build a High-Definition FPV UAV using a Raspberry PI with HD camera, using a high speed WiFi link.

In my first post on the subject (located here), I discussed the parts I used, and how to install them into a Hobby King Go-Discover FPV model. 

In this post, I will discuss installing the Raspberry PI and the PI camera in the Go-Discover gimbals, and the software configuration for both the Raspberry PI and the ground station PC.

From the previous post, step 3 was completed by installing the Ubiquity Rocket M5 in the model.  Now onto step 4:

Step 4: Install the Raspberry PI and PI Camera

Here is a photo of the position of the PI in the Go-Discover model:


The PI fits nicely just behind the camera gimbals, with the USB and HDMI ports on top. In the right side you can see the Cat5 network cable attached. This cable connects to the ethernet switch, which is also connected to the Rocket M5 input port.  

The two cables shown on top are the servo control wires for the gimbals, which I have directly connected to channel 4 and 5 on my radio.  I am using channel 4 (normally the rudder stick on my radio. Since there is no rudder on a flying wing, this is a convenient channel to use to move left and right with the camera. I have not (yet) moved to a head tracker, but if you already have that setup, just assign the channels accordingly.

To install the PI camera, remove the stock plate from the gimbals (for a GoPro), and mount the PI camera as shown in this photo:


The PI camera case fits very nicely into the slot, and again I used a small piece of velcro to hold it down. You could use a couple of small screws instead if you want a more secure hold.  The two gimbals servos are also shown here. They are simple to install, just follow the Go-Discover instructions.

Here is a front view of the PI camera installed:


Here is the block diagram describing all the connections:


Some comments on my previous post suggested that it is possible to eliminate the ethernet switch and serial-to-ethernet converter using the Raspberry PI and a serial port on the PI. I believe this post describes how to talk to the PI via the NavLink, but in this case, I want to use the PI to bridge the connection from the ground station to the APM/PixHawk. Somebody please comment on this if you know more about it.   I believe it would require a TCP/IP to serial link from the PI to the telemetry port on the APM, and some software on the PI to act as the bridge.  The main connection to the ground station is via the Rocket M5 and TCP/IP, not through a telemetry link (900 Mhz or Zigbee like I used on my other models).

Step 5: Getting it all to work with software configuration (the really fun part starts now).

Check out this post on what others have done with streaming and the PI.  My experiments showed that using GStreamer on both the PI and on Windows gives really good results with very low latency, if you use the right parameters. 

Get GStreamer on the PI by following this blog.   This is the same version of GStreamer that I am using on my setup. 

Make sure your PI camera works ok by plugging in the PI to a standard monitor using the HDMI port and follow the instructions on the Raspberry PI website on how to get the camera up and running (without GStreamer).  Once you have a working PI and camera, you can then proceed to stream things over the network.  

Note: It is suggested that you first get the PI streaming video by plugging it directly into your local network where you can also connect your ground station PC with the correct IP addresses (without the Rocket M5).   For my PI, I picked,  and for the ground station,    Make sure you can ping the PI from your PC and the PC from the PI.  

For streaming, you will also have to make sure all the ports you intent to use are open on the firewall (described later).

For the ground station PC,  you can download GStreamer here.  Make sure when you install, select to install everything , or full installation (not the default). 

Here is the command I use for the PI to pipe the camera output to GStreamer:

raspivid -t 0 -w 1280 -h 720 -fps 30 -b 1700000 -o - | gst-launch1.0 -v fdsrc ! h264parse config-interval=1 ! rtph264pay ! udpsink host = port= 9000

The command is explained as follows:

raspivid is the command to start the camera capture on the PI.  The -w switch is for the width in pixels, and the -h switch is for the height.  In this case, I am using 1280 X 720, but you can try any combination that fits your needs. 

The -b switch is the bit rate for the sampling. In this case I chose 1.7mbs to send over the stream. Again you can experiment with higher or lower values. This settings seems to work good for me, and the latency is almost unnoticeable.  

the "-o - |" is piping the output to gstreamer.  Make sure you include the dash before the pipe "|" symbol. 

For the GStreamer command, all the filters are separated with an exclamation point "!", as these are individual drivers that are part of GStreamer.  Since the PI has hardware accelerated video, the output is in a format called "H264", which is a highly-compressed stream. The GStreamer filters are configured to transport the output via a UDP socket connection to the target PC. Notice the 'udpsink' element which specifies the host - in this case your ground station, and the UDP port.  I am using port 9000, but you can use any open port on your system, but be sure to open the firewall or it won't work!  You can also use TCP instead of UDP, but for such a data stream, I chose to use UDP since dropouts are certainly possible, and with UDP this is ok, but with TCP, you could have socket problems and higher latency. 

Note: to get the PI to execute this command on boot, make a shell script with the above command and add it to your local.rc boot sequence. That way when the PI boots, you get the stream without having to log into the PI remotely. 

For the ground station PC, once you have installed GStreamer and opened the correct ports, use this command (from the command prompt) to view the stream:

c:\gstreamer\1.0\x86_64\bin\gst-launch-1.0 udpsrc port=9000 ! application/x-rtp,encoding-name=H264,payload=96 ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink

If all goes well, you should see the PI camera output on your PC screen in a popup window.  For those of you what want to use FPV goggles, you can connect to the HDMI port on your PC to display the output if your goggles support HDMI. 

I have this command in a batch file (with a PAUSE) statement at the end to keep the window open.

WHEW!  If you got this far, you are amazing. 

The last step to complete the build is to connect to the APM from mission planner.  The method I used to connect was to install a utility that converts a TCP connection to a virtual serial port, but I also think that directly connecting the mission planner to the TCP port will also work, however I have not tried it. I will post back later after trying it.

Here is the link to setup the serial to ethernet device to have an IP address and port.

Here is the link to the configuration utility for installing the virtual serial port.   

Once you have a serial connection over TCP/IP working to the APM, you should be able to connect with Mission Planner. On the maiden flight, it worked perfectly, and I didn't see a single drop in the telemetry data or anything noticeable in the video transmission, however my first flight was limited to 2km.

The last step is to connect the Rocket M5 to the Nano M5 and test everything using the OTA (over the air) connection. If all is well, you are ready to fly!  But be careful on your maiden, you just spent $700. 

Finally, here is a photo of my Antenna Tracker with the Nano M5 attached. My next update will include a video of a longer flight.  


Happy Flying!

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • @Cap,  I have not tried the BBB but others have had success using your suggested setup. I have tried the C920 with the PI and the PCDuino, and the measured latency is worse than the PI with the standard PI camera, but it is still a good solution. The camera is better than the PI cam so if you are looking for better video, this is certainly an option.

      You are correct about the H264 encoding on the camera, it does not matter if you use a BBB or a PI in this case as the performance is directly related to the H264 encoding and not the CPU.  The GPU on the PI is doing what the C920 does internally.  

    I am actually using the A+ model PI with my new setups on multi-rotors and the latency is the same as the B+ or PI2, and it's smaller and fits nicely in a quad.

    For the Android solution, you can download the GStreamer HUD version from this link:

    It's also on the Google Play store, but the link is a free version, but you have to side-load the APK.

    Eventually, I will get back to working on the terrain data and additional enhancements to the HUD. 

    Shared with Dropbox
  • Also, separate telemetry question...

    Does anyone have any true performance metrics on using mavproxy VS ser2net VS ???.

    I see many people use ser2net, so I assume it's a proven (flyable) method. Has anyone actually flown an aircraft using mavproxy to relay telemetry between UAS and GCS over a UDP link? What is the latency and/or how can latency of this type of link be determined?

    We've only tested with mavproxy using a vehicle *not in flight*, but we could not detect any human-noticeable latency. Our test involved an aircraft connected via UDP to Mission Planner on a PC. The signal path as follows;

    [APM/PixHawk] <---- serial/uart ----> [(onboard) BeagleBoneBlack running mavproxy] <----- UDP over WAN -----> [PC running mavproxy and MP]

  • I literally just read the past 55 pages of comments to make sure I was "up to speed" before entering the convo...

    First off, thanks to everyone that's done such a good job documenting gstreamer here and on the various linked blogs (Derek Malloy!). A friend and I have had great success with gstreamer and C920's and are confident in using this solution for our project.

    That said, I have to ask... Is anyone using BeagleBone Black for this besides us? I understand RPi has an advantage of hardware-assisted h264 encoding, but my understanding is that if the camera encodes its own h264 stream (C920) then it's a moot point?

    If that's true, is there any other advantage to the Pi over the BeagleBone Black?

    I will admit that one disadvantage I've discovered with BBB is that most of these "ready to go" solutions are quicker to implement on RPi due to wider support, more up-to-date package repo's and better documentation. However, I haven't hit any hard stops yet that I couldn't accomplish with BBB.... Still curious what the community's thoughts are on BBB vs RPi for a combination of streaming video as well as relaying telemetry using mavproxy OR ser2net.

    @Patrick  Really appreciate the work you're putting into this in your spare time, I personally look forward to your Android solution in hopes I can receive these gstreamer feeds on Android. The currently available apps for this are heavily tailored towards very niche applications and not nearly as customizable as a true gstreamer instance is.

    @Jerry @Patrick I'm really enjoying this conversation about augmented reality with terrain data, etc... Please keep that going :)

  • @Patrick Thanks for the reply.I am targeting a quadcopter at this stage as well. Hopefully I can get around to testing a setup soon. Look forward to the antenna blog.

  • @Glenn Gregory,  I am experimenting with various antenna combinations, and eventually I will get around to actually publishing some data.  Choosing the antenna combo depends on what vehicle you are targeting. For the GoDiscover platform I am using two Ubiquity Rocket M5 units with a pair of 'skew planar wheel' antennas (Circular Wirless), one LHCP and one RHCP.   On the GCS, I have two 16dbi helical antennas, purchased from IBCrazy. I modified one of them to be LHCP by rewinding it, with a bit of soldering.  So far, this setup has given me the best performance for MIMO.  I have also tried using the Nano M5 on the ground, which has two patch antennas integrated, one horizontally polarized and one vertical.  The disadvantage to this setup is the 3db loss if you use patch antennas on the UAV.  If you use linear polarized antennas, you need to mount one horizontal and one vertical on your UAV.  

    I recently built a quadcopter and used a high-power USB wifi adapter instead of the MIMO rocket M5 setup, and I have tested it to about 1 mile with success using ordinary dipole antennas, and the Rocket M5 on the ground.  The WiFi adapter is much smaller than the Rocket M5 and works good for the quad. I have seen a build where someone mounted a Rocket M on a multi-rotor, but I have not tried this setup, as I rarely fly the copter beyond a mile anyway, so it just depends on what you are trying to accomplish with the range when you pick your antenna types.

  • I can't believe I have only just found this blog. Looks like I have alot of backreading to do!

    Has there been a followup blog / summary that summarizes the results of the best MIMO unit / antenna types to use?

    Thanks for such detailed excellent blogs!

  • @Jerry,   I have not have time to work on the Android App recently. Almost all of my time has been consumed on a project for Apple, and they actually pay real money so I can have this hobby. I'll probably get back on it in the next couple of weeks.

    Your quad looks good. I would be interested to see the schematic and a parts list of the sensors you are using, (compass/mag/accel/barometer) etc.  Are you using the ArduPilot firmware recompiled or ??  I am using the A+ model PI on my quad, with an APM, but it sure would be nice to have everything on one board.  The PI2 has a quad-core processor so it should have the horsepower to do the flight controller and video link. This is a great project.

  • Hi @Patrick, any progress in Android HUD app? i have almost done with my Raspilot.3701987129?profile=original

  • Just found this:

    I'll buy one in May and connect it to GoPro. Let's see how well it will perform.

  • I was thinking about the GoPro bus that 3DR was talking about with the release of Solo, however there is no info available at the moment and I doubt it will never become public. The HDMI output comes out from Gopro has some noticable latency, so I think the latency after HDMI capture from Gstreamer then piping to GCS would probably be high. I've been searching a low cost solution but still can't find any good one yet. 

    I nearly pulled trigger on this: It's a bit too expensive, about 450 euro if I order from Germany distributor.

This reply was deleted.