MSD P10236TOP SECRET

PRODUCT TEST PLAN/ VERIFICATION RESULTS

Configurable Control Platformfor Unmanned Vehicles

Note: Many instructions in this test plan assume that the test engineer possesses the knowledge of how each sub-system connects to each other and how the product is programmed and used in general. This is done to avoid the numerous and ultimately wasteful reiteration of highly detailed instructions that will be published in the detailed user guide for this product. Any reader who is not familiar with the product must consult the detailed user manual and become familiar with the product in order to assume to be able to perform these tests.

(The detailed manual will still be a work in progress at the time of the evaluation of this test plan, but when published, it will be available for download on the project EDGE website.

http://edge.rit.edu/content/P10236/public/Home).

Metrics #1 and #2 – Power efficiency / Input Voltage RangeEquipment Required

Lab Power Supply (Rating of 0-5V @ 4.5+ A, 5-17V @ 1+ A) and lead wires Multi-meter (DC Amperes) and probes Oscilloscope ( 1MHz+) and probes Test load (range from 1 ohm – 5 ohms)

Setup1. Connect PRM input leads (+/- DC Input) to Lab Power Supply2. Connect test load and multi-meter to PRM output in series configuration.3. Connect Oscilloscope test probes across PRM Output (parallel with load and meter).

Test1. Set Power Supply to 1V and Test Load to 5 ohms2. Record Power Supply output current (readout on unit)3. Record PRM output current (multi-meter)4. Record PRM output voltage (RMS from oscilloscope)5. Increase load by 1 ohm, repeat steps 2-5 up to 1 ohm load6. Increase power supply voltage by 1V, repeat steps 1-5 up to 17V

Notes Power Efficiency = (PSU Voltage * PSU Current) / (PRM voltage * PRM current) Calculate efficiency for all data points taken during test

Results

Criteria Metric 1 PASS = 80% efficiency over operating load and input voltage ranges FAIL = less than 80% efficiency over operating load and input voltage ranges

Criteria Metric 2 PASS = PRM Voltage Output within 5% of nominal voltage output (3.3V, 3.6V, or 5V)

for all input voltages between 4.6V and 5.8V

FAIL = PRM Voltage Output not within 5% of nominal voltage output for all input voltages between 4.6V and 5.8V

Metric #3 – Guaranteed Operating Time

Equipment Required Power Regulation Module (2) 3.3 ohm Power Resistors (1) 10 ohm Power Resistor Ni-MH battery pack Digital Ni-MH charger with charge energy reading

Test1.Charge Ni-MH battery pack.2.Connect 3.3 ohm resistors to 3.3V and 3.6V output rails3.Connect 10 ohm resistor to 5.0V output rail4.Connect battery pack to PRM (will run at 9.4W)5.Run PRM at full power (9.4W) for 30 minutes6.Disconnect and recharge battery pack7.Note the recharge energy in mA-hours.

Notes The PRM maximum output power exceeds the maximum possible power consumption

of the entire system by a large margin. Therefore, although this test does not involve running the actual system, it WILL result in the extreme worst case operating time.

Results

Discharge Rate Battery used after 30 minutes % Battery used (of 2500mAh)

2.5 A (Output power 9.4W / 0.8 efficiency) 1148 mAh 46%

1.7 A (Output power 4.8W / 0.6 efficiency) 830 mAh 33%

Criteria 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 #4 – Provides Mounting Points to Vehicle Chassis

[Test by Design]

Criteria Metric 4 PASS = Product provides mounting holes to accept mounting hardware. Holes are pre-

drilled, 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 #5 – Total System WeightEquipment Required

Scale (Range 0 – 3+ lbs)

Test1. Weigh total system (Platform Assembly + IOB)

ResultsSystem weight = 0.76 lbs

Criteria Metric 5 PASS = Product less than 3 lbs in weight FAIL = Product more than 3 lbs in weight

Metric #6 – Operates over expected operating temperatureEquipment Required

MonoKote® Heat Gun (for model aircraft) Freezer Box or other enclosure to fit whole system Computer with Terminal (for serial communication) USB Cable, Power cable for IOC Temperature sensor connected to IOC through IOB

Setup Power ON Control Platform Connect to IOC via Terminal through USB cable Load Platform with Simulink Model

Test1. Put system into enclosure2. Initiate Simulink Model Execution3. Add heat from heat gun into enclosure until temperature reads 38C4. Monitor system I/O through Terminal, note any crashes or errors5. Put system into freezer, note any crashes or errors

Notes Because it is difficult to find a freezer to -20C, test may not be feasible to that low of a

temperature. Verify as low as possible with test, supplement with theory. System will report any device communication errors, and in general, data can be

monitored for ballpark expected range. It is impractical to take this too far.

Results

Maximum tested temperature 49C

Minimum tested temperature -8C

DiscussionCould not find a viable way to test lower than-8C at this time. All electronics are rated better than -20C, so no problems are anticipated.

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

Metric #7 – Power and Programming ports are externally accessibleTest [Inspection]

Verify that programming port and power connectors are accessible without removing the product from casing or removing the casing from the vehicle

Criteria 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 #8 – Compatible Simulink BlocksEquipment Required

PC running MATLAB Simulink™ and Terminal, with USB cable to IOC

Setup1. Install CCP_GPP tool-chain2. Prepare Simulink Model containing all blocks to test3. Configure IOC and Sensors to make data available to CCP (use UI)4. Connect

Test1. Run C-code generator in Simulink Real-Time Workshop using ccp_gpp.tlc tool-chain2. Link compiled model I/O blocks to parameters using the UI3. Compile / Load the model and configuration to the Control Platform4. Run code on Platform – monitor model parameters through IOC USB port

ResultsThe tested Simulink model is shown below.

DiscussionThis Simulink model, as well as a few other test subjects, were all successfully built, compiled and executed on the CCP. At this time, none of the Simulink blocks have been found not to work. This drastically exceeds our expectations and customer needs.

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

Metrics #9 and #10 – I/O Throughput / Control Processing BandwidthTest

1. Connect UAV IOB, CCP, and IOC2. Load UAV IOB peripheral drivers3. Run 1000Hz control system on CCP ( i.e. MAV II model)4. Verify no errors thrown to Terminal monitor

Notes The CCP and all sensor test driver will throw overflow errors if the requested control

cycle execution or data transfer rate exceeds their limits. These errors are specifically for the testing of these two metrics. If no overflow errors are seen, control model speed is slow enough for proper execution, and this spec is met.

Results / DiscussionDue to limitations in available testing time, the system was only tested at exactly 1000Hz. The product meets this specification, however, more testing should be done to find the full maximum capability of the system.

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

Criteria 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 #11 – Non-volatile storage for control codeEquipment Required

CCP Module with programming cable

Test1. Upload compiled Simulink® control code (50kB+ in size) to CCP FLASH storage2. Reboot CCP without programming cable connected

Criteria Metric 11 PASS = CCP boots and runs control code without re-programming FAIL = CCP is unable to boot and runs control code without re-programming

Metric #12 – Architecture bit length/accuracyEquipment Required

Computer with Terminal Power Supply (capable of 3.3V output) IOC and IOB Modules

Setup1. Connect power supply to one of the IOB analog headers (+ / - inputs)2. Set power supply output to 3.3V

Test [demonstration]1. Send Terminal request for ADC value2. Show that maximum value is 0xFFxx (16-bits)

Criteria Metric 12 (a) PASS = ADC output is 16-bits FAIL = ADC output is less than 16 bits

Metric #13 – System can use external waypoints and data in control codeEquipment Required

Computer with Terminal IOC, IOB, and CCP with USB programming cable Hobby servo

Setup1. Load a simple Simulink® Model with one input that is looped back to drive one of the

PWM outputs proportional to the input value2. Connect the hobby servo to the PWM output on the IOB

Test [demonstration]1. Using Terminal, write a value to the shared memory for the model’s input2. Repeat [1] if desired, showing the servo move after each command

Notes The operation of the Terminal interface is identical to that of the UART interface of the

telemetry unit. Demonstrating that values entered from the terminal can be used to in the control code demonstrates that data input from an external source can be used in the control model by this method. Since the CCP can use the input data as any type of input (a waypoint, a sensor value, a command), the successful demonstration of this test is adequate to prove the ability of the user to use ANY external data in the control code.

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

Metric #14 – I/O peripheral types, numbers, and pin-outs are configurableTest

Using the designed software as in the user manual, create a profile for the UAV IOB, and link a sample Simulink model’s input and output blocks to the respective sensor values.

Results At the moment, the software back end for this feature is still in development. However,

anyone with knowledge of micro-controller GPIO behavior can, by inspection of the test code currently in place and lower-level demonstration, verify that peripheral types, numbers, and pin-outs can be set. The customer has seen that this functionality exists.

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

Metric #15 – All source data is freely available and documentedTest [Inspection]

Download a snapshot of the repository Check that all code is compliable and cleanly organized Check that code meets documentation standard Check for complete schematics and layouts of every board Demonstrate configuration and programming according to documented instructions,

show that no undesired software is required to use the final product

ResultsBelow is a complete list of the software used to develop, produce, and use the system:

MathWorks MATLAB / Simulink Eagle CAD (Schematic capture, PCB Layout) Xilinx® WebPack OpenEmbedded Tools Notepad++ GCC MIPS Compiler TCC (Tiny C-Compiler) TeraTerm

DiscussionAll of the software above, with the exception of Simulink, is either free or open-source software packages. Although some agreements disallow the direct distribution of the software, the programs are freely available for use to any person or company. Simulink is permitted as an exception, since it was specifically required that the system be capable of working directly with Simulink control models. It is notable, however, that Simulink is not REQUIRED – the user may also choose any language for programming that can be compiled for the Atmel A8 or generic MIPS processing core.

The requirement for a comprehensive user manual has not yet been met. Although documentation is in the works, the second part of this metric is deemed a failure due to the lack of the completion of this document at the official end of development.

Criteria 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.

Criteria Metric 15 (b) PASS = The procedure can be reliably reproduced using the instructions in the

documentation

FAIL = The product cannot be used using only the instructions provided

Metric #16 – I/O peripherals connect externallyResults:

IOB can be detached from the control platform by disconnecting the analog & digital ribbon cables as well as a power connector. IOB can remain in the vehicle without the need to disconnect peripherals individually.

Criteria Metric 15 [by Inspection] PASS = Control Platform can be removed from vehicle without the need to also remove

the 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 #17 – Physical Size[Test by Inspection]

Insert control system into Airframe C

Results:Final size of enclosure is 4.7L x 3.2W x 2.2H inches

Criteria Metric 12 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 #18 – Provide interface to telemetryEquipment Required

Computer with Terminal IOC

Setup1. Connect Computer to IOC via USB cable

Test [demonstration]1. Using Terminal, show that interface with IOC is possible (issue commands, read values)

Notes The Terminal interface is identical to the IOC as the telemetry group interface (UART). In

other words, the IOC’s ability to communicate with the computer Terminal is a guarantee that the telemetry interface will work when that system finally exists, and is ready for testing

Results:A UART terminal was used throughout the development process successfully to communicate with the IOC.

Criteria Metric 19 PASS = Final design is demonstrated to be able to communicate via UART, and

collaboration has taken place to guarantee compatibility and functionality

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 #19 – Non-volatile removable storage for logged data[Test by Demonstration]

1. Connect IOC and IOB2. Attach signal generator to IOB analog input3. Load and execute SD Data-logger driver and test program into IOC4. After test completion, remove SD card and plug into computer5. Verify data is written to SD card, and plot data in Microsoft Excel to verify accurate

reproduction of the analog input signal

Results:A 10Hz 0-3v sinusoidal input signal was successfully reconstructed from a log produced by the IOC.

Criteria Metric 19 PASS = Data is successfully logged 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 #20 – Voltage ranges of analog sensor inputsTest [demonstration]

1. Connect UAV IOB to CCP2. User Terminal test program to monitor each analog sensor input3. Verify that no clipping occurs in targeted range (1.8-4.5V)

Notes The voltage range of any analog sensor can be conditioned to meet the input

requirements of an ADC. Signal conditioning on that level is not necessarily part of a reasonable scope for this project, and is, therefore, the responsibility of the end user. However, demonstrating that the analog sensors for the UAV CAN be properly input to the system is the true goal behind this metric, and can therefore be verified.

Results:Analog sensor values for the UAV were successfully converted using the ADC.

Criteria 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 #21 – Number of analog channelsTest [demonstration]

1. Connect signal generator to one ADC input channel2. Use Terminal to verify that data can be read from that channel3. Repeat [1] and [2] for each channel

Results:All channels were successfully able to read analog data reliably.

Criteria 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 #23 – Protocols Supported / Concurrent Digital PeripheralsTest [demonstration]

1. Connect one of each type of digital peripheral (SPI, UART, I2C). In this case, the UAV IOB with connected SPI IMU and NMEA UART is ample. I2C is optional, and can be tested separately.

2. Load test driver for each device onto IOC3. Using Terminal, show that data is acquired from each digital sensor, and that both can

be connected and used without reconfiguration

Results:Multiple SPI and UART protocols have been tested simultaneously for functionality successfully.

Criteria Metric 22 PASS = Device is capable of GPS NMEA (UART) and SPI (IMU) protocols FAIL = Devices does not support both UART and SPI

Criteria Metric 23 PASS = At least two digital devices (1x SPI + 1x UART) 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 #24 – Tool set necessary to disconnect vehicle peripheralsTest [demonstration]

With the IOB and IOC connected as when installed in the vehicle, disconnect the IOB and remove the IOC.

Results:IOB can be detached from the IOC by disconnecting the analog and digital ribbon cables as well as the single power connector. This can be done in under a minute by hand.

Criteria Metric 24 PASS = The IOB can be detached from the control platform using a reasonably 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 #25 – Control parameters, sensor data and system status is externally accessible

Test [demonstration ] 1. Connect CCP, IOC, IOB2. Configure Simulink control program to output intermediate system values for debug3. Connect system to USB interface and program control system4. Read control model intermediate debug values from Terminal during code execution5. Read sensor data and system status message from Terminal

Results:Data has been successfully read from the shared memory and outputted onto the terminal.

Criteria Metric 25

PASS = Debug values and sensor values are available from Terminal FAIL = Debug values or sensor values are inaccessible from Terminal

Metric #26 – Manual OverrideTest [demonstration]

1. Connect control platform to UAV IOB2. Connect R/C Receiver to UAV IOB3. Load CCP with test control code to fluctuate servo outputs4. Connect at least one hobby servo to IOB PWM output5. With system enabled and override disabled, show that CCP has control over servo6. Switch the manual override ON, show that servos are now under manual control7. Switch the manual override OFF, show that CCP regains control over servos

Results:Test was conducted as described above. Toggling of override failed to switch servo control over to receiver control.

Discussion:Calibration of override circuit was attempted using the onboard potentiometer with no positive results. Further investigation is needed to debug the circuit. Circuit has been implemented in the past so it is likely that a manufacturing error has occurred.

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

transmitter has complete control over servo motion.

FAIL = Upon enabling override, the control servos fail to follow R/C transmitter inputs without interference or sporad