MSD P10236

TOP SECRET

PRODUCT TEST PLAN/ VERIFICATION RESULTS

Configurable Control Platformfor Unmanned Vehicles

Metrics #1 and #2 – Power efficiency / Input Voltage Range

Equipment 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)

Setup

  1. Connect PRM input leads (+/- DC Input) to Lab Power Supply
  2. 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).

Test

  1. Set Power Supply to 1V and Test Load to 5 ohms
  2. 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 load
  6. 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

Test

  1. Charge Ni-MH battery pack.
  2. Connect 3.3 ohm resistors to 3.3V and 3.6V output rails
  3. Connect 10 ohm resistor to 5.0V output rail
  4. Connect battery pack to PRM (will run at 9.4W)
  5. Run PRM at full power (9.4W) for 30 minutes
  6. Disconnect and recharge battery pack
  7. 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 Weight

Equipment Required

  • Scale (Range 0 – 3+ lbs)

Test

  1. Weigh total system (Platform Assembly + IOB)

Results

System weight = 0.76 lbs

Criteria Metric 5

  • PASS =Product less than 3 lbs in weight
  • FAIL =Product more than 3lbs in weight

Metric #6 – Operates over expected operating temperature

Equipment 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

Test

  1. Put system into enclosure
  2. Initiate Simulink Model Execution
  3. Add heat from heat gun into enclosure until temperature reads 38C
  4. Monitor system I/O through Terminal, note any crashes or errors
  5. 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

Discussion

Could 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 accessible

Test [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 Blocks

Equipment Required

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

Setup

  1. Install CCP_GPP tool-chain
  2. Prepare Simulink Model containing all blocks to test
  3. Configure IOC and Sensors to make data available to CCP (use UI)
  4. Connect

Test

  1. Run C-code generator in Simulink Real-Time Workshop using ccp_gpp.tlc tool-chain
  2. Link compiled model I/O blocks to parameters using the UI
  3. Compile / Load the model and configuration to the Control Platform
  4. Run code on Platform – monitor model parameters through IOC USB port

Results

The tested Simulink model is shown below.

Discussion

This 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 Bandwidth

Test

  1. Connect UAV IOB, CCP, and IOC
  2. Load UAV IOB peripheral drivers
  3. 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 / Discussion

Due 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 code

Equipment Required

  • CCP Module with programming cable

Test

  1. Upload compiled Simulink® control code (50kB+ in size) to CCP FLASH storage
  2. 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/accuracy

Equipment Required

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

Setup

  1. 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 value
  2. 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 code

Equipment Required

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

Setup

  1. Load a simple Simulink® Model with one input that is looped back to drive one of the PWM outputs proportional to the input value
  2. 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 input
  2. 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 configurable

Test

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 documented

Test [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

Results

Below 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

Discussion

All 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 externally

Results:

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 telemetry

Equipment Required

  • Computer with Terminal
  • IOC

Setup

  1. 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 IOB
  2. Attach signal generator to IOB analog input
  3. Load and execute SD Data-logger driver and test program into IOC
  4. After test completion, remove SD card and plug into computer
  5. 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 inputs

Test [demonstration]

  1. Connect UAV IOB to CCP
  2. User Terminal test program to monitor each analog sensor input
  3. 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 channels

Test [demonstration]

  1. Connect signal generator to one ADC input channel
  2. Use Terminal to verify that data can be read from that channel
  3. 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 Peripherals

Test [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 IOC
  3. 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 peripherals

Test [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.