Proceedings of the Multi-Disciplinary Senior Design Conference Page 13

Project Number: P10236
http://edge.rit.edu/content/P10236/public/Home

Configurable control platform
for unmanned vehicles

Proceedings of the Multi-Disciplinary Senior Design Conference Page 13

I. Abstract

The goal of P10236 is to design and implement an embedded, real-time processing platform to act as the controller for unmanned vehicles. The system is designed to (1) provide electrical connection to a variety of analog and digital sensors, (2) gather any and all required data from those sensors, (3) store and execute control code generated in MATLAB Simulink. The final product consists of four, hardware-separable sub-modules to complete each task: (1) A Texas Instruments OMAP (ARM Processor + Digital Signal Processor) is used to execute control code, (2) an FPGA containing a 32-bit microprocessor and several specialized digital communication peripherals to arbitrate data acquisition from sensors, (3) a swappable connector breakout board to allow for different sensor sets to be easily switched, and (4) a dedicated power conditioning module to maximize power sourcing options. The overall product delivers the above-mentioned hardware in a package small enough to fit on medium-sized radio-controlled aircraft. The key to the product’s usefulness is a custom software package including a tool-chain for the Simulink RealTime Workshop, tailored for the OMAP processor, and PC-based user-interface to allow the user to easily reconfigure sensors and connections, map sensor data to Simulink input/output blocks, and program the unit through USB.

II. NomenclaturE

ADC - Analog to Digital Converter

ARM - Acorn RISC Machine Microprocessors

CCP - (Sub-Module #1) Control Code Processor

Control Platform – The Final P10236 “Product”

Core - FPGA Synthesizable subsystem

DCM - Digital Clock Manager. Conditions incoming clock signals on the FPGA.

DCR - equivalent DC resistance of an inductor

ESR - equivalent series DC resistance of a capacitor

FPGA - Field Programmable Gate Array

Firmware - Compiled code that is executed on an embedded platform

IOB - (Sub-Module #3) Input/Output breakout Board

IOC - (Sub-Module #2) Input/Output Controller

IRQ - Interrupt Request. Signal generated that requests an interrupt from the CPU.

ISR - Interrupt Service Routine. Subroutine executed when an interrupt is received.

JTAG - Joint Test Action Group. Refers to the interface used to configure the FPGA

Kernel - Hardware supervisor

MMC - Multi-Media Card. Older removable storage interface supported by most SD cards.

McSPI - Multichannel SPI

OMAP - Microprocessors by Texas Instruments

PLD – Programmable Logic Device

PRM - (Sub-Module #4) Power Regulation Module

PWM - Pulse Width Modulation

Rigidware - FPGA logical configuration

SEPIC - Single-Ended Primary Inductor Converter

SMPS - Switched-Mode Power Supply

SPI - Serial Peripheral Interface Bus

SRAM - Static Random Access Memory

Soft Microprocessor - Microprocessor that can be implemented using synthesized logic on an FPGA

UART - Universal Asynchronous Receiver & Transmitter

VHDL - VHSIC (Very High Speed IC) Hardware Description Language.

III. introduction and background

Over the past few years, through recent Micro-Arial Vehicle (MAV) and Unmanned Arial Vehicle (UAV) related projects, RIT has been exploring the development of autonomous aircraft platforms through the Multi-disciplinary Senior Design (MSD) program. These projects have been driven by a number of factors including inter-collegiate competitions, university research, and external interest from commercial and military organizations.

During the 2008-2009 academic year, the UAV Project Family successfully flew the first of its airframe designs and is ready to start development of the flight control system. This is the first UAV project to begin work on this system through the development of a control system platform that provides the means to interface with various types vehicle sensors and control actuators, as well as a processing core capable of running control program.

IV. NEEDS AND SPECIFICATIONS

The needs of P10236 come from two primary customers – Dr. Kolodziej, head of the UAV Project at the Rochester Institute of Technology, and Harris Corporation, RF Division from Rochester, NY. Both customers’ needs were fairly aligned, and were combined to form a final list. The following list is a more concise summary of these needs. The full list can be viewed on the project website at the address shown on the title page of this document.

· Compiles, stores and executes control models from MATLAB Simulink®

· Interfaces with all UAV sensors, servo-actuators, and future wireless telemetry unit

· System data values can be externally monitored (sensor and servo values, control variables)

· Supports data logging to removable storage

· Physically fits into and mounts to UAV C

· Powered from unregulated battery source

· Operates for entire duration of mission

· Extended set of I/O capabilities for expansion to other vehicle platforms

· Serviceable “in-field” with limited tools and a laptop, if necessary, for re-programming

· Open-source, open-architecture solution that does not require expensive proprietary licensing to develop, produce, or use

The critical engineering specifications are listed next in Table 1. Once again, see the project site for the fully detailed list of engineering specifications.

Table 1: Project Specs (condensed)

SPECIFICATION / UNIT / TARGET
Power Efficiency / % / 80
Input Voltage Range / Volts / 4.6 - 5.8
Guaranteed Operating Time / Minutes / 30
Total System Weight / Pounds / <3
Compatible Simulink™ Blocks / (list) / Std. Block Set
Control Iteration / Data Acquisition Speed / Hertz / 1000
Physical Size / Inches / 6"x6"x6"
Data Log Size (Flash Memory) / MBytes / 8.4+
Analog Sensor Range / Volts / 1.8-4.5
Number of Analog Inputs / # / 3
Protocols Supported / (list) / UART, SPI
Digital Peripheral Connections / # / 2

V. concept development summary

The initial concept development phase yielded a handful of feasible system concepts, but a much longer list of design considerations that becomes convoluted when the entire set of system tasks is assumed to be performed by one single device of one type or another (i.e. a single processor, PLD, or microcontroller running the whole system).

To avoid the need to make any steep or detrimental performance tradeoffs between one system task and another, the system is broken down into independent sub-systems, each of which targeting a particular set of tasks. Each sub-system module is designed around the ideal solution or method for completing that set of tasks, therefore maximizing the capabilities of the final product as a whole.

The selected system concept features four primary hardware sub-systems. The Control Code Processor (CCP) module handles the storage and execution of the compiled Simulink® control code. A dedicated I/O Controller (IOC) manages all of the low-level input/output functions, while the I/O Breakout Board (IOB) provides the physical connectors to the vehicle sensors and peripherals. Finally, the Power Regulation Module (PRM) conditions the power for the whole system, eliminating the need for individual, and less robust regulators on each board.

vi. DESIGN PROCESS BY SUB-SYSTEM

Control Code Processor (CCP)

CCP - Specification

It is the responsibility of the CCP to execute the control program. The processing core of this module must have high enough processing power and data throughput in order to execute the control algorithm in real-time, as desired. The following calculations are used to form an estimate of the required processing speed and throughput of the CCP.

Equations 1, 2, and 3
Control Code Processor Throughput Calculations

The customer desires a controllable bandwidth of 50Hz. Multiplying by twenty provides the required controller bandwidth (10 x Nyquist frequency) [1]. In order to reduce any pure delay in the control system caused by the calculation and processing time of the processor, the calculation-and-store time is set to one-tenth the time of one control cycle [1]. This means that in order to provide adequate control with a bandwidth of 50Hz, the CCP must execute an entire iteration of the control loop (including calculations and data retrieval / storage) in less than 100us.

The CCP is implemented using a Gumstix System-on-Chip (SoC), featuring a Texas Instruments OMAP Application Processor. The OMAP™ consists of an ARM Cortex-A8 general-purpose processor and C64x+ Digital Signal Processor on the same chip. The Gumstix board also adds non-volatile FLASH memory, a DDRAM module, and a power monitoring and control IC made specifically for the OMAP.

Table 2: Gumstix System Specs

Gumstix Overo® Water

ARM Cortex-A8 @ 600 MHz
TMS320C64x+ DSP @ 430 MHz
RAM: 256MB mDDR (2.7 GByte/s)
Flash: 256MB NAND
Card slot: microSD/SDHC
Size: 0.67 in. x 2.28 in. 0.16 in.

The OMAP™ processor is capable of a maximum 1200 Dhrystone MIPS. Based on code execution testing performed by the P09122 team using a much less powerful processing platform, the Gumstix® SoC is certain to exceed all required performance specifications set by the needs of the UAV platform. Although a hardware (PLD) real-time solution would provide faster execution, expensive proprietary HDL encoding software and licensing would be required and is therefore not a viable solution for this project.

CCP - Implementation

In the implementation of the CCP, an up-to-date version of Linux-2.6 is compiled to run on the OMAP Cortex-A8 processor. Software and kernel driver development for the CPP uses the cross-compilation tools [2] available in the OpenEmbedded development environment.

The CCP software breaks down to two components: the kernel driver for the communications link, and the user-space application that executes the generated Simulink® model.

Kernel Driver Development

For communicating with the IOC, a bidirectional link using a high-speed serial interface (SPI) allows data to be read in from sensors and sent back out to actuators during each iteration of the control system. To enable the OMAP link to the IOC, the existing McSPI driver code base is leveraged to create a custom SPI peripheral device driver.

The design of the Linux SPI bus subsystem separates the SPI peripheral device drivers from the driver of the SPI controller. Once Linux becomes aware of a new SPI peripheral device, it searches for a driver that matches the device name. Once matched, the device is enabled and control is transferred to the driver. For the CCP, the device is a custom memory interface to the IOC’s onboard memory. The driver exports functionality to the user-space by registering a character device which allows user-mode applications to treat communication with the driver in a similar manner to reading and writing to a file.

User-space Development

The user-space application is responsible for linking the control code from the generated Simulink® model to the data communications link. Since an arbitrary model can be used, a framework was developed for linking the input and output variables to available data services of the IOC.

Simulink Model Generation

The Simulink® model is converted into C code using a custom system target file developed for Real-Time Workshop. Once generated, the code is run through the IO mapping UI, where the end-user generates the mapping file and specifies the peripheral configuration parameters. The model is then compiled using the framework, resulting in the final executable application.

Proceedings of the Multi-Disciplinary Senior Design Conference Page 13

Input/Output Controller (IOC)

IOC – Specification

The purpose of the IOC is to provide a versatile abstraction layer between the peripherals on the IOB and the Simulink model being executed in the CCP. The IOC is required to be able to interface with a wide variety of sensors, actuators and other peripherals and provide a single high speed data link to the CCP. Being capable of interfacing with SPI, I2C, UART and PWM devices as well as reading analog inputs is deemed sufficient coverage of the majority of sensors and actuators most commonly found in unmanned vehicles.

Since many digital peripherals require device-specific command sequences in order to acquire data, higher level operations such as these lend themselves to be performed by a program code executing microprocessor. The majority of general-purpose microcontrollers provide the required variety of interfaces however they lack the ability to provide a fast enough data link to the CCP. The need to have numerous instances of SPI, I2C, UART and PWM peripherals also excludes the possibility of using a general-purpose microcontroller.

In order to get the best of both worlds, program code execution capability and a largely customizable platform, the decision was made to implement the IOC using an FPGA with a soft-microprocessor in its rigidware. The Plasma soft-microprocessor core from OpenCores [3] is chosen since it is freely available for commercial and non-commercial uses free of any cost. The previous project group P09122 [4] also used the Plasma core in a similar control project.

FPGA Rigidware Design

Since the architecture of the Plasma core is open to modification, various custom cores are implemented that are capable of performing general operations and act as peripherals to the CPU. These cores can perform operations on external devices independently from the operation of the CPU. Figure 1 shows the simplified architecture of the Plasma core’s peripheral set.

Several different cores are implemented in order to provide easy interface with external devices. Since a dedicated ADC is provided on the IOC, a core is designed to operate specifically with it in conjunction with an analog multiplexer. Up to 16 analog channels can be sampled in quick succession without any CPU intervention.

Most vehicle platforms use servos to actuate mechanical parts which require some method of PWM signal generation. For this reason, a core is specifically designed to convert digital values into a PWM servo signals. Since vehicles that use servos are likely to have the capability for a human control override, a core to read PWM inputs is also provided. Human servo input data can be valuable information when designing a control system for a new vehicle.

The remaining peripherals, Ports 0 to 4, are designed for general-purpose use. Each port core can be configured to operate as general purpose IO as well as UART, SPI and I2C. This provides the capability of interfacing with nearly any other external device.

In order to be able to rapidly transfer data between the IOC and the CCP, a memory tap controller core is implemented. This core allows the CCP to tap into the IOC’s memory space without interrupting the operation of the Plasma CPU. Data is transmitted between the IOC and the CCP using a custom high speed SPI interface.