I could keep writing a lot about the ideas behind the project, my personal motivation and such but well, OpenStreetMap is one of the rare projects I'm contributing to that actually require people to get out and see things for themselves ! So that's very good for us hackers that are used to do our work behind a screen: for once, we're required to get some fresh air. That has been a good opportunity for me to discover more of the city where I live, do some sports by the way and discover many relaxing places in a natural environment.
From the moment I started mapping, I always used a bike to move around town. That's probably the best way to catch every detail surrounding your ride, making it easy to stop at any moment and any place. I've done mapping on my feet a couple time too, it's good when there is a high-density of POI (Points Of Interest), like in the town centre. If this is not the case where you live, you are most likely going to waste a lot of valuable time. On the other hand, this can be a fun way to spend some hours to kill in the middle of the day.
The first device I used to do mapping was the Neo FreeRunner and its embedded GPS. I also got an external antenna to improve the reliability of the traces. On the software side, I was most of the time using Hackable:1 and TangoGPS but at some point switched to SHR with FoxtrotGPS. That was pretty nice to use, except that the keyboard with very small and required me to carry a pen. I attached the FreeRunner to my bike using cable ties though I had to drive very carefully to avoid damaging the phone.
Carrying a sheet of paper and a pen can also turn out to be very useful to draw a quick sketch of the ways and their names. When possible, printing walking papers (black and white is fine) with the already mapped OSM informations helps a lot too. I'm not a regular user of these methods but from time to time it helps, especially when there is not a lot of informations already available on OSM. Another kind of complementary mapping technique that I used from time to time is voice recording: this permits to be very precise in the description. These techniques are used best along with regular GPS tracking.
As soon as all the streets were properly tagged, I focused on adding particular POI such as stores, bus stops, public buildings, etc. Thanks to the Cadastre, we have the detail of every building available in OSM, so we can precisely place POI without the need of GPS traces. The FreeRunner remains relevant for this task but just as well as other devices. At some point, I decided to switch to Android devices to map (with the OsmAnd app, that is free software). Since most of these devices come with a camera, it also permits to take pictures of the place quickly while mapping. A phone is fine for that, but the best I've found is a tablet with a large screen: you can place the POI precisely that way and enjoy the large keyboard. OSM mapping is one of the tasks you'll really enjoy doing with a tablet more than any other device.
I have been contributing to OpenStreetMap since years now, and only rarely wrote about it, while there is actually a lot to say about the whole experience. I'll be presenting my feedback over the project in a series of articles, starting with this one.
So first thing's first: let's talk a bit about why I care about the OpenStreetMap project. You may have understood from this blog that I am a computer programmer involved in free software development. Though, the reasons behind my involvement in OSM aren't quite exactly the same as the ones that explain why I care about free software. While free software is mostly about giving back to the user control over their computing, OSM is related to data, not software.
Both software and data have legal owners, who can restrict the use that is made of them. In the case of software, that restriction can be made to a point where it becomes obvious that the user doesn't get enough rights to still control the computing they do with such software: we call that lacking freedom. That is why the free software movement was started years ago, coming with a solution in the form of legal licenses assuring the user basic freedom, denying unjust powers to the software copyright holder. That's the main reason why I believe free software matters.
Though, when it comes to data, the question doesn't remain quite the same. First, data released with a permissive license or with a strict license will look the very same, and the license can change without any change made to the data itself. This is not the case for software: a permissive license is pretty much useless if no source code is ever released: that means free software needs to be released with source code, while a music will sound just the same whether it's under a permissive license or not. Another point is that software can harm, data usually can't. Computers make it incredibly easy to spy on people, track them, read their online conversations, etc. That's why it is so obvious non-free software is bad: with such issues at stake, you'd better be in control of your computing. Data is instead pretty much harmless. So it seems clear to me that what is at stake for software makes the need of free software very obvious while for data, the issues aren't as serious and the experience you get from the data will remain the same.
Well, strictly the same isn't quite true. There must be something more that comes with content under a permissive license. Of course, that's the ability to edit, remix, reuse and share the content. Now I think it's all about a personal consideration: whether you think it is ok to forbid the user from doing these things. I personally believe that such rights should be guaranteed and the fact that guaranteeing them would perhaps harm sales rate isn't a good enough justification to refuse them, compared to the benefits of sharing culture among people. And yes, we can find other ways to let the authors of the content live of what they're doing, it just needs to be fair enough between the authors and the public. So this is why I believe data, content should be licensed under permissive licenses. I won't get too much into details there, about under what conditions exactly I find the bargain fair, but it's worth writing about. Also, note that even though I disapprove the licensing of content under restrictive licenses, I do not see any reason to refuse using it under the given terms since, as I wrote before, it seems to do no harm and basically, using it with the involved restrictions seems better than doing nothing. With these elements cleared up, we can get to why I decided to get involved in OpenStreetMap.
Maps are just another type of data, licensed under the same rules as any other content. As a matter of fact, all of the serious maps providers were licensing their maps under restrictive licenses, which I, just like the people behind OSM, disapprove. I could have just decided to pick one and use it anyway, but OpenStreetMap was there. As its name suggests, OpenStreetMap provides maps under a permissive license, that used to be the Creative Commons BY-SA license and recently changed to the Open Database License (ODbL). It's also doing more than just providing content: it is also a community effort, that lets everyone contribute to the map! At some point, I got a Neo Freerunner, with GPS capability, so I just told myself: hey, why not try and contribute to the effort, I have everything that is needed for that (which is basically only a GPS).
Quite a while ago, I bought some device with a laser pointer. I did lost it over time and eventually ran into it just a couple days ago. In the meantime, I bought an Arduino and started experiencing with it, especially with photo-sensitive resistors (photoresistors).
So I wondered what kind of fun could come out of a laser + a photoresistor + an Arduino. Actually, it didn't take long to figure out what to do. Remember all the Mission: Impossible-like movies and shows, where people are to move into laser-secured rooms, without interrupting any of the laser beams? Well, that's pretty-much the idea I came up with: "securing" my room door with such things.
The setup is pretty easy: the Arduino is on one side of the door, with the photoresistor and another 10k resistor that we need to have a changing voltage. The laser is on the other side of the door, directed right to the photoresistor and connected to the Arduino via a couple wires. So the general idea here is to make the Arduino power the laser and get the tension from the photoresistor (or the 10k resistor) a couple times every second. Here is a scheme:
Here is a demo video of the Arduindoor system running (first time making an alarm ring, second time playing/pausing music) :
If you're interested in the idea, you can setup your own with the additional help of:
During this summer period, temperatures are starting to get really high, and often higher than what my computer can handle, apparently.
Since a couple of weeks, I noticed a nasty white flickering taking over the screen after hours of use, with my integrated Intel HD Graphics 2000 on SandyBridge Intel i3 2120.
I tried to search for a solution but couldn't find anything that helps, except turning the computer off for some hours, thus letting it cool down.
So this happens more and more often as uptime increases and at some point, it gets so frustrating that my only solution is to turn the computer down and do some other business. It happens more when running 3D games and also continues on tty sessions (even with X not running at all).
So I made a video to explain the situation to Intel GFX people on IRC, who sadly couldn't bring me much more help.
As I am porting Replicant, our fully free Android derivate, to the new Goldelico GTA04, I had to deal with ALSA user-space integration in Gingerbread. So let's take a quick look about it: On Gingebread (and previous versions), user-space audio is done via the libaudio library. The Android framework will basically interact with AudioFlinger that is the component in charge of loading that libaudio library and dealing with it (that's frameworks/base/services/audioflinger/AudioFlinger.cpp). So libaudio is basically the place where PCM read/write and mixer stuff happens. As we started looking into the various existing ALSA libaudio, my fellow Replicant developer GNUtoo told me about TinyHAL, a clean and flexible audio module that does ALSA and routing from XML configuration files. Too bad, TinyHAL was designed for Ice Cream Sandwich, and the Audio API changed in ICS (basically, it is now a module, like the ones for gps, sensors, lights, etc). So I couldn't use it as-is, but there were various concepts I hoped I would be able to reuse, like the XML routing config or the use of the TinyALSA lib, that is very clean, simple to use and handles ioctl-level ALSA stuff.
In the end, I decided to write my own libaudio, using both TinyALSA and XML config files, that I called TinyALSA-Audio. Audio output and Mixer was quite straightforward and worked quickly. AudioFlinger basically opens the AudioStreamOut at 44100Hz, 2 chans, S16_LE format (signed 16bits, little endian), which works fine with the audio hardware, a TWL4030 Codec here, that didn't complain at all.
Next step was about audio input and recording. At first sight, I thought it would be as easy as audio output, that is just setting the controls, opening the device via TinyALSA, sending the config following what AudioFlinger asks and just read the data. So I basically wrote code that was that simple, but it failed while setting the config: cannot set hw params: Invalid argument was the error. As I didn't see what could possibly be wrong about the params, I decided to take a look at how tinycap, the capture utility that comes with TinyALSA handles things. It actually sets the params at 44100Hz, 2 chans, S16_LE, and recording works then. When I tried to force the params to what AudioFlinger asks, that is 8000Hz, 1 chan, S16_LE, I got the very same error as on my libaudio: cannot set hw params: Invalid argument.
So what was it all about? Does the CODEC only records at 44100Hz, 2 chans? I tried with zygote stopped, and then 8000Hz mono worked. I also checked in the kernel code: the TWL4030 CODEC is supposed to work at 8000Hz mono as well. So I deducted that when the output device is opened, the input device will only work at the same config (rate, chans). What a bummer! AudioFlinger asks for 8000Hz mono, not 44100hz stereo, though that's all I can get when output is opened (which is always the case when zygote is running).
Thanks to the AOSP, there are various others libaudio that I could use to learn things. First thing to know was if that "issue" was specific to TWL4030 or common to all ALSA CODECS. So I did the same test (with tinycap) on the Nexus S and Galaxy S, and the result was that both couldn't record at any other rate/chans that the ones set when opening output. Galaxy Nexus audio module confirmed that too. So what is the solution here? Obviously, it consists in finding a way to return 8000Hz mono data to AudioFlinger while reading 44100Hz stereo data: that's resampling.
Galaxy S and Nexus S libaudio all handled resampling by internal algorithms, which seemed a pain to use and adapt on my libaudio. The solution finally came from the Galaxy Nexus audio module. And I really want to send a big Thank-You to the people who wrote it. First of all, it uses the very same TinyALSA as my libaudio uses. Second thing is that it doesn't embed complicated algorithms for resampling but uses the new Android 4 framework for resampling, that wasn't so hard to understand. behind that engine is the libspeexresampler lib, that is part of speex code. So all I had to do was to backport that Android 4 resampling code, enable to build of libspeexresampler in gingerbread and make use of all that in my lib.
Though, wait a second, when reading AudioFlinger code, it all seemed to indicate that AudioFlinger embeds its own resampling engine, so that when the lbiaudio reports different parameters, it handles resampling to what it wants (mostly 8000hz mono). So I tried to make use of that, in vain. I couldn't figure out why it didn't work, it just didn't. I read the AudioFlinger code several times, made sure the resampler was enabled and all, but in the end, the produced audio was just garbage, so I just gave up on using AudioFlinfer's resampler. After all, if all the AOSP libaudio do not make use of it, there might be a reason. So the thing appears to be totally messed-up and nobody cares enough to fix it but rather implement resampling in the libaudio itself. Not a very good thing for me, I would have preferred to leave resampling to the upper layer, but anyway, I had Galaxy Nexus code that could be adapted to my lib. So that's basically what I did: backporting the Android 4 resampler code to my libaudio, making use of it and using ICS external/speex repo. In the end of this misadventure and with some fine tuning, it all worked.
That's pretty much the end of the story, now I have my TinyALSA-Audio lib that handles input/output routing via mixer audio output and audio input as well, to various rates. Here are some links:
