MSD Project 10236Configurable Control Platform

for Unmanned Vehicles

Project Review

Joe PinzoneAlex Mykyta

Roberto StolfaRobert Ghilduta

Jason Stanislawski

P10236 Project Review

Customer Needs (condensed)

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

• Interfaces with UAV sensors, servo-actuators, and future wireless link

• External monitoring of system data

• Supports data logging to removable storage

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

P10236 Project Review

Constraints

• Physically fits into and mounts to UAV C

• Powered from (unregulated) battery source

• Operates for duration of 30-minute mission

• Serviceable “in-field” with limited set of tools

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

P10236 Project Review

Specifications (condensed)

P10236 Project Review

Selected Concept

• Four Independent, Interconnected Sub-systemso Input / Output Controller (IOC) o Control Code Processor (CCP) o Power Regulation Module (PRM)o Input / Output Breakout Board (IOB) – not pictured

• Physically separable, swappable modules

• Allows each sub-system design to be idealized for performing each task

P10236 Project Review

IOC

CCP

PRM

CCP – Control Code Processor• Stores & executes Simulink-generated control code• Gumstix Overo® Water Specs & Features:

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

IOC – Input/Output Controller• Arbitration of peripheral communication and data I/O• Dual port RAM for easy data sharing

– Connects to CCP using a dedicated high speed SPI bus– Can operate asynchronously and independently from CCP

• Features:– Up to 5 (each) SPI & UART controllers

(space reserved for future I2C controllers)– Up to 40 GPIO pins compatible with

1.65 to 5.5v logic levels– 16 channel multiplexed 16-bit ADC with

3.0v reference. 256 kSPS– 8 PWM input & 8 PWM output channels– 32 kB internal RAM + 512 kB external SRAM– 4MB FLASH program storage memory– Micro-SD card socket for data logging– Configurable through USB

USB Port

Spartan 3EFPGA

SRAM

Level Shifters

Micro-SD Card

Digital IO & PWM Header Analog Header

Power & Power-good status

JTAG

Final IOC Rigidware Overview

Input / Output Breakout Board (IOB)

Purpose:

• FPGA pin breakout - Sensor routing - Signal conditioning

• Control switching - Hobby receiver (manual) - IOC control (autonomous)

• IOC Testing • Swappable peripheral sets - UAV set (pictured) - Platform specific - Various IOB’s can be connected

Analog Header

GPS

IMU

R/C Receiver Header

Digital Header

Analog Sensors

Servo Output Header

Power In and Battery monitor headers

Airspeed Sensor

Temperature Sensor

P10236 Project Review

Simulink Real-Time Workshop Code Code Generation

End User Workflow

Yes

Yes

Power Regulation Module (PRM)

P10236 Project Review

• Designed around TI Power Controller• TPS43000 PWM• SEPIC topology• More advantageous than LDO solution

•Provides three system power rails• 3.3V (I/O Controller)• 3.6V (Control Code Processor)• 5.0V (I/O Breakout Board)

• Maximizes input voltage range

• Final rev. includes 3V “Jump-starter” battery• Allows startup of IC with low-voltage supply

System Test Results

Metrics #1 and #2Power Efficiency / Input Voltage Range

Test Overview• Connect Power Regulation Module (PRM) to:

– a Laboratory power supply– a test load

• Measure: – Power supply output current – PRM output current– PRM output voltage

• Calculate efficiency• Measurements repeat over the range of test loads

Metric 1• PASS = 80% efficiency over operating load and input voltage ranges• FAIL = < 80% efficiency over operating load and input voltage ranges

Metric 2• PASS = Regulated output within 5% of nominal Voutput for Vinput between 4.6V - 5.8V

• FAIL = Regulated output not within 5% of nominal Voutput for Vinput between 4.6V - 5.8V

PRMCurrentPRMVoltage

CurrentPSUVoltagePSUiencyPowerEffic

*

*

Metric #1 Power Efficiency

Metric 1• PASS = 80% efficiency over operating load and input voltage ranges• FAIL = < 80% efficiency over operating load and input voltage ranges

PRMCurrentPRMVoltage

CurrentPSUVoltagePSUiencyPowerEffic

*

*

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

0 200 400 600 800 1000 1200 1400

Series1

Series2

Series3

Series4

Series5

Series6

Series7

Series8

Series9

Series10

Series11

Series12

Series13

Metric #2 Input Voltage Range

Metric 2• PASS = Regulated output within 5% of nominal Voutput for Vinput between 4.6V - 5.8V

• FAIL = Regulated output not within 5% of nominal Voutput for Vinput between 4.6V - 5.8V

3.290

3.295

3.300

3.305

3.310

3.315

3.320

3.325

3.330

0 2 4 6 8 10 12 14 16 18

Ou

tpu

t V

olt

age

(V

olt

s)

INput voltage (volts)

Output Voltage vs Input Voltage

280 mA

300mA

310 mA

325 mA

340 mA

570 mA

690 mA

880 mA

1210 mA

Metric #3Guaranteed Operating Time

Test Overview• The Power Regulation Module (PRM) is connected to a test load.• connect a charged Ni-MH battery pack• Measure energy consumed after 30 minutes

Metric 3• PASS = After 30 minutes, no more than 2/3 battery capacity is used• FAIL = After 30 minutes, more than 2/3 battery capacity is used

Metric #4Provides Mounting Points to Vehicle

Metric 4• PASS = Product provides mounting holes to accept mounting hardware. Holes are predrilled, or a surface is

designated for drilling for mounts. Mount is appropriate for attachment to flat surface.• FAIL = No mounting points are supplied, and there are no proper places to drill and attach the product to a flat

surface

Metric #5Total System Weight

Test Overview• Weigh total System

Metric 5• PASS = Product < 3 lbs in weight• FAIL = Product >= 3 lbs in weight

Final Weight (with IOB) = 0.76 lbs

Metric #6Operates over expected temperature

Test Overview• Heat running system to 38 degrees C, monitor for crashes or errors• Cool system as low as possible (-20C desired), monitor for crashes or errors

Metric 6• PASS = All sub-systems operate without errors for -20C to 38C• FAIL = System crashes while within desired temperature range of -20C to 38C

Metric #7Ports are externally accessible

Metric 7• PASS = System power and programming ports can be accessed without removing any part of the system

from vehicle• FAIL = System must be removed in some way to access ports

Metric #8Compatible Simulink Blocks

Metric 8• PASS = Model successfully builds, compiles, and runs on CCP• FAIL = Model can not be successfully built, compiled, and executed.

Metrics #9 and #10I/O Throughput / Control Processing Bandwidth

Test Overview• Run MAV II control model on CCP (1000Hz model)• Acquire IOC sensor data for UAV at 1000 Hz• Verify no errors

Metric 9• PASS = The IOC and I/O cores execute control model with throwing overflow errors• FAIL = The IOC or the I/O cores overflow when data request rate is 1000 Hz

Metric 10• PASS = The CCP does not throw any overflow errors during code execution at 1000 Hz• FAIL = The CCP throw overflow errors during code execution at 1000 Hz

Metric #11Non-volatile storage for control code

Test Overview• Upload compiled Simulink control code to CCP• Reboot CCP and see if model is still on system

Metric 11• PASS = The CCP boots and runs control code without re-programming• FAIL = The CCP is unable to boot and run control code without reprogramming

Metric #12Architecture bit length/accuracy

Test Overview• Connect power to IOB analog header• Request ADC value• Show returned value

Metric 12• PASS = ADC output is 16-bits• FAIL = ADC output is less than 16-bits

Metric #13System can use external data in control code

Test Overview• Run Simulink model with input looped back to drive one of the PWM outputs proportional to the input

value• Connect hobby servo to the PWM output on the IOB• Write a value to the shared memory, show servo move after each command (Mimics operation of

telemetry unit)

Metric 13• PASS = Manually-entered data successfully affects servo output• FAIL = External data cannot be used by control code processor

Metric #14I/O peripheral set is configurable

Metric 14• PASS = Types and numbers of I/O types are readily configurable in the user interface• FAIL = The user cannot change the set of peripherals attached to the system

Metric #15All source data is freely available and documented

Metric 15 (a)• PASS = The software and data used to construct the final product is openly available to the public. The

re-generation of the product does not require any software that requires a license to use, except the specific case of MATLAB Simulink RTW. Code format and commenting is clean and clear

• FAIL = The use or reproduction of the system requires the licensing of proprietary technology from one or more third-parties. Code is messy, uncommented.

Metric 15 (b)• PASS = The procedure can be reliably reproduced using the instructions in the documentation• FAIL = The product cannot be used with only the instructions provided

Metric #16I/O peripherals connect externally

Metric 16• PASS =Control Platform can be removed from vehicle without the need to also remove attached vehicle

sensors or other peripherals

• FAIL =Removal of the Control Platform requires the otherwise unnecessary removal of one or more of the other vehicle peripherals

Metric #17Physical Size

Metric 17• PASS = Total system package fits within the allocated space on Airframe C• FAIL = Total system does not fit in allocated space on Airframe C

Metric #18Provide interface to telemetry

Metric 18• PASS = Final design is demonstrated to be able to communicate via UART, and collaboration has taken

place to guarantee compatibility • FAIL = No provisions are evident to suggest that telemetry project hardware interface is compatible with

final product, or that UART is supported in general

Metric #19Non-volatile removable storage for logged data

Metric 19• PASS = Data is successfully logged to non-volatile, removable storage. More than 8.4MB of space is

available• FAIL = Removable storage is not supported, or is not capable of storing at least 8.4MB.

Metric #20Voltage ranges of analog sensor inputs

Test Overview• Monitor analog sensor inputs using terminal• Verify no clipping occurs in targeted range

Metric 20• PASS = UAV analog sensors are correctly read without clipping through full expected range of operation• FAIL = UAV analog sensor inputs cause clipping of input data that cannot be fixed or by an adjustment on

the I/O Breakout Board

Metric #21Number of analog channels

Test Overview• Test each analog sensor channel for functionality

Metric 21• PASS = Design supports the ability to connect and read at least 3 analog inputs• FAIL = Design supports less than 3 analog inputs

Metrics #22 and #23Protocols Supported / Concurrent Digital Peripherals

Test Overview• Each one of supported protocols is tested for functionality

– IMU: SPI bus– GPS: NMEA over UART

Metric 22• PASS = Device is capable of NMEA over UART (GPS) and SPI (IMU) protocols.• FAIL = Device does not support these two protocols

Metric 23• PASS = At least two digital devices (1x SPI + 1xUART) may be connected and used by the system

at the same time on the same mission• FAIL = Does not support digital peripherals, or only one may be used per mission

Metric #24Tool set necessary to disconnect vehicle peripherals

Test Overview• With IOB and IOC connect as when installed in the vehicle, disconnect the IOB and remove the IOC.

Metric 24• PASS = The IOB can be detached from the control platform using a reasonable limited set of standard

in-field tools (i.e., screwdriver, wrench, hand)• FAIL = Detaching vehicle sensors from control platform requires an extended toolset, and is unreasonable

to service in field.

Metric #25Control parameters, sensor data and system status

are externally accessibleTest Overview• Connect CCP, IOC, IOB• Program the CCP with a model with debug output• Read control model debug values from terminal• Read sensor data and system status messages from terminal

Metric 25• PASS = Debug values and sensor values are available from terminal• FAIL = Debug values or sensor values are inaccessible from terminal

Metric #26Manual Override

Test Overview• Connect control platform and R/C receiver to UAV IOB• Load CCP with a model that fluctuates servo outputs• With system enabled and override disabled, show CCP has control over output• Switch manual override on, and show manual control over output• Switch manual override off, show that CCP regains control over servos

Metric 26• PASS = Upon enabling override, the control servos stop responding to control code. R/C controller

has complete control over servo motion.• FAIL = Upon enabling override, the control servos fail to follow R/C transmitter inputs without

interference or sporadic behavior.

Product Successes

• Subsystems are physically and functionally separable– IOC can operate on its own– Interfaces between subsystems are not obscure and can be used by non-P10236 systems

• Robust• Exceeds performance specifications

– Power supply input voltage range is incredibly broad– IOC and CCP throughput exceeds initial specifications

• Easy for future developers to continue work– Highly organized repository structure– Detailed IOC system documentation

• Lots of potential– Wide variety of uses including non-vehicle applications– Has generated interest from several different groups at RIT

• Aero Club• Robotics Club• CSH• Various faculty at RIT

Product Shortfalls• Unable to fully integrate systems• Desired IOC SRAM performance was not achieved

– Timing constraints were overlooked causing slower operation.

• I2C capability not implemented• Power efficiency at nominal operating point is under 80%• Targeting DSP to execute control code was unsuccessful

– Time could have been better spent implementing GPP from the start

• System configuration user interface incomplete

Risk Mitigation• Layout errors

– Packages were manually checked to ensure that they match with footprint before board fabrication– FPGA package mismatch resolved with minimum productivity loss

• Joe continued assembly of IOC while Alex fabricated retrofit using DuPont Pyralux flexible PCB material

• Design mistakes– Team members constantly checked each other’s work to reduce possibility of design errors– Fine details of each subsystem and interface were discussed thoroughly and agreed upon

• Data Loss– Fanatically demanded each other to commit work to repository regularly

“If its not in the repository, it doesn’t exist!”

• Timeliness– Specifically designed around parts available to order

• ESD safety– Lab station equipped with ESD resistant mat– Consistently wore ground straps when handling sensitive equipment

Future Work• Second revision of IOC

– Fix package errors– Rework USB interface to include bus powered option

• Enhance IOC Rigidware– Implement I2C– Improve firmware robustness by implementing a watchdog timer and memory protection

• Second revision of IOB– 4-layer board to reduce size and improve noise immunity– IMU and GPS not mounted directly on IOB. Enables more optimal placement

• Implement Software interface for easy configuration• Adjust power design for better efficiency at operating point• Enable Simulink code processing on DSP• Finish developer level tools• UAV specific block set for Simulink• Build remaining boards and assemble final product.

Final Spending

PCB Proto and Fab $ 112.39

Components $ 388.45

Gumstix System $ 169.00

Gumstix Dev. Hardware $ 91.83

Total $ 761.67

P10236 Project Review

MSD Project 10236Configurable Control Platform

for Unmanned Vehicles

Project Review

Joe PinzoneAlex Mykyta

Roberto StolfaRobert Ghilduta

Jason Stanislawski

P10236 Project Review