Archive for the ‘Rant’ Category

MediaLab Chrzelice and KAP

September 6, 2010

Three weeks ago I took part in the MediaLab Chrzelice aka. Culture 2.0 Camp, and didn’t have time to mention it here yet.  I wrote about it in some more detail at the OSM diaries here & here, but let me just say that it was lots of fun, and I’m also really satisfied with how the OpenStreetMapping part of the workshop turned out.  I was never really good at convincing people to do things, but at the workshop I had introduced the project to people who had never heard of OSM and they were immediately very eager to actually go out and start collecting data and then putting it onto the map as quickly as possible (specially since the village where this was held was a very blank spot), which was very satisfying to see.  The GPSes hadn’t arrived, and we didn’t manage to produce good aerial imagery, but trying to launch the balloon and then flying the kite was fun anyway (possibly educative? when something fails is it more educative or less educative?). Two people who had come from Warsaw like me signed up for re-trying the balloon launch some time in the coming weeks, using some new ideas we had. Also one of the concurrent workshops was the Arduido workshop led by Daniel Soltis of Tinker.it! London and I got an arduino kit as a gift. I had some ideas of things I’d like to do with an arduino board, the only problem is I’m truly clueless about low-level electronics (I’m definitely a software person), I can’t even solder properly, so whatever I do with it, I’ll need help making any use of it.

My friend and me had some more attempts at Kite Aerial Photography here in Warsaw after I was back and actually are starting to get some nice pictures although I still need to build a better rig for the camera and get more line (currently have 600 metres and that let us lift the camera to 450-500 metres above the ground).  The current rig was the “plastic bottle”-type (aka. pendulum type) just without the bottle, using just string and duct tape, and attached just about 3m below the kite.  The advantage is that you get pictures taken in all directions.  With a picavet-type rig they will be looking straight down but the swinging is greatly reduced, specially if the rig is attached some 20 metres below, and so you can get much better ground resolution even on not-as-sunny days, because the exposition times can be longer and ISO lower.  So possibly I’ll be attaching multiple cameras instead of one to cover more directions, or building/ordering one of the fancy RC rigs (but more likely just attaching three or four cameras if I can get them from somewhere).  I figured out how to do “interval photography” with a WebOS phone like the Palm Pre (without installing any App Store apps like the Time Lapse Maker for EUR1.99) and I’ll post my app here later — turns out making webOS apps is really simple, even if you’ve never made any you can make a time-lapse app in about 1h without using any SDK or documentation, when on a bus trip for example.

Also my early impression with the latest Canon cameras is that they are terribly bad and there can seriously be no other reason to buy one other than CHDK suport (although the really new ones are not supported anymore because the firmware blobs encryption has changed — particularly what the CHDK developers call the dancing bits sequence).  If you’re looking for a nice pocket camera with high ccd resolution, get a Casio for example (seems to be just starting in the pocket camera market), although not usable for KAP.  I was never very up-to-date with things like hardware specs and prices and benchmarks but now that I had to decide on a camera, I’m taking the opportunity to sound like I have a clue :)

For the next couple of weeks I will be super busy with a university project (I even took a week of vacations at work) and will resume my world dominationkite flying plans afterwards.  I’m also seriously considering RC drones, some of the cheaper ready-to-fly models are slightly cheaper than the bigger kites.  The problem with the kites is that to make a good photo-map suitable for mapping, covering the area size of Warsaw, I’d need to fly it in about 80 places in the city and while it’s fun, it’s also tiring, possibly risky (if you haven’t registered with air traffic control a week ahead) and very weather-dependent.  With drones these are all things yet to figure out as people are just starting to experiment as far as I see on the web.

Unscientific GPS note

April 28, 2008

Last week I charged the different batteries and took a GTA01 Neo, a GTA02 Neo and a Nokia N810 with me to enable their GPSes on my way home from school. Then I saved the traces they logged and loaded into JOSM to have a look (GTA01, GTA02, N810 – gpx files converted using gpsbabel from nmea)

The devices made respectively 11.28km, 12.12km and 11.07km routes (sitting in the same bag the whole time).

All in all I like the GTA01 accuracy the most although all three sometimes have horrible errors. They all three have accuracy about near the bottom line of usability for OSM mapping for a city, so if you get a GPS with that in mind, it may be slightly disappointing. All three are quite good at keeping the fix while indoor but everytime there’s not enough real input available they will invent their own rather than admit (if you had physics experiments at high-school and had to prove theories that way, you know how this works), resulting in run-offs to alternative realities – especially the N810 likes to make virtual trips. They all three apparently do advanced extrapolation and most of the time get things right, but the GTA01 GPS (the hammerhead) very notably assumes in all the calculations that the vehicle in which you move has a certain inertia and treats tight turns as errors. I’m on a bike most of the time and can turn very quickly and it feels as if the firmware was made for a car (SpeedEvil thinks rather a supertanker).

It’s suprising how well they all three can determine the direction in which they’re pointing even when not moving (the GTAs more so). The firmwares seem to rely on that more than on the actual position data sometimes. This results in a funny effect that the errors they make are very consistent even if very big – once the GPS thinks it’s on the other side of a river from you (or worse in the middle), it will stay there as long as you keep going along the river.

I’m curious to see what improvement the galileo system brings over GPS.

UPDATE: I was curious about the precision with which the altitude is reported, which can’t be seen in JOSM.  First I found that the $GPGGA sentences on my GTA01 have always 000.0 in the elevation field, but the field before it (normally containing HDOP) has a value that kind of makes sense as an altitude, so I swapped the two fields (HDOP value should be < 20.0 I believe?).  Then I loaded the data into gnuplot to generate this chart:

The horizontal axis has longitude and vertical the elevation in metres above mean sea level.  Err, sure?  I might have screwed something up but I checked everything twice.  Except the GTA01 which might be a different value completely – but the is some correlation.  I’m not sure which one to trust now.

Going into defense

September 30, 2007

Well, I’m not the kind of free software supporter that finds most pleasure in blaming a big M. corporation, author of a popular operating system, for all evil. I don’t say bad things about their software or business strategies… unless I’m asked to give my opinion.., ok, I am this kind of free software fan. But I’m trying to not be this kind of free software fan, but, well, the said corporation just makes it very hard…

I just hit an Ad banner on some news site today, that I though was funny and the Ad took me to this page. It looks like a joke page but not entirely. It manages to be funny and pathetic at the same time. I just wish they had made some funny spelling error on the front page, but no :(

ALP ctd.

July 19, 2007

I’m spending this week at GUADEC 07 in Birmingham, UK and it’s great fun so far. The theme seems to be in a big part about two things (not counting GNOME, Linux, etc.): desktop web integration and mobile Linux. One of the presentation explained that with a slide that said “Go where the money is: 1. Web, 2. Mobile”. Unfortunately a lot of the talks, especially the keynotes, talk about money-oriented development being the best thing, complying with the needs of corporate users, competing with ms-windows, and even saying deadlines help you make better code (that maybe actually true but it’s so pragmatic and put in my face). Oh well, probably that’s normal in the desktop development world, which I’m not so much into. Everything’s pragmatic here.

In the same spirit was a talk about Hiker & ALP that the ACCESS Systems people had yesterday. The presentation gave some new insight into the whole ALP thing, but not a terrible lot of it. The Hiker guys had working demos of ALP simulator (basically Xephyr) on their laptops and the presentation had a couple of screenshots.

  • The look: ALP looks pretty much like PalmOS with a new, blue theme (default; there’s also a theme called Pony). The UI ideas are also taken from PalmOS but that’s probably an advantage for ALP, because that’s what PalmOS did right. The UI integrates nicely with GTK, has keypad navigation across all widgets that are on screen, and is closed-source.
  • The openness: as could be expected, ALP is horribly littered with proprietary software, in fact you could say it’s a whole new proprietary OS with the Linux kernel and some free projects unnaturally fitted into it, and the Hiker part open-sourced in order to keep appearance.
  • Hiker is not necessarily evil but imho it’s also not a piece of software that solves any current or serious problems of mobile computing, it’s just an alternative to a couple of other opensource frameworks for mobile apps (fortunately the Hiker authors made impression of being aware of that).
  • How does it compare to them? It probably stresses security more than the other projects and has this part covered more extensively (at least the presentation had). The approach to security is definitely original but it’s hard for me to tell if it’s totally correct. The idea is that the system assumes there’s only a single user (which is not a terribly bad assumption and the existing competing mobile distros also have this assumption in a lot of places), and since then the UNIX user and group IDs would be practically unused, they are instead used for process control, i.e. different programs run with different UIDs/GIDs and that allows for easy access control like allowing different apps to use different sets of resources (like /dev nodes, iptables) and preventing e.g. malware from spreading this way. It’s cool that they thought about malware but is this approach ok? UID stands for user id after all. They mentioned a kernel patch they had sent to mainline, related to this approach, which wasn’t accepted, so maybe that’s why. One thing that’s surely positive for Hiker is the clearly defined (ripped off PalmOS) applications behaviour policy (e.g. ensuring only a single instance of most normal apps at a time, etc.), this is where OpenMoko is probably lacking.
  • How does the rest of ALP compare? ALP looks much like a rewrite of PalmOS but this time based on a Linux kernel and other pieces of modern software. Unfortunately ALP is currently not yet even at the point where PalmOS left off, the implementation is just slowly caching up. It’s not any more open than PalmOS was and ACCESS is willing to go for all kind of compromises with hardware vendors and implement all those lock-ins whose avoiding is one of the objectives of a Free Phone (OpenMoko). They will also do a lot to promote their stuff, as is shown by the leaflets they handed out at their stands, full of typical marketting babble except in some places being completely untrue, rather than unclear.

There was some talk about allowing only certified apps to be used on ALP phones, depending on what the particular phone vendor decides.

The .prc loader depends on something called GarnetVM which is completely proprietary and which also in a way depends on Hiker, so probably quite useless for reusing on other devices. I was told it does load native ARM .prc’s as well as the m68k ones, although the Hiker people were not satisfied by the current compatibility level. They said it probably should run “properly written” PalmOS apps without modification, so this can mean many things. There is no connection that they know of, between their .prc loader and Palm Foleo .prc loader and compatibility layer, or any other parts of the Palm Foleo software.

ALP has the arguable advantage that it’s written with ease of making 3rd party apps in mind. There’s a set of Eclipse + CDT templates for ALP apps for everyone’s use (though they are making it sound like a whole new development environment based on opensource solutions, whenever they can) and the simulator thing (Xephyr). There’s obviously no hardware level emulation because they are not a hardware company and they don’t know what hardware ACCESS Linux will first be shipped with yet. They are looking for proposals. I saw one development phone that they use, it was a PXA running at about 300 MHz, CF and miniSD slots, 64 MB of RAM and 64 MB of Flash, a nice white case. If I guessed correctly, it had two cameras, one facing the user and one on the other side. The camera is supported under ALP. It had no touchscreen.

A Maemo person asked if they have had problems with startup times on ALP because that’s one of the things Maemo earlier struggled with and they confirmed they did and still do have problems.

It was said that they talked to Mickeyl about using Hiker in OpenMoko and Mickey liked the idea. I’m pretty sure that won’t happen before the Neo1973 release because Hiker seems to be currently even less complete than OpenMoko, also I can’t see any problem that switching to Hiker might possibly solve. Note, however, that the 0.9.1 tarball I downloaded from their site before GUADEC, was mostly a 2006 code and there must have been some progress since then. (This also shows that it’s not a normal open project because the development was going on in some internal repositories except the two released tarballs. The whole developer network (ADN) for which you have to register, also hints on palmsource.com, msdn and the likes).

Since yesterday Hiker is double-licensed under MPL and LGPL, fact that was announced during the talk.

OpenMoko to start taking orders

July 7, 2007

So around this week OpenMoko is supposed to start selling the Neo1973 developer preview (aka. Phase 1) devices. It’s hard to say if they will make it this week but either way it shouldn’t take very long now.

It just so happens there is a Phase 1 Neo1973 phone sitting on my desk and I have a couple of comments on it for those who are planning to get one for themselves too. Firstly, at least one person expressed amazement about the fact that now, three days before shipping, things like SMS support are being worked on and are nowhere near finished on the software side. Apparently it wasn’t made clear enough that this Neo1973 release is *really* a developer version and is targeted for ambitious developers who would otherwise be disappointed if the device they get comes packed with all software ready to use. And I’m sure there will be a lot more people who didn’t get it and are going to be giving OpenMoko bad reviews and this is annoying, because what they will be reviewing is not even the OpenMoko platform yet, it’s a developer snapshot. (This is similar to those folks who beg you to let them taste what you have in your pot when you’re in the middle of cooking something, and then they’ll say something about not liking the soup or worse, about your cooking skills, based on this. The thing is they are tasting a development snapshot of the soup, not the soup. It might even be poisonous, and the final dish still be perfectly fine. Guess I’m hungry…)

Another thing, when you get your device it’s a good idea to back up the factory contents of the Flash chip so you don’t lose some of the files on it before flashing an update later. Updates will overwrite all of the data in the Flash and there is a couple of files there that are not available from internet (don’t ask me why). A simple way I found to make a backup is using netcat from under Linux after it boots for the first time. It will take about 30 minutes and here’s how it’s done: connect the device to your PC with a USB cable or Bluetooth and run the following spell on the PC side:

$ for i in 0 1 2 3 4; do netcat -l -p 20000 > mtdblock$i; done

Netcat will listen for the backup data on TCP and write the five chunks (Flash partitions) to files named mtblockN in the current directory. Log into the phone through ssh and do:

# for i in /dev/mtdblock?; do cat $i | nc 192.168.0.200 20000; done

These files should be enough to restore the original state of the phone’s memory at any later time.

One more comment I have is that with the current Neo1973 kernel it doesn’t make much sense suspending and waking the system up when you’re coding something on the PC and are periodically testing it on the phone. Leave it running, power the device off entirely after you’ve finished. There’s something seriously wrong with power usage in suspend/resume. I have not made any measures and the battery I’m using is not 100% compatible but I risk to say it draws more power when suspended than when fully on. There is a curiously looking patch on the mailing lists that might explain this but I haven’t tried it yet. On the other hand I²C peripherals alone shouldn’t have that much impact.

For comparison, a different ARM-based device I own can live ~4 hours powered on and over two months suspended (i.e. with only RAM constantly on), from a full battery. The Neo will have the additional sucking from the GSM modem, but it didn’t seem to make much difference when I powered the GSM off through GPIO (assuming I did it correctly).