Between hardware difficulties, our drivers’ developpement has gone forth, and it has been one week now since our codec has begun to work, playing songs and recording sound. Our FRAM was functionnal much sooner, and Bertrand has implemented the ChibiOS BaseChannel interface on our SPI driven microSD card, so that it couldn’t be easier to write the recorded sound to it, and stream WAV, MP3 and Ogg Vorbis files from it. The last lacking driver is for the push buttons, but it has been written by Guillaume and should need only a bit of debugging.
The main program structure which will support our applications is also on the way, we have all it needs to exchange ZigBee messages between our modules, parse them and internally dispatch them to the right threads… Well, as it is there is only one thread needing to exchange data with other modules, and our dispatching thread can seem a bit useless, but our idea of what Maestrose will perform next week is meant to evolve and, well, if this small thread remains pointless, discarding it shouldn’t be a big matter.
The next big deal for us will be time synchronization through ZigBee. In fact I had begun working on it before some more important matters required my attention, and here too there’s some debugging to do.
Maestrose, coming soon…
Back to this algorithm deriving the modules’ repartition based on the whole set of distances in between.
It is now implemented, and thoroughly trialed. It has taken some transformations for the results to be comparable to the (pseudo-random) entries, but let’s come to the jist of it.
For the first time in this project’s (and its precursor’s) history, I have the great honor and the deep pleasure to write these two words (and one exclamation mark, which is the bare minimum) :
It works !
Which is more, I now understand why. But our hardest difficulties still stand beyond us, and measuring the distances data isn’t the least of them. It is very likely that it be the greatest, in fact, not to mention that the aforementioned algorithm demands that every module see each other, which can only be if they all stand at less from 100m from each other.
One step is still one step, and tomorrow shall bring the next !
Our greatest problem here is to find a way to determine, based only on ZigBee exchanges, first approximate distances between our modules, spaced from at least something around one meter, then their positions relative to one another (though it’s perfectly clear that with nothing mor than distances, relative positions will be defined up to any rotation and/or symmetry).
After one week spent rummaging through various studies announcing with more or les enthusiasm their rather disheartening results (mostly a wide error range, the use of many anchors, and often total dysfunction indoors), I finally stumbled upon this one, where inaccuracy is countered by the use of many channels (all channels internationaly offered by IEEE 802.15.4 and ZigBee, in fact). It comes down to an error of less than a meter, and even less than 30cm, for distances ranging up to 5m (if I remember well) between nodes, which is quite exceptional.
If this precision would by itself satisfy our needs (though better would still be appreciated), the method still isn’t perfect, since it uses 2n+1 anchors in a n-dimensional space. In our case no anchor should be used, and I am now trying to understand how all of that works together (while previous studies seemed so simplistic, this one is quite tough), and where anchors intervene, to see if we can make wiithout them and what it would then cost. But right now, I still don’t figure out why the method is presented as based on IEEE 802.15.4 (and even ZigBee, if I’m not mistaken) while all I can see is either pure mathematics or pure RF, so I gather it will take time for me to understand the whole thing.
In parallel, I have found in the appendices of a panorama study an heuristic to derive relative positions of the modules from their relative distances. It seems quite simple (nothing harder than to diagonalize a real symmetric matrix comes into play), and not silly, until the last step, which seems quite dubious to me. Indeed, since the method gives a vector far too wide for what it should mean, we simply throw away its least significant components. Before believing that has any chance to work, I have to implement it and see for myself.
So there’s work to do… Well, that’s what we’re here for !
Success is the ability to go from one failure to another with no loss of enthusiasm.
Sir Winston Churchil
After our last project’s failure (Miss you, DHEXTROSE !), we embedded on a brand new one, and here it is :
Audio modules able to synchronize so that the sound heard by one of them, or drawn from a (micro)SD card, could be propagated as a sound wave accross space, always spreading to the nearest neighbours first. They shall also operate as a network of audio sensors performing observations.
We began today to consider which components our modules would comprise. Here is what we could settle :
- a surface transducer
- a MP3 codec
- obviously, a microphone and a battery
We still have to choose a ZigBee module microcontroller (for instance a STM32). Few calculations being needed, our choice willl primarily being guided by autonomy considerations. I’m also told introducing an amplificator between the codec and te speaker would be relevant.
Today, we lowered our objectives to somewhat more modest ones – as an initial goal, to be merrily exceeded !
And don’t laugh, it took some doing
Behold the frame on which we’ve set our bleeding hearts for our tender Daredevil HEXapod Trekking for ROSE, in the whole of our ignorance !
More of her here, have a look at how supple she is ! (And intelligent, but that part will be up to us.)
Obviously, that’s a she…
Guillaume C., Aurélien M., Bertrand M.