And then I had one of my bright moments. The NXT’s batteries were dead, and I didn’t feel like waiting ages for the batteries to charge. So I did what any sane person (read: redneck) would’ve done, and got out the power drill. First gear worked beatifully, but second gear had a tendency to… destroy things. As can be seen in the following carnage pics:

The first broken gear:

The first and second broken gear:

A gear cutting into the supporting beam o.O:

So after wasting two gears on that, we decided to call it a day and try with the NXT motors hooked up. No more breakage (what a surprise eh?)!

Oh, and I think I found my next project on the same site:
Tatra 6×6

So, behold:

// ==UserScript==
// @name           Reddit Pics
// @namespace      http://www.reddit.com/r/
// @description    Makes imgur links into the proper link
// @include        http://www.reddit.com/r/
// ==/UserScript==

var entries = document.getElementsByTagName("a");

for(var i = 0; i != entries.length; i++)
{
	var link = entries[i];

	// Is link to imgur
	if(/*link.className.indexOf("title loggedin ") != -1 && */link.href.indexOf("imgur.com") != -1)
	{
		if(link.href.split(".").length < 3)
		{
			link.title = "Original at: " + link.href;
			link.href += ".png";
			link.href = wtf_replace(link.href, "imgur.com", "i.imgur.com");
		}
		else if(link.href.indexOf("i.imgur.com") == -1)
		{
			link.title = "Original at: " + link.href;
			link.href = wtf_replace(link.href, "imgur.com", "i.imgur.com");
		}
	}
}

function wtf_replace(str, text, rwith)
{
	return str.substr(0, str.indexOf(text)) + rwith + str.substr(str.indexOf(text) + text.length);
}

Don't mind the custom replace function, it was to debug the regex, but I figure this could well be faster and I can't be arsed removing it.

Just set it to work on all of Reddit, and every link to imgur will be turned into the fast version.

In the months before the contest, a few hints are given out, like telling you which sensors you’ll be needing lots of. On the day itself though, you have around 6-7 hours of time to build and program your robot. And in my case an hour or so of that was wasted on reading a tutorial, as it had been a rather long time since I last worked with NXC.

Of course the base of your robot doesn’t have to be built that day, such a rule would just kill off all the non-Lego competitors.

I’d like to believe our team, At Random, didn’t do that badly with a second place, mainly because of a glitch that we still haven’t confirmed (but it is believed to be the afterglow of one of the lamps that gave too high a reading on the light sensor).

And in the name of team spirit and open-source software, have some code.
All of this code is written in NXC using the BricxCC IDE.

The first assignment – Go towards a random light source

The goal of this assignment was to break a beam of light (as done by our legendary pirate flag, it was talk like a pirate day anyway), and then either go left or right towards a light source. Which direction to go in was randomly selected.

/* Motor defs */
#define LMOTOR OUT_B
#define RMOTOR OUT_C
#define MOTORS OUT_BC

/* Motor control defs */
#define Fwd(motor, speed) OnFwdReg(motor, speed, OUT_REGMODE_SYNC)
#define Rev(motor, speed) OnRevReg(motor, speed, OUT_REGMODE_SYNC)
#define TFwd(motor, speed) OnFwd(motor, speed)
#define TRev(motor, speed) OnRev(motor, speed)

/* Sensor defs */
#define LIGHTLEFT IN_2
#define LIGHTRIGHT IN_3

/* Other defs */
#define STOPAT_1 40
#define STOPAT_2 25
#define LIGHTSOURCE 95

#define rotationspeed 60
#define rot90deg 420

int rotcount = 0;
bool side = false; // false = left, true = right

void turnLeft()
{
    RotateMotor(RMOTOR, rotationspeed, rot90deg);
}

void turnRight()
{
    RotateMotor(LMOTOR, rotationspeed, rot90deg);
}

task main()
{
     /* Sensor init */
     SetSensorLowspeed(IN_4);
     SetSensorLight(LIGHTLEFT);
     SetSensorLight(LIGHTRIGHT);

     /* Move to middle */
     Fwd(MOTORS, 65);
     until(SensorUS(IN_4) <= STOPAT_1);
     Off(MOTORS);

     /* Scan light source */
     if(Sensor(LIGHTLEFT) >= LIGHTSOURCE)
     {
         /* Turn left */
         turnLeft();
         Off(MOTORS);

         side = false;
     }
     else if(Sensor(LIGHTRIGHT) >= LIGHTSOURCE)
     {
         /* Turn right */
         turnRight();
         Off(MOTORS);

         side = true;
     }

     ResetAllTachoCounts(MOTORS);
     ResetRotationCount(MOTORS);

     Fwd(MOTORS, 75);
     until(SensorUS(IN_4) <= STOPAT_2);
     Off(MOTORS);

     // Left
     if(side == true)
     {
         turnRight();
         turnRight();
         Off(MOTORS);
     }
     else
     {
         turnLeft();
         turnLeft();
         Off(MOTORS);
     }

     Fwd(MOTORS, 75);
     until(SensorUS(IN_4) <= 180);
     Off(MOTORS);

     if(side == true)
     {
         /* Turn left */
         turnLeft();
         Off(MOTORS);
     }
     else
     {
         /* Turn right */
         turnRight();
         Off(MOTORS);
     }

     Fwd(MOTORS, 75);
     until(SensorUS(IN_4) <= STOPAT_2);
     Off(MOTORS);
}

The second assignment – line following

This is actually the assignment we kept as last, as it seemed to be the hardest one… boy were we wrong. We did it in about half an hour, and had to add an extra sensor to the robot for the sharp turns, and it worked. I proclaim another victory against the laws of physics and logic.
The most special bit about this code is the multithreading, which worked great, even without mutexes, probably because it’s only written once and read many times.
We had to up the light threshold in this bit, because the rear sensor didn’t have the special cardboard magic to stop other light from affecting it, but in the end it didn’t seem to make that much of a difference.

/* Motor defs */
#define LMOTOR OUT_B
#define RMOTOR OUT_C
#define MOTORS OUT_BC

/* Motor control defs */
#define Fwd(motor, speed) OnFwdReg(motor, speed, OUT_REGMODE_SYNC)
#define Rev(motor, speed) OnRevReg(motor, speed, OUT_REGMODE_SYNC)
#define TFwd(motor, speed) OnFwd(motor, speed)
#define TRev(motor, speed) OnRev(motor, speed)

/* Sensor defs */
#define LIGHTLEFT IN_2
#define LIGHTRIGHT IN_3
#define LIGHTBACK IN_1

/* Other defs */
#define SPEED 35
#define TURNSPEED 20

#define LINE_lower 25
#define LINE_upper 50

int leftSpeed = 0;
int rightSpeed = 0;

task leftWheel()
{
    while(true)
    {
        TFwd(LMOTOR, leftSpeed);
    }
}

task rightWheel()
{
    while(true)
    {
        TFwd(RMOTOR, rightSpeed);
    }
}

task checkSensors()
{
    while(true)
    {
        if(Sensor(LIGHTLEFT) > LINE_upper && Sensor(LIGHTRIGHT) > LINE_upper)
        {
            leftSpeed = SPEED;
            rightSpeed = SPEED;
        }
        else if(Sensor(LIGHTLEFT) <= LINE_upper && Sensor(LIGHTRIGHT) > LINE_upper)
        {
            leftSpeed -= TURNSPEED;
            rightSpeed = SPEED;

            if(Sensor(LIGHTBACK) <= LINE_upper)
            {
                leftSpeed = -100;
                PlayTone(500, 250);
            }

            if(leftSpeed < 0)
                leftSpeed = 0;
        }
        else if(Sensor(LIGHTLEFT) > LINE_upper && Sensor(LIGHTRIGHT) <= LINE_upper)
        {
            leftSpeed = SPEED;
            rightSpeed -= TURNSPEED;

            if(Sensor(LIGHTBACK) <= LINE_upper)
            {
                rightSpeed = -100;
                PlayTone(500, 250);
            }

            if(rightSpeed < 0)
                rightSpeed = 0;
        }
    }
}

task main()
{
    SetSensorLight(LIGHTLEFT);
    SetSensorLight(LIGHTRIGHT);
    SetSensorLight(LIGHTBACK);

    Precedes(checkSensors, leftWheel, rightWheel);
}

The third assignment – line detection

This was the simplest and hardest of all. A contradiction you say? Pah!
The premise was dead easy: drive in a straight line and back again, crossing 3 black lines, but not a fourth. At the detection of each black line, but not the gray lines, you had to beep. When going back, you had to detect both lines (to see when to stop), but only beep on the gray lines. This proved tricky for many teams as white + black = gray, and of course there’s this very tiny bit of a black line that the sensor sees as being gray. We solved this by waiting a bit before the final sensor poll that’d have to tell us which colour the line was, to make sure the robot wasn’t in that pesky gray area.

/* Motor defs */
#define LMOTOR OUT_B
#define RMOTOR OUT_C
#define MOTORS OUT_BC

/* Motor control defs */
#define Fwd(motor, speed) OnFwdReg(motor, speed, OUT_REGMODE_SYNC)
#define Rev(motor, speed) OnRevReg(motor, speed, OUT_REGMODE_SYNC)
#define TFwd(motor, speed) OnFwd(motor, speed)
#define TRev(motor, speed) OnRev(motor, speed)

/* Sensor defs */
#define LIGHTLEFT IN_2
#define LIGHTRIGHT IN_3

/* Other defs */
#define SPEED 65
#define WAITTIME 200

/* Line defs */
#define DARKLINE_lower 25
#define DARKLINE_upper 35

#define GRAYLINE_lower 39
#define GRAYLINE_upper 43

int blackcount = 0;
int graycount = 0;
int sensorvalue = 100;

task main()
{
    /* Sensor init */
    SetSensorLowspeed(IN_4);
    SetSensorLight(LIGHTLEFT);
    SetSensorLight(LIGHTRIGHT);

    /* Run 1 */
    while(blackcount < 3)
    {
        Fwd(MOTORS, SPEED);
        until(Sensor(LIGHTLEFT) <= DARKLINE_upper);

        if(blackcount < 2)
            Wait(WAITTIME);
        Off(MOTORS);

        PlayTone(500, 250);
        blackcount++;
    }

    Rev(MOTORS, SPEED);
    Wait(WAITTIME);

    /* Run 2 */
    blackcount = 0;
    while(blackcount < 3)
    {
        Rev(MOTORS, SPEED);
        until(Sensor(LIGHTLEFT) <= GRAYLINE_upper);

        Wait(20);
        sensorvalue = Sensor(LIGHTLEFT);

        NumOut(1, 1, sensorvalue, 0);

        if(blackcount < 2)
            Wait(WAITTIME);
        Off(MOTORS);

        if(sensorvalue >= DARKLINE_lower && sensorvalue <= DARKLINE_upper)
        {
            blackcount++;
            Wait(WAITTIME);
        }
        else if(sensorvalue >= GRAYLINE_lower && sensorvalue <= GRAYLINE_upper)
        {
            PlayTone(800, 250);
            graycount++;
        }
    }

    Rev(MOTORS, SPEED);
    Wait(500);
    Off(MOTORS);
}

I hope the code is of use to you, and it’s as much fun for you figuring out what it does as it was for me figuring out how to make it do it.

Keep an eye on this thread, it’ll have more videos of the action cam on our robot, and probably pictures too.

There was at least one person who liked the idea, Xander, and we agreed to make some plans (and robots ofcourse) for it. So yesterday I got cracking in Lego Digital Designer, and poked something together. And today I got out the Lego and started building. Thanks to LDD’s building guide, it was done rather quickly, although I spent 90% of my time reordering my Lego in order to find the components I need. It’s very small, and hopefully quite agile.

Front view:

Front view of CTFBot 1

Other front view

As you may have noticed, the part for picking up the flag isn’t quite done. That’s mostly because I’m not sure yet how that’ll be achieved. I was thinking of attaching a magnet to it, and hopefully holding on the the flag that way (and just drive against the wall or so to shake off the flag).

Well, this was the easy part. What I need to do now is write the code to find the *right* flag, bring it to the *right* base, and then stop.
For the first incarnation anyway, because the goal is to eventually be able to steal the flag from an opponent, bring it back to your base, etc.

More information on the CTF game will follow soon (I hope).

And all of this with just a little bit of CSS:

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document domain("uni16.ogame.nl") {
body { height: 100% !important; width: 100% !important; margin: 0 !important; overflow: auto !important; }
#header_top, #content { width: auto !important; }
#content center { text-align: -moz-left !important; }

#content, #header_top { height: auto !important; left: 0 !important; position: relative !important; margin-left: 125px; margin-right: 5px !important; }
#content { top: 0 !important; margin-right: 30px; }
#header_top { overflow: auto !important; }

#content center table { width: 100% !important; }

center #combox_container { display: none !important; }

#content center td.b { background-color: #445576 !important; }

td.l { background-image: none !important; }
td.l:last-child { background-color: #3F5277 !important; }

td.k input { font-size: 1.3em !important; }

form#ressourcen td.k { font-weight: bold; }

td.header font { font-style: normal !important; }
#header_top * { text-align: -moz-center !important; }

#menu { width: 115px !important; margin-left: 5px; }
#menu nobr { display: none; }

/* */
#ResourcesDiv { position: relative !important; }

#errorbox { top: 12px !important; position: absolute !important; background-color: #BB0000; width: 80px !important; left: 170px !important; }
}

This should work on all Ogame sites using the ‘old’ layout. When the new layout comes, I’ll quit for sure, as it’s obviously been made by a madman on LSD.

I know, I know, I’m not the first one to rant about this, and I most certainly won’t be the last.

PHP is pretty much the only language I know deeply, and I’ve been working with it for ages. About 6-7 years I think, I’m never sure. It’s an excellent tool for building websites, but it has a dark side. And this side is very dark indeed; it’s called simplicity. PHP is so simple every idiot with a keyboard can slap his hand onto it and find a functional piece of code.

And here is where I like to make a rather important distinction between functional and working. A functional page does the job, but doesn’t necessarily do it properly. A working page on the other hand does the job, does it properly, and tries to do it as efficiently as possible.

You can probably guess where I’m going with this: in PHP, the difference between a functional and a working page is humongous. The smallest child can hack something together and call it his homepage, but not a lot of people actually know the intricacies and best practices that can make PHP a rather nice and powerful language.

This is why PHP needs developers with experience and a will to do the right thing, to optimise away and to see the errors in their ways. There are saddeningly little of these people. In fact, off the top of my head, the ones like this I can count on one hand. The rest more often than not say “but it works!”. But it doesn’t.

Of course, the same can be said for many other languages, including CSS: easy to cock about in, but hard to master.

You shouldn’t think that this is the only problem though; there are many others. And the problem just keeps on growing and growing. There have been a great many bad design decisions in PHP; register_globals, safe_mode, magic_quotes_gpc, short tags, just to name a few.

And now they’re doing more! Sure, they’re removing the previous design cockups, but they’re adding new ones. New ones that could be worse than ever, and with a reasoning even someone on LSD wouldn’t even be able to follow. If you’re been following the evolution of PHP lately, you’ll probably know what I’m going at: the new namespace separator. This is in my eyes one of the biggest atrocities they could’ve done to a decent language.

I mean, seriously, a backslash? That’s about on par with a smiley face (note: also suggested in that article). I see it going horribly wrong on so many levels it wants to make me cry (a namespace called ‘n’ called inside a double quote string anyone?).

Ever since they’ve been talking about namespaces in PHP, I’ve had my mind set on a decent way to do it: namespace inclusion. Sure, it wouldn’t be as pretty as in some other languages, but atleast it wouldn’t break backwards compatibility. I’ll set out my original idea to you.

Basically, it’d use the commonly ignored comment character #. Right now, # is a character used for single-line comments, just like //. I’ve perhaps come across one script that uses it, and I’ve seen my share of scripts. So no harm done if it gets a different meaning I’d say.

A meaning used in the form of:

<php
#using mynamespace

myFunction(); // It's really mynamespace::myFunction();
?>

And you could take that even further, using the #using directive as a way to signal to the interpreter “this namespace will be called upon, reserve it”.

So then it could be used in the way of:

<php
#using mynamespace

mynamespace::myFunction();
anothernamespace::aFunction(); // Would throw an error

class mynamespace { } // Would also throw an error
?>

This way the interpreter could reserve the name of that namespace and throw an error if any class tries to declare itself as that namespace.

I know, perhaps not the prettiest of ways, but it’s work, and we’d be able to keep the :: operator.

Or, you know, they could just make a namespace a static class and allow the nesting of classes. Problem (somewhat) solved!

So naturally I look up guides and wiki pages and whatnot about the subject, research a language (I took Haskell because everyone says it’s awesome), etc. But every time I do so I just scratch my head and have a rather blank stare… It seems completely alien to me, and there’s hardly any aspect of it that I understand or even find remotely logical.

Some people have been trying to convince me it’s just because I’m unwilling to learn it properly. I disagree with that. And here start my contemplations on the subject.

I have problems with maths, I even have a proven learning disability called dyscalculia, which causes me to be very bad at calculating things and remembering formulas amongst others. And I believe this is why I have difficulty grasping most of functional programming: everything seems to have its roots in maths, and to truly understand it you have to understand its roots. Which I can’t. Which is a problem.

Now, ‘regular’ programming, AKA imperative programming, I have absolutely no problems with. And I like to believe this is because my brain seems to be geared rather towards logic, on which all imperative languages are built. Describing what to do to a computer by telling it how to do so seems much more logical to me than the functional programming approach, which just tells the computer what to do, with seemingly little control of the how.

To prove my point further: I recently found my true love to be with Assembly, because I find it to be so awesomely logical. I finally know how everything is done at the lowest level I can comprehend (no, I don’t have a built in hex translator), and it helps me write better imperative code in other languages. Functional programming just doesn’t give me the idea that I’m programming and making the best and most performant piece of code I can, as I don’t control what the compiler thinks I mean with a certain command.

So, to sum it up:
1 xor 0 = <3
1 !^=< 0 = the hell?
Note: this may or may not be an actual Haskell operator, but I wouldn’t be surprised if it was.

I suppose only time will tell…

Well done Wordpress, you’ve certainly improved!