Powered by an Anker 10amp-hr (why do they call it 10000mA-hr ? sounds so much bigger I suppose) battery pack, I took my RPi for its first parambulation, packed away in my backpack with input via the presenter and output via earphones. In this first usage I have a simple GPS tracker, logging the position periodically.With the presenter I can turn logging on and off, adjust the frequency of logging and add numbered markers to the log, with incrementing and decrementing the marker number. The resultant log can then be converted to kml. For added interest I can hear periodic reports of the speed and direction.
Here is an example track http://kitwallace.co.uk/gps/track8.kml . I wonder how much can be gleaned from this data?
A major change was to the menu code. The simple hierarchical menu system just doesn't work well for incrementing and decrementing, operations better suited to a more general directed graph. In the simple menu, on visiting an item we execute the associated action if any and stay on that item until another button is pressed to change the current item. I made a simple addition of a next attribute which if set determines the next item. For this target items need to have an id set. The result is something of a hybrid between a hierarchy and a statechart.
To control the logger and the progress talker, i needed an object that could be incremented and decremented and could be turmed on and off. The class Control does this, and this class is instantiated to provide a control for the logging, a control for the markers and a control for the speed reporting.
I needed a couple of iterations on the menu design. I also needed to handle errors due to bad NMEA sentences, and reader/writer clashes on the pickled objects. There is only one updater per object but multiple readers, especially of the GPS position object which is updated one per second (the cycle time of the RMC sentence). If a read occurs mid update, the read fails so I now retry a couple of times before failing. This hack seems to work but at some stage I need to rethink the whole IPC approach.
Code is here
The main problem is with the presenter input as it sometimes generates repeated keys. An alternative input device would be good to find. The presenter is rather fragile anyway, so I'm thinking a radio-linked glove device or something more exotic - I've just started a Coursera module on Bioelectricity so you can see where I'd like to go!