yes, it might, time will tell, but 11 A is pretty low already…
There is WiFi from RPi to onboard 4G modem. The introduces latency is not noticable. More than 95% or so of the latency is the 4G connection. You certainly can connect a USB modem directly, but it is not always straight forward and you need to pay special attention to reconnect etc. With the router all this is really easy, all you need is the make RPi work with WiFi. Another benefit is that you also have the option of flying with WiFi at close range which is free and faster.
1 Like
Thanks for the clarification around that…and the diagram. 
It certainly would be easier development wise to start out with the WiFi based solution. Going forward though things should get very interesting with LTE-A and future technologies were the latency becomes <10ms…hopefully it becomes easier to implement wireless 4G…or 5G sticks into the Linux OS. I have to say being fairly new with Linux I find it unnecessarily complicated to do simple things. You would think in 2015 one could plug-in a 4G stick into the RPI and it would just work.
-Derek
There are two aspects of this design I think should be separated: 1) The networking protocol and messaging, requirements = it just works, no matter how, auto reconnect and retry, priority and QoS. 2) Your application domain, the stuff you would write on top of a finished reliable connection. You shouldn’t have to code anything from the first part, except perhaps a DDNS helper service action to avoid additional components in #1
Actually part 1 could even be split into 2 again…
1A) “Internetworking” - I’m thinking of trying something similar with long range Wifi and drone-to-drone mesh networking. Maybe you want to try the BATMAN or similar mesh protocol. The pain point is that IBSS/Ad-Hoc mode wifi is a pain to configure on Linux (if at all possible) because the whole driver model (or lack of one) is backwards by design (deliberately no binary contract/compatibility) so you’ll waste time with half-implemented drivers (no ad-hoc support) and no official master source for any of the newest/faster devices.
1B) “Messaging” - rather than writing your own man-in-the-middle there are reliable delivery systems already available for re-use. You need priorities, timeouts, resend, permissions and all that stuff to make it robust and not lose control when the video wants to consume all the bandwidth/processor. Maybe some inspiration for you here. Anyway what you are doing already is a great example.
Personally, rather than Microsoft Azure I prefer to run .NET hosted web service/applications on GoDaddy for cheapo average-mediocre speed or my own rented server (e.g. Server4U) for super fast response times. One tip for Azure I learnt the hard way… keep your eye on the database transactions else you’ll find a nasty bill in the post! Or did they make it truly flat rate already?
Maybe MSMQ or whatever the vNext replacement is will be better to build on top of. Maybe most of this is already included in an IPv6Mobile capable mesh protocol. Just ideas needing some investigation. I’m experienced with WCF and MSMQ years ago but guess there have been a lot of improvements since.
What you’re doing already is a great example. I’m looking for a magic combination of technologies and services I can repeat and rely upon and it’s along these lines. At some point we’ll have a kind of P2P drone network “defacto standard” for sure.
Very interesting input! My solution is just a very quick and dirty implementation to get something up and running with minimal effort. I have experience with programming in .Net, but this is my first try at Linux, so that plays a big part in the way it is implemented too. It enables me to:
start Arducopter and auto connect to internet and my PC,
provide in-flight info about 4G connection quality
provide in-flight changes to video streaming quality
a way of reconnecting to the quad in case of IP change, (due a PC restart for instance) (not in-flight yet)
I’m using Azure because I’m so used to it, and it is so easy to set up (and free!). I’m not using a DB. I wrote a very simple file based key/value store. It is really just a quick mock up.
I totally agree with you on abstracting and separating messaging and network protocol etc. I guess someone will need to look more into this if more people want to use internet and modem connections. They way it works at the moment not ideal. For one I think there should be a way of reconnecting to a running Arducopter with a new IP. I guess someone should rethink the whole architecture for dealing with: changing IPs, standard solutions for video streaming, easy to setup connection through routers and firewalls of mobile providers, better and easy to setup failsafe options etc.
I think if someone (Emlid?..) put together a RPi image with everything setup, including videostreaming, failsafe options, autoconnect through internet etc.and a recommendation on compatible hardware (camera modem etc) it would be very popular! 
3 Likes
@ogulbrandsen @Bernt_Christian_Egel hi, i have some questions on how to setup a 3G/4g connection on rpi2. i follow your sakis3g/UQMI guide Ole with no success. my first dongle is a Huawei E3276 4G LTE. do you think the E8278 will be much easier to setup???
secondly, my ISP only provide private IP address (with a NAT to public address) on 3G/4G network, and i think it s the same with all ISP in france, how can i perform the connection to the GCS ? thanks
Correct me if I am wrong… With ipv6 there is no more need to change IP addresses for any reason. There are 340 trillion trillion trillion available addresses so…maybe the issue of IP address changing will no longer be an issue in future.
Florent, I would recommend just using WiFi dongle and setup WiFi hotspot with separate self contained modem…in my case just putting a light weight nexus 5 inside my drone…you could use cheaper device though…mine has broken screen so don’t care.
The Huawei E8278, is a little different than other modems, in that it is also a WiFi router/hotspot. This means you can connect to it by WiFi, and not directly through the USB. Setting up WiFi on a RPi is very easy. Setting up a direct connection to the modem through the USB requires Sakis etc and is more tricky and time consuming. On my quad the E8278 is not connected to the RPi USB port, I just soldered a power wire directly from the 5v BEC. The E8278 is also handy as you on close range can connect to your quad directly from your laptop with wifi. Useful for testing and PID tuning.
Using a onboard WiFi router also makes it easy to have more than one RPi connected. Until they have solved the performance issues with streaming the Logitech camera while Arducopter is running on one RPi, I will be using one RPi for each task.
(BTW: The guide is by Bernt who has much more experience than me on modems etc.)
(I found the modem by searching EBay for “E8278s-602”, it costs around 60 USD with shipping.)
Curious, how much approximately did this awesome project lighten your pocket? I’m very interested in starting a very similar project inspired by yours, but I’m limited to approximately 1000$ tops.
CF Frame parts: around 80 USD
Modem 60 USD
RPi2 35 USD
NAVIO+ 214
4 Tiger Motors around 240 USD ( There are cheaper alternatives )
4 Tiger Props around 200 USD ( There are cheaper alternatives)
4 ESC 30 USD
4 LEDs 10
2 UBEC 20
Batteries 120 USD,. 14.8v 17000mah
Taranis Radio 200 USD
EzUHF Rx 60 USD (Optional)
EzUHF Tx 100 USD (Optional)
Joystick
Web Camera
PC
Battery Charger
Silicone Wires
Heatshrink cables
Soldering iron
Dremel
Ok, I’ve changed the ESC and redone some of the wiring. The motor glitching has gone now, and I had a 50 minutes test flight. The battery is holding up very well! The maximum hovertime is probably over an hour.
I’m having some problems with the PPM input to the NAVIO, looking at the logs in APM there seems to be a lot of noise and spikes in the RCIN channels, I noticed it in flight too. Not sure what is causing it, but it has to be fixed. Could be my wiring that is causing noise to the PPM signal. I tried twisting the wires and putting the RX closer to NAVIO, but I could not see an improvement.
I’ve ordered a pocket oscilloscope to have a closer look at the signals. Anyone else with similar problems?
A neat trick I use for “crimp” connections (servo, power, etc…) is to tin the wire, drop a bit of flux into the crimp connector before crimping, then tap the soldering iron on to tack it. Now crimping is a lot easier because the pin stays in place. Once crimped, give it a longer touch with the soldering iron until the remaining flux fizzes away (also creates a complete solder connection with the upper crimped part then. Use a bit more solder than usual when tinning, but don’t make a big blob and don’t try to add solder after crimping, else you will have trouble inserting the pin into the connector.
My first quadcopter build had random drop-outs and long GPS fix times. After re-making the connections like this, the problems went away and the connections are very strong. I find it especially useful for those smaller delicate DF13 connectors we have on Navio+ and Pixhawk.
The other thing I always do is twist the wires. For standard 3-wire solid servo wires, pull them apart too before twisting for a more flexible result.
p.s. Those are amazing flight times!
Regarding the PPM noise:
What APM version do you use?
Is it the same when a video transmission is off?
thanks for tips! but I’ve soldered all connections, even the connections to NAVIO. I do not think the “noise” is coming from the bad connections. I suspect it is coming from the ESCs or other electronic components. It could also be something with the PPM coming from the EzUHF RX that somehow is not decoded correctly by NAVIO…
I’m using Arducopter v3.3 dev (9e506e97). Currently only Arducopter is running. Camera is connected, but it is not capturing or streaming video.
I suppose one way to diagnose external interference would be to look at the log/graph when moving the RC controls around with and without the components connected (ESC wires, video, additional radios).
It causes small “jumps” about every 5 sec. It comes and goes. I’ll publish some log files