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