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:

  1. FC: Flight Control - This sub-system includes the RTOS based autopilot, telemetry radio*, RC receiver* and peripherals

  2. CC : Companion Computer - This sub-system includes higher level Linux based CPU and peripherals

  3. 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

  4. 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

 

Views: 7662

Replies to This Discussion

Hi Ben

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.

Hi John

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+

Hello Ben
Regarding Wifi I would like to clarify my position on that
- I am using L-com USB radio, you are probably aware of this because we are the only one that have documented this subcategory within CC
-this radio is using ralink chip that is fully compliant with ALL operating modes of the Linux Wireless
-so the image we are trying to build will be probably bases on the generic nl80211 driver so we dont have to mess top much with the kernel
-standard and legal ragio power is 20 dbm (100 mW) and presonnaly I would add antenna gain before getting into higher power radio because RF amp adds NOISE into the link budget
- yes I know Patrick Duffy's experiment and I do have great respect for his forum. If I ever need to go long range I would certainly ask for his help and advice

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.

Lol dont shoot im just the messenger but YES it is 31dbI max radiated. And looking at the spec of DJI sytem,a while ago and they were "street legal"... That is the only way to get FCC sticker on the thing

But if you really want to drag racing, be my guest and put a 20watt amp on a 3 meter dish .... :-)

Hello  developers,

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:
-nl80211 driver

-mikrotik R11e-2HnD

Would be a safe bet to enable Diy builders to get moving in the directions they need to. All the best.

Bonjour Pierre,

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 ?

Best Regards

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.

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service