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

3689618661?profile=original

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:

3689618887?profile=original

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:

3689618926?profile=original

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:

3689618962?profile=original

Here is the block diagram describing all the connections:

3689618829?profile=original

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 192.168.1.2,  and for the ground station, 192.168.1.1.    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 = 192.168.1.1 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.  

3689618942?profile=original

Happy Flying!

E-mail me when people leave their comments –

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

Join diydrones

Comments

  • Hi, Patrick, Gavin.

    I just had some reading on oreilly's 3 wifi books (definitive guide, n, ac survial guide), and did some google search to understand the airMax(TM) from ubnt. here's my draft feelings about the technology and how to choose a ubnt hardware:

    * they are based HW  driver of L2/L3 to implement, ubnt  ac series may have a dedicated ASIC for timing sync for better TDMA resolution and spectrum sensing, this asic is ubnt IP or atheros i could not find out. (marketing papers 

    * FreeBSD 8.0 kernel had a atheros 5xxx version TDMA, simply putting a timing interval based on beacon signals

    * BPSK vs OFDM is based on MCS(modulation and coding set), i don't know if bandwidth(5-40~80ac) could manually select this, but looks very likely to be so.

    right now i wish i have advanced linux wireless driver dev skills to play with TDMA with some 9x atheros dongles ...

    but a glider equipped ppz on board with a nanobeam ac may function like a satellite, having much more fun...

    I think i want to go buy a nanobeam ac first, it's price is lower than a M5 ac, and disassemble it to see if a pair of ipx connectors are there so i can plug some UHF 5.8 FPV mushroom antennas there, one TX, one RX (as L/R pairs, if my guess is right), then i put up a ground station with regular ac dongle with 2X2:2 MIMO, i have a RTL8812AU. if i could google how to make a pair of helix yagi type pointing at my drone. 

    if nanobeam could not apply external antennas, i'll buy a m5 ac.

    about latency testing results from Patrick, how is your benchmark setup, did the experiment had different MCS configurations, or field test experience of ubnt latency doesn't appear to be noticeable  when RX signal is low.

    i guess i would try a ac for the TDMA resulotion, and MIMO for that extra 10db+ cross-polarization rejection.

    thanks for you guys.

  • @Gavin,  the improvement in latency would be negligible.  When I ran tests comparing latency, a wired ethernet connection had the same latency as the Rocket wireless connection, or even standard WiFi. Most of the latency comes from the source sampling and compressing the stream to H264, and on the GCS, de-compressing and processing the video. The network latency is a small percentage of the total, so squeezing a few milliseconds out in the network won't gain you much.  

  • Wouldn't it help latency?

  • @Gavin,  Rocket AC looks good, but might be overkill for a single client.  I don't think my UAV goes over about 10mbs, even when transmitting full HD using and H264 data stream for the camera.

  • @Jerry, if you use the rocket with 'AirMax' (Ubiquity MIMO) enabled, and you have an antenna setup that can take advantage of MIMO, you can get both improved throughput and better noise immunity. Using 40mhz bandwidth is better for throughput on MIMO, but the noise figure is not as good, so range could be limited for a wider bandwidth.  There is a trade-off between range and bandwidth because of the noise in the wider band. If you want more range, and don't need the throughput, use a smaller bandwidth. The issue with MIMO on a UAV is not beam-forming, but antenna diversity.  You can't really beam form unless you have a high gain antenna like a dish or a directional helical, which would require the UAV to 'point' the antenna at the GCS which is not really practical.  For MIMO to work, you have to have uncorrelated signals, and this is normally done using horizontally and vertically polarized antennas. This is great for a fixed ground station where you can mount a dish with two dipoles, but not for a UAV, that's constantly moving around. The 'solution' is to use circularly polarized antennas, one LHCP and one RHCP.  The cross-polarization rejection of the two is >10db, so you get a reasonable uncorrelated signal.  For my setup, I have two Rocket M5s, with the LHCP/RHCP helical antennas mounted on the unit.   For the UAV, I purchased two 'skew planer wheel' antennas from Circular Wireless, one LHCP and one RHCP,  but I recently looked on their website, and couldn't find the LHCP version.  Not that many people are trying MIMO with these antennas, so maybe the demand isn't there. 

    As for the bullet, this is certainly an option, especially for a quad copter, or smaller UAV.  If you use the bullet and configure it to be compatible with standard WiFi, you can connect to an M5 on the ground and use the M5 as a wireless router. This is what I am doing with my quad, and it works great for shorter-range applications.  It all just depends on what you are trying to accomplish with your setup.  Range vs. Throughput, vs. connection stability.  

  • Aalso the rocket m5 boats almost 2x processing horsepower over nanostation/loco with the AC being 5x more than rocket m5.

  • I would use:

     

    Ubiquiti R5AC-Lite US Version, Rocket M5 AC Lite up to 450+ Mbps. It has a 10/100/1000 ethernet port so no bottlenecking. 

    DATASHEET:

    http://www.flyteccomputers.com/ext/Ubiquiti/Rocket5ac_DS.pdf

    BUY:

    http://www.flyteccomputers.com/details.cfm?wid=5507&wb=R5AC-LIT...

    Did I mention works with all existing Ubiquiti 5 Ghz antennas (even rocketdish) that connect to rocket m5? Easy upgrade for existing systems. 

  • Hi Patrick, i want to buy a pair of ubnt devices to test the setup, right now i couldn't decide what models fits best.

    My questioin is, what's the benefit of using Rocket M instead a Bullet, if Rocket support MIMO, the antenna array on airframe may have better chance to deliver uninterrupted streaming by beam forming? And a wider bandwith (like 40M) could use Space-Time Block Coding (STBC) for better result?

    I want to use a NanoBeam for GC, and a Bullet on air , i believe this is a SISO setup. i couldn't decide to go SISO or MIMO, could you offer some advice?

  • FYI,  I have been testing the Raspberry PI 2, with gstreamer, and the results are in.  There is a 'slight' improvement in latency, but it's maybe 15 ms on the same system running a PI 1. It's not enough to make any real difference, but since the price of the PI2 is the same, get it if you are going to invest in one.  The test I did were performed with Raspbian, and not the latest and greatest ARMv7 optimized OS, which is still not released. There is a 'snappy' Ubuntu version, but it lacks all the video drivers and gstreamer build so testing it will have to wait a bit. 

  • Thx! Hoppfully that Will fix the problem. Will try and move the gps a little bit more.
This reply was deleted.