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.

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)
Language	Files	Code	Comment	Comment %	Blank	Total
java	2737	227551	102476	31.1%	61095	391122
xml	1814	87627	5470	5.9%	3134	96231
xmlschema	418	69194	8743	11.2%	753	78690
javascript	423	41392	9386	18.5%	5096	55874
html	429	19675	580	2.9%	2025	22280
css	86	8697	619	6.6%	1951	11267
sql	10	7289	246	3.3%	168	7703
xslt	47	3092	636	17.1%	569	4297
php	2	600	110	15.5%	102	812
bat	11	575	22	3.7%	166	763
scala	5	552	35	6.0%	99	686
python	29	544	786	59.1%	419	1749
shell	18	502	95	15.9%	99	696
make	6	356	24	6.3%	78	458
Total	6036	467707	129228	21.6%	75759	672694

Cloc gives similar numbers off by a few thousand and separated by csh vs bash. Ohcount could do with some more shell script discrimination.

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.



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.



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
version:        2.3.0.4
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.