Gait Analyser and Wearable Movement Sensing Device

About.

The project aim is to create an innovative motion tracking device for different usages such healthcare, the RSL10 EVK board brings new possibilities by providing a complete solution ready to be used, simplifying the development. The focus is to track motion, one type been the gait analysis which is of interest to healthcare providers. Thou a final product is not realized, the work proof the product is viable and is a low cost solution alternative to available commercial products.

Gait Analyser.

The individual walking performance will vary and it has been noticed by physicians that certain diseases or conditions alters it such as in parkinson, strokes, orthopedic and in elderly individuals. There are many studies about gait analysis and it's association with those conditions, i.e. there is study showing an association between gait speed and survival in older adults (Studenski et al., 2011)

A very typical gait test is performed in a corridor, the distance might vary depending on the individual or healthcare provider needs.

RSL10 SENSE in a portable application.

The RSL10 SENSE EVK has all the sensors needed for the application, actually it has a few more than actually needed which might be beneficial in some applications.

Here is a brief of some of the on-board sensors.

The RSL10 SENSE EVK comes with a coin battery connector which makes it ideally for portable applications.

Fixture.

The EVK board is tiny and as every electronic device is delicate and sensitive to damage by incorrectly handling, to minimize a possible damage during tests a small 3D container was done.

With the aid of a hook and loop fastener the 3d enclosure can be fitted into a person shoes for example, but other body parts are also possible.

Software.

This device can easily be commercially but it will need a hard work on a custom software which is not the aim of this project. Here the aim is to speed up development and help in the research of gait analysis by using latest technology from ON and Bosch company. For the software I decide to use MATLAB as it allows easy connectivity and has all the post-processing tools to analyze it.

The firmware used is the Custom Service Protocol Firmware available from the SDK examples as sense_ics_firmware.

MATLAB has a Bluetooth Low Energy communication library that is very convenient to use, your computer has to have a 4.0 BLE adapter, you can connect with a BLE device by doing

b = ble(Address);

where address is you BLE RSL10 address. In my case I found that address by previously running the blelist command

After you connect using the ble command, the characteristics can be known

The characteristics can be displayed as well

To query and receive data from the sensors we use the two custom characteristics seen above, we setup this by doing

rxc = characteristic(b, "E093F3B5-00A3-A9E5-9ECA-40016E0EDC24", "E093F3B6-00A3-A9E5-9ECA-40026E0EDC24");

txc = characteristic(b, "E093F3B5-00A3-A9E5-9ECA-40016E0EDC24", "E093F3B7-00A3-A9E5-9ECA-40036E0EDC24");

We haven't modify the firmware, thou a real product will need modifications, the default configuration is enough to get 5 samples per second which is ok at this point.

But in order to receive data in Matlab, a callback function was implemented, this will run in the background to attend data received. We can install the callback by doing

subscribe(rxc);
rxc.DataAvailableFcn = @displayCharacteristicData;

where displayCharacteristicData is the function

function displayCharacteristicData(src,evt)
    global i;
    global dv;
    global gv;
    [data,timestamp] = read(src,'oldest');
    c = char(data);
    cs = split(c, '/');
    packet = char(cs(1));
    switch packet
        case 'A'
            acc = split(cs(2), ',');
            dv(i, 1) = str2double(acc(1));
            dv(i, 2) = str2double(acc(2));
            dv(i, 3) = str2double(acc(3));
            dv(i, 4) = i;
        case 'G'
            gyro = split(cs(2), ',');
            gv(i, 1) = str2double(gyro(1));
            gv(i, 2) = str2double(gyro(2));
            gv(i, 3) = str2double(gyro(3));
            gv(i, 4) = i;
        otherwise
            disp('not implemented response-reception');
        end
end

It's difficult to understand the reason of the switch cases above without understanding how the data is query and received.

I have previously setup a segger RT viewer console to see the output of the debug statements, then run the android demo application, the idea is to get an insight of how the query and parse is done.

In the code below it can be seen how the accelerometer and gyroscope command parsing is implemented. The variables are arrays of 4 rows, the three first rows contains the X, Y and Z components of acceleration and gyroscope, the last one is just an index that keep track of the sample received.

The sample code is written to allow sampling for a given period of time and then stop, the samples are requested every 200 ms n this case.

record_length = 60;
sample_rate = 5;       %samples per second.
rsamples = record_length*sample_rate;
i = 1;
dv = zeros(10,4);
gv = zeros(10,4);


disp('start acquisition loop');
% request data every sampling period
while true
    write(txc, 'A/AO/A');               % accel data
    %     write(txc, 'G/AO/AR');        % gyro data
    if(i > rsamples)
        return;
    else
        pause(1/sample_rate);
        i = i + 1;
    end
end

To allow faster sampling a modification to the firmware is needed, since the sensor is already configured to interrupt every 1/5 of a second. A extract of this is shown below, this is located in file CSN_AO.c

retval += BHI160_NDOF_EnableSensor(BHI160_NDOF_S_LINEAR_ACCELERATION,
CSN_AO_SensorCallback, 5);

In this case 5 is the sample rate per second. Increasing the sampling rate is necessary but it's also necessary to test how fast it can go without compromising the data, in this case we are sending a BLE query to the custom characteristics every 200ms but as it goes faster this might give some problems. So a better approach might be to rewrite the custom characteristics to hold a few samples in a buffer and transmit them at once every 200 ms. In this case the callback function CSN_AO_SensorCallback is key to start that modification.

But back to our test, after running a capture using 60 seconds we got an array of 4 rows with 300 samples on each.

After plotting the accelerometer data of some movements I did on the RSL10 board with my arm.

The data is expressed in samples counts not in a physical quantity. I tried to convert to m/s2 by using the following formula.

dvmod = (dv/32768)*4*9.80665/3.2808;

It seems the raw value has to be scaled further to get m/s2, not 100% sure but if the value is in ft/s2, the values makes more sense. In the above formula, numer 4 is the dynamic range.

Gait data acquisition.

A small walk was done to capture accelerometer and gyroscope data in a similar way.

Conclusions.

The project shows how feasible is to have a low cost platform to study gait pattern and in general movement of human body. It can be portable, the SDK example is a good starting point for further modifications.