Archiv für den Monat: Dezember 2009

ifgi StudentsDay

Our project was successfully presented on the ifgi StudentsDay last week.  After a Hack-Lab in the morning, where our team worked on some bug fixing and further development, we had a stand and a poster about the GeospatialLearning@PrimarySchool project.

On the stand, visitors could test our applications on the XO-Laptop and we had a first look on Usability issues. We had a small survey on some development issues concerning Usability and mapping issues. The results are being proceeded by now, they will be implemented into further software devlopment and tested on the first tests in school, to be announced.

Cooperation with OLPC Learning Center in Rwanda

It is already two weeks ago that Martina Forster (ESRI Germany) and I met the OLPC team in Kigali/Rwanda, which is led by OLPC’s vice president David Cavallo. They are supporting Rwanda’s OLPC activities and set up a Center for Laptops and Learning, which aims to serve the educational and learning needs of countries across Africa. It is a tremendous challenge and they are doing a great job!

We discussed the ‘geospatial’ issue and our ideas and goals about developing XO-activities as a means to playfully learning basic concepts like position, direction, distance..

We soon realized, that we’re working on the same idea and that a closer cooperation would yield significant benefits. We agreed to integrate our field studies with schools in Rwanda into their OLPC camps next year. Furthermore we will collaborate both in the conceptual phase and in the evaluation of the field tests. This helps us in terms of organizational issues and is of benefit for the OLPC project as we are providing new elements into the educational program.

So we’re looking foreward to our OLPC camp in Rwanda, which is preliminarily scheduled for April 2010 now.

Some more screenshots

For this I’d like to present a new screenshot. As you remember the first shots were taken showing OpenLayers embedded into a gtk widget via hulahop.

Now I’d like to show a different approach using one of the great tile servers offering rendered OSM data. Have a look at implemented functions like navigation and zooming. Also note the crosshairs (showing current WGS84 lon/lat coordinates). It is also possible to jump to the current location (if GPS connection is available of course).

Crosshair and lon/lat coordinates

Crosshair and lon/lat coordinates

If GPS signal is available, jump to it by simply clicking a button.

If GPS signal is available, jump to it by simply clicking a button.

Hacknight the 2nd

As I mentioned here some results from the Hacknight we had on the 3rd of December. We were three groups (2–3 people each), one playing around with the OLPC server, another one which tryed to work out the collaboration stuff and the third one which targeted to integrate GPS positioning in the application.

Here a short summary of each group:

OLPC Server

Target was to investigate if the OLPC XS is capable to act as a Tile@Home server. Tile@Home is similar to the classic SETI@HOME where you were able to share CPU time with NASAs efforts in searching for extraterrestrial life when your computer was in idle state. Well, we’re not really  interested in extraterrestrial life (at least that night ;-)), but wondered if XS has enough power to act as an OSM tile server. The main idea evolves from the fact that internet is not a safe thing in rural areas. If there is an internet connection, the school server could share it and all XOs would be able to download tiles from servers like the mapnik tile server. But if there is no internet connection, the server could either

  1. has cached all tiles (of interest) or
  2. even calculate its own tiles from a local OSM database.

Both possibilities are quite  interesting.

However, to simplify the work we decided to concentrate on the caching variant. For this we set up a small server script delivering tiles which are already cached on serverside. See on the Hacknight Twiki for some code.

Collaboration

Getting connected with other XOs is important to create a colloborative game. The second group wanted to find out more about the sharing functionality of an ativity. For this, we created a small activity reading out information about other XOs connected to the mesh network.

Nicknames,  Hashcodes and other attributes could be read out. Unfortunately, no exchange of custom data could be established at the Hacknight. Nevertheless, the basic steps and experiences were made we can build on.

GPS/Position Integration

Location is essential and probably the most importatnt thing when communicating and mediating geospatial conciousness. Running the great GPS daemon gpsd (for now we’ve to start it in the terminal, but it wouldn’t be too hard to start it from python, I guess), we extract the gps info via python gps module and keep it up to date every three seconds:

<br />
#!/usr/bin/env python<br />
import os<br />
import gps<br />
import time<br />
import logging</p>
<p>import utils<br />
import constants</p>
<p>LOGGER = logging.getLogger('position-logger')<br />
utils.init_logging(LOGGER)</p>
<p># this prepares for intended start of gpsd from terminal (e.g. gpsd /dev/ttyACM0)<br />
_FILE = open(os.path.join(constants.CONFIG_PATH, 'gpsdevice'))<br />
_DEVICES = [dev.strip() for dev in _FILE.readlines() if not dev.startswith('#')]<br />
if len(_DEVICES) != 1:<br />
    LOGGER.warn('Check your gpsdevices config file.')</p>
<p>try:<br />
    GPS_SESSION = gps.gps()<br />
except:<br />
    GPS_SESSION = None #IGNORE:W0702<br />
    LOGGER.warning('Could not initialize GPS session.')</p>
<p>###################################################<br />
class GPSReceiver():<br />
    """Receives GPS signal from gpsd Daemon.</p>
<p>    TODO There is a dbus alternative. . .<br />
    """<br />
    def __init__(self, gps_infos):<br />
        """Creates GPS_SESSION."""<br />
        LOGGER.debug('Create GPSReceiver.')<br />
        self.result = gps_infos</p>
<p>    def get_position(self, query='admosy'):<br />
        """Gathers the current position information."""<br />
        try:<br />
            GPS_SESSION.query(query)<br />
        except:<br />
            LOGGER.error("No GPS connection possible. ")<br />
            raise StopIteration, "No GPS connection possible. "<br />
        if GPS_SESSION:<br />
            self.result['latitude'] = GPS_SESSION.fix.latitude<br />
            self.result['longitude'] = GPS_SESSION.fix.longitude<br />
            self.result['utc'] = GPS_SESSION.fix.time<br />
            self.result['altitude'] = GPS_SESSION.fix.altitude<br />
            self.result['eph'] = GPS_SESSION.fix.eph<br />
            self.result['epv'] = GPS_SESSION.fix.epv<br />
            self.result['speed'] = GPS_SESSION.fix.speed<br />
            self.result['climb'] = GPS_SESSION.fix.climb<br />
            self.result['satellites'] = GPS_SESSION.satellites</p>
<p>            if self.result['latitude'] == 0 and self.result['longitude'] == 0:<br />
                # wait if gps has not been initialized yet.<br />
                LOGGER.debug('wait for connection')<br />
            #LOGGER.debug(self.result)</p>
<p>###################################################</p>
<p>if __name__ == '__main__':</p>
<p>    infos = {'latitude'  : 0.0,  # WGS84 latitude<br />
             'longitude' : 0.0,  # WGS84 longitude<br />
             'utc'       : None, # UTC time<br />
             'altitude'  : 0.0,  # m over sealevel<br />
             'eph'       : 0.0,  #<br />
             'epv'       : 0.0,  #<br />
             'speed'     : 0.0,  # current speed<br />
             'climb'     : 0.0,  #<br />
             'satellites': 0     # #satellites<br />
             }</p>
<p>    recvr = GPSReceiver(infos)</p>
<p>    for i in range(0, 100):<br />
        recvr.get_position()</p>
<p>        print 'latitude    ' , infos['latitude']<br />
        print 'longitude   ' , infos['longitude']<br />
        print 'time utc    ' , infos['utc']<br />
        print 'altitude    ' , infos['altitude']<br />
        print 'eph         ' , infos['eph']<br />
        print 'epv         ' , infos['epv']<br />
        print 'speed       ' , infos['speed']<br />
        print 'climb       ' , infos['climb']<br />
        print infos['satellites']</p>
<p>        time.sleep(3)<br />


Hacknight

On Thursday we had out Hacknight. I’d like to give some results and impressions of that event, but the fact that I closed the door at ~3.30 am tells me that it was quite successful. Honestly, I didn’t expect more than 5 participants (in fact we were 9 participants). However, I’ll split the summary of the Hacknight in two posts, this one about the plan, preparations and what some problems we had. A second one will tell s/th about results we made and the next steps.

We started at 5 pm with some introductory words and gave an idea of OLPC, the activities in Rwanda and our own project. After a short Python intro, a coarse idea of how Sugar and activities are wired together was procured. We didn’t get into details here, because we had some special challenges to investigate which mostly hadn’t to much dependency to Sugar. These challenges were:

  • Collaboration: Exchange some status data
  • OLPC Server: Setup an XS to serve as OSM tile server
  • GPS: Positioning and tracing
  • Openlayers & Co.: Javascript and Python communication

This is definitely not an exhaustive list, one could investigate when new to OLPC, Sugar and activities, but enough for one event, I guess.

For the first part we setup a development environment on the notebook of each participant. This was a bit more combersome I expected. We installed a Fedora system with sugar on a portable VirtualBox which we then copied on each machine. With a zipped 2.5 GB file not to fast, though. Unfortunately on some machines it didn’t run at all :(. After all, installing VirtualBox and using the harddisk from the portable one worked.

I created an eclipse package with yoxos which is a tool to create an eclipse package containing all plugins, preferences, settings etc. you might want to use for a project with several participants. Stupidly, it did not fulfill some security issues the Fedora system required (I’m not a Fedora geek), so we had to install it from sources with appropriate plugins (which is not too hard, thanks to these great package manager systems).

Sugar and Emulator was already installed on the virtual harddisk so we only had to checkout the project code and link it in the ~/Activities directory. Yes, I could have done this on the virtual harddisk before, though, .. touche. At least,f or the next time the environment is prepared ;-).

The next post will give a summary of some results we made.