DUBwise UI over time

Today I got some amazing images for DUBwise for UAVTalk from a really cool and professional guy called grass man which enabled me to make DUBwise for UAVTalk look really sweet:

I am working on the mother project DUBwise since 2007 and this is the first time I like the appearance of it. I always had the problem that I cannot simply take free images of the web as DUBwise has this crude (but important for me ) non-military creative-commons licence-construct. Anyway seeing my baby in such a glance today inspired me to look back a bit. Starting with a small step back in time:

The above screen was the state after I came back from my trip around the world I tested all these shiny new UI Patterns like the popular pagers / dashboard / actionbar - was not feeling bad but needed attention from GFX-Pro's e.g. the connection indicator was just a drawColor ( green or red ) - the rest are images that "fit" which i took with my IXUS 80 - and my IXUS is much more like flying and taking pictures like these :-)
But it gets even worse. In Android beginning I did most stuff with ListViews and icons from android.R.drawable:

Now with big steps deep into the dark J2ME area. There I did nearly everything via an LCD+4way-input style interface but with light and dark theming - voice output and a lot of nifty useful things:

and finally this is the very beginning - just plain text writing values from the UAS ( MK at this time ) and the insight that the RC and the Mobile belong together:

DUBwise for UAVTalk

There is now a new Version of DUBwise - this Blog-Post intends to give some background and insight about this new thingy.

Why UAVtalk?

UAVTalk is an open protocol designed for communicating with UAVs. It is originated by the great OpenPilot-Project but can also be used in other projects. It is very efficient and flexible by using xml for the protocol description but raw binary values for transfer.

Why a new version?

To be honest, I tried to make the recent DUBwise speak UAVtalk but I failed badly. This has two main reasons: #1 DUBwise is grown wild over about 2 years and especially with its roots in J2ME and the MikroKopter Protocol. I have to confess that it has grown to a big and fragile beast. #2 When I really started the project I was on a backpacking trip to the other side of the world which consumed and is consuming a lot of my time and abilities.

I realised that way to late after wasting a lot of precious time walking in the wrong direction. But better now than never I started DUBwise for UAVTalk as a new project when I had the van all for myself for three weeks. What does that mean for the user:

- no J2ME support ( as this was the biggest problem with the DUBwise code base - perhaps I will do a minimal J2ME version when I have a week in a dark cellar, but just because my UAVTalk protocol code had J2ME still in mind and to justify the pain and uglyness of that )

- very limited functionality on the start ( The initial version in the market has only a UAVObject Browser and Audio Voice output - but even that little bit could help on the field so I am releasing it now as it is)

That is bad for the user on one side, but on the other it is better in the long-run because I also gain more flexibility and am not bound to old ideas. For the example of the Audio Voice Output ( StatusVoice ) this means that the user can not only switch on and off stuff that is spoken statically - he can also define text blocks which can contain UAVObjects that are spoken. That is a very flexible approach and so much closer to the flexible OpenPilot way of thinking.

Release steps:

I uploaded the version to the market and commited the rest of the protocol stuff to the OpenPilot repository. I released the protocol stuff ( juavtalk and juavobjects ) in their svn repo with "OpenPilot Team" as author and unter the GPL but I will stick with my non military cc license for the DUBwise code. I will publish the DUBwise code as usual on my github account - but I need to do a cleanup first and I am going to a 5day-ish backcountry hiking trip now, so there could be a delay with that and the reply from me - but are now probably used to that fact since as a backpacker now I am not on my PC 24/7 anymore at this moment ( will change ) ..

Forecast:

As I said for approx. 5 days I will be in the bush without equipment the next time, but after that I will try to reply to the feedback. After that I will build a screen to show an artificcial horizon and values. I will use the same mechanism I produced for the StatusVoice to pick UAVObjects to display. These are the two things which are used most in the MK-DUBwise Version so I will polish them first ( like adding conditions to the StatusVoice blocks ) before adding more features. It is getting colder and colder here in New Zealand so I think I will find more time for coding now.

tracedroid - send Stacktraces via Email after FC's on Android

This work is inspired by remote stacktrace for Android i played with recently. But after looking at the sourcecode I decided to do a total rewrite with these things in mind:

• main: Option to send the trace in other ways - e.g. share via email - pros:

1. no need for internet permission
2. having a email adress of the sender to contact the user after e.g. the bugfix
3. no problem when there is no internet at the moment
4. user is able to write some more info into the stacktrace mail
5. user can easily see what is send ( can be important with logging stuff ) and can delete parts of the log
   

• modularize ( diffrent send modules )
• small core ( only collecting stacktraces to files - nothing else )
• sending asyncronous to collecting - being able to send stacktraces when the user is more in the mood ( e.g. in wlan range )
• attach Logging info

the screenshot above is from gobandroid 0.46 which now includes tracedroid.

the sourcecode is on github

my first #barcamp - the #mcdd10

I noticed #mcdd10 in the context of the barcamp before droidcon. I heard about barcamps before but never digged deeper. But there is even a german wikipedia article about barcamps so it must be relevant and first hand impressions are always the best. Also the topic of #mcdd10 matched my interest as I am into mobile development and gave me the chance to experience one barcamp before droidcon which matches my interests even more.



The whole thing started @TU-Dresden with a self introduction of each participant by three tags to keep it short. I really like that idea - it blocks self exposers from ruining that and helps shy ones to do well here to.
My keywords where Android, J2ME and bluetooth. There where a lot of users with tags I disliked like mobile marketing or other stuff of which I don't think that it improves the world we live in - just stuff to make money with from my point of view. I somehow expected more developers there.
But my luck was that in the sessions which where highly interactive some devs showed up with interesting info. The first session was on how to bring mobile apps into corperations. The topic was not really my interest but it was interesting hear from *them* how many problems they have with closed platforms like apple. The big issue is deployment. They simply can't do what they want to do there - Jailbreaking is not an option for corperation use and the other way is through steve and he dont wants to play with them. This was my chance to promote open systems by telling them that it is possible with android to solve the deployment there easily and have noone between the user and you who decides if an app can be deployed.
The next session was all about blind people using mobile phones. First there was hands on an I-Phone with a screenreader. The touchscreen was used for input and voice synthesis for output. Nobody here was blind but the session-initializers said they made experiments with blinds and it is really useful for them. In the discussion some issues came up. It seemed not to be able to switch off the display even if you cannot use it like a blind one. You can only dim the backlight to a very low value and so drain your battery more than you have to. The second thing was that an physical keyboard would be great for entering long texts ( And Android has such devices ).
I don't want to review all the sessions here because this blog entry is getting too long otherwise but noticeable where brainstorming sessions. The start was done by one image and one written location for each group. Our image was frankenstein and our location was a nuclear power plant. Then we should write down ideas based on image and location very fast without a need for quality - only quantity was needed here. The second thing was to select one idea by putting stars on each group member's favorite idea. It was nice to see that my idea got by far the most stars. It was an app to show how far an nuclear power plant is away from your phones position. After selecting the idea we where told to improve it. Some nice Idea came up like morphing from your image to frankenstein based on the distance to the next power plant. The last part was to figure out how to make money with it this part was not my thing but nobody had a problem that i was quite there. Caused by the lot of company members there it felt like this was a cheap harvesting of Idea here but i had no problem with that because the idea was ethical and I don't have the time at the moment to do another project.
The session after that was based on the brainstorming before. It was all about making a video representing the idea. I thought videos making is taking long time. But the trick here was to improvise and give a very short deadline ( 30min ). Here are the results of the 3 groups:
* Barcoo
* SnackR
* Frankenstein

Possible flight spaces where limited on the location so i was not realy able to show up with my mobile-phone project but i did a small flight on the space on the picture below so that carying all the stuff around >20km by foot made at least some sense:


After all it was an very nice weekend. I had a lot of interesting communication - the sun was enabled all the time - got a lot of coffee there and Dresden is a very nice city. Special big up to the orga, my drivers and my friendly host - it all worked like a charm.

Styling geodata with POLYMAP3 ( LGPL GIS )

This is one of the Projects I did at Polymap - the Geodata-Styler:

Styling geodata with POLYMAP3 ( LGPL GIS ) from POLYMAP on Vimeo.

POLYMAP3 is developed under an open source license (LGPL). POLYMAP3 is based on Eclipse/RAP, OpenLayers, GeoTools, uDig and a lot of other great open source software components.

POLYMAP3 aims to provide a multi-user SDI platform. Supporting the power user with an ad-hoc data workbench, the admin user with configuration workbench and the end users with a simple to use web client and OGC services. UI is the web browser.

http://polymap.org/wiki
http://polymap.org

gobandroid GnuGo AI support

Based on the NDK part of Andreas Grothe' godroid I managed to add GnuGo AI support to gobandroid with v0.29
I'm more a java than a c guy and my time is very limited at the moment, thats why I had no time to dig into the NDK stuff - so special thanks to Andreas Grothe for the NDK work! I just had to make it work with NDK1.6 ( NDK 1.5 is not avialable any longer ) and change namings in the java bridge and it worked like a charm ;-)
Because gnugo is relatively big for an mobile application and not all users like playing a computer i splitted the GnuGo support to a diffrent apk which acts as a android service. This also opens the possibility to easily add other go AI's ( e.g. fuego ).

It's all GPL - here are the sources:
NDK Part
SDK Part

Gobandroid 0.22

Gobandroid can now load saved SGF's and has some review features now.



Also there is now QVGA support and a new Settings Screen where you can choose diffrent skins for board and Stones:

DUBwise with QMK Communicator

DUBwise can now ( V0.77 ) handle the Protocol wrapper from KeyOz for the QMK Communicator:

Gobandroid

When i got my first Android Phone ~2 months ago there was no goban for android yet - but i wantet some - so i started the opensource project gobandroid ( goban + android ;-)
I got a lot of feedback, that's one of the reasons why i am writing this blogpost. First of all thanx to the first contributor Ruth Hinckley aka Lironah for with first images ( i started with single color circles and lines ;-) See the difference:





Second thanx to the potential contributor shay raikin who wants to implement gnugo !-)
And last but not least thanx to all the mails with bugreports/ideas and greetinx.
There are not much features yet but even with these little featureset some users are just happy with it e.g. to write down games and save them to SGF.
Tonight I implemented something new - the skins are now saved to SD-Card with applications called gobandroid skinstaller ( skin + installer ;-) - These applications uninstall after they did the job of copying images to the sd-card - so there is not much Application Space is needed. Application Space is actually a big issue on android at this time. I have a lot of space on sd-card but lack space where i can install application. This needs to be fixxed on android but until then I'm going this workaround.




here is the code of gobandroid: http://github.com/ligi/gobandroid

the code is GPL licenced

and here is the code of the installer ( perhaps the uninstalling or the resources to SD-Card part is interesting for someone ) : http://github.com/ligi/gobandroid-skinstaller-lironah/

Work

thats the stuff im doing at work atm:

POLYMAP3 from POLYMAP on Vimeo.

POLYMAP3 is developed under an open source license (LGPL). POLYMAP3 is based on Eclipse/RAP, OpenLayers, GeoTools, uDig and a lot of other great open source software components.

POLYMAP3 aims to provide a multi-user SDI platform. Supporting the power user with an ad-hoc data workbench, the admin user with configuration workbench and the end users with a simple to use web client and OGC services. UI is the web browser.

http://polymap.org/wiki
http://polymap.org

Controlling Mikrokopter with a SpaceMouse on an OpenWrt Router

I improved my SpaceMouse MikroKopter flying setup so that it's now more practical. In the old setup for piloting the MikroKopter with a SpaceMouse ( look here) - I used my notebook for running Riddim. This mainly had 3 drawbacks:
- setup time until i can start flying with this setup was very high
- not reliable enough ( I install software and do experimental stuff on my notebook too often to believe it could be a reliable MultiKopter Controller )
- in the notebook setup piloting was only possible when sitting

In the new setup i use one openwrt router ( asus wl500g premium ) to run the riddim software:


The Datalink to the Mikrokopter is done with ZigBee Pro - which is connected over one MK-USB to the router ( later i can get rid of the MK-USB and use one of the 2 native serial ports in the router to save weigth and power).
The keyswitch to start the mikrokopter and the other switches are connected to an mini gamepad i bought for ~5Eur and took apart to connect wires.




The whole thing is powered by a 2S LiPo ( to ensure the 7805 is not getting to hot).




résumé

Pros:
- very intuitive ( you move the mouse as you want your QuadroKopter to fly )
- one free hand - only one hand needed for flying ( so you have one hand free for operating other functions, for a cigarett, a mobile phone ,a tissue , ... )
- keyswitch to start the Multikopter often lets spectator smile ;-)

Cons:
- router needs ~1min to boot ( i deactivated some stuff in the init.d allready but i have some more options left i can try like boot_wait_time, removing modules i dont need , ... - i hope i can get it ready in <30s )
- landing ( more touch down than soft at the moment with preasure sensor )
- not really suitable for acrobatic flight

credits
- xm for help on porting to openwrt
- sublab for infrastructure

DUBwise J2ME Installer

With J2ME there is always the trouble with lots of JAR and JAD Files to handle device differences. It's theoretically possible to write a one-fits-all application in J2ME - but only with a lot of drawbacks. One big problem ist the usage of special APIs or profiles. The other big thing is that you have to include different ressources for the same thing to (really) 'work' on the device. Handling these problems on the device leads to very big and slow applications. Keep in mind that some people still pay a lot of $$$ for mobile bandwith and/or have slow devices. Thats why one-fits-all jar's are very rare and DUBwise isn't one of it. But it leads to problems in finding the right jar/jad for a lot of people. And until now this problem was solved by a human (me) by answering questions from users. But I like the idea of letting computers or machines do the monotone work ..-)

The most common solution to this problem out there are device lists - but these lists are never complete and need a lot of maintenance (there are a lot of devices emerging every month). The solution for DUBwise is the "DUBwise Installer" which is a small (<10kb) one-fits-hopefully-all application which assembles information about the device, selects the right jar/jad combination and gives the possibility to install it.
This is an easy way for users, but the coders side had some stepping stones. Now i had to build all possible combinations - and this was more of a problem than it sounds because there are 3456 combinations possible actually:
6 - sound packs
*6 - image packs
*3 - firmware packs
*2 - bluetooth usage
*2 - cldc1.1 or cldc1.0 usage
*2 - jsr179 usage
*2 - FileConnection API usage
*2 - deviceControl usage
----
=3456 Jars

This is more than one Gigabyte of jar and jad files and took ~6 houres to build on my Core Duo. Reducing the diversity was not an option for me - so i had to work on Filesize ( i didn't want to crash the svn server on the host project) and on compiling speed.
First tests with my standard packers bzip/bzip2 where very disappointing because they did not siginificantly decrease the size - the very minimum i got where ~800MB - and i had a lot less in my mind because i thought that the entropy is not very high and i can compress this content very good (i could explain why verbally but im not able to write it down ..). Then i searched the net a bit to find a better packer - i stumbled over 7zip - but the tests on the site i found only showed a small difference (which is anyway good for the content they tested - but not the jump i searched for). So i gave it a try and the results where amazing - I got a 17MB File with the default settings and compressing/decompressing are rather fast.
The next problem was the build time - until now i had no problem with it because it was less than 10s/build which is ok for building an app - but not ok for building an app 3456-times ..
The most time consuming part were the jumps to ANT where the sources are preprocessed, compiled and stuff. Now i do this only when the code is changed and just bring the right ressources into the jar otherwise.

Links:
- jar and jad of the Installer
- Source Code of the Installer

DUBwise for Android SDK 0.9-r1

I stopped working on DUBwise for Android while they kept the actual SDK secret under NDA's. Yesterday Google finally released Android SDK 0.9-r1. So i checked if the old DUBwise version could be installed on the new SDK and it didnt work - nothing else was to expect ;-) Compiling with the new SDK was blocked by 31 Errors resulting in API-Changes ( e.g. Bitmap.width() => Bitmap.getWith() ) - I fixed those Errors and then I ran into singing-issues - which could be fixxed by creating a new build.xml via activityCreator.py.
So finally DUBwise is running with the new SDK:

KeyCodes in Android View

If you don't get any keycodes try:

setFocusable(true);

Android Canvas Application

just ported the Smart4Mobile Intro to Android - getting used to the Android-Framework