Autonomous Embedded Platform :: To provide a completely integrated software and hardware platform operable as both a physically heterogeneous device set (such as UAVs, etc), and as a single Universal Control mechanism designed to operate within any number of said physical devices - by operating within the capabilities presented within the current actual physical platform.
Project output should include hardware component information, hardware assembly instructional documentation, Linux firmware and operating documentation.
Description:
The Autonomous Tasking System was first conceived on Friday February 16, 2007. It represents the culmination of one man's dreams of flight, and another man's dreams of artificial intelligence. Neither had tried such a thing before, but both knew it could be done with off-the-shelf components, gratuitous re-use of existing personal projects, engineering know-how, and a little Internet research.
With both men being dreamers the project scaled quickly from a specific solution to an aggressively scoped architecture. However, in order to meet the original objective, the project must deliver a software and hardware platform able to translate a set of high level mission parameters, from a universal command set, into a co-ordinated, linear, physical activity that is defined, in part, by the capabilities and characteristics of the underlying hardware; a UAV in the first case.
Architecturally, the ATS is not bound by its hardware platform. Initial thinking indicates that High Altitude Devices (including balloons, rockets and satellites), Low Altitude Devices (including aeroplanes and helicopters), Terrestrial Devices (including cars, boats and robots such as walkers and climbers), Submersible Devices (submarines), and even Fixed Devices (including terrestrial encampments and silos, and submersible fixtures) are all viable physical platforms for an ATS function. Each hardware platform is free to implement its own hardware features from the known feature set supported by the ATS firmware. Hardware device systems have been initially defined as H-C (Chassis), H-CPU (Central Processing Unit), H-CS (Communications System), H-GPS (Global Positioning System), H-RPS (Relative Positioning System), H-MACS (Motor and Actuator Control System), and H-VRS (Visual Reconnaissance System).
The integration of the vastly differing physical platforms into a functional ATS unit occurs in software. The software architecture has been initially defined via the software systems S-NS (Navigation System) and S-CS (Control System). The S-CS is further divided into the two sub-systems S-DDCS (Device Dependant Control Sub-system) and S-UCS (Universal Control Sub-system). By the time the S-UCS has been appended to the top of the ATS architecture pyramid, a simple and uniform command language will be able to be applied to any ATS device of any hardware description and, so long as the hardware was capable, that mission or command set could be operationalised - potentially by multiple independent ATS units.
As the project was founded within the aviation realm, the prototype hardware platform will be an Unmanned Aerial Vehicle; a glider based design with a single propeller and solar cell wing coverings for in-flight re-fuelling.
Ideologically, the prototype should be able to be used as a search and rescue aid; to bring resources to bare against mountainous, forestry or oceanic rescue efforts. By performing mundane pattern searching in hazardous regions the ATS could be leveraged to to minimise risk exposure to humans.
Since initiating the project a number of existing resources have been located, those that are relevant are linked below.
As at March 2007, the H-CPU device has arrived from Thailand, and software platform testing has begun. The Linux based proof of concept platform developed for libMidnightCode version 1.2 has been adapted to the new hardware, and can be operational from a cold start within 60 seconds. The H-VRS unit arrived from Sydney, and libMidnightCode was updated to include the relevant camera controls. Version 1.3 of libMidnightCode was released mid-March. The H-C fixed-wing aeroplane chassis arrived from the US and physical platform testing has begun. The H-MACS device is en-route from the US, as is the H-CS prototype board.
It is hoped that the H-CS module will provide GSM based PPP connectivity back to the Internet to enable global command and control to any ATS platform that remains within a 30 kilometer radius of any GSM tower operating within the typical quad-band spectrum. While this is not ideal for oceanic search and rescue, it will facilitate terrestrial missions nicely.
As at May 2008, after about 2 months of work, 8 months off and then 3 more months of work, it can be said that there has been much progress!
H-CS testing resulted in a PPP link of about 40 seconds of maximum duration, and/or 20kbits of data transfer, before being terminated by the network. Testing was aborted, and the cause has not yet been identified.
Prototype-1 was planned; a human-controlled H-C chassis in two phases. Prototype-1, Phase-I, was to be the H-C chassis human operated via regular hobby RC controller hardware to the five on-board servos (rudder, rear flap, left aileron, right aileron and propeller). Prototype-1, Phase-II was to be the same H-C chassis human operated, but via the H-CPU-01 based flight package, to the five on-board servos. Both phases operated correctly on the bench.
Phase-II saw a Desktop PC booted to a libMidnightCode based USB Linux distribution, and the flight package booted to a libMidnightCode based Compact Flash Linux distribution. A joystick was connected to the ground control platform, and a program read the joystick user input and converted that into control data to be routed to the flight package over TCP/IP. The flight package ran a corresponding program that turned user control data into servo instructions. The ground control platform was ethernet connected to an 802.11b wireless router, while the flight package was driving a miniPCI 802.11b wireless adapter. Version 1.6 of libMidnightCode, to be released after the two test flights, will contain all of this software.
In late April 2008, while installing the H-CPU-01 flight package into the H-C chassis, the H-CPU-01 (a MicroClient Jr) was destroyed when the H-MACS-01 (Phidgets 4 motor servo controller) unit allowed voltage to feedback via the USB bus, through to the common power supply. In haste, H-CPU-02 was ordered (a MicroClient JrSX), as it shipped with USB2 interfaces which would automatically improve the resolution of H-VRS-01. Unfortunately while H-CPU-01 was an i586 architecture, H-CPU-02 was an i486sx architecture, which resulted in the entire software platform needing to be cross-compiled. Once the voltage feedback was identified, a small modification was made to the H-MACS-01 in order to take servo1, server2 and servo3 power from the USB power rail, as servo0 did.
In early May 2008, the H-IO-01 interface board was acquired along with the H-INS-01 Amperage sensor, the H-INS-02 Voltage sensor and the H-INS-03 Temperature sensor. At the same time, the H-LPS-01 Gyro and Gravity sensing hardware was ordered, but this order has additional lead time due to supplier assembly. Together, this hardware should enable a new generation of prototypes with real-world perception, and give the flight package a solid platform upon which the AI can be grounded, to achieve a comprehensive guidance system.
In late May 2008, H-CPU-02 was successfully booted from a fully fitted H-C chassis. A recharger is being constructed for the custom battery solution, as the last step before the Prototype-1 test flights.
A good deal of thought has gone into the AI for the second generation prototypes. Ultra thin and very light solar hardware has also been identified for future acquisition. The combination of these features, a larger chassis and the improved guidance solution, should allow for autonomous international flight.
