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
Thanks for contributing to the thread. Currently we are trying to establish a software "backbone" where we can accommodate any CC from a PiZero to a TX1, which btw we're developing on another thread.
This is a work in progress, and it would be good to have as many developers as we can to support this, so you are of course welcome to join.
Thank you very much for your post. I've been following some of your awesome work over at Navstik and I would really welcome you participating here to assist. I've also been talking to Nitin behind the scenes and I think there's potential in making great things happen with the CC platform.
I like your software categorization as well and I think we should adopt the structure. Maybe we can start our own thread titled "CC Software Categorization" based on your diagram, and everyone can start adding to the list, from which we can then decide which ones to adopt first? We have the laundry list but it needs some more structure, and a dev plan. Let me know what you think.
I don't know if you or anyone else has seen the hummingboard range of board computers? It has the mini pcie ports we require:
It does not have hdmi-in though.
I wonder if anyone has or has developed an adapter to allow digital-to-digital? HDMI-to-CSI adapter?
It seems that the 'pi foundation' (whatever that is) won't release hdmi-in or an adapter (possibly through broadcom pressure I can only speculate).
but anyway, the hummingboard computers have mini pcie which allows the use of mikrotik wifi high-power, it also has a csi port.
how hard is it to make a hdmi-csi convertor anyhow?
hello, thanks for explaining your plans. I have experience with pi2 & TK1, and have some decent peripheral compatibility knowledge if that helps?
As far as experience goes, I find the pi fiddly to get things running such as opencv & gstreamer. The TK1 is much more compatible. I think a pi zero shield is a good idea.
Perhaps the pi-zero shield could have a mini pcie slot but with its own power distribution? I'm fairly sure that mini pcie is 3.3v, but using a mikrotik board at 800mw might be too much for a pi to deliver by itself. It would require a test.
With regards to mini pcie, I wonder if it is possible to interface with pi gpio? I don't know if/how this would affect data bus/speeds.
Pi-Linux drivers for mikrotik wifi would certainly be achievable
Thank you JB,
Yes. The laundry list thread has been a great compilation and now needs structure, dev plan.
The categorization will help us manage the list of software components, also I think for development plan we need something more, like software architecture.
The idea of new thread is great, but I would suggest doing it in slightly different way. If we can get the current software laundry list thread to organize the components in above categories, then we can use this list as the starting point for a special thread on "CC software Architecture".
I can propose some initial structure which we can discuss. Once we get the list and place all components in the architecture then everything will be clear. We can easily get to the dev plan then.
At the same time we are working hard on releasing the FlytOS for PX4. So practically anybody can put an odroid with a flytOS image on his drone. It would be awesome to see some demos working out of the box. I am thinking about putting balloon finder or some other object tracking based demo. Also
It will be interesting to work on this. Lets discuss it over and decide when to launch the new thread.
That would help for sure!
We have created a "laundry list" of software items we want to include on the CC image. I'm currently going through them and putting them into a spreadsheet so we can keep track of priority, progress and issues which I'm hoping to put up in the next few days. This should help focus some development where it's needed most.
In regards to the wifi hardware solutions I don't think having the wifi hardware on the Pi itself is always a good idea. Typically RF separation is critical to keep the RF noise floor down and a separate wifi module means you can place the antenna for best reception. BTW PCIE is not possible natively on the ARM running in any of the Pi's. Using the GPIO for PCIE would require kernel level libraries etc and would unlikely achieve better speeds than available through USB. I'd also recommend moving to an Odroid C2 or similar for much better performance than the Pi2 at the same price.
Hi dhirajdhule (without wanting to be rude but can I ask you what we can call you that is a bit shorter please?) ;-)
That sounds like a plan. If you can could you please compose the laundry list into your structure to organise it? I will PM you with gdrive access so we can collaborate online more easily.
Out of interest is flytOS open source or proprietary?
Thanks again for you time and help!
Ohh :) Please call me Dhiraj.
Yeah. That sounds great. I will come up with an initial structure.
Currently FlytOS is Free to use. We have already released a demo version which can be used for developing apps and testing them in SITL.
We are strongly looking forward to releasing FlytOS source to the community, but I am not perfectly sure when and whether it will happen. Right now all I can say is it is free to use.
Waiting for your PM.
I'm not sure if it helps anyone, but you can get a "USB to Mini Pcie" adapter board for $6 here on ebay. I would like to see this adapted to directly inferface with the Raspberry Pi Zero by soldering the TX/RX/Vcc/GND wires.
I would like to see the data transfer rate using this method.
A Mikrotik mini pcie module could then be used.
No probs Dhiraj! PM Sent!
Happy to have you onboard!
I might have to try FlytOS then! Sounds good. Does it need a XU4 or will it run on a C1+/Pi2 too?
Thanks. Replied to PM.
Yes. In next week we are going to release XU4 image for PX4. Running some tests currently.
And I guess we will have to compile it for Pi2. Havent done yet. Also not sure if it will run right away on C1.