OpenShoe

As you might have seen the page tree in the menu has been grow­ing a lot as the doc­u­men­ta­tion has been added and became quite hard to nav­i­gate in. There­fore I took it away and replaced it with a smaller menu and hyper­links within the pages.

We set out yes­ter­day to tune the sys­tem but it was more dif­fi­cult than we first had expected. It turned out that the ini­tial poor per­for­mance was not a mat­ter of para­me­ter set­tings but rather of numer­i­cal problems.

It showed out that the sys­tem worked per­fectly (apart from some small bugs which were dis­cov­ered in the process) when com­piled for dou­ble pre­ci­sion (64-bits floats) but hade prob­lems when com­piled for sin­gle pre­ci­sion (32-bits floats). It worked fine with sin­gle pre­ci­sion for some old data that we used when ini­tially cod­ing the sys­tem. How­ever, when run with the new data, recorded from the cur­rent sys­tem, the covari­ance val­ues went bananas. The main dif­fer­ence is that the new data come in at 819[Hz] in com­par­i­son with 250[Hz] for the old data. The process noise scale with f^-2, where f is the fre­quency, while we do not scale the mea­sure­ment noise with time. This means that the ratio between process noise and mea­sure­ment noise decreased with roughly a fac­tor 10. For some rea­son this made the sys­tem unhappy run­ning on sin­gle precision.

Unfor­tu­nately we can only make hard­ware float­ing point oper­a­tions with sin­gle pre­ci­sion so the fact that it worked fine with dou­ble pre­ci­sion did not help much. We have started the work to pin down the numer­i­cal prob­lems but this far still with­out luck. How­ever, tweek­ing the para­me­ter val­ues we could still make the sys­tem run just fine. Here’s a sam­ple of what the sys­tem can do this far

The plot is of me (JO) tak­ing a turn in the cor­ri­dors of our depart­ment build­ing. The plot was dis­played in real-time on the lap­top used to receive and record the sys­tem posi­tion estimates.

Of cause, after hav­ing the fist Open­Shoe unit assem­bled, we were eager to try it out. Our spe­cial made shoes are cur­rently at the shoe­maker for some minor repair but for­tu­nately we hade some old trashed exper­i­ment boots which we could fit the unit in. Below you see that first (real-time) plot pro­duced by the sys­tem dur­ing the first walk by JO around the lab:

The axis are in meter and the posi­tion out­put was only 4[Hz]. As you can see the first plot was a real lucky shot, almost the exact same start and stop posi­tions. The fol­low­ing longer walks gave vary­ing per­for­mance. How­ever, we have only roughly tuned the sys­tem para­me­ters with visual inspec­tions of the out­put of the sys­tem on the desk­top, so after all we were very sat­is­fied.
Foto of the place­ment of the Open­Shoe unit in the trashed exper­i­ment boots

Yes­ter­day evening we finally got the cas­ings. There were some minor issues with tol­er­ances but after some hours with a file and some sol­der­ing of cables we finally got the first two full Open­Shoe units assembled:

The box is (includ­ing lid) 27.5x40.5x32[mm].

Really the assem­bly is not com­plete yet. As you can see there is no screws in the lid. Those, together with insets which will go in the holes in the box, we will hope­fully get tomor­row. Cur­rently we are solv­ing the prob­lem with some tape around the box.

A Mat­lab script repos­i­tory has been added under our Sor­ce­Forge account. This is for easy inter­fac­ing and test­ing of Open­Shoe. Cur­rently there is only a sin­gle script for record­ing data to a binary file but as soon as we have time to clean up and com­ment all other scripts that we have (e.g. for real time plot­ting of posi­tion), we will move them over to the repo.