Blogs

Hey guys, this is a proposed hardware architecture for the UAS.  It is preliminary and more to show what we can do for documentation and how we might layout our systems.  This is just the command and control system.  There are some things to figure out like camera connections, controller layout, etc.  I think we will have to diagram our software architecture as well but I do not think we can do that yet until we have a better idea of what we are using in the system.  Our critical design review is due April 30^th so I think we can also do this with pictures from the plane and may not have to have CAD drawings if we do not get that far.  What I mean by that is that we can take a picture without the wires and photoshop in the connections for labeling.  I will now try to explain connections and what each piece of hardware is and does.

A. Odroid U3

The Odroid U3 is a quad core 1.7 Ghz microcontroller.  It is very fast has a lot of processing chops for our system.  This controller was proposed by Jono to use with Andrew Tridgewell’s on board image recognition software.  It should also be able to control other systems like metal detection and RFID.  Maybe not for this competition but eventually we would actually like to have the autopilot software loaded on the Odroid or a BeagleBoneBlack and we will not have to worry about having a separate APM or Pixhawk.  The Odroid will probably in the second fuselage and will be connected to the AP (D) through USB and we have an I/O shield for the Odroid for connections to the additional embedded sensor payloads.

B. XtremeOSD

The XtremeOSD (formally the ExtremeOSD) has not even hit the market.  It should be available for sale to the general public in the next couple of months.  It has been under development for over two years and is well worth the wait.  We are the first people outside of the development team to work with this board. We could possibly be the first with a production hobby class full color OSD in the world!  The XOSD is connected to the GPS (G) in this picture but in reality the GPS will probably be connected to the AP (D).  The GPS (G) and telemetry have to be shared with the XOSD (B), the AP (D), Teleflypro (H) and of course the Bluetooth (F) and radio downlink (C).

B1. This is a controller for more convenient placement of controls if the OSD is buried in the plane.

C. 1 watt OpenLRS Tx

The OpenLRS Tx is hacked to be a transceiver which is not a standard OpenLRS branch of firmware.  This will give us a bidirectional communications with the plane.  The receiver is providing PPM input to the Channel Wizard (E) and servo instructions are transferred from there.   (See radio control function through Channel Wizard)  The telemetry and mission control will be transferred back and forth from the UART of the tranciever and the AP (D).  In this picture I connected the UART pins of the XOSD (B) and the OpenLRS (C).  Actually the UART from the OpenLRS (C) will connect to the AP (D) and then the UART from XOSD (B) will then got to the Teleflypro (H) instead of from the AP (D) to the TeleflyPro (H)

D. AUAV3 or AUAV X-1

The autopilot or AP pictured is the AUAV3.  This is from our sponsors, Nick Arsov and Philip Kocmoud, of Arsov RC Technology.  They are also about to have their production AUAV X-1 underway.  The AUAV3 is very capable autopilot that runs MatrixPilot.  The MatrixPilot is underdevelopment and has a lot of exciting capabilities.  However,  the most of our peripherals have been developed and are stable with a Pixhawk based AP running APM firmware.  While we have the board we are going to experiment and will probably use it in our Drone Prize Cycolps, we will probably have to stick with the APM based AP for the Wildlife Challenge plane.  The XOSD, and the telemetry hack are all based in APM so it will speed development in our short timeline for this contest.  That is where the AUAV X-1 comes in.  We are waiting on the shipment of two of these boards from Arsov RC Technology in the next week or so.  This is their vision of the Pixhawk board with some possibilities of seriously upgrading the microprocessor.  I also liked that they forgo the flimsy molex connectors of the Pixhawk in favor of sturdy pin outs that are standard with most of our RC equipment.

D1. Current sensor board for the AUAV3

E. Channel Wizard

The Channel Wizard will actually have a twin.  We need it to provide servo pin outs from the Radio Control Rx (C) since it is actually a transmitter module that is hacked into a receiver.  It will serve as a PPM pass through for the first eight channels to the AP and will provide us with 7 additional channels in the first fuselage and 8 additional channels for the second fuselage.  Three channels from the primary fuselage Channel Wizard will control the XOSD (B) functions.  The plane should have a total of at least 23 usable channels for flight control, on board systems manipulation, and secondary user control of camera and embedded sensors.

F. Bluetooth

The Bluetooth module may or may not be used.  It can be used for wireless changes to AP on the ground without the need to dig in the aircraft to connect a USB.  This strictly for changes on the ground.  Changes in the air will be handled by the long range telemetry link of the 1W OpenLRS (C).

G. GPS module

The GPS module pictured is probably not the module that we wish to use long term.  The AP (D) has an onboard magnetometer but I believe that we will wish to use a remote compass on the GPS module itself.  I have it connected to the XOSD (B) but will probably wish to have it connected through the GPS UART of the AP.

H. Telefly Pro

The Telefly Pro is hopefully going to be more like an appendix.  We will wish to remove it.  The reason that we will have it connected is to modulate the GPS and telemetry data via the AV channels for the MyFlyDream Automatic Antenna Tracker.  We are not showing camera and VTX connections in this picture for two reasons.  This is a hardware layout for the control systems.  The peripherals will be shown as they are connected to the individual control components.  The second reason is because we will have to decide where in the video stream the connections will happen.  It will either be connected between OSD and Camera or OSD and VTx.