MSD Project P10236:
Configurable Control Platform
for Unmanned Vehicles
Joe Pinzone
Rob Ghilduta
Alex Mykyta
Jason Stanislawski
Roberto Stolfa
System Overview and Nomenclature
The final control platform consists of three physically separable modules.:
Control Code Processor (CCP)
The control code processor contains a general-purpose processor and DSP
processor combination. This module stores and executes control code
generated and compiled from a Simulink model. On-board flash, RAM, and
power management make this module a stand-alone processor. A high-speed
serial bus is used to transfer control outputs and sensory information
between the CCP and the Input/Output Controller.
Input / Output Controller (IOC)
The Input/Output Controller (IOC) arbitrates all sensor and actuator
input/output streams, while simultaneously transmitting sensory data and
receiving control output data from the CCP. This module is implemented on
an FPGA and implements a highly parallelized architecture in order to
maximize data throughput. Two I/O headers are provided (analog and
digital) to connect to the I/O Breakout board.
Input / Output Breakout Board (IOB)
The IOB is a platform-specific hardware box which is designed to break the
IOC header out to the vehicle sensors and actuators. This box is physically
separate from the main control platform, since it is infeasible to be
compatible with the slew of connectors available on the market straight off of
the IOC. The RIT UAV IOB has been designed during P10236 in order to
demonstrate the full system and perform full-system functional tests.
Other nomenclature as used in this document:
Firmware: Program code that runs on the embedded processors. This does
not include the Control Code, which will always be referred to specifically.
Rigidware: The HDL containing the “image” of the FPGA gate configuration.
This may contain RAM/ROM initialization images and basic boot loader to
initialize and load the stored firmware. This term generally pertains only to
the IOC, since it is the only programmable-logic device in the system.
Software: Any program that runs on the user PC for the purpose of
programming, configuring, compiling, or monitoring the embedded system.
The image below is a CAD draft of the physical system layout. Note that each subsystem is truly physically separable. The three main boards (CCP, IOC, Power) will
be contained in one box, which will have the appropriate connectors for power,
programming, and connections to the I/O Breakout Board, which will be contained
in its own box.
IOC Board
Gumstix Overo
CCP Board
Power Board
Application Specific
IOB Box
Vehicle Control
Platform
1. Power Board
There are three subsystems requiring power. The Control Code Processor (CCP),
the Input/Output Controller (IOC), and the Input/Output Breakout board
(UAV_IOB). Table (1.1) below shows the power requirements for each electronic
component, organized by sub-system.
Device / System
Vmin
Vnom
Vmax
Imax (A)
Pmax (W)
3.2
4
4.5
0.4
1.6
FPGA VCC INT
1.14
1.2
1.26
0.088
0.1056
FPGA VCC AUX
2.375
2.5
2.625
0.045
0.1125
0.0264
Control Code Processor
CCP (Gumstix = OMAP + PM)
I/O Controller
3
3.3
3.75
0.008
4.75
5
5.25
0.05
0.25
3
3.3
3.6
0.145
0.4785
FLASH IC
2.7
3.3
3.6
0.025
0.0825
FPGA CONFIG IC
1.8
3.3
3.6
0.02
0.066
0.025
0.0825
FPGA VCC I/O
ADC IC
USB > SERIAL CONVERTER
3.3
SD CARD
3
3.3
3.6
0.04
0.132
EEPROM for USB > SERIAL
1.8
3.3
5.5
0.002
0.0066
DAC
4.5
5
5.5
0.0014
0.007
Voltage Translators (x8)
1.2
3.3
3.6
0.000032
0.0001056
4.75
5
5.25
0.057
0.285
3
3.3
3.6
0.057
0.1881
4.75
5
5.25
0.01
0.05
5
5
0.000015
0.000075
Oscillators (2)
UAV I/O Breakout Board
IMU
GPS
Dual Pressure Sensor
Thermistor
IO Multiplexor
Single Pressure Sensor
2
5
6
0.00016
0.0008
4.75
5
5.25
0.01
0.05
TOTAL CCP + IOC
0.849432
2.9497056
TOTAL UAV_IOB
0.134175
0.573975
0.983607
3.5236806
OVERALL TOTAL
Supply Voltage
4.8
Efficiency
V
80%
Source Energy
2.7
A-h
0.734100125
Ideal Batt. Curent
0.917625156
Battery Current
2.942377922
Battery Life (hrs)
Table 1.1: Detailed Power Requirements
From Table (1.1), the power system requirements are condensed into Table (1.2),
showing the necessary voltage rails, maximum current for each rail, and overall
system power consumption.
VOLTAGE RAIL
MAX CURRENT (AMPS)
POWER REQUIRED (W)
1.2V
0.088
0.106
2.5V
0.045
0.113
3.3V
0.322
1.063
4.0V
0.400
1.600
5.0V
0.129
0.643
Table 1.2: Power Requirement Summary
Part of the desires for the future of this product includes the use of alternative
energy sources. For this first iteration, we assume to use a standard COTS hobby
receiver power pack for our main power source. The pack consists of four, seriesconnected nickel-metal-hydride cells. The voltage range of the battery pack (full
discharged to fully charged) is 4.6-5.8V.
In order to accommodate the need for a 5V rail across the voltage range of the
battery while still maintaining power efficiency, a step-up/down switched-mode
power module will be used for the front end of the power chain. To reduce output
power ripple and eliminate the more demanding design effort required for five
independent switched-mode regulators, low-dropout linear regulators are used
between the front-end switched-mode converter and the electronics themselves. If
time permits, a second revision replacing the LDO regulators with SM regulators will
be developed, tested, and swapped in to the final product.
The Texas Instruments TPS43000 Multi-Topology High-Frequency PWM Controller
will be used in SEPIC configuration for the front-end power conditioning. This IC
permits the use of external MOSFET switches, which will allow for the controlling
high-current outputs. With an input voltage range of 1.8-9.0VDC the TPS43000 is
compatible with the 4-cell Ni-MH pack, and provides input voltage flexibility for use
with future possible power sources in that voltage range.
It is notable that in general the power needs for the I/O breakout board is variable,
and therefore it is unreasonable to assume that the IOC interface will provide all of
the power needs for the breakout board. However, since the majority of the I/O
sensing peripherals used in mobile applications are relatively low-power and
require no more than 5V, the IOC interface will provide access to the 5V/250mA
power bus which can be regulated however the break-out board designer desires.
In the event that peripherals on the I/O breakout board require higher power, a
separate power source will have to be provided.
The following diagram shows the schematic for the TPS43000 SEPIC power system.
Figure 1.1: 5v Output Boost Topology
[Source: TPS43000 Datasheet]
This schematic is based on a model given in the design doc of the TPS43000 IC. The
parts and values shown are the actual values to be used. The calculations for these
components are based on equations contained in the TPS43000 data sheet, as well
as a design guide titled “Designing DC/DC converters based on SEPIC topology” By
Jeff Falin, Senior Applications Engineer for Texas Instruments.
To reduce redundancy, the equations will not be copied in this document. Instead,
the original documents are available for download directly from the P10236 EDGE
space, or from the Texas Instruments server - using the following links:
http://www.ti.com/lit/gpn/tps43000
http://focus.ti.com/lit/an/slyt309/slyt309.pdf
TPS43000-Based
5V/0.25A
IOB, ADC, DAC
4V/0.5A
CCP
SW-MODE PSU
OUTPUT 5V/1.5A
3.3V/0.5A
Battery Pack
2.5V/0.1A
IOC
1.2V/0.1A
Figure 1.2: Power System Layout
It is also notable that switched-mode power noise may pose a problem for the
system. A thin mu-metal shield box will be built around the power electronics to
prevent EM leaks from the power unit. Output filter capacitors will be used on each
LDO output before being sent out to the other modules through the power header.
2. Input/Output Controller Module
Introduction:
The Input/Output Controller (IOC) is responsible for bridging the gap between the
various sensory and control peripherals to be used in the vehicle and the Control
Code Processor (CCP). The IOC is designed to be capable of communicating with a
wide variety of peripherals, logging data, and making data available to the CCP for
use during execution of the Simulink-generated control code.
Using a dedicated, FPGA-implemented I/O controller module offloads the task of I/O
arbitration from the CCP and offers parallelization of the I/O flow, thus improving
control and I/O throughput. Physical and functional modularization also allows the
IOC to be disconnected from, or operated independently of the P10236 CCP. This
means that the IOC can operate as a standalone data logger and arbiter, or be
connected to any a future revision of the CCP assuming the same interface.
Hardware:
The IOC is to be implemented using a Xilinx Spartan 3E FPGA as the backbone for
peripheral control. The Spartan 3E family of FPGAs is chosen because of its relative
ease of implementation and competitive price. The XCS500E-PQ208 offers the
highest pin count and highest logic size without the requirement of a Ball Grid Array
(BGA) package. Use of a BGA package is avoided due to routing difficulties and the
inherent requirement of a circuit board with more than 4 copper layers.
Figure 2.1 shows an overview of the IOC hardware and electrical connections. The
FPGA is provided two system clocks for internal use. The 50 MHz clock is provided
for the internal time reference as well as all processor control. A second 14.7456
MHz clock is provided for convenient conversion to a wide range of common serial
transmission baud rates. The remaining hardware subsystems are described in
further detail in the following sections.
Header to CCP
High Speed
Serial
(or future GPMC)
Rx Tx
USBàDual
UART
FT2232
USB
USB Mini-B
JTAG Header
EEPROM
AT93C46E
IRQ
IRQ
Rx
SD/MMC
Card
socket
SPI FLASH
PM Storage
SST25VF032B
Tx
SPI
JTAG
JTAG
FPGA Config. IC
XCF02S
JTAG
Config.
14.7456 MHz Clock
Xilinx Spartan 3E
XC3S500E-4
PQ208
50.0000 MHz Clock
SPI
8 Channel 16-bit
ADC
ADS1178
[-]
Voltage
Reference
DAC
TLV5623C
IO Ports
Bidirectional
Voltage
Translator
TXB0108
[+]
8
8
PWM In
8
Analog Header
Bidirectional
Voltage
Translator
TXB0108
Bidirectional
Voltage
Translator
TXB0108
Bidirectional
Voltage
Translator
TXB0108
PWM Out
8
8
Bank
Vref
8
Bank
Vref
8
Bank
Vref
8
Bank
Vref
Digital IO Header
Figure 2.1: Overview of IOC Hardware
Digital IO
The digital IO ports on the IOC are organized in groups of 8 signals similar to typical
microcontroller IO banks. Two of these groups are dedicated solely to reading and
generating Pulse Width Modulated (PWM) signals for servo actuator control. It is
beneficial to be able to read PWM inputs from sources like a hobby radio because a
user may want to record manual control inputs, or implement a control mixer as
part of their control code.
The remaining groupings of digital IO are general-purpose, bi-directional banks.
Each signal is fed through a TXB0108 voltage translator. This IC is capable of
translating the 3.3v FPGA bank levels to a custom logic level (up to 5v) set by the
user-provided voltage reference through the ‘Bank Vref’ pin. Each bank can be
separately configured to operate at a different voltage level. In addition, the bidirectional voltage translator ICs are capable of automatically detecting the
direction of the signal drive, and therefore do not require any signal direction
information.
For the MAV set of peripherals to be used, only one of the general-purpose, bidirectional banks are required. A target of 5 digital I/O banks (not including PWM)
is planned (if the FPGA has logical space) for the final implementation of the IOC,
which will allow for implementation in larger systems in the future.
Analog Inputs
The IOC is designed to accept up to 8 differential analog inputs. A differential, 16-bit,
8-channel ADC (ADS1178) is used for this purpose. As shown in Figure 2.1, the ADC
is shown side by side with an 8-bit DAC. The DAC is used to generate the full-scale
voltage reference for the ADC, allowing the user to define the dynamic range of each
analog channel, thus maximizing the use of the 16-bit digital range of the ADC.
The analog signal inputs are grouped into a separate analog connector to the I/O
breakout board. This connection is to be physically separated from the digital
signals in order to avoid analog signal corruption.
SD/MMC Card
Along with the provided I/O peripheral interfaces, the IOC board includes a socket
for a standard SD card. Communication to the SD card is done using a standard MMC
mode over the SPI protocol. The SD card’s primary function is to provide nonvolatile removable storage for data and event logging purposes. Since the FLASH is
only used during boot time, The SD card is chained on the same SPI bus as the SPI
FLASH module. This chain conserves pins on the FPGA as well as logic that would
otherwise need to be used to implement a second SPI module.
Rigidware:
Figure 2.2 shows a detailed overview of the rigidware within the FPGA. At the center
of the diagram is the “Plasma core”. The Plasma core is an open source HDL
implementation of a MIPS-I 32-bit processor. This core is chosen because it is open
source and can be manipulated to suit the needs of the IOC. Compared to other free
controller cores, it provides good documentation and provides an easy to use tool
chain for compiling program code.
Outside of the CPU are several peripherals that are mapped to the Plasma core’s
address space. This includes approximately 40kB of block RAM that resides within
the FPGA, as well as 1kB of dual port RAM. The dual port RAM provides the CCP
unrestricted access to part of the IOC’s address space without interrupting the IOC’s
operation. The remaining peripherals are discussed in further detail in the following
sections.
SPI Bus:
PM Storage & SD Card
To CCP
High Speed Serial
IRQ
IRQ
Tx
DO
Serial
Controller
Rx
CK
DI
CE
A
Dedicated
UART
D
Dual Port RAM
1kB
~40kB RAM
NOTE: All IO Ports, ADC Controller, Dedicated UART and
SD/PM SPI module are capable of generating interrupts.
SPI Master
System Clock
Counter
D
A
Plasma Core
CK
SO
SI
ADC
Controller
CS-ADC
CS-DAC
PWM Reader
8
PWM
Generator
8
IO Port
8
IO Port
8
IO Port
8
IO Port
8
Figure 2.2: FPGA Logic Overview
Dedicated Peripheral Controllers:
Two of the IOC’s peripheral controllers are dedicated as ADC and PWM Controllers.
The ADC controller is responsible solely for acquisition of data from the analog
hardware outside of the FPGA. This includes the task of setting the DAC voltage
reference and acquiring channel data from the ADC. The resulting conversion values
are stored in registers in Plasma’s address space. This allows the CPU firmware to
access and transfer analog data without consuming time in firmware to control
communication.
The PWM input and output controllers work similarly to the analog controller. For
PWM outputs, all that is necessary to move the connected servo is to write an 8-bit
value is a register in the PWM Generator. The PWM reader is responsible for
calculating the duty cycle of the input and placing that result in an 8-bit register in
the CPU address space. This configuration allows PWM control to be performed
without the need for firmware intervention.
Configurable IO Ports:
The remaining peripherals in Figure 2.2 are multiple instances of configurable I/O
ports. Each IO port is responsible for controlling eight (8) bi-directional signals for
multipurpose use. Each of the 8 signals can either be configured to be a generalpurpose input, output, or to perform a special function. Special functions include the
ability to communicate using SPI, I2C or asynchronous serial (UART). When
configured as a special function, that signal becomes connected to the respective
communications controller. Figure 2.3 illustrates the operation of each configurable
I/O port. Each port function can be configured using a control register in the Plasma
address space.
A
D
A
I2C
Core
SPI Core
CE
CK
DO
D
DI
SDA SCL
A
D
UART
Tx
A
D
GPIO
8
Rx
Special Function
Select
Figure 2.3: Detail of Configurable IO Port
Programming Interface
In order to configure the IOC, a few steps need to be taken to load the FPGA with its
rigidware, and the Plasma core with its firmware. The FPGA rigidware is
programmed by connecting a JTAG programmer to a header on the IOC bard and
uploading a bit-stream to configure the FPGA. Instead of directly configuring the
FPGA with the bit-stream, the rigidware is saved in an onboard configuration IC.
This allows for the previous bit-stream to be loaded into the FPGA during every
power up without the need to reprogram via JTAG. The rigidware includes partially
initialized RAM, to which a small boot loader is programmed to load the firmware
for the IOC (containing configuration registers for the IOC peripheral interfaces and
drivers for the serial device protocols). Because the rigidware configuration and
boot loader will not need to change, re-synthesis of the FPGA rigidware is
unnecessary for the end-user, and will only change during development.
Encouraging users to only change the firmware results in a faster turn around time
between system updates.
The boot loader is executed at each power up of the FPGA, and is responsible for
initializing the rest of the RAM with the current application’s I/O control code.
During normal operation, this code is stored on an onboard SPI FLASH IC shown in
Figure 2.1. At power up, the boot loader checks the FLASH for an available program
and loads it into memory. The boot loader is also capable of reprogramming the
FLASH with new program code. This program code is sent to the IOC via the USB
interface. A dual USB to UART converter IC is provided on the IOC board to enable
easy programming. [The second UART channel on the USB converter IC is routed
straight to the CCP for configuration of that device. The dual UART IC eliminates the
need for the user to switch physical plugs during configuration of the two devices.]
CCP Interface
In order to take full advantage of using separate I/O control and control code
processing systems, a shared dual-port memory block is used for part of the IOC
memory space. This allows the IOC and CCP to access the same memory space
simultaneously, enabling efficient, bi-directional data transfer between the two
systems. The interface between the CCP and IOC is a high speed serial bus similar to
SPI, where the CCP is the master device. Using this interface, the CCP can request a
read or write to specific addresses in the shared RAM. As suggested in Figure 2.1,
extra pins and signals are reserved for the future possibility of changing this
interface to a higher speed parallel GPMC bus if the CCP hardware can support that
protocol in the future.
Analysis:
Logic Cost Estimation
Table 2.1 shows an itemized breakdown of major components within the IOC
rigidware and amount of look-up tables (LUT) used. Using this information, it is
possible to conclude that implementing up to 5 configurable IO ports is reasonable
for the logic constraints of the FPGA selected. The remaining logic (~20%) is left
unused in order to facilitate uncertainties in estimations.
Plasma Core
Total (LUT)
3306
2-Stage CPU
2705
Fixed UART
101
Misc.
500
High Speed Serial Controller
Total (LUT)
300
PWM IO Controller
Total (LUT)
300
Analog Controller
Total (LUT)
230
SPI
130
Control Logic
100
Configurable IO Port
Total (LUT)
710
SPI
130
I2C
230
UART
150
Port Config. Logic
200
Number of IO Ports:
5
Total LUTs Used:
7686 (82.5%)
Available LUTs
9312
Remaining LUTs
1626
Table 2.1: Logic Cost Estimates for Rigidware Subsystems
Throughput Estimation
In order to have confidence in the feasibility of the IOC controller, a basic sampling
throughput experiment is conducted using the standard MAV peripheral set as a
model. Using information about the protocols used to communicate to the
peripherals, a simple dummy program is written that emulates a sampling iteration.
Since the PWM and analog inputs are designed to place resulting values in the
memory space, a simple move instruction for each parameter is required. Similarly
for PWM outputs, a memory-memory move instruction is performed for each
channel. For the IMU, each parameter is read from the device by writing a command
word and reading the resulting word. Since the SPI protocol of the IMU can operate
at up to 2MHz and each parameter can be passed in 32 clock cycles, the time that the
CPU must wait can also be computed. It is determined that each sampling iteration
can be performed in approximately 140 clock cycles at 25 MHz. Since the actual
control program is likely to have more complex flow control instructions, the value
of 140 cycles is tripled as a safety margin. Combining these values results in a
theoretical maximum sampling rate of approximately 30 kHz, which is well over the
target of 4 kHz.
It is possible that the sampling speed can be improved further since the actual
implementation will use interrupts to control peripherals, allowing more efficient
multitasking.
3. I/O Breakout Board
Description:
The I/O breakout board (IOB) will be used to break out the IOC I/O connector to the
vehicle-specific sensors and actuator circuitry or connectors. This module will be
unique for each vehicle application, and connects to the I/O Controller (IOC)
through two external headers (Analog and Digital). A typical IOB may include
connections for analog sensors, headers for PWM signal outputs, inertial/spatial
sensors on an SPI or I2C bus, etc, and route these signals to the IOC / IOB header.
Although normally it will be up to the vehicle engineers to make this board, an IOB
will be designed and manufactured so that the entire system can be tested and
verified to be working properly. In the case of the UAV, the IOB will connect sensors
used for the acquisition of flight parameters such as altitude, pressure, temperature,
and position. The UAV IOB will also break out PWM I/O in order to control the UAV
control servos.
The basic set of sensors to be included on the UAV IOB is listed in Table 3.2.
DEVICE LIST FOR UAV IOB
Analog Devices IMU
Tyco Electronics GPS
Airspeed Differential Pressure Sensor
Altimeter Absolute Pressure Sensor
Thermistor
Table 3.2: List of Sensors to be included on UAV IOB
The P10236 system will need to be installed in a vehicle whose sensors and
actuators are permanently mounted. As a result, it is necessary to allow the IOB to
be easily and readily disconnected from the sensors and actuators. To meet this
need, the servo outputs and receiver inputs will connect via header pins on the sides
of the IOB box. The pressure sensor tubes will protrude from the sides of the box
and connect to the sensor tubes with a coupler. This configuration allows the IOB to
be completely disconnected and removed from the vehicle without the need to
remove the vehicles electronics.
Analog Peripherals:
The I/O Controller provides eight 16-bit, differential ADC inputs. The full-scale
reference voltage can be set for each input using a programmable 8-bit DAC, which
generates the full-scale reference voltage for the ADC. The ADC channels have the
following interface requirements:
Diff V_IN max. ( V+) - ( V-) +/- 3.1 V
V_IN max.
V+ or V-
5.1 V
V_IN min.
V+ or V-
- 0.1V
In order to meet the input requirements, any analog output whose voltage may
exceed 5.1 volts, or whose full-scale span is greater than 3.1V must be divided down
before connection to the ADC. The absolute minimum voltage of -0.1V will be met
by using the analog ground provided by the IOC as the negative-most potential of
the sensor ICs.
In order to take full advantage of the digital range of the ADC (both + and –
differential voltages), the V- input shall be the median output voltage. This Vreference is generated (in this implementation) through the use of a voltage divider
network from a 5V source.
For example. An analog sensor with an output range of 3-5.5V must first divide the
output by 1.1 in order to meet the absolute voltage limit of the ADC. The output fullscale range then becomes 2.72 – 5V, with the median output being (5 + 2.72)/2 =
3.86V. A 3.86V reference signal would be generated by a voltage divider network
from a 5V source and fed to the V- input of the ADC. With a differential range of +/1.14V relative to V-, the DAC would be programmed provide 1.14V as the full-scale
differential reference voltage to the ADC, therefore maximizing the accuracy of the
digital conversion.
Airspeed Sensor: (already meets all spec for ADC connection, no scaling necessary)
(4.7V + .2V)/2 = 2.45V = VAltitude Sensor: (already meets all spec for ADC connection, no scaling necessary)
( 4.5V + .5V)/2 = 2.5V = V-
Temperature:
The output voltage values for temperature need to be determined before calculating
Vin-. These maximum and minimum voltages were calculated by finding the
thermistor resistance at the two extreme operating temperatures and then
calculating the output voltage of the thermistor voltage divider circuit. A formula
for determining thermistor resistor is given in the components datasheet. Assume a
5V input and a 10kΩ resistor for the voltage divider (the recommended setup).
Temperature(⁰C) Resistance
Vout
-80
3.58MΩ
4.986 V
120
481Ω
0.229 V
Table 3.3: Operating temperature characteristics
Therefore…
(4.986V + .229V) / 2 = 2.493V = VFor circuit simplicity, a voltage of 2.5V will be used as V- for all three analog sensors.
Next, the full-scale differential reference voltage must be calculated. Vref is
calculated by halving the full scale span of each sensor (from data sheets). The full
scale span is the difference between maximum output voltage and minimum output
voltage. Each sensor will have its own reference voltage for A/D conversion, set by
the DAC onboard the IOC when conversion is taking place.
Sensor
Vref
Altimeter
2.25V
Air Pressure
2.0V
Temperature
2.38V
Table 3.4: Vref for each sensor (calculated by (Full Scale Span)/2)
Digital Peripherals
The UAV IOB will contain two digital peripherals, the GPS and IMU (inertial
measurement unit). The protocols required are UART (NMEA) and SPI, respectively.
Since the IOC supports these protocols by design, the IOB only need route the digital
signals to the corresponding pins on the Digital I/O header to the IOC.
Telemetry Interface Spec:
The telemetry module will be connected as another digital I/O peripheral directly to
the IOC through the IOB header. The telemetry system is therefore required to use
SPI, I2C, or a UART protocol in order to transfer data to/from the system. The UAV
IOB will provide a standard header outside the case for this purpose.
Manual Override:
A manual override will be provided in case of control system failure or some other
need for manual control of the vehicle. This override will be implemented through
the use of two, quad 2-to-1 MUX ICs, switched by one of the spare receiver channels
on the R/C receiver. The MUX is powered by the RX system battery, making it
impervious to control system power failures.
External Interface:
The CCP/IOC and IOB boxes will be standard aluminum (or similar) project boxes.
An area inside the plane will be fitted with a mounting plate spanning the available
area. The project boxes and plate can be drilled in any desired configuration, and
attached via nut and bolt. This provides mounting flexibility to the aircraft for CG
adjustments, while still providing firm attachment to the aircraft.
NOTE: TELEMETRY CONNECTOR AND ROUTED MUX SWITCH SIGNAL NOT SHOWN
Figure 3.2: IO Breakout Board Schematic
Packaging:
The IOB case in will be an off the shelf project box. The appropriate holes will be cut
to fit the selected connectors and sensors. This will allow for greater flexibility in
IOB layout rather than selecting a box with predetermined connector locations and
other such requirements. Connectors have not all been specified yet, but
distributors have been bookmarked and lead times have been researched so any
risk due to this selection has been mitigated.
The connectors for the (8) servo outputs and (8) receiver inputs will be 3 row, 24
position right angle Molex connectors. Each of the 16 columns will contain one
ground, one power and one signal line. The pressure sensor tubes will have
couplings on the ends in order to allow connection without disassembling the box.
4. Control Code Processor
Hardware:
To satisfy the control system processor’s needed capabilities, especially numerical
throughput, it was decided that a solution implementing TI DSPs would be optimal.
After comparing and contrasting between various manufacturers and model
numbers, the OMAP “Application Processor” was selected. The processor is a fusion
between a general-purpose processor and a high-throughput DSP. Despite its
voluminous feature set, the OMAP is a very low-power chip, making it suitable for
use in battery-powered applications.
To mitigate possible risks, an incremental design approach is adopted. It is planned
that each completed revision will be capable of meeting the customer’s needs. For
the initial revision, an off-the-shelf Gumstix board will be used. Future revisions can
incorporate improvements such as upgrading the IOC interface, using lower power
modules, and reducing layout area.
The Gumstix board is a ready to run, out of the box solution for the OMAP processor.
The board features on-board expansion slots that allow for simple and
straightforward interfacing with the I/O controller. The board contains all of the
necessary power management, RAM, and FLASH resources needed, and therefore
only a very small number of pins must be routed in order to function properly;
specifically, power and IOC interface pins.
Architecturally, the system relies on a separate I/O controller (IOC) to acquire and
transmit control data with the system peripherals. An obvious interface
requirement exists between the two devices. In order to avoid throughput-limiting
communication techniques (such as polling or interrupting), the ideal interface is
either DMA, or a memory controller interface. Unfortunately, the Gumstix board
does not break out all of the OMAP pins. Specifically, the board lacks
sys_ndmareq[1:4] pins, making it infeasible to implement a complete GPMC
(General-purpose Memory Controller) interface to talk to the I/O controller, which
is the highest throughput bus the OMAP supports and the ideal interface solution.
Instead, a McBSP (Multi-channel Buffered Serial Port) will be used for the CCP/IOC
interface. Although slower than the GPMC interface, McBSP is highly configurable
and still provides ample bandwidth for this application. According to Texas
Instruments' "OMAP35x Applications Processor Technical Reference Manual", the
OMAP supports full-duplex, twin-channel, asynchronous, high-speed serial
communication with a sustained speed of 8 bits per cycle of the "OMAP's peripheral
L3 connect clock." Simply stated, the serial transceiver can be configured to support
burst speeds of up to 200MB/s, which is well above the specification. The McBSP
features DMA capabilities, allowing for a solution, which, from the DSP’s software
perspective, behaves, similar to the GPMC.
For reference, the GPMC is an enhanced version of a typical SRAM interface
consisting of a configurable number data and address lines (8 or 16 in the case of
the OMAP), and control line (chip-select, clock, read/write, direction, write protect).
Using the OMAP's MMU it is possible to have memory references within a specific
memory region travel off the chip through the GPMC interface, on the other side of
this interface would lie the I/O controller which would act like a memory device,
sending back I/O data depending on the requested memory address.
The main disadvantage of the Gumstix board is that the manufacturer does not
provide schematics or layouts. Additionally, the current Gumstix boards feature
hardware for video and audio processing which is not needed, and only consume
extra power. In order to maximize power efficiency and minimize extraneous
hardware, future versions of the CCP can make use of a custom board solution with
more appropriately-featured hardware. A redesign would provide an opportunity to
reimplement the IOC interface to use the GPMC. This change would provide lower
latencies between sampling and control system executions, thus increase the
performance of the system as a whole and reducing delay effects in the control
system.
Software
One of the criteria for selecting the OMAP3 for the Control Code Processor(CCP) was
the available software development environment. The OMAP3 met this need by
having TI-supported free Windows tool chains for both the ARM and DSP cores.
The MATLAB/Simulink integration requires a new Realtime Workshop target
template to be written for our processor and environment. This involves writing
the ARM-side wrapper for initializing the DSP bridge and starting the DSP node, as
well as writing the DSP node wrapper that actually runs the Simulink model.
Further, this code must be aware of a vehicle-specific configuration file that
describes the sensors and actuators available. Figure 4.1 shows the end-user
workflow for creating the vehicle control code and uploading it to the system.
Figure 4.2 shows the execution flowchart for the control code.
Figure 4.1: End-User Workflow
Figure 4.2: Control Code Flowchart
Due to the choice of the OMAP3 processor, the opportunity arose to use the Linux
operating system on the CCP. Using a pre-existing operating system removes the
need to write hardware device drivers for our peripherals and provides an ideal
debugging/monitoring interface. Furthermore, Linux provides a wide range of real-
time capabilities without having to switch a more traditional real-time operating
system. Figure 4.3 shows the CCP's boot process.
Figure 4.3: Control Code Processor Boot Sequence
As the last task in the boot sequence, the control code loader daemon will run. This
loads and runs any existing control code software. The control code loader daemon
also periodically checks for new control code. If new control code becomes
available, it then terminates the old control code, and launches the update. Figure
4.4 shows the flowchart for the control code loader daemon.
Figure 4.4: Flowchart for the Control Code Loader Daemon