Here is Revision 2 of the Companion Computer System Architecture. Thank to JB for this one !!
This is the latest revision of the Companion Computer Architecture.
After some more discussion regarding the overall structure, we thought it would be a good idea to incorporate the various parts of the the complete system typically used in flying a UAV.
Please note that some of the items are optional or redundant and can be left out as indicated by a *. Ideally the RF link comprises of only one link, most likely over wifi, however for redundancy and compliance purposes other connections are shown.
This is composed of 4 main building blocks:
FC: Flight Control - This sub-system includes the RTOS based autopilot, telemetry radio*, RC receiver* and peripherals
CC : Companion Computer - This sub-system includes higher level Linux based CPU and peripherals
GCS: Ground Control Station - This sub system is the user interface for UAV control - This typically includes PC/Linux/iOS and Android based platforms that can communicate via telemetry radio, wifi or LTE/3G/4G
MLG: Multi Link Gateway - This is an optional system for use on the ground to provide connectivity with the CC and FC. It can also be used as a local AP, media store and antenna tracker etc.
The FC is connected as follows:
via RC receiver* to the remote control
via Telemetry* radio to the GCS
via UART or Ethernet to the CC
via FC IO to peripherals like ESC, servos etc.
The CC is connected as follows:
via WLAN to the GCS and/or MLG
via LTE/3G/4G* modem to the GCS and/or MLG
via UART or Ethernet to the FC
via CC IO to HD peripherals, like USB or CSI camera etc
The GCS is connected as follows:
via telemetry* radio from the FC
via MLG WLAN or MLG AP or direct from the CC AP
via MLG or direct LTE/3G/4G* through the internet or PtP
control of tracking unit on the MLG*
various peripherals like joystick, VR goggles etc
Thx for the info. So essentially it's just another wifi module with some extra features? The output can also be achieved over USB and the functionality you describe can also be achieved over USB and is not only possible with the microtek gear.
In regards to the PCIE stuff on a Pi I haven't found anything saying that it has been done. From what I know the Pi GPIO don't even run at PCIE bus speeds, so it's unlikely to help develping these low cost options with that kind of low cost hardware. The TX1 might be a candidate, but that already has wifi/BT built in, which will likely need a range upgrade.
Our experience so far has been the opposite with using Android. But I think it depends on the application and what sort of hardware is used, so it's difficult to generalize as far as being able to say it doesn't work at all. There are both benefits and drawbacks to any system, Android included.
In particular I find that Android has promise as a very low cost, easy to use CC for UAV's. It's possible to pick up $60 quad core 1GBram dual sim LTE mobiles with OTG and Full HD 8MP camera, that's a fair bit of hardware for a low cost...and it's only going to get cheaper and more powerful.
how much range do you think a standard (100mw) USB wifi adapter will achieve? 60m? 150m? It's not such a good idea with such short range & potential foliage blocking.
Try 800mw-1000mw and you will achieve 1km+
Try including high power groundstation and you will achieve 5km+
Wifi has legal requirements? I never knew, I just thought it was everywhere these days. How does Phantom 3 & Solo achieve range only using 100mw? Why is the Phantom 3 drone mounted unit fan assisted with only 100mw? Why is the 3dr solo module using high power pcie? There's an interesting video link for the solo wifi upgrade here, if you're interested in this idea.
Back from my week end getaway, there is a lot of very interesting discussion going on . First of all, Thanks to JB for keeping the forum alive and well, very appreciated. Here some news:
- We have a release 2 of the architecture, this is JB's creation, and it look real good !!
- Comments and questions enhancement are welcome.
- About the Android-Smartphone as a Companion Computer debate, my personal position on this is simple: I really think that it is a futile debate that reminds me of the butter -vs- margarine endless story. It would be much more constructive, if someone really interested in this solution, would begin a dedicated forum within the CC Group so that all those in favor can start working and create a nice developer community so that everybody can join and reap the benefit of this collaboration.
- About the wireless link: I want to make my position clear on this. I have a pretty good success by implementing Hostapd and wpa_supplicant as an AP or SM using standard nl80211 driver and I will publish both configurations: AP and SM. This forum is not about wireless, JB already add a sub forum on wireless (ad_hoc for the moment) , we can discuss about different technologies there, but as I wrote a couple of time, Patrick Duffy is doing a great job on this and if we need advice, we just have to visit him and generally we have an answer within the hours.
-About new proposals, any proposal for a new architecture that keep the spirit of the following are welcome:
''Companion Computer based on Single Board Computer that is mostly running on ARM cores and ingrate -or not- a GPU that is dedicated to run advanced tasks like mission control - autonomous fly based on vision, Lidar, Sonar, or any other environment interface and running on any standard Linux Operating System''
Well, I think it's fair to think that we should perhaps include driver support/functionality for a few wifi modules namely:
Would be a safe bet to enable Diy builders to get moving in the directions they need to. All the best.
Vraiment content d'avoir de tes nouvelles :-)
Happy to know that you are alive in kicking following the ErlBrain experience !!
So what I can conclude is that you recommend using router like the small ubiquity (lPatrick Duffy works with these) instead of dongle. I wish you could try my HOSTAPD recipe it works fine , look here.
Can you comment on how to set all mavlink streams at high rate ?
What version of ROS are you using, I guess it is INDIGO ?
Can you elaborate on this : Using ROS feature, I got liveview on screen easily (no gstreamer stuff etc ...)
The ground based RPI , we call it the Multi Link Gateway, MLG,
I like the Mjpg-streamer as well it is light, but I encountered compatibility problem on Kernel 4.x ,(seem that non UVC camera are no longer working) have you experienced this problem , if yes have you made it work with these releases ?
Gstreamer yes we need to TEE it, if anyone can provide the pipeline for h264 to the udp sink and TEE to openCV, that would be appreciated...
Swarm, there is Dhiraj (page 7) that has this operating mode implemented in their stack, you could PM him to elaborate on this
Question: I talked with in PM with JB, ROS is not real time at the present release (Release 2 is still Alpha), do you have any concern on running a CC without any RTOS capabilities (UDP messaging, NO PREEMPT Kernel) ?
Hope your Swarm Thesis is going fine and hope to hear from you soon ... Salutations
With the proposed system being heavily depended on Ethernet packets (a good thing in my book), I would suggest taking a look at the IP camera standard ONVIF. https://en.wikipedia.org/wiki/ONVIF
It's built on industry standard RTP/RTSP streaming with new standards for config, detection, PTZ control etc. on top.
And while you get overhead compared to a RAW CSI/MIPI camera, you also get standardization with thousands of cameras supported ranging from high end with great zoom and auto-focus optics, to direct-from-china-cheap. For example: http://www.aliexpress.com/item/HD-IP-Camera-Module-720P-1-0-Megapix...
With dedicated decoder hardware in most ARM systems the CC processing overhead is surprisingly small. Using CSI/MIPI raw also comes with additional hidden overhead to get a color format suitable for computer vision etc.. Complete glass-to-glass latency is typically in the 100-150ms range. Less in a CC system that does not have to wait for monitor refresh.
Another benefit is that with an ETH based camera, you can now easily have multiple cameras. And you can select where the stream goes. Directly to the CC, or to the GCS, or both.
Thanks John Arne,
This is a very interesting option that you are suggesting here, this camera seems to integrate everything and YES interfacing on Ethernet is good. Its now on my wish list :-)
Meanwhile, I know that you are a gstreamer guru :-)....Can we write a pipeline recipe so that we can source the C920 and sink using a TEE to both the TCP and OpenCV ?
Sure. Once you have the h246 video from the C920 inside gstreamer, you tee it. One for network streaming (rtpmux, udpsink etc.), while the other you decode, colorconvert and appsink. From the appsink you then get a pointer to a uncompressed video buffer you can copy and process in openCV.