OpenShoe

Today I did some ten 10 min­utes walks around our lab (the film runts at x20). Some bet­ter, some worse, noth­ing cen­sored. Two MIMU22BT mod­ules on the top of the forefeet and a Sam­sung Galaxy S3 Android phone were used. Step-wise iner­tial nav­i­ga­tion and wire­less trans­mis­sion of the steps to the phone where the dead reck­on­ing was per­formed. No mag­ne­tome­ters, only accelerom­e­ters and gyros. Fusion of the two dead reck­on­ing sys­tems on the phone.

The shown tra­jec­to­ries are rather benign. Plain walk­ing in a bounded area will cer­tainly not stress the sys­tem but I hope it gives you a feel­ing for the per­for­mance of the mod­ules dur­ing a rea­son­ably real­is­tic sce­nar­iou and not a worst case sce­nar­iou (straight line) which I would typ­i­cally use to assess the performance.

I did 5 walks, charged the mod­ules, and then did 5 more walks. I let the mod­ules warm up for 20 min­utes before the walks. Yes, the mod­ules can give worse per­for­mance dur­ing warm-up.

The map is man­u­ally adjusted to the first lap of the tra­jec­tory. No per­fect fits. Dif­fi­cult with clumsy fin­gers on a small screen. I did not want to adjust it after the first lap since it would be cheat­ing. The bars around the edges of the screen indi­cate 5 meters. The build­ing is roughly 15x50 meters. Con­se­quently each walk is around 700m.

The mod­ules were cal­i­brated a few hours before the walks.

Why 10 min­utes? Well, we have a lim­i­ta­tion in our Android soft­ware which means we can plot at most 10 min­utes of his­tory. Also, over 10 min­utes, the errors are rea­son­ably small such that the results don’t look too messy. Note that the earth rotates some 2.5° over 10 minutes.

What you see is a play­back of what I saw dur­ing the walks. That’s why you see a charg­ing sym­bol every now and then. Simul­ta­ne­ous screen cap­ture would require four arms or reli­able WiFi over the floor. I had neither.

New updates, new bugs.

In test­ing the updated code at the end of last week I expe­ri­enced some strange behav­iour. It turned out to be a sub­tle issue with the manip­u­la­tion of the process sequence. The result was poor ini­tial (first time after power on) per­for­mance for the dead reck­on­ing. In the worst case sce­nario it could give errors in the order of a meter for the first steps. The bug had been around since the revi­sion from 16th of Jan. Now it’s fixed in revi­sion 15f969 and I rec­om­mend to upgrade if you are using the dead reck­on­ing com­mand (0x34).

I’ve also made a few other updates. The only impor­tant one from the user per­spec­tive is that I’ve moved the func­tions which read data from the IMUs to the process sequence. This is to get more flex­i­bil­ity, and really there is noth­ing spe­cial about this func­tion so it fits bet­ter in the process sequence than beside it. The imu_read() func­tion is in the process sequence by default and it has been added to all com­bined com­mands. Con­se­quently, from the user inter­face per­spec­tive, the dif­fer­ences are small. How­ever, if you are man­u­ally manip­u­lat­ing the process sequence, you will have to take into account that the imu_read() func­tion should prob­a­bly reside in the first slot in the sequence.

The plan is to spend part of this week on test­ing, revis­ing and refac­tor­ing the code so more updates may come. How­ever, the revi­sion of the com­mu­ni­ca­tion pro­to­col was a one-time thing and I do not plan on mak­ing any sig­nif­i­cant changes there.

A new and improved cal­i­bra­tion script is avail­able below. First of all, you do not longer have to man­u­ally ver­ify data from each side of the cal­i­bra­tion body. Con­se­quently, the pro­ce­dure is much faster. Sec­ondly, the script is adapted to the recent updates to the embed­ded code. If you change the com­mands and the pars­ing mex-file to those of the old script pack­age, you could use it with an old mod­ule with­out repro­gram­ming it, but then it’s prob­a­bly bet­ter to sim­ply repro­gram your mod­ule. Thirdly, it comes with a brief instruc­tion video:

Zip-file with cal­i­bra­tion script pack­age. Down­load and run main.m.

MIMU_calibration

(Note: if you do not use 64-bit win­dows you will have to com­pile the .cpp file with mex com­man in Matlab)

(Note: Your mod­ule will work with­out any cal­i­bra­tion. How­ever, it will pos­si­bly work bet­ter with it.)

GT-Silicon (who are build­ing and sell­ing com­plete Open­Shoe mod­ules) have a lot of resources related to the mod­ules on their home­page. You can find them at:

www.inertialelements.com

Not many updates here lately, but a larger num­ber of updates in the repos­i­tory. Dur­ing the last month, I have revised, com­ple­mented, and cleaned up pri­mar­ily the com­mu­ni­ca­tion pro­to­col. I’ve even writ­ten some doc­u­men­ta­tion! The bad news is that the com­mu­ni­ca­tion pro­to­col has changed slightly but keep­ing the messy order of com­mand IDs seemed even worth. The com­mu­ni­ca­tion logic is the same but some com­mand head­ers have changed. Any­how, this should not be too big of a prob­lem since now you can find all com­mands described in the fol­low­ing document:

OpenShoe_communication_protocol

Just to sum up, the sig­nif­i­cant changes are:

1. There are now a two byte pack­age num­ber in the pack­ages com­ing over the USB inter­face, just like it has always been for the Blue­tooth inter­face. The long term inten­tion is to con­nect the inter­faces much tighter. Now they only sig­nif­i­cant dif­fer­ence is the lack of a “loss­less” mode for the USB interface.
2. A num­ber of com­mands have new headers.
3. A num­ber of new com­mands have been added to make the pro­to­col more complete.
4. Sup­port for the old­est gen­er­a­tion of Open­Shoe mod­ules (those based on the AD16367 IMU) have been removed.

To make get­ting started with the mod­ules eas­ier I have also com­piled a num­ber of Mat­lab scripts which I use. These scripts demon­strates the basic usage of the mod­ules. You find the scripts below:

OpenShoe_Matlab_scripts

Some of the scripts rely on mex-files. The C++-code is included but it has only been com­piled for 64-bit Win­dows. If you are run­ning some other OS, you need to com­pile those functions.