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 to rectify that this is actually not true. Even running on the same board the worst that could happen is your hog application not being able to do its job. The flight stack will continue to work. Once you have the extension board attached, you could experiment that by removing the APM/pixhawk/other from the game and just communicating with the flight stack on the same board using a socket.
Hello Lucas,
Agree with you, as long as the crash is within a shell (userspace) , but sometimes it happens that it goes beyond that level and runs straight to a full kernel panic with a complete system shutdown. ...That used to happens quite often on 3,x kernel and it really looks better on 4,x . As an example, if you have both usb camera and wifi dongle overloading the usb driver because you try to push too much data, you can easily get in that state.
That is bad... bad driver that needs fixing probably. The platform that I usually stress the HW is a MinnowBoard Max and I don't have such issues. The other Linux boards I usually run the flight stack alone or with very little processing.
(here a disclaimer is needed probably... I work for Intel and MinnowBoard Max is an Intel product)
Hello Lucas,
By the way, is is great to have you in the forum !!
Thanks for your contribution and promotion of Linux in this development space. :-)
I experienced these problems on the BBB working with releases 3.8.x kernels with a Logitech c-170 and the nl80211 drivers for my wifi dongle and it was nasty.. was crashing rock solid as well with POLOLU Maestro drivers.... Fortunately these setups never took off the bench !!
Seem to be much more stable now on 4.1, thanks to the work of Robert c Nelson, working with new devices now anyway. I just wanted to point out -as an example -that when you are doing experiments that might crash the Kernel, like new builds, new drivers, and users space tools like iw and v4l2-ctl that can be modified ''live'' with an app, the Companion Computer approch migt be a good thing. BTW , my dedicated Flight Controler is a BBBMINI running on Mirko's ArduPilot.
Would the MinnowBoard Max would qualify as a good Companion Computer ?
Best Regards
Patrick,
Thanks for the reply, and all you have noted make perfect sense. That said, it all makes for some exciting times in the robotics tech arena! The new DOT COM play. :)
I will be receiving some of the Navio2's and would be interested in testing out the Balloon_Finder on a setup. Should have them in about 10 days, and will let you know once I have one in the air.
Cheers!
Cool !!
Hey guys, just a comment from the cheap seats. Is there any intention to bring Telemetry into the Wifi stream so we can reduce one Rf link? And then, maybe control, too? (actually control could simply be RC Over-rides from the GCS over MAVlink/telemetry)
If the vehicle is intended to be flown under manual control, there's still a case to be made for using traditional RC links as they're very reliable and guaranteed low-latency. But for other systems intended primarily for waypoint flight or whatnot, would be nice to have only the single RF link.
Hi Rob
Great to see you around here too. Your input is always welcome! In the thread header description I tried to outline this type of single link type connection over wifi. The RF links marked with a * are optional. The idea is to enable a single wifi link for telemetry, RC and video etc, however as a part of the process not impede them from working as well if required. Ideally all types of connections remain available, but wifi, as one of the only ones that can likely handle all data streams, is used to replace them in most WP type use cases.
Further there will eventually be a GUI to simplify the setup the various interfaces according to the user's requirements.
Regards
LOL , JB we are like GPS, were on sync on each side of the planet !!!
Lol Yeah Patrick! We should start our own atomic clock while we're at it! ;-)
Especially so since I'm travelling atm and only randomly stopped at the petrol station where I wrote the post on my mobile, at exactly the same time as you!
-
1
-
2
-
3
-
4
-
5
of 17 Next