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
Replies
Just "fyi", MAVProxy has a module written by Jaime Machuca that can talk to that camera. My understanding though is that it takes about 5sec to retrieve each image.
Perhaps I've misunderstood the audience for your proposal. Is your architecture intended specifically to satisfy the needs of your baloon_finder use case? If its intended to be more generic I would challenge some of your assumptions. For example a photography rig being flown LOS can tolerate orders of magnitude more latency but would realize significant benefit by having better integration with the camera through the gcs.
On the note of the AP bridge, your diagram shows a dedicated piece of hardware. Separate from the CC as well as the GCS. If that's the case I would expect I would expect hardware designed with that specific use case in mind (like the ubiquiti) to perform as well or better than a rpi with a USB WiFi card functioning as an AP.
Hello Steve
The proposal is really for a broader range of application and it is intended to generate this kind of discussion so your challenge is very welcome and needed to push the envelope of the concept so be my guest.
I will probably create a subset of the forum that will address specifically Randy's ballon_finder project at a later stage but we needed to settle on an architecture because the list of request was getting to broad.
The AP bridge at the present design stage is a 'black box'' and the list of features is still open. It can be a simple antenna tracker with a usb WIFI connected directly to a portable (See my antenna tracker picture attached). OR it can be an Access Point with much more elaborate features like an RPI2 running with the antenna tracker software and having a LTE dongle and a local hotspot for the GCS running on tablets. Or it can be a Ubiquity based AP running more advanced connection, like a L2TP session over internet... You name it.
I agree with JB that you should start a new forum within the companion computer group with this concept so we can discuss and elaborate on this specific architecture.
Hi Patrick
I am no big Linux crack but if I understand correctly the main goal of this group (= "provide reference images"), then there is no need to evaluate my concept much further. Simply because you can just take the diagram above, skip any steps in between and start "programming apps". The things, on which this groups puts the focus on (again assumed I have understood it correctly), are just given and work out of the box on a smartphone. I never have to deal with images or drivers when programming smartphone apps.
A bit tongue in check I could say, that the destination where this group is heading to, is the origin of a journey using a smartphone based concept.
For three years I am now developing my project FlightZoomer focusing on features and stretching the possibilities of a companion computer to the max (in a somewhat uncommon direction though, but that's not impacting the system architecture discussion). And from day one I was just adding features and use cases. Hardware or OS topics were solved before I started.
So when I posted my diagram it was not my intention to start a new forum for a smartphone based CC architecture. I just wanted to say, that there might be other promising setups, which possibly offer huge shortcuts compared to the efforts going on here...
Yes Martin , you are absolutely right with your assumption, we are building a smartphone from scratch. This forum name should have been called: Proposal for a Companion Computer Hardware Architecture, using SBC on a Linux environment.
The possibility to tailor a specific platform using the right peripheral with the best interface , or building it as Laser Developer does, and adapt the driver to the kernel sounds like fun to me. My goal here is to experiment and explore the model without any type of commercial pressure like conquering a market or beating the competition or running against a time to market strategy.
This is basically the essence of DIY, that we are exploring here and I am quit happy to have the opportunity to discuss with knowledgeable and experienced developers like You, Laser, Randy, Aldo and others :-
P.S. The FlightZoomer is a very interesting project. I like the Idea of a real plane cockpit approach.
Hi Patrick
I certainly see the value of this thread and also I can see that in many cases the SBC approach would be superior to the smartphone approach. Especially for highest performance or real time processing requirements.
Hi Martin
I completely agree that Android based CC is a good concept. As mentioned previously we started that in 2013 already for our Outback Challenge project using an onboard Android camera. It's a far simpler structure to work with as much of the hardware is integrated already, plus from a GUI and connectivity perspective it's a solved problem. Let alone the hardware is typically cheaper and more capable, even the mobile cameras are getting really good. You can't compete with Samsung's hardware prowess. SBC's are a few billion dollars behind on that front!
I've been trying to get interest in the Android side of things here for years, I think it's time has come :-)
The main reason CC development is interesting now, at least in my opinion, is that a lot of the fundamental work (a lot thanks to Tridge/CUAV) have given rise to a toolkit that can be used on SBC. I've had this same discussion with Tridge in 2013; "please can't we just skip to Android"? But every goal has it's own requirements, back then it was the OBC, using Linux based SBC running a high frame rate Pt Gray Camera over USB. We did imaging on Android instead because for still imaging it was simpler and better for our setup. Going forwards there's still a requirement for CC type development, in particular for specialised hardware and peripherals, like the TX1 and high speed computer vision. Anyway that's how we got to this CC development in the first place!
I think you partially mis-understood Patrick's comments, I don't think he intended to say we don't want to include that in the CC development, rather that it warrants it's own dedicated development, in particular for those items that aren't available on that platform yet. It's not a competition of which platform to use, rather an convergence according to the available hardware and software available for each particular task.
In that regard we should start another thread where Android based CC development can be discussed and where we can make a list of items that need to be ported to get it all to work. Does that sound like a plan?
Regards
Hi JB
I understand better now. Smartphone based CC should be discussed separately and I agree. I am just not sure what topics we could discuss for a smartphone based CC architecture. Because everything exists already. You buy a 2nd hand device and 30 minutes later you develop apps. That's it. Nothing in between. The system architecture is given. Not much degree of freedom there but also not much need for it. Standard periphery just works and can be addressed in code in very easy ways.
I have to add, that off course the smartphone based architecture is not the answer to any requirement out there. I just believe it has advantages for many uses cases where we have seen complex and complicated SBC solutions...
@Martin, @JB - this is such an interesting concept, let me throw my 2c in.
A few years back we recognized the cost savings, shorter dev time and better performance of using "cell phones" either as GUI's or CCs for industrial and high end commercial products. We proposed their use with our OEM customers, end users, distributers and anyone who would listen but were shocked to learn that they were totally unacceptable! The reasons were many but basically it boils down to the difference between consumer/hobby grade equipment and equipment that is used commercially for making money.
Commercial operators need equipment from a single supplier who will offer guarantees on quality and performance and who will maintain and repair their products for between 5 and 10 years. In terms of quality management processes they cannot accept the idea of buying any off-the-shelf consumer components because they have no recourse when that part number becomes obsolete. Additionally, because the phone would be used in a non-standard way, they would have no warranty claim or insurance coverage if something went wrong. Finally, they didn't like the idea of using consumer phones because of the increased theft risk.
For people used to the free-for-all of open source development these excuses may all seem ridiculous, but if you've ever had to maintain an ISO system for a large company then you'll know what I'm talking about :}.
So I'm with JB on this - two different solutions for two different market sectors.
-
10
-
11
-
12
-
13
-
14
of 17 Next