Naba's Blog

Time to bring in new colors

2011-09-22T14:43:00.003+03:00

Time to bring in some new colors in life! ...

After

Before

Finally, get ready for the ultimate linux phone: Nokia N900

2009-08-30T22:34:00.008+03:00

Nokia n900 is the latest offering from Nokia that runs Maemo operating system based on debian linux. Basically, it's a fairly powerful computer in your pocket.

The word "convergence" [1] has been tossed around for a very long time. A lot of big talks happened about how the concept is the future of consumer devices and how it will change the way people get the "one device to rule all media". I first heard about it in 2001 and I couldn't stop thinking we are in 2009, 8 years later, and the word has still been ... a buzz word.

The problem it seems is that to truly converge consumer electronic devices, one would literally need a computer. Yes, in a way laptop is a converged device -- you can essentially do anything that most electronic devices can do for you in separated devices (tv, radio, video, Internet, telephony, composition etc.). The only missing part is mobility; there is a set of devices that general computers can not yet cover -- the mobile devices.

This is where I claim that Nokia n900 is the first true convergence device or at least a meaningful beginning. Why? Because it's a decent computer and a cellular phone combined (specs), on an open maemo platform.

The software platform is the most interesting part. Based on debian like distribution, Maemo is like any other linux distrubtion and you can use it to write literally any software that you can do for your desktop or laptop computer. Of course, the processing power could be a limiting factor for some heavy applications, but that's largely a limiting factor born out of high power computers, not the limitation of functions that you want for a pocket computer (hint: most of your home media systems have really tiny CPUs). But it still sports one of the fasted hardware specs you can get in a mobile device now (600Mhz Arm cortex-A8 CPU, 256MB ram, 32GB drive, 3D hardware acceleration, gps, cellular, camera and everything that you can get in any modern mobile phone).

One might argue that modern "smartphones" have been around that does a lot of things already what N900 does now. That's true, however they are quite limited in how you can treat them, both hardware wise and software wise. For example, iPhone, android, palm-pre etc., while quite cheezy, are fairly distant from being a small computer that anyone can write apps freely and openly -- the very reason why your PC is versatile. N900 opens that field.

Here is a hands-on youtube video demonstrating N900 if you wish:

[1] Consumer devices convergence, not the other kinds like service convergence or technology convergence.

Time to revive a dying laptop: dell inspiron 2650

2009-05-17T12:45:00.005+03:00

I have a dell inspiron 2650 laptop that was bought 7 years ago. It did a fairly good job of serving me at the time. With nvidia GForce2 GO graphics chipset (hot at that time), I abused it with good amount of FPS games -- the keyboard mostly took the hit :). Now 7 years later, I was amazed to see it still surviving and running. All the important stuffs; motherboard, LCD display, CPU etc. are working perfectly. Considering how well it severed me, I decided to revive it. The following things were dead though:

1. Keyboard: This took the most hit. Arrow keys were non-functional, lost few key caps, and most annoyingly 'Fn' key was non-functioning. This means this keyboard was useless to control screen backlight. This was unfortunate because there is no software way to control screen brightness in this laptop. Cost: 20 USD

2. Harddrive was dead. But fortunately, I had a spare 40 GB, 2.5 hard disk lying around that was used as external usb storage. It was still in good condition for replacement, and had somehow previous ubuntu feisty installation (7.10) still on it. Cost: 0 USD.

3. RAM was 265 MB. It was good for the old time, but now it won't be enough to run GNOME desktop environment. Browsing around the net, I found that the max RAM it can take is 512 MB, in 2 DIMM slots -- each 256 MB module (it had 2 x 128 MB modules). A pair of 256 MB PC100 DIMM modules were quite cheap in ebay so I decided to max out the RAM. Cost: 20 USD.

4. Battery holds something like 20 mins of charge. Replacement battery with 4400 mAH cost 45 USD in ebay.

5. Power supply plug was broken (on the laptop side of the cord). The power brick itself was functioning quite well, but shame that the cord is directly hooked up from the brick. So there is no way you could upgrade only the cord (short of pulling it out from another brick). I decided to replace the whole brick. Cost: 20 USD.

6. CDROM drive was dead. Considering how little I use CD drive now a days (most things come from internet and my NAS storage anyways), I decided not to fix it.

9. Fan was quite noisy and active, indicating cooling problem with CPU. When I opened the laptop, I found good amount of dirts on heatsink and other places (no surprise :)). I bought a compressed air can and blow them out. Then followed by cleaning the fans with dry-wet cloth to remove sticky dirts. There were 2 fans, one for CPU heatsink and another smaller one for general laptop around the graphics heatsink. Another problem was that the thermal paste between the CPU and heatsink was dead dry and opening the heatsink invalidated it further. Bought a ceramic based thermal paste (those white ones) and applied it. Also, dropped a drop of cooking oil in the fans' hinges, just in case it helps :). Now they are less noisy and less active.

10. The LCD cover was cracked around the hinges. A bit of super glue helped there.

Software: Upgraded bios to A13 version (the last update from Dell) and upgraded Ubuntu over the network from Feisty (7.10) to Hardy (8.04) to Interprid (8.10) and then to latest Ubuntu Jaunty (9.04). The upgrades went smoothly except for few gliches in nvidia driver update. Apparently nvidia stopped supporting Geforce2 go in its newer drivers. The last support was in version 96.something. Suspend does not work in Ubuntu 9.04 (a known regression), but I managed to get Hibernation to work by blacklisting 'intel_agp' and 'agpgard' modules as suggested in some forums. GNOME desktop runs smoothly with all the compiz eye candies.

So overall I spend around total of 130 EUR by ordering the items from US ebay, shipping charge and VAT tax, to have a fully functional laptop. Not bad for a spec of P4 1.7 GHz, 512 MB RAM, Geforce2 graphics, 40 GB drive and brand new keyboard and battery.

Now it's as good as new :)

Carrot-following vehicle with mindstorms nxt

2009-04-27T19:51:00.005+03:00

After implementing Odometer, the next step is to implement a generic vehicle that navigates a given path. Path following is a basic requirement for an autonomous vehicle which tries follow a given path generated by some higher (more intelligent) entity as closely as possible.

The problem is fairly common and there is a selection of algorithms to choose from. The least complex, but not necessarily the most effective algorithm is the "carrot following" method. Vehicle.nxc now does this implementation in libnxter library.

In this method, the robot looks ahead in a circle towards the path to follow and takes the point of intersection with the path as a goal to chase. There will be two points of intersection between the look ahead circle and the path. The one closer to the direction of path is obviously the pick. If the look ahead circle does not intersect with the path, then the carrot is located at the nearest point (on the circle) towards the path. This is illustrated in following figure.

When a list of navigation points are used to describe the path robot should take, the current path is described by last navigation point visited and next navigation point to visit. In the above figure, P1(x,y) is the last visited point and P2(x,y) is the next point to visit. The robot switches to next navigation point as soon as current navigation point comes within the look ahead circle.

The two points of intersection can be computed with basic geometry of a circle intersecting a line. For example, this site gives a very well explanation of it. Of the two solutions, the point closest to P2(x,y) is selected as carrot. Function VehicleGetLookahead() implements this.

Robot(x,y) position and orientation is the current vector of the robot provided by the Odometer. Navigation points P1, P2, ... and so on are maintained in a queue internally which can be continuously fed with VehicleAddNavPoint() or VehicleAddNavPoints().

Driving the vehicle

Once carrot vector is computed, next thing is to steer the vehicle towards it and try to keep it always pointed at the carrot. This is actually a tough bit. The problem is that we have to make it somehow both smooth and stable. It might look like simple control problem where you just steer proportional to orientation error; I tried it and it doesn't work :). Power of the motors has to be taken into account as well, otherwise either it ended up being too unstable or doesn't have enough steering dynamics (making big round arcs when steering).

When mindstorms nxt is configured as a 2 wheels drive with differential steering, the steering dynamics is very high. Starting from going straight (i.e. no steering), you can steer it in-place which is the highest steering. To take advantage of this steering range, we have to control the power of vehicle as well. Just like in driving a car, lower power allows making sharper turns, but when moving fast there is a limit to how much steering you can do without destabilizing it.

After playing around a while and trying many different ways, I settled on a fairly good approach -- something that sounds quite familiar when you are driving a real car :).

First off, notice that steering and power are not linearly related -- that is, half the power doesn't mean that you can do half the steering. Steering capacity reduces dramatically as the power increases. I found that a typical inverse relation is much more fitting. Like in a way given in this graph.

X-axis is steering factor which can range from -100 to +100 (+/-100 steering is in-place steering where the two motors move in opposite direction equally, either left or right and 0 would mean not steering at all). Y-axis is the power level below which the vehicle needs to be to make the given turn. As you can see, the green line represents the power below which any steering is allowed (and is also the minimum power the vehicle should try to maintain all the time). If you flip the graph, it gives maximum steering the vehicle can make at a given power level.

So, the steering equation can be written as:

Conversely,

VehicleStep() implements the Driving loop that tries to keep the vehicle running at a power level not limited by the steering factor needed, or slows down to make necessary steering. This is exactly what happens when driving a car. You try to reduce the speed to make necessary turn, or speedup when there is less turning to make.

The orientation error is determined by subtracting robot orientation from that of carrot's and is multiplied by a constant to get proportional steering factor. This is the needed steering to reduce the orientation error as swiftly as possible.

If the current power level allows making this steering factor (the above graph or first equation), no problem and we set it. At the same time, it also means that we are driving the vehicle slower than it needs to so we increases the power a bit (accelerates).

Else the vehicle is moving too fast for the needed steering, so reduce the power a bit (braking) and determine the allowed steering level (flipped version of the graph or second equation) at this reduced power. This new 'allowed' steering factor will be lower than the requested one, but is what is actually possible with the current power level.

In essence, this is also a standard proportional controller trying to control both power and steering factor using orientation error as input, where power and steering are constrained by each other. This has worked fine so far with me. But I am sure there is a more elegant solution to it. If you find one, please let me know :).

Example

Here is the path used to test run the vehicle (this is not the exact trace of what is seen in following video, but rather approximately made up). Notice that it doesn't really touch the navigation points. Instead it tries to make smooth turns around them. However around sharp turns, it actually cuts too much corner. This is one drawback of carrot-following method.

Two wheels drive odometry

2008-08-31T19:06:00.085+03:00

Odometry is a way to keep track of robot (or vehicle) position from its wheels tachometer readings. Mindstorms nxt motors have integrated tachometers that make life easier to implement odometry. libnxter project implements odometery with the class Odometry2 and this article describes how it is implemented and what the geometry behind is. It uses integer Vector representation for all its geometry for performance on the tiny CPU it has got (not to mention NXC doesn't support floating point operations).

Basically, it uses standard integration of axial movements over time, taking mid position of the axial connecting the two wheels as the reference point of robot, and is what is tracked as current position. Naturally, the position of robot at time t is given by vector sum of its discrete displacements over time since the beginning:

Position change for each time step is approximated for low angles. As long as integration steps are performed quickly enough (but not very quickly where accuracy of tachometers would suffer), the position should be fairly accurate. Each time step is performed with a call to Odometer2Step() function.

At each step, the distance traveled D along the direction of current robot orientation is given by following equation. Actually, this is only true for small angles where D is approximately straight line. For more acute turns, D is curved and the equation is no more accurate. Therefore, the steps must be executed at fairly quick pace.

Where, and are distance traveled by left wheel and right wheel, respectively. It can be further written down using anglular rotation of each wheel and gear ratio:

Where, is wheel radius, is gear ratio (output to input) and and are angular rotation (radians) of left and right wheels respectively.

The angular rotation is essentially tachometer counts of each wheel, reduced by appropriate gear ratio. In Odometry2 implementation, gear ratio is given in percentage (for integer maths, of course) and tachometer counts are in degrees. So the final equation is:

Where, is wheel diameter, and are tachometer counts of left and right wheels, respectively.

Change in orientation of robot is given by:

Where, is wheel axial length.

After computing and , the new robot position vector is given as:

This is what is implemented in Odometry2Step() method.

Odometry unfortunately suffers from drift error if used over a long period of time without any correction. Despite how assuring the math is, there are several factors that can easily introduce errors during each step, starting from systematic errors (inaccuracy in wheel diameter, axial length etc.), quantization errors (A/D conversion, integer calculations etc.) to random errors. The errors actually grow quadratically with distance traveled and as a result they accumulate real fast. To compensate for the collective drift error, there needs to be a separate mechanism to periodically 'fix' it. Naturally, it's only useful to 'hold on' the tracking while some expensive localization computation is going on or waiting for some measurement/observation to happen.

Helpfully, Odometry2 maintains two positions - a comulative position and a delta position. Comulative position is robot's current position in world coordinate system. The delta position is its relative position from the point where drift was last corrected. The correction point creates the origin of delta coordinate system and delta integration happens on this frame-of-reference. Following diagram illustrates it:

The reason there is a separate delta integration in addition to comulative integration is to give room for robot localization to perform at slower pace (not unusual for small robots with slow CPU) or waiting for observation points to become measurable (losing GPS signal, landmarks not visible etc.). If nothing else, it can be used conveniently as a secondary position tracker in separate coordinate system, like a temporary tracking.

How it works is like this: Let's assume at position , the robot completed its last localization step ( is the result of that correction) and it starts the next round using then current position . Delta coordinate system is reset and this position becomes its origin. By the time it managed to finish the localization round, which could involved waiting for observations, taking measurements, calculating the observed position etc., the robot is already at position (notice the 'tick' mark). At the same time, it has been moving non-stop and also tracking deltaX.

But to use the result of this localization update, it must be applied at position, not later. So, it transforms deltaX position from its delta coordinate system back to world coordinate system after assuming the corrected position as the new delta frame-of-reference. The drift correction is shown in the diagram by the dotted line drawn from position. This translated position becomes the new comulative integral (). And the cycle repeats. Drift correction is implemented in method Odometer2SetDriftCorrection().

My next attempt is to implement Sonar and Radar.

libnxt name collision

2008-08-04T13:08:00.004+03:00

After starting my own library for lego mindstroms nxt robotics kits, called libnxt, that provides basic robotics building blocks, I discovered another project already existing with similar name (but different purpose). My bad that I didn't do a basic research for a name. I guess I will rename my project to libnxter instead.

Update: Project is now renamed to libnxter; thanks to SF support team.

Partial solar eclipse in Helsinki

2008-08-01T12:00:00.001+03:00

There was a partial solar eclipse visible from Helsinki on 1st Aug 2008, 12:00pm. Here is shot of it taken with my camera phone with a filter attached.

Kalman filter for lego mindstorms nxt

2008-07-18T18:31:00.066+03:00

One thing that becomes glaringly clear when starting robotics is that nothing goes as expected. The motors don't go as instructed and the sensors don't read as expected. This is a fundamental problem one faces in real world systems where noise is abundant and randomness is part of life. For example, when a motor is rotated by certain degree, it is never guaranteed to land on the desired position due to several physical uncertainties. Rather, it lands on a so call 'cloud of probability distribution'. Which basically means it will land on any point surrounding the desired point with certain probability. That's more of a gambling than precise control.

If one continues running the system based on some ideal model, these errors quickly accumulate and very soon you have a deceivingly wrong understanding of what the state of the system is (it's called system drift). One way to counter this and prevent the error from growing high is obviously to have some feedback of the system state from an independent observation. That's where sensors come in handy.

Unfortunately, as life would be, sensors themselves are not perfect and have the same problem of reading from a cloud of probability. The measurements are seldom the actual state. Instead, it is something close to the actual value depending on whatever dice reading god happens to have at that point in time. The dice readings, of course, is governed by the measurement probability cloud involved in that particular sensor setup.

Depending on how much you paid for the motors and sensors, the clouds will be smaller or larger. But irrespectively, some clouds will always be there and one of the goals of many robot enthusiasts is to deal with these clouds.

One savior in this department is a famous (or infamous, depending on how it goes with you :)) Kalman Filter. This algorithm tries to maintain a good estimate of current state based on two important knowledge of the dynamic system; 1) the model of the actuation and 2) the measurement readings. In ideal world, both of them will determine the exact state independently, but in real world, random errors make them hard to use directly. The best is to use them together in some form of statistically averaging way. Kalman Filter is one such way of doing that.

I have implemented standard kalman filter for lego mindstorms nxt and the source code is available in libnxt library. It's done in NXC language and runs on the standard firmware. It's a flexible implementation using integer matrix algebra and can be used comfortably for one, two, or three dimentional state vectors (above that, you could still use it, but it becomes very slow on nxt hardware).

To use it in meaningful way, it's useful to know how kalman filter works (but not necessarily to the extend of knowing every details). Understanding the model at least will help provide the right parameters for the filter. I found this excellent article explaining Kalman Filter that I felt was very well written. It explains it for one scaler variable, but can be easily applied to vectors using matrix operations.

Cutting long story short, here is how it can be summarized. Kalman Filter works by maintaining the state of the system based on its actuation model and at the same time taking weighted contribution from the measurement. The weight, officially known as Kalman Gain, is determined from an understanding of how accurate the measurement is compared to the accuracy of the current estimate (which is known as Posteriori error covariance). Highly inconsistent measurements have lower weight and therefore contributes less to the final estimate.

It introduces two important assumptions in kalman filter. First is that the system must be linear. That's because the understanding of accuray above is actually computed by simple linear comparison. If the system is not linear, the understanding itself will be flawed. If the system is not linear, there are ways to linearize the system or some other modified/improved form of Kalman filter is used, such as Extended Kalman Filter or Unscented Kalman Filter. In my opinion it's just better to skip Mr. Kalman at that point and go for other versatile algorithms such as Particle Filter

The second assumption in kalman model is that the error introduced is Gaussian distribution, also known as white noise. This is again because it only maintains one estimate of the state which it tries to converge based on the fact that statistically most likely estimate is the actual state, and as one go further away from the actual state, the less likely they happen. This is the basis of many naturally occurring random errors. For example, if you throw 1000 darts at a target, close to bulls eye is where you find most of the darts landing and it becomes thinner as you look further away from bulls-eye. If the error or uncertainty involved is not approximately Gaussian distribution, or not uni-modal (that is, it has more than 1 most-likely estimates), then go for more versatile (but expensive) algorithms such as Particle Filters

The following two equations describe the kalman model; a linear system with white noise introduced. The first is Actuation model and the second is the Observation or measurement model

The actuation model describes that current state is derived from previous state (transformed linearly by function ) and adding whatever input control was applied to the system. is obviously the transformation function that converts control input to the its consequence in state space. is the dreaded white noise which has mean 0 and covariance .

The observation model is described by observation (the observed parameter) being made off current state . is the function that maps system state to the observation parameter. is the white noise added in .

Then the filter steps in a continuous loop. Each step is a time step (represented by t in the equations) and has three phases -- predict phase, intermediate phase and update phase.

Predict phase, given by the following 2 equations, is when it determines the state of the system (called Priori estimate, indicated by the 'hat') based on its actuation model.

Predicted state:

Predicted estimate covariance:

The intermediate phase is where it determines the understanding of accuracy and , called residuals, and the best Kalman Gain for that step.

Innovation or measurement residual:

Innovation (or residual) covariance:

Optimal Kalman gain:

And lastly update phase is where it uses the Kalman Gain to update the Priori estimate making it Postariori estimate , which is the final estimate of the step.

Updated state estimate:

Updated estimate covariance:

All along, there is another paramenter that goes together with the state estimate, called estimate covariance , that maintains the accuracy of state estimate.

The biggest challenge for me was in implementing integer matrix operations and maintaining Kalmain Gain. While kalman equations where quite straight forward (just a bunch of matrix operations), doing it in integer form was a different beast. The dynamics of the equations were so large that holding them within integer range was non-trivial. I had to go with several 'tweaks' to make it work. The first tweak is about holding a matrix inverse in integer form. It's explained in detail at libnxt matrix documentation. The second tweak was with Kalman Gain. This parameter is a fractional parameter that ranges from 0 to 1.0 and must maintain a good precision especially close to 0 for the filter to converge correctly around the set point. On top of that NXC doesn't support function calls recursion so it was another fight to implement matrix co-factor computation.

Here is a video running a simulation on nxt brick:

Making AlphaRex walk

2008-07-12T14:57:00.013+03:00

As it turned out, Making the official AlphaRex model walk properly wasn't easy. Here is the video of AlphaRex walking. The program was written using NXC in Brixcc and is available here. There are several issues making it annoyingly hard to walk consistently. Some tweaks need to be done beyond the official model.

The first is the gears positioning. The two motors, used for tilt and stride, have to be aligned every freaking time before starting a walking program. This is annoying at best. There is simply no feedback about their initial positions and hence some pre-start position has to be assumed by the program.

I solved it by using the touch and light sensors (otherwise uselessly mounted on AlphaRex as decoration) to detect tilt and stride positions. The program then calibrates the robot's alignment before starting walk sequence. During the calibration, it also determines motors' cycles needed for walking (hence, avoiding manual determination of gear ratios and so on).

The second problem is that it has very little ground clearance for the feet, so it's easy for the robot to walk one-step-forward-half-step-backward if the strides are not made at perfect tilt positions where ground clearance is highest. The solution to this is simply to run the motors in turn. You make the strides only when the tilt is maximum or make turning moves with appropriate tilts. Rotating the motors continuously, as demonstrated by the official program, doesn't take advantage of 'maximum tilt position' and also because of positional drifts, the robot just ends up shuffling on the ground.

The third problem is with the firmware's PID control. Since I am positioning the motors rather than rotating them continuously, I needed accurate and fast angular positioning (otherwise, it was a slow walk because of too much settling time). For the life of me, I couldn't tune the PID values for the firmware's implementation, even using Ziegler–Nichols method. Out of frustration, I ended up implementing my own. A quick glance at firmware source code shows the implementation is done for speed control. Perhaps that's the reason why it sucked at position control.

Walking is implemented using state machine. The state of the robot is described by a combination of tilt and stride positions. A state transition table describes what would be next state, given current state and current movement command. This allows the robot to switch to any walking state any moment based on a command. A separate table describes transition actions -- the physical actions needed to perform to get the robot from any given state to any other state.

My implementation is different from the one described here, in the sense that I separated transition states and transition actions, allowing it to walk, turn and stop smoothly without having to enter a 'neutral' state in between. But otherwise, the idea is more or less similar. I think making states and actions separate makes it simpler to understand and put together. Also more flexible in hopping between states as a continuum; just like human doesn't stop before taking a turn. It looks like the walking can be sped up a little bit by starting strides already before tilt got to maximum, but I haven't bothered doing it.

Using the touch sensor sensor was pretty easy because there is a clear 'detection' of tilt extreme.

On the other hand, using the light sensor as proximity sensor was very hard because of ambient light not being uniform everywhere. After trying a lot, including implementing a high pass filter (code) (ambient light is very low frequency; almost DC like), the best way turned out to be to use it to detect object sticking right in front of it. If the object is wide enough, it will block most of the ambient light and hence the reading would be uniform. Since we are talking about dead-on collision of the sensor and object, it was important to have some cushion to avoid strain on AlphaRex's leg. I used the supplied rubber connector to give some springy load to it. Check the video to see how the tilt and stride sensors are added.

The program has three different threads: one is movement (motor control), the second is navigation (obstacle avoidance) and the third is command (user commands). The navigation and command threads are just some test routines and can be easily extended for other fun stuffs. The state table can also be extended to include backward movement and dancing movement etc.

Lego mindstorms NXT

2008-07-05T15:00:00.004+03:00

So, I got myself a lego mindstorms NXT set to play around with robotics. It's pretty cool kit for a starter. It has surprisingly very powerful on board computer (called NXT brick) that has 2 processors (32 bit main processor and 8 bit co-processor). Most other 'expensive' robotics kits usually have very small rudimentary controller (such as an 8 bit microcontroller) and depends on external computers for real work.

It also has got servo motors instead of stepper motors like other kits. Servos are known to be more accurate since you get positional feedbacks while stepper motor is open loop system, albeit more difficult to control. You get to learn control systems to take full advantage of the motors.

The firmware is pretty powerful as well; supports multithreading, has full blown servo control (allowing you to micro manage your motors), write programs in C-like language NXC and above all, it's open source! The only disappointment I have is with the number of servos with the set. 3 servos aren't good enough for robotics. You get to build a vehicle with 2 motors and then what?

The interesting part is the programming. The first thing you need to do after unboxing it is to ditch the bloatware called NXT-G software that comes with it and install Brix command center to program in NBC/NXC and start digging around the firmware APIs for real kicks.

My first try was with the "obstacle-avoiding enemy-stinging scorpion" based on official 'Spike' model. I just got rid of the decorative 'spikes' around it that does nothing better than entangling around chair legs. Pretty simple programming.

Next is to try out the official 'AlphaRex' model. I heard it's pretty hard to make it walk ...

We just had a baby girl!

2006-06-30T23:31:00.000+03:00

26th June 2:53am, Anjuta and I just had a cute baby girl! With the entry of third member in family, our lifes have changed and we are all in gear for the new comer. We are both very excited with the baby and looking forward to her new life. Mother is taking rest now but is recovering well. Our baby, Liya, cries a lot and we are having tough time getting sleeps (especially for Anjuta), but that's normal :).

Anjuta 2.0: Project properties

2005-08-11T20:19:00.001+03:00

It's been long since I wrote anything. Here is a shot of project properties that I have been working on for last couple of days.

2005-06-30T09:01:00.001+03:00

I just stumbled across this nice article by Nathan Willis about version numbers abuse in Open Source software releases. He presents quite a few examples to support the claim that the classic 'x.0.0 is a stable release' paradigm is no longer being respected in most open source softwares.

The fact is it is quite true and I have seen it done myself. The problem is, it simply doesn't seem to work with free software releases. There is a fundamental difference between commertial releases and free software releases. In commertial case, development releases are seldomn made public and most releases done are so called 'stable releases', mostly at the end of development cycles. I think the 'x.0.0 is stable release' fits more appropriately in this situation (since they can pretty much follow whatever numbering schemes inbetween for their developments).

In free software releases however, there is this 'release often' philosophy where pretty much any change in the software is released to the public. In this situation, the version numbers are more or less used to indicate the amount of changes done to the software (hence the major.minor.micro versioning scheme). So following this logic, foobar-3.0.0 is a major change from foobar-2.0.0, while foobar-3.1.0 is a minor change from foobar-3.0.0 and so on. This basically represents a visual scale for the users to grade the development of the software and to indicate how much change has occurred.

However, we also need to accomodate the 'development' and 'stable' releases within this scheme.

Anjuta 2.0 Devel: New website

2004-11-27T18:26:00.001+02:00

I spent the last couple of days learning CSS and as a show off to my newly acquired knowledge, I have given a nice facelift to Anjuta website and my weblog. Both use the same style-sheets and therefore follow the same theme. For a first-timer, it's not that bad.

Until this, I didn't realize how shitty some browsers can have the CSS implementations done. I had to go for several workarounds to make the CSS work in these browsers. Especially useful in this quest was this particular Unofficial Internet Explorer hackery which allowed conditional HTML codes to get included in head section if IE is used. It is also possible to check for the right version of IE using the same syntax. Here is what I did:

<head>
   ....
   <link href="css/default.css" type="text/css" rel="stylesheet">
   <!--[if IE 6]>
   <link href="css/default-ie6.css" type="text/css" rel="stylesheet">
   <![endif]-->
   ....
</head>

The idea is to override some css properties for IE. The style-sheets, so far, work fine with mozilla and IE6. But IE5 completely gorks on it and I am sure other browsers will also break. I should remember to fix it in the near future. CSS is a powerful web technology, but until all the browsers implement the specifications correctly, there's going to be lot of problems. No doubt all the web developers in world are already facing it.

Anjuta 2.0 Devel: Test Shell

2004-10-11T19:29:00.003+03:00

Lots of things have happened recently in Anjuta CVS. Some important additions are Symbol Browser plugin, a plugins browser/testing shell, initial debugger plugin and lots of bug fixes. Pavol Bosik did a nice work with the recent addtion of debugger plugin initial codes. Johannes is continuing working on version control plugin.

Symbol browser plugin is just half-done for now. It can load project symbols, but file symbols (current file) that shows up in the toolbar is not yet functional. The GtkUIManager, which anjuta uses for UI juggling, apparently is very limited in what toolbar components one can use. The common stuffs like buttons and toggle buttons are there, but more complex components like combo box entry and others are not available. Anjuta implements two components; entry and combo components for its own use. Entry component (EggEntryAction) was implemented long ago and the editor plugin has been using it. The combo action (EggComboAction) was recently completed (and tested). It is required for symbol browser plugin to display per-file symbols. I plan to complete the per-file symbols view soon. With that, symbol-browser plugin should be ready for prime use .. err .. testing. Here is screen shot showing symbol-browser plugin.

There will be one more problem with symbol-browser plugin's per-file symbols display. The GtkComboBox widget displays the list as menu. And that could be a problem when there are lots of symbols -- driving the menus out of screen display. The classic "show as list" combo, which was scrollable, is probably possible, but I haven't yet figured out how to bring it back in the new GtkComboBox widget.

The todo plugin is fairly working. I added the code to load/unload a todo file. There is still a bug which makes it not to refresh when a project is loaded/unloaded. I should remember to fix it sometime soon.

The new "Test shell" (for the lack of better name) is a step forward for plugins developer. It allows to browse currently available plugins and selectively activate or deactivate them. This should make developing/testing plugins easier. Earlier, whole anjuta had to be launched everytime a plugin is tested and that was quite annoying. Here is a screen shots showing the new test shell.

Anjuta 2.0 Devel: File Wizard plugin

2004-09-15T19:57:00.002+03:00

I finally completed and committed the "New File Wizard" plugin.

Anjuta 2.0 Devel: Todo plugin

2004-09-09T19:43:00.002+03:00

For sometime I have been thinking about a TODO manager plugin for Anjuta and have been putting it off because of somewhat depressing thought of creating it from ground up. The true light and inspiration to start on this came when I discovered Gnome TODO list manager project and so here it is.

Here is a screenshot showing a TODO manager plugin in Anjuta. The plugin is directly based on Gtodo project by qball (at) qballcow.nl. I took the source, separated the main UI from the central widget and created a plugin out it.

The work is still under progress. The plugin UI (menus) and preferences are yet to be integrated into Anjuta. So far I haven't yet contacted the author regarding Anjuta integration, but I plan to do so when I have properly segregated UI out of central widget's way, which is right now all mingled in gtodo code.

Once segregation is complete, the central widget and it's associated elements can be put in a separate library (in Gtodo project) and the UI (windows, menus etc.) can then use this library to build gtodo binary. At Anjuta's end, it can utilize this gtodo component library to build its plugin. Somewhat like we are doing with devhelp plugin.

More updates to come ...

Violation of (basic) human rights in Manipur

2004-08-04T19:24:00.001+03:00

I have been closely monitoring the news for happenings in Manipur. Unlike a few days ago, it seems like we are getting some attention from top indian media. Things are moving forward and central leaders are evaluating possible solutions for the troubles in Manipur. However, there doesn't seem to be any indication of central leaders agreeing to remove AFSP act yet.

Especially enlightening among the news is this one. Apparently, a women has come forward as eye witness to give her account on what happened at the time of murder. According to her report, she saw some army persons in uniform taking a body of a woman towards the scene of crime and she heard some 5 to 6 gun shots about a fews minutes later.

Notice the emphasis above. This makes one thing very clear. The original statement given by Assam Riffles that the woman was shot while she tried to escape is a lie. Either she was dead before they brought her there or she was severly injured. And one does not need 5-6 shots to prevent near-dead someone escaping, assuming she indeed tried to escape.

I found this interesting and comprehensive article on Armed Forces Special Powers Act (AFSP Act) describing everything about this draconian legislation. Some of the flaws in the act, which make this act rather inhuman and violate basic human rights, are quoted below from the article. Particularly disheartening is section 6 which protects them against legal procecutions.

The army can shoot to kill, under the powers of section 4(a), for the commission or suspicion of the commission of the following offenses: acting in contravention of any law or order for the time being in force in the disturbed area prohibiting the assembly of five or more persons, carrying weapons, or carrying anything which is capable of being used as a fire-arm or ammunition. To justify the invocation of this provision, the officer need only be "of the opinion that it is necessary to do so for the maintenance of public order" and only give "such due warning as he may consider necessary".
The army can destroy property under section 4(b) if it is an arms dump, a fortified position or shelter from where armed attacks are made or are suspected of being made, if the structure is used as a training camp, or as a hide-out by armed gangs or absconders.
The army can arrest anyone without a warrant under section 4(c) who has committed, is suspected of having committed or of being about to commit, a cognisable offense and use any amount of force "necessary to effect the arrest".
Under section 4(d), the army can enter and search without a warrant to make an arrest or to recover any property, arms, ammunition or explosives which are believed to be unlawfully kept on the premises. This section also allows the use of force necessary for the search.
Section 5 states that after the military has arrested someone under the AFSPA, they must hand that person over to the nearest police station with the "least possible delay". There is no definition in the act of what constitutes the least possible delay.
Section 6 establishes that no legal proceeding can be brought against any member of the armed forces acting under the AFSPA, without the permission of the Central Government. This section leaves the victims of the armed forces abuses without a remedy.

So much of law and order situation being bad in Manipur, there is no proper law in the first place *sigh*. This is not the first time such crime by army has happened. Many such incidents have happend before at alarming density and they have gone unnoticed by the media. Manorama's brutal murder was just the last straw.

Anjuta 2.0 development

2004-07-27T18:55:00.002+03:00

After a long break, I polished up some of my un-committed changes in Anjuta cvs head. The preferences now use gconf system, but there are still more work to do in plugins to properly use it. gconf schema files need to be created and certain 'domain' need to be defined in preferences keys to enable groupings. Right now, there is no such grouping and all preferences are dumped together in a single gconf directory. Also, proper gconf notifications need to be implemented in plugins.

Here is a screenshot of what I am working on:

One interesting feature is the "Context menu merge", which allows plugins to merge their own context menus into other plugins. For example, Debugger plugin can merge its context menu into Editor plugin's menu for setting breakpoints and variable inspections. The merged menu can be manipulated (including, unmerged) by the owning plugin independent of the host plugin. Of course, rest of the communication and notification is through shell. Following screenshot highlights a build context menu merged by Build plugin into File Manager's context menu and controls it depending on what sort of build system is found in the directory.

Apart from these, a file loader plugin has been implemented that loads plugins based on file mime types. File manager plugin now uses file loader plugin to open files. GDL library has also been updated with newer changes. Overall, the changes are ready to be committed in CVS, which I will do in a couple of days.

Funny: ROTFL Bug report

2004-07-21T14:20:00.001+03:00

I just came across this hilarious bug report for GTKRadiant project. Have a nice laugh. My friend TTimo must have found it amusing when he got the bug report (He is the admin of GTKRadiant plugins and helped in Anjuta development in past).

Food: Quick egg noodles

2004-07-21T10:09:00.001+03:00

If you are tired of eating plain maggi or raman, try this out and you will like it. This is an ultra quick way to cook up tasty and nutritious noodles. It takes about 30 more seconds than vanilla noodles.

Ingredients: A pack of noodles (maggi, raman etc.), one tomato, some peas (20 to 100 peas) and two eggs.

Procedure: Heat 1.5 cups of water with the peas until it boils in one stove and start boiling the eggs in another stove. Put noodles, tastemaker and sliced tomato in the boiling water. Cook it for 2 mins. By the time noodles is ready, the eggs would have been half-boiled (make sure the eggs are no more than half-boiled). Stop the stoves and cool the eggs in cold running water. Break the eggs in middle and use a spoon to take out pastury egg contents into the noodles. Stir lighty and serve hot.

Happy and Sad

2004-07-20T18:31:00.001+03:00

Today, I was both happy and sad. Happy because I talked to Anjuta (my fiancee) on phone and it was really nice. We talked about situation in Manipur (my previous blog entry) and how lonely we felt without each other. She is right now in Manipur, while I am still in New Delhi and we are not expected to meet before our marriage on Oct 25.

I am sad because one of her close friends (and my friend too) has recently eloped with a guy (subsequently known as "the guy"). Well, nothing odd about it, execpt that the guy is not the one she intends to marry. She has a stable and committed relationship with another friend of mine and they have been into this relationship for a considerable time. They also have the committment to marry each other. Suddenly, this strange guy popped out of nowhere and caused a serious trouble in their relationship. Both my friends have been very heart broken on this.

We have a tradition of eloping before marriage and it seems to have become "the system". Normally, couples eloping is a way to tell their parents that they are ready to marry. As long as "the system" works this way, everything is fine.

Unfortunately, there are drawbacks to this approach and there are people, especially guys, who take advantage of this. They would force the girls to elope with them under questionable circumstances. Girls being "caught" in the situation without any possible recourse, have to either accept the marriage proposal or suffer moral setback (for being involved with a guy she is not marrying). This makes it rather hard to draw a clear line between elopement and abduction. Strange that our society still belives in this lousy system.

Something similar has happened to my friend. Apparently, neither she nor her parents in any way seem to be interested in a marriage with the guy. They have only known each other for a month or so. There might have been some flirting between the two, but that does not justify the obvious unwillful elopement of my friend and putting her (and her boyfriend) in a jeoparadizing situation.

I don't have any further information on this, but if both my friends agree to continue their relationship despite this tragedy, I would expect some sort of deserving punishment for the guy (possibly involving police). But that would require my friends to cooperate each other and continue their committments, rather than surrender to the unfaithful social obligations.

End of Neverwinter Night

2004-07-20T18:16:00.001+03:00

I finally completed playing Neverwinter nights. It was a fun game and had a much better D&D ruleset than Baldur's Gate 2. It also had a much better graphics than BG2 (3D vs 2D). I am not a great games fan, but I do love playing intutive games and would sometimes spend quite a bit of time playing at strech. The game is little old, but I loved playing it.

Contrary to what I have read, the last fight (killing the evil Morag) was not that difficult, especially for a Wizard (which I was). In fact, it was quite easy and I doubt any other class would have handled it so comfortably). Here was my strategy (Warning: spoiler ahead).

The first assuring fact is that Morag is actually a wizard and her offence and defence are spells only. Because you can not rest inside the source stone and you will run out of your memorized spells pretty quickly (even before reaching Morag), you need to get some scrolls and potions before you enter the source stone. I suggest you get Greater spell mantle (15), Greater restoration (10), and some offensive spells (negative energy burst (5), Horrid witting (5), Fireballs (10), Summon animal VIII (4) etc.).

The first thing you need to take care is to protect yourself from the offensive spells from Morag. Just keep on putting spell mantles and you would be invincible. Note that Morag also seems to have quite a lot of Moleskin Disjunction spells (the best breaching spell) and she will constantly try to strip your spell protection down, but you don't have to worry as you have lots of spell mantles.

Meantime, you need to take care of other physical monsters cropping around. For that I engaged my henchmen (strong) and a greater fire elemental. Monitor their health and cast Greater restoration whenever necessary.

You also need to take care of those praying clerics first before you can do any harm to Morag. They protect Morag from various damages. The clerics are immune to quite a bit of things (mind spells, dead magic, disease, acid, fire etc.), but fortunately they are so absorbed in their prayer they won't harm you and they are very vulnerable to Negative energy. Drop some Negative energy bursts and they are doomed. I also left a Dire Boar around them, which took care of them, while I concentrated on other things.

Then bring down Morag's spell protection with a dispell magic and she is a kitten. Just continue casting your offensive spells and at last she will fall.

The only hard time was when she casts Time Stops, which makes you rather vunerable as you can't continue your spell protection. If she begins with a Moleskin Disjunction and follow with powerful offensive spells, you might die. But fortunately, the AI doesn't seem to be that smart.

The brutal murder of Manorama

2004-07-19T20:27:00.001+03:00

The brutal murder of Thangjam Manorama, on July 10, after she was taken under custody by armed forces with an arrest warrent has resulted in a chaos in Manipur (a state of India). As the police force try to suppress protests from various organizations and localities, a massive civil crisis (photographs) has been triggered resulting in many casualties. There even was nude protest against the "17 assam rifles" responsible for this brutal murder. It is perhaps the first time in India that such event has happened, clearly showing how frustrated the people of Manipur are with the abuse of power by armed forces. Even more frustating is the continued indefinite curfew and failure of the goverment to perform a judcial probe of the matter. Ten days have passed since the event, but the timeline of the event seems to show no progress in this judicial inquiry, which the govenment has been promising to do right from the begining. On the contrary, it seems govenment has some other explaination for not being able to conduct any justice.

Justice is a very expensive comodity considering the breakdown of law and order situation in Manipur. No doubt, a crime as gruesome, inhuman and sensitive for public as this one is, it would have been solved in hours in some other parts of world. But in Manipur, thanks to the abuse of Armed Forces Special Power Act, there seem to be no way for the people of northeast India even to get close to justice. It is difficult to guage the faith of Manipur as long as this power is abused by armed forces.

The state government has some concerns over completely removing this Act from the region, because it belives it might bring other adminstrative problems, notably from the insurgent groups active in the region. While the claim is true, letting the public suffer between the two powers is no justification. The govenment has also failed to ensure the safety of public (from the abuse of the act) despite getting its safety from the act. Sounds paradoxical?

My new home

2004-07-19T18:22:00.001+03:00

After a much debate over when I should look for a new home, I finally did it this month. My old residence was far away from my workplace and my new residence saves me 2 to 3 hours of commuting daily. It's a little expensive, but that evens out with the fuel and time saved. The hardest part of the shift was moving my stuffs. I decided to do it myself rather than hiring a movers-n-packers, because it was kind of fun. It took me 4 days of 1 trip per day of one-man hard labour (read: exercise) to complete it. Now, it's been three days I have lived in my new home and I find it quite enjoyable.

The most disturbing news in the last few days I have come cross is the fire in a school that killed more than 90 kids. Government is closing down more than 200 schools in the hope of preventing more such accidents. However, I wonder what will happen to the students of these 200 schools.