In full disclosure I work at a company that builds WiFi Access Points, routers etc for enterprises and I just put a hotspot on a drone for fun
It is hard to imagine now, but Ethernet as we know it today (802.3) was not the obvious choice for wired performant connections in 1996, many competing technologies like ATM, Token Ring, RS485, 802.4 etc seemed like more reliable choices, but because Ethernet was fast and cheap (among other reasons) it won out - since then it is hard to imagine a new technology displacing it.
Like Ethernet, WiFi is in the process of subsuming all adjacent technologies (802.15.4, Bluetooth, etc) and for all connections beyond the WAN (which will likely be LTE) it has the ability to be lower power, have better range (within reason) and perform better. This is not because WiFi is necessarily better spec'd - in fact it is unnecessarily complicated - it is because the R&D dollars are focused on it rather than competing technologies. A modern 3x3:3 802.11n chip has massive DSP resource and with .11ac we are seeing double the compute inside the mac/baseband. In addition we are seeing huge improvements in frame detection, phased antenna arrays and RF front ends which has the consequence of increasing link budget (link budget is roughly analogous to signal strength).
Okay, so where am I going with this: as a community we should be looking to use WiFi to consolidate our communication paths with our drones rather than 900MHz telemetry, 2.4GHz remote, 5.8GHz analog. Only fully integrated products like the Parrot AR drone use WiFi and I think that is a mistake. Here are a few reasons why WiFi makes sense:
- We put a digital RX with -95 db sensitivity inches away from a video transmitter transmitting at 23 dBm (in my case, or if you go illegal 36dBm) - this desensitizes our RX significantly reducing link budget. While this is one example, putting a high power transmitter next to a high sensitivity receiver is a bad idea always and we do it 3 times on drones.
- We need to deal with varying ranges and qualities of TX/RX pairs, complicated antenna and ground station setups.
- Analog video is incredibly susceptible to multi-path, limiting quality and antenna types. Don't we all want HD?
- Wouldn't it be convenient to just have one communication path? with maybe a remote as a backup.
Because there are naysayers (correctly so) out there, I thought I would point out common arguments against WiFi:
- WiFi requires a much higher SNR than 802.15.4 - this is true, but the quality of receivers and transmitters along with techniques MRC overcomes much of this and gives you a link that has a much lower duty cycle making it less susceptible to interference and provides superior error checking. A distance of 2-4km is totally practical with WiFi assuming good radios and modest antennas (we do a lot further at my company without too much issue)
- Using WiFi requires IP - yup… but does anybody think this isn't inevitable for us?
- WiFi is unreliable - okay, this needs a 2 part answer - WiFi is actually extremely reliable… it offers very good error checking (CRC) and will do 9 retries before dropping a frame at which point the higher level protocol will also send retries. On the flip side, we are often used to the crappy WiFi found in an Acer laptop (not picking on Acer, just mentioning a random pc vendor) where the radio is placed poorly, the analog front end is poorly designed and the antennas are in odd positions - remove those limitations and buy a $20 card from a reputable manufacturer and you will find superior performance.
- WiFi is really hard to integrate, especially when you need connections beyond serial speeds - I actually dont have an argument here. Most WiFi cards today use a soft MAC which means that most of the radio runs in software - replicating that in Arduino is infeasible. This is why the Arduino Yun uses a linux and a SoC to deliver WiFi. The obvious fix would be to put Autopilot on a linux based platform like OpenWRT, Android or Raspberry Pi
I don't think that it is a question of whether WiFi will become prevalent on drones, it is only a question of when. In the meantime I am working on my WiFi drone, I have 4G and WiFi on mine, Telemetry and Video are the next pieces to get working. I will update as I progress.
Comments
Adam, Thanks for all the advise. Please post a few links to a mini PCI or PCIe 2x2 802.11n module with discrete PAs and LNAs you recommend. I would like to purchase and test a few for my project. Both Atheros and Broadcom have such a large selection of options I thought it would be better to ask you to post 2 or 3 links for me, so I can avoid mistakes.
And if you have a WiFi link "Find My Drone" andMAVPilot will connect with ease.
Hi Brent, There are two key parts to focus on when purchasing a wifi module the MAC/Baseband and the Phy (or RF Front End). For a MAC/Baseband I would recommend a 2x2 802.11n module (you can get 3x3 but it probably wont do you a lot of good outdoors) with either an Atheros or Broadcom chip. Do not buy an a/b/g module they don't have the signal processing desired or true diversity, for the RF Front end you are going to probably be stuck with the crummy integrated Front End Modules (FEMs) rather than discrete PAs and LNAs preferred by folks like me. I think that you will have a hard time sourcing high end modules that will provide a USB interface, but you may want to google it. Generally the modules you would want are only offered in a mPCI interface. Alternatively you could connect to a high end AP and go through ethernet for your ground station, Aerohive's AP 350 would be an example, however it is probably more than you would be willing to spend. However if you stick with 2.4GHz, the discrete front end doesn't buy you much, so the easiest path is to just choose 2.4.
Antennas are tougher - If money is no object, you will likely want a 7dbi dual-polarity patch antenna for short medium range connections and a higher gain dual-polarity for long range - one note is that dual polarity patch antennas can be spendy, so I would start with cheapo dipoles and see what you achieve. you can provide polar diversity by putting them 90 degrees offset from each other however I would try them vertical and parallel first, and try them 90 degrees later.
Adam, would you please give an example, with brand names, of a good setup. An access point and USB dongle radio or to USB dongle radios communicating together in ad-hoc (aka peer-to-peer) system. What would give the best performance in speed and distance. Also please advise the type of antennas needed for your recommendation (circular polarized etc). FYI I am using Beagle-bone(s) and Ubuntu both in the air and in my ground station.
I would be open to looking at it. I am an autonomous flyer mostly so I care less about FPV but with the raspberry pi (yes, I know that this isn't a good solution ultimately) with a camera now we may have a good platform for testing. I have been contemplating an Android platform using IOIO but am not a strong Java coder (I am only an engineer by night these days)
@Adam, sub 120ms sounds impressive. I've done a lot of research on the subject and reliable streams seem only possible >150ms. One of the reasons being the scene variability. It's easy to get a working stream from a static camera, but things change when you start hitting peaks as the scene changes rapidly.
A specific wifi module design for drones would certainly go a long way already, because reliability is determined by the way the link behaves and either adjusts or not. The way the camera outputs data (constant,variable) and adjusts its frame rate to keep within the set budget is also very important.
A quad has limited possibilities for spatial separation, so your only option may be to include specific shielding using metal plates. Unfortunately, I've seen quads and hexas starting a "fly away" when video tx was on in fully autonomous mode.
@Adam, is it your intention to develop this tech further for drones? If so, we should probably hook up. I'm possibly going to be involved in a project requiring higher data rates where analog is no longer an option. The tech needs to be affordable and lightweight, so COFDM / DVB-T are no longer within reach.
Hi Gerard and Thomas,
WiFi itself should only introduce 1-2 ms delay at most. the delay as you pointed out is in the capture - encode - packetization -TX/RX - jitter buffer - decode - display. All of this can be done sub 120ms (I see it all the time at work - I do WiFi all day) and you are very right to point out that with digital video you can capture more rapidly than the 33ms of NTSC signals. I would suspect that the cameras you were using were treating bandwidth as a scarcity and therefore were trading latency for compression - we shouldn't have to do that with drones. This is useful feedback though as I choose my camera platform. As for the "digital cliff" the software should be able to look at SNR and data-rates and be able to prep for that cliff just as clients do for roaming.
Thomas, regarding interference between bands - it is there even if you cannot readily see it. We are transmitting and receiving within the same "Near Field" which means that we cannot conveniently ignore the extra 28db which would make all of this easier (if you read my other blog post, near field is what is screwing up my GPS). What might be a 3dB loss may not be noticeable when you are up close may be impacting your range in subtle ways. Physics says it is impossible to avoid this completely, and it is highly unlikely that this is being pushed below the noise floor. There is also a probabilistic issue at play here but this comment is too short to discuss duty cycle and carrier detection - maybe that will be my next blog post.
Not to get all corny, but, I think on DIY drones we are vanguards of an industry and have an opportunity to make this happen
Hi Adam,
I posted something about my project for HD video over wifi some time ago. I agree when it comes to speedy links for telemetry data, but the issue of video is more complicated. With wifi you're not going to get sub 120ms latencies, although you can win some latency back if you use higher frame rates like the Arecont ones at 42fps. Analog video in comparison is up to 40ms standard and the use of CP antennas has significantly reduced multipathing for example. As a matter of fact, people are now demonstrating that it's possible to work around dead corners or other factors interfering with video and they are able to maintain a crystal clear image during the entire flight without a single cut-out. So I wouldn't throw analog video away yet.
Processing requirements on the ground to decode video is another hurdle. I ran a video link on a pandaboard using the proprietary DSP chip and this introduced a latency of 500ms. Doing more there deemed very complicated, for example virtual tunnels by painting more stuff on the screen as an overaly. Which is why I went with a macmini in the end.
Beyond extra technological complexity, there's also the impact of additional cost, not related to wifi equipment itself, but the extra hardware you need to get. An IP cam for example costs more than double an analog cam at least and always comes out heavier, which makes it less suitable for light, foam platforms. Then there's the issue of getting telemetry+video routed onboard.
I think the onboard solution needs to be simplified a lot more, for example a board with a processing unit + camera that does all the video work which also accepts a connection from an autopilot to mix the telemetry in the outgoing data streams.
The "digital cliff" also needs to be looked at. Analog video has graceful degradation, this gives you a very clear idea about the limits of the system. In WiFi it disappears suddenly, but these modules at least offer insight into the "signal strength", which should then be used to provide visual indications instead.
I'm not against it, I'm actually working on this myself. But it's not realistic to expect everyone will eventually migrate to digital. There are definitely benefits to running analog video in terms of cost, simplicity (thus reliability) and the amount of equipment you need to purchase to get started.
I own this rover from brookstone which runs off a wifi hotspot inside the rover if you're interested in checking it out.
http://www.brookstone.com/rover-20-app-controlled-spy-tank?bkiid=Ma...
I looked into using wifi for telemetry and HD video a while ago (over a year) and found a couple of annoying issues that at the time I did not really have a method of surmounting, the chief one being latency and frameloss.
The latency wad not he wifis fault at all, but rather the lack of speedy compression- and the lack of speedy integration of the sinal back through to the host. I an not sure about the latter, but the prior is easily rectified now by use of a relatively expensive IP camera (HD of course) that encodes to h.264 or something natively.
Frame loss is an annoying problem, but it can be easily resolved with the proper equipment and some effort and time.
I wish you luck, and look forward to more information.
-
2
-
3
-
4
-
5
-
6
of 6 Next