Joined: 01 Jan 2001
Posts: 3232
Location: Reading, UK
Posted: Thu Jan 12, 2006 11:30 am
Post subject: Logical Genetics Patent Walk Logger
Skene reminded me that if we're going to be doing the long walk again this year, I'm going to have to think about getting the GPS logging thingy working. Since I was ill yesterday, and therefore not bothered about doing PhD work, I had a quick go at fixing the problems I'd been having with the system and managed to get it working.
So, I now have a system which can run for 24 hours or so on 4 rechargable AA batteries, during which time it logs time and position readings to an MMC card at two second intervals.
The next step is for me to work out how to make it talk to Skene's laptop, so we can dump the data file onto the longwalk website and display it on a Google Map jobbie. This shouldn't be too hard, since it already does USB networking with a Linux host. Or we could just borrow an MMC reader!
So it looks pretty promising really. USB Gadget interfacing jobbie and a box is all that's needed...
But, what else could we add to it to make it better?
What benefits does a walker look for in a walk logging system?
A quick look at the Gumstix Website should give you an idea of what hardware's available. I doubt there's much call for an ethernet version, but perhaps some sound recording would be handy? Or some way of linking photo stops or blog entries with geographic goordinates?
I was very keen to synchronise the photos with the map last time (although in the end didn't even manage to get the map). It occurs to me that we could do this pretty simply as long as we use cameras that will timestamp the photos. Then we can just work out where we were at the time. I'll have to look at my camera, and Jo's to see if this is possible, and it might involve some minimal additional programming for the map interface. I know you can add markers with data to Google maps though, so it should be doable.
I'm also quite keen to replace daily reports (which in practice don't get written, or are only written long after the walk) with short audio blogs recorded at the end of the day. Dan mentioned that he was going to take his camera, so we could use that, although we'd probably have to seperate the soundtrack from the pictures to save space on the website.
Joined: 01 Jan 2001
Posts: 1514
Location: Oxford, UK
Posted: Thu Jan 12, 2006 1:41 pm
Post subject:
well im up for the walk again, thou im not sure what technical assistance i can supply other than the loss of hubcaps
_________________ "Dear Buddha, I would like a pony and a plastic rocket"
Joined: 01 Jan 2001
Posts: 3232
Location: Reading, UK
Posted: Thu Jan 12, 2006 1:55 pm
Post subject:
Photo timestamps are stored in the exif header in the pictures my camera takes (and no doubt your cameras are similar), but I never bother to set the time on the camera after it gets left without batteries for any period of time, so I've never used the information before. There are also issues with this information being corrupted when the image is sized or editted before being uploaded to the website.
As far as I know, the coppermine gallery software gets the exif information out and stores it in it's database so, as you say, we should be able to add markers (like these) by matching the timestamps of the pictures to the timestamps from the route data. Implementing a click-through interface, and/or popping up the image thumbnail in the speech-bubble-popup-thingy should be pretty darned simple.
As for audio, I don't really know how to do it. Recording audio, converting it and uploading it is hard. Well, not hard but time consuming. Since, generally, we managed little more than eating and sleeping after each day's activities I don't know if getting anything out of the video camera would be realistic, until we've got home. Some kind of dictaphone device which records audio and packages it ready for uploading to the website might be a good idea, but might also be hard to do.
Expanding on what I said about video, it might also be a bugger to get people to unload all their photos at the end of each day. Don't know how real-time the website should be, but the more real-time we want it, the more work needs to be done each day
Another thing I might do is look at how simple it would be to get the gumstix talking to a phone, so uploading can be done without the need for a PC. That'd lower the effort in that department.
I wasn't really considering uploading stuff while we are on the walk. What we need to do though is make it as easy as possible to get the website up to scratch once we get back. What happened after the last walk was that nobody could be bothered (with the possible exception of Jo, who posted some reports on her own blog), so the website was left in disarray, rather than being a nice record of what we did. Perhaps I just need to be less lazy, but things like gathering some audio on the way will mean no need to write up long reports etc.
Joined: 01 Jan 2001
Posts: 3232
Location: Reading, UK
Posted: Thu Jan 12, 2006 3:16 pm
Post subject:
That makes the whole thing easier then, both in terms of logging stuff on the GPS dodah and amalgamating everything into some kind of coherent report on the website at the end of the walk.
I'll look into how easy (and how cheap) it'd be to get the gumstix recording sound snippets and see what I can do about that. There might be problems with storage though, since it won't do MP3 encoding easily...
Any other ideas about cool stuff to record and things to do while on the move would be greatly appreciated.
Joined: 01 Jan 2001
Posts: 3232
Location: Reading, UK
Posted: Fri Jan 13, 2006 12:25 am
Post subject:
OK, I now have the walk-logger in a position where I can do a beta test. Unlike with the Alpha test (the walk I did with my Dad last year) I should be able to trust the gumstix to start everything up of it's own accord as soon as I plug in a freshly charged set of batteries - no need to use a serial console to start things up.
At the moment the Gumstix, GPS and batteries are safe and secure in a large heavy metal box I borrowed from work. As well as being pretty shock resistant it's also water resistant (to some standard or other) so it's basically the first version of the future Land Rover tracking device, almost ready to be bolted under the bonnet The case is far too big and bulky to be carried around on a walk though. The next step is to get it all into a hat.
The pictures show the case and the internal gubbins. The 10p coin is for scale. The light-green board in the background is a taped up old PCB which I'm using to mount everything; only the dark green, piggybacked Gumstix PCBs, the mostly-hidden GPS module and the four AA batteries are required to make it work (in fact, three batteries would do).
I'll slap the whole thing in the car tomorrow and log my route to work, just to make the GPS side of things more interesting. The batteries should last more than long enough to log the entire day.
Joined: 01 Jan 2001
Posts: 3232
Location: Reading, UK
Posted: Sat Jan 14, 2006 6:17 pm
Post subject:
The beta test was a success in (almost) every way!
Here's a screenshot from Google Earth of the route data. The yellow line is the route to the office from home and the green line is the route home via Richard Tarrants house in the East Side.
Halfway through Friday, while the GPS sat ticking away in the car, Dave walked up to me in the office to let me know that Google had released new satellite imagery for the Reading and Newbury area that morning. A very lucky coincidence indeed. Instead of seeing the lines plotted on a fuzzy lime green blur it's possible to actually see our car, shed and garden umberalla, as well as the Johnson-Mobile parked up in the office carpark. We think the imagery is about two years old and was, judging by the locations of our cars, taken on a Wednesday or at about 09:15 on a weekday morning.
I'm repeating myself when I say this but I don't care: Google are great
DT
PS: The almost refers to the fact that I may have nuked the MMC card by writing to it too often. Some alterations to the code needed there I think.
Joined: 01 Jan 2001
Posts: 1514
Location: Oxford, UK
Posted: Sun Jan 15, 2006 9:01 pm
Post subject:
highy impressive
shame they still havent updated oxford yet, you can just about make out the ring road but that about it
_________________ "Dear Buddha, I would like a pony and a plastic rocket"
Joined: 01 Jan 2001
Posts: 3232
Location: Reading, UK
Posted: Sun Jan 15, 2006 10:25 pm
Post subject:
That's the puppy
A little south of Newbury is the Greenham Common airbase, formerly the longest runway in Europe and home to some still-classified ground launched nuclear missile bunker jobbies.
Joined: 01 Jan 2001
Posts: 3232
Location: Reading, UK
Posted: Fri Jan 20, 2006 12:34 am
Post subject:
Johnson and me had a bit of a chat about the walk logger today. Basic plan for a development PCB and a cool name for the project were decided upon.
The PCB won't exactly be small. Probably about 100mm x 100mm or so, depending on the box we choose, which is a bit big but will provide plenty of space for wiring extra stuff up. Some of the things included will be...
* Gumstix
* GPS module
* Console port connector and RS232 drivers
* Voltage regulator and associated power gubbins
* Various "Customer Reassurance LEDs"
* Connector for the little phone screen (in transit from the USA now)
* Backlight driver for above
* Three push buttons for simple user interface (up, down, OK)
* USB client socket for connection to an XP machine
* Assorted solder pads and headers to break out the i2c bus and various GPIO lines etc
There's probably other things that'll get glued on there too but I've forgotten about them.
As for the name, Johnson suggested "Klog". Based on "Blog", but it's for logging walks, not the web. Geddit?
Joined: 01 Jan 2001
Posts: 1514
Location: Oxford, UK
Posted: Fri Jan 20, 2006 9:18 am
Post subject:
im guessing its probably best to have a non square pcb, as it will make carrying it about somewhat easyer
_________________ "Dear Buddha, I would like a pony and a plastic rocket"
Joined: 01 Jan 2001
Posts: 3232
Location: Reading, UK
Posted: Mon Feb 20, 2006 1:23 am
Post subject:
Spent hours this weekend manipulating my aged, spade-pointed soldering iron over the delicate surface of the Gumstix "Waysmall" daughterboard. I'd started to get pretty sick of having to attach hundered of spaghetti-like wires between Waysmall and various peripherals and the effort of tracing where all the wires went was starting to be greater than that of writing drivers and stuff. A hand carved chunk of Veroboard and three miles of ribbon cable later I've gone from spaghetti to tagliatelli...
Note the cool new peripherals for the Klog(tm) though. The jogwheel (currenty sporting a stylish thermostat knob) and three colour LED are both working nicely, complete with working drivers. The screen is so close to working it's painful. Johnson's found me a slightly more appropriate case too. Though it is one of those "I built this in School" style Maplins jobbies, it's still better than the 27Kg metal thing I've been using up 'til now (see above).
Anyway, the hardware's coming on well. All I need to do now (once the screen's working I mean) is hone the GPS logging software and work on some kind of UI.
Joined: 01 Jan 2001
Posts: 3232
Location: Reading, UK
Posted: Mon Mar 06, 2006 3:28 pm
Post subject:
Took the Klog out for a walk to Henley on Sunday, all packed up in an ugly plastic box. Managed to log most of the journey, but it crashed at some point (just as we left Lower Shiplake in fact) and stopped logging.
I haven't set up the watchdog timer yet, so when it crashes it stays crashed. I'm not 100% sure why it died, but I know it died on a pretty low level, since the LED device driver stopped working and the console was unresponsive when I plugged in a serial line.
One problem might be my GPS logging software, which seems to be very CPU intensive, for no apparent reason. It tends to knock the CPU usage up to about 1.7 (170%), which can't be good really. There are some things I can do to the software to stop that. At the moment it's doing silly stuff when it polls the gpsd server. Hopefully that'll stop the Gumstix crashing.
If all else fails then crashes like this should be easy to deal with using the watchdog, which would cause a reset after 60 seconds of inactivity.
The most annoying problem with the whole project, however, has nothing to do with the temperamental nature of the platform, but with either my GPS module or gpsd. Basically there is a problem with the current month number. The GPS reports different month numbers at seemingly random times, which has something to do with the fact that two month standards are used by the GPS system, one which is zero-based (January = 0) and one which is one-based (January = 1).
So when I log the path to the database, every few samples the time switches backwards and forwards by exactly one month. Currently, the CGI application which converts database data to KML uses the following query...
select longitude, latitude, timestamp from positions order by timestamp
The result of which is two almost identical journeys, one in March (say) and one in February. The two journeys overlap on the map and it gives a very odd effect. Lord knows what would happen if I tried it in January, as some samples would claim to be in month 0 and would probably blow up the date functions.
Adding one to the month number would solve the problem, but unless it's January it's impossible to know when to add one and when to add nothing, because it's equally impossible to know what date standard the GPS thinks it's using.
Currently I have no idea how to solve the problem. Syncing the Gumstix clock and using that would be one option, but there's no backup power for the real time clock so it'll forget as soon as it's powered down. Of course, I could use the GPS to set the clock on startup, but that'd just get me back to square one; how would I know what month it is?
I'm sure I'll come up with a solution, but I doubt it'll be an elegant one
On a more positive note, I've made quite a few leaps forward in terms of data storage. The relational database stores loads of route data and some info on satellite positions, signal strengths and suchlike. Also, the USB networking is working, so I can plug the Klog into my Win XP machine and bridge it to my home network. The webserver on the Klog has been set up to serve up my noddy Javascript/Google Maps page and uses a CGI app to read dynamic KML data and display the map. So with a Klog, a broadband connection and a little mucking about with Windows network settings it's now a usable (albeit buggy) system. Horray!
Sparkfun's GPS datalogger uses the same GPS module as the Klog and logs everything to a text file, which you can read by pulling out an SD card and plugging it into a card reader. They also do a "sort of KML" mode, though it seems to require some cutting and pasting activity.
Of course, their logger doesn't run Linux, so it's not half as extensible as the Klog, but it is a damned sight cheaper
What about taking the average month value for your entire period of capture and then rounding it up or down?
The only problem with this would be if you were walking out at midnight on the 31st of a month......
Joined: 01 Jan 2001
Posts: 3232
Location: Reading, UK
Posted: Wed Mar 08, 2006 1:12 pm
Post subject:
That's a good plan actually. It's a little more complicated, since another aim of the Klog is to log Johnson's Amazing Africa Drive, which is going to take more than a couple of months - during which time the logger's going to be on 24x7. Obviously, taking an average here is going to be confusing.
Given that there are two possible situations...
* The reported month is correct
* The reported month is actually last month
It'll need to do something like select the maximum month number from all the samples recorded since midnight on the 1st day of this month. That's slightly ambiguous, because we don't know what this month is, but you get the idea! More specifically, we record the last 100 (say) valid samples from the GPS and take the maximum month number in our list of samples as being the current month. If the list contains a month transition (day number goes from high to low at any point in the list of numbers) we only use the samples recorded after the transition point. Geddit?
That means that any month errors will only happen for a maximum of 100 seconds or so after midnight on the first of the month. There are no doubt ways we can fix that too.
Joined: 01 Jan 2001
Posts: 1514
Location: Oxford, UK
Posted: Wed Mar 08, 2006 1:41 pm
Post subject:
if anything i would say that its a software problem in gpsd. have you come accros anything on newsgoups etc?
i also have another posible workaround. does the stix have a working onboard clock? it doesnt have to be masivly accurate, but u could use that to determin the month and override what the gps is saying
_________________ "Dear Buddha, I would like a pony and a plastic rocket"
Joined: 01 Jan 2001
Posts: 3232
Location: Reading, UK
Posted: Wed Mar 08, 2006 2:02 pm
Post subject:
As I mentioned somewhere in my million word essay in a previous post, the Gumstix clock is pretty accurate, but not battery backed up when it turns off, so the same month problem apears when trying to set the clock after a reset or power loss.
The bug's in the firmware on the GPS module I think.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Profile
FAQ
Calendar
Log in
Register
Calendar
The case is far too big and bulky to be carried around on a walk though. The next step is to get it all into a hat.
