Wednesday, May 25, 2011

Dragging Geotools kicking and screaming to OSGi land

Me and others have been making some noise on the Geotools list to convert the current modules in Geotools from being only modules in name to proper OSGi bundles with services being published for use by other bundles and packages being imported and exported cleanly.

There seem to have been several attempts to osgify the Geotools mud-ball with only the bits the users needed to get things done being taken care of and hard bit, particularly those using the Sun ServiceLoader interface being left out.
  1. Classic example from Harald Wellman currently hosted on Berlios
  2. Argeo attempt - Mathieu is putting the OSGi modification back into Geotools core
  3. Humboldt project - Same idea using Bnd.

There are 2 solutions to the META-INF/services dilemma (introduced by the classloader separation inherent in OSGi)
  1. A bundle lifecycle interceptor that picks up all the SPI based services and converts them to OSGi service.
  2. A compile time mangler that does the same conversion and adds OSGI-INF/*.xml for the services.
The reference factories being registered look pretty nice in ASCII art.

The other issue plaguing the migration of geotools is the presence of split package, another ripple from the OSGi classloader per bundle approach. There are various hacks to solve this, but none of them is quite neat. As a stop-gap package can be merged using the split directive in the manifest or via Bnd.

Hope the transformation will be over soon and we will have truly modular Geotools.

    Saturday, May 14, 2011

    Counting code - Ohcount vs Cloc

    We have lots of evil csh which we want to convert to bash or even perl or python. So I decided to test some code line counting tools to estimate the effort involved in terms of pure lines of code. I tested 2 options: the old and venerable cloc and the child of web 2.0 ohcount. Like the definition of the metre, what constitutes a line of code can vary a bit.
    Ohloh Line Count Summary
    Examining 16633 file(s)
    LanguageFilesCodeCommentComment %BlankTotal
    Cloc gives similar numbers off by a few thousand and separated by csh vs bash. Ohcount could do with some more shell script discrimination.

    Sunday, May 1, 2011

    Bringing back an old favourite - the Butteruino

    After I had done some damage with AVR's bought from Dick Smith in 2002 on a breadboard, I moved onto the butterfly. I did a mini project measuring waterflow using thermistors for GroGuard. Then they lay disused in boxes until recently. I ordered a carrier board from Ecross and put together a handy proto-typing platform, except the serial port on the butterfly I have seems to be obstinately broken.

    What could have been the #arduino , bring back the butterflies

    This did not stop me from getting some software together for loading code onto it. Since everybody has caught the Arduino fever. I decided to go with Wiring and the Arduino IDE to develop for the butterfly, fortunately the Butteruino project has already done a lot of the hardwork for me, I just upgraded the changes to v22 of the Arduino IDE release. The patch should go live on SVN soon. Till then if you have a butterfly and want to test it with the Arduino IDE get it here.

    Now the assembled carrier will lie in boxes till I work up the courage to order some more old butterfly's from Digikey.
    In spite of all their peripherals and fancy demo code, the butterflies suffer from the weirdness of the joystick, lack of FTDI for direct USB connection and overall fragility. Still they are excellent for long-term, low-power data logging applications, may be coupled with an Xbee. I believe given slightly different design choices, a better IDE than AvrStudio, no funny press the reset button and pray code uploads, the butterfly could have beaten the Arduino back then. I will look into making the flow sensor again once I get my hands on a working butterfly and develop some more Eagle skills.

    Making wheel under the cameras - Beagle has 4 wheels

    All the work with stereo vision and kinect hackery is of not much use without obstacles to sense and avoid. Hence the beagleboard is now mounted on 4 DC motors driven by the DFRobot Arduino Romeo board. The robot base is quite sturdy aluminum and has plenty of pre-drilled holes, but to mount the beagle I had to acquire my first rotary tool set.

    Stereo vision robot taking shape I wish the wireless drivers on beagle were easier - ralink 2870 meh

    ASUS is coming out with the PC version (Xtion PRO) of Kinect soon, which will be smaller than the original and will not have the RGB camera, it will also be purely USB powered. Perfect opportunity to use it along with the stereo vision cameras to increase the depth of field and build a platform which can use vision indoor and outdoors and in complete darkness, by combining the sensors.

    Next comes getting data from the camera out wirelessly with sufficient bandwidth. I have the Beagle working with 3G modems, but this was going to be a first with a Ralink 2870 (which I got el-cheapo at DealExtreme) . With Koen's advice I decided to use the rt3070sta, the modinfo makes is obvious that this is going to work with the card:

    root@beagleboard:~# modinfo rt3070sta
    filename:       /lib/modules/2.6.32/kernel/drivers/net/wireless/rt3070sta.ko
    license:        GPL
    description:    RT2870 Wireless Lan Linux Driver
    author:         Paul Lin

    It does not like pumping dhcp at boot time so I have to go the long way and pull it up with ifup later on. The usual gstreamer tricks work fine for sending the camera streams around:

    In the beagle - gst-launch v4l2src device=/dev/video1 ! queue ! videorate ! video/x-raw-yuv,framerate=15/1 ! videoscale ! video/x-raw-yuv,width=320,height=240 !  ffmpegcolorspace ! jpegenc ! udpsink host=x.x.x.x port=xxxx

    In the laptop - usr/bin/gst-launch udpsrc port=xxxx ! jpegdec ! autovideosink

    Next comes pan-tilt and actual object avoidance and object following. Pass the dog a ball.