Skip to content

Designing a test suite for the apparatus

The prototype device will need to be tested. Here is a potential idea for a test suite.

Architecture

Simulink and KiCad SPICE can be used to test the mechanism's architecture before anything is printed.

Sensors

Before integrated testing, each of the 25 sensors will need to be tested independently to ensure no faulty components are supplied. This will involve sending the appropriate polling commands to the sensors and reading the returned data. The error conditions for each sensor should also be known so that the software can enter an error state upon detection. Accelerating the device to test its IMU measurements may be necessary.

Record:

  • sensor I2C address (should be unique to each sensor type)
  • Write/poll command (may need to write more than once if data is too long)
  • Read command (may need to read more than once if data is too long)
  • Error conditions (multiple)

Most sensors can accept a range of supply voltages (around 1.7 to 3.6V) so should be able to use voltage bus or the microcontroller as a voltage source. At this point the DC power bank can be used as a constant voltage source before batteries are implemented. The best and worst-case power consumption can help inform the sizing of the battery.

Software

Due to the independent nature of the boards, it is possible that fewer boards than 5 can be tested at once, with one board running multiple sensors. A failure can be simulated on one board and the device can be tested to check the contract passing routine. The contract return system can also be tested in the same way. Once more boards are integrated, then the 'circle of responsibility' can be tested, whereby upon error, the faulty board passes its queue to the next microcontroller while it resets. The newly reset board will need to perform a series of self-checks on itself. For this to work, it will need to poll the sensors it was previously polling ('ghost contract queue', data is not sent to main telemetry) and perform the same error checks on the microprocessor's calculations. If there is no error, then the board can request its contract queue back from the board that it was sent to. This contract return system may be too complex to implement, so another idea is to have the faulty board lay permanently dormant.

Possible routine (pseudocode)

A queue object Q representing the contracted sensors, updated using interrupts A list of I2C addresses e.g. Accelerometer = 0x68 (every micro has the same list) Variable error for error state?

while(errorState=1){
address = Q.poll() // poll from head of queue, represents address
sensorError = i2c.writeto(address,code) // send polling code to address (may need to look up code in a table)
if (sensorError = 0) { // writing error
    errorRoutine("write error")}
sensorError = i2c.readfrom(address,code) // send polling code to address (may need to look up code in a table)
if (sensorError = 0) { // reading error
    errorRoutine("read error")}
Then maybe send a command to put sensor into idle mode?
Q.add(address) // add address to the tail of the queue
}

Power

A DC-DC converter such as the buck, boost, or buck-boost converter may be used to step up or down the voltage from the battery. There will be no solar panels used in our design so the energy management system does not need to be as complex. Performing a full charge-discharge cycle will help inform the battery life and expected longevity of the flight controller device. The battery could be tested under difference operating temperatures as well, although care should be taken. This was performed in RESE322 week 4 laboratory, although most batteries did not show any change in current output under low temperature (cooled by dry ice at -30 degrees C). The multimeters found in CO249 would be useful. Redundant batteries can be connected in parallel, and can add and remove batteries in testing. We may also implement battery fault protection for extra safety.

Edited by Ellie Wright