gronbaek.net

To compile Delta3D it is necessary to first create a solution file for a IDE (or some other environment) and then build the project using that tool. Delta3D 2.1.0 does not come with pre-created VS2005/8 solution files like older versions of Delta3D did.

To create a VS2008 solution for Delta3D 2.1.0 first obtain the following programs/sources:

1. Download Delta3D 2.1.0 from Sourceforge.
2. Download Delta3D 2.1.0 dependencies from Sourceforge.
3. Download the open source C++ edition of Qt from Trolltech.
4. Download NMake build tool from Microsoft.
5. Download CMake build tool from cmake.org.

Now you have the resources you need to be able to start the build process. Please notice that the version of Qt to download must be the source code (src) version, not the MinGW version, which Delta3D can not use. Now you need to install nmake, cmake and the other tools. I am assuming that you already have VS2008 installed…

1. Install NMake - create a directory for NMake, for example C:\Program Files\NMake and move the NMake executable file to the new foldet. Run the file and it will unzip to a couple of files, among them nmake.exe.
2. Install CMake - just follow the instructions.
3. Unzip the Qt package to where you will want it installed, for example C:\Qt\4.4.3 (depending on version).
4. Install Delta3D from the executable - again just follow the instructions.
5. Unzip the Delta3D dependencies package to your Delta3D installation folder, for example C:\Program Files\Delta3D_REL-2.1.0. The package contains a single folder, ext, which you should overwrite the existing Delta3D ext folder with.

Now the tools are basically installed. The first step is then to compile Qt:

1. Add NMake to your path - For example add C:\Program Files\NMake to your path varialble if that is where you installed the NMake tool.
2. Add the Qt bin folder to your path - If you installed Qt to C:\Qt\4.4.3 then add C:\Qt\4.4.3\bin to your path.
3. Start a Visual Studio 2008 Command Prompt, not the usual cmd but the VS2008 one so that Qt can find the compilation (cl) and linking (link) tools.
4. Navigate to the Qt folder, for example C:\Qt\4.4.3, and run “configure.exe -platform win32-msvc-2008″ which should create a file called “Makefile” in the Qt directory.
5. Run NMake by typing “nmake” and wait while Qt compiles… this takes a LONG time.

Now that Qt is installed you are able to create a VS2008 solution file for Delta3D:

1. Open the CMake tool. Select the CMake entry in your start menu (not the cmake-gui).
2. Open an explorer window and drag the CMakeLists.txt file from the Delta3D folder into the CMake window.
3. Click configure and wait while it checks your system. If it complains about QMAKE missing, find the relevant entry (some where in the bottom of the configurations in CMake) and point it to the qmake.exe in your Qt bin directory, and press configure again.
4. When successfully configured press OK.

Now you have a VS2008 solution file in the root of your Delta3D folder. Open that with Visual Studio and build as necessary.

Quick rant… if you, like me, use Ubuntu Hardy Heron or some other Linux distribution with SCIM enabled, and for some reason can’t use the ctrl+space auto-completion feature of Eclipse, check your SCIM key settings. In Hardy Heron SCIM gets input before other applications, like Eclipse, and ctrl+space is captured by SCIM and not send on to Eclipse. To get rid of that, simply delete that combination.

I don’t know why SCIM got enabled in the first place, but it’s pretty annoying. I know it makes you able to write Chinese characters ect. on the fly, but I don’t really need that! At first it had a bloody obnoxious input window pop-up all the time, but that’s easy to disable. For some reason the SCIM status icon in the panel can’t be removed. It has an exit option, but choosing exit only closes the program for a split second, after which it simply starts again. My best advice is simply to delete all keyboad shortcuts.

Really annoying!

The objective of the AM36 2007 course was to build an animal-like robot, using Lego Mindstorms NXT, for the RobotsAtPlay Festival 2007. Specific requirements included: Not using wheels for propulsion, some form of interactivity available, and ready in two weeks.

Designing the Robot

The following drawings were made for the initial design of the robot.The head and body were implemented in the basic style sketched here,while several changes were made to the design of the legs. Additionally, some of the planned sensors were not used, and the activities linked to those sensors not implemented.

Head design and a first draft of possible design for legs.

Body seen from top. Approximate proportions, and sensor placement.

The following sections are the design document containing the original plans for interaction, software, use of sensors etc.

Concept

The Lego Crocodile is an interactive Lego model, resembling in outlook and behaviour a real crocodile. The model is capable of moving around, either because of activity in its proximity, as well as by its own will. The model will in general remain passive, seeking to obtain a position in the sun, as other animals in the reptile family. Occasionally it will become active, either seeking a better position in the sun, or scavenging for food in its vicinity. The model can also be activated by other animals or humans entering its proximity. Depending on a number of things, including the interval since last eating, the crocodile will attempt to either engage the disturbance, or move to another position to resume sun bathing.

Interactivity

To make the robot interactive, the robot processes sensory input simulating sound, sight and touch. The robot will also have additional behaviour patterns, which are driven by a schedule. Finally, a remote controller, using Bluetooth, can activate several functions of the robot.

Activity patterns

The robot will actively try to place it self in a lighted area, seeking sunlight as other animals in the reptile family. It will stay in the light for a period of time, unless disturbed, and occasionally seek out a better spot. The robot can be “stirred” by entering into its field of vision, and will then react according to several variables. Either moving towards the object in its vision, or trying to back away and finding a new place to rest. The robot will send out sounds, warning intruders of its mood. As well as vision, the robot will use hearing to react to objects coming close to it. If stirred by its hearing, the robot will try to move around, seeking to get the disturbance into its field of vision. The robot will seek out food thrown to it, if it’s hungry, and try to consume the food. (more…)

As written here, we have be doing a classic AI project for the last 3
month and got quite a good result. I’ll just post some material from
our solution, pictures, source code and some comments. There’s a
report available here as well. It includes some of the source code and
some explanation of the design, but does not detail everything.

Sokoban is described in the previously mentioned post, or you can
just try Googling (http://www.google.dk/search?q=Sokoban) it, if you don’t know it. When dealing with robotics
and AI, Sokoban is an interesting problem, because it simulates a
production environment, where the robot is handling crates in a
warehouse, and it combines robotics with a path planning AI
implementation.

The development was done in two parts, with several iterations in each
part. The first part was exclusivly about evaluating the physical
Sokoban field, and then designing and building a Lego Mindstorms robot
that would be able to solve the puzzle. The second part was about
developing a program for finding the solution, translating the soution
for the robot, and finally fine-tuning the robot.

The Sokoban Robot

Our physical Sokoban “field” consisted of a whiteboard with a grid made
out of black tape on top of it. Each cross section of the tape lines
counted for a cell in the Sokoban game, while walls were represented
by white background (cut off tape lines). So the basic idea was of
course to construct a robot, that could differentiate black from
white, follow black lines, and recognise the cross sections.

The robot was based on the standard robots from the LEGO Mindstorm
set, since we were in a hurry, and then adapted for our specific task.
We took an interative approach and simply build a first version of the
robot, without really working to much with specific construction
consideration. The standard robot was equipped with some light sensors for following the black line, and using some straight forward code, a few test runs were performed.

After a few test runs with the robot some obvious points to consider emerged:

1. the turning radius
2. the sensor sampling speed
3. sensor placement

Starting from the last point… the sensor placement was crucial to the effective movement of the robot. They needed to be close to the black line to ensure that the robot moves straight forward without zig-zag’ing, but still so far apart that the robot had time to react to the black line. The sensors should also be ahead of the robot, to increase the distance between the center of the robot’s turning point and the sensors, which increased the accuracy of the robot. At the same time the sensors could not get to far in front of the robot, since this makes the sensors move so fast, when the robot turns, that the sensor sampling rate becomes to slow. The robot simply doesn’t catch the black lines, when doing turns.

The placement of the sensors also influence the robots turning radius. To far ahead of the robot, and the robot would not be able to turn 90 degrees between to intersections of the lines, due to its increased length.

The turning radius was also influenced by the motors driving each wheel. At first the robot simply increased stopped one wheel, while continuing to drive on the other wheel. This turned out to be inadequate for making the turns sharp enough, so we had to do something additional. We then experimented with letting the wheels drive in opposite directions, which of course decreased the turning radius a lot. This solution did give other problems, including making the robot move past intersections in a sort of stop-and-go pattern, but in the end we stuck to that solution.

This video shows the robot being tested on a sample field. All the lines are unbroken in this example, meaning that there is no wall in this particular puzzle. You can see that the two sensors closest to the robot are used for following the lines, and thus controlling the robot. The front most sensor, which isn’t tested are only used when moving a diamond in the game, to ensure that it is placed right on an intersection.

In the end it turned out that a few modifications were needed before the robot was ready for the real Sokoban puzzle. More about this in my next post.

There is a report available on the complete development of the robot, and the path finding code used when solving the puzzle in this report: AI00 Sokoban Robot Report. The report has detailed chapter on the construction of the robot, incl. test of different sensor positions and different speed settings on the motors.

My next post will be an introduction to the Java program used for solving the Sokoban puzzle. It’s also included in the report above.

JAOO2007 is over, and I’m back from one day of tutorial and three days of conference. Got to see a lot of stuff, hear some great people, and talk to other developers and it-professionals. Didn’t quite get to see as much as hoped for, since working as crew this year definitely took more of my time than last year.

As previously said here I was participating in Diana Larsons “Leading Agile Retrospectives” tutorial. The tutorial was held Sunday before the conference and was joined by about 25 people. We were split in four groups and used the time before the lunch break for presentations and performing a simulated retrospective in the groups, with Diana as a leader. The goal was to try out some different techniques and the discuss how each group felt about using the technique and what results were achieved.

After lunch we worked with in groups again, analysing a “case” and coming up with a plan for a retrospective. Our group had a hard one, with a 20 people team using 30 day iterations, not currently using retrospectives and a completely failed project. Now the VP of the organisation had decreed the need for a project post-mortem, and everybody were suspecting that the board were out looking for somebody to blame. It was a challenge coming up with a retrospective that would convince the team that it was not about blame, but more about what to do better. We made quite a good plan, which I’ll try to write up and publish here later.

Anyway… the tutorial was definitely the best thing about JAOO2007 seen from my perspective. It was the first time I participated in one, and next year, I’ll try to get to participate in all three days.

The conference it self wasn’t bad of course. There were some really good speakers, and the exhibitors who had found their way to the main hall of the conference area, genuinely had some good products to show, and were willing to talk about technical stuff, and not just marketspeech.

I got to hear the following speakers (in no particular order):

• Refactoring Databases - Pramod Sadalage
• Testing Data Access Code Programmatically - Roy Osherove
• .NET Cardspaces - Rene Løhde
• Introduction to Spring.NET - Mark Pollack
• .NET Language Integrated Query (LINQ) - Luca Bolognese
• C# 3.0 Under the Hood - Mads Torgersen
• Scrum @ Yahoo - Gabrielle Benefield
• Democratizing the Cloud - Erik Meijer

and several others. Sadalage, Osherove and Bolognese immediately got to have their blogs added to my feed-reader. Gabrielle Benefield gave a very good presentation but doesn’t seem to have blog, most unfortunately. The best speaker I heard at JAOO2007 was probably Roy Osherove, who both had some neat techniques to show, but also held the entire audience at his presentation awake and focussed with his style and humour. He ended his session with a small performance by him self on guitar, singing a tune about database design. Fantastic.

Luca Bolognese also had a very good mix of humour and coding in his presentation. He had 3 slides and then proceeded by writing code in a tweaked Visual Studio 2008 for 50 minutes. And everybody was kept focused throughout the entire session. Mads Torgensen actually used the same style, but Bolognese was the master of the new dicipline “codetainment”.

In addition I had the opportunity to hear Robert C. Martin (Uncle Bob) talk about applying craftsmanship to programming. Don’t know how useful it was, but Uncle Bob is very entertaining, and has some very strong opinions on rules every developer should “live” by.

Finally some pictures from JAOO2007:

Charles Simonyi (inventor of Word and Excel) shows slides from his tour to space.

Ridehuset, the main food and party area. Monday night conference party.

The Sun Campus Ambassador from SDU being busy….

Part of the exhibition area, IBM and Google booths in the foreground.

Well, that was JAOO2007. Already looking forward to 2008, with even more tutorials for me.

In two days it’s time for the annual JAOO conference in Aarhus, Denmark. Again this year, my buddy Jesper and I will be participating, as crew. As student you need to work 12 hours, but the you’re free to participate in all tracks and sessions at the conference, get your dinner paid, and a party on Monday night. Definitely worth 12 hours of my time.

I have not completely decided all the tracks I’m going to participate in yet, but I’m definitely going to participate in the Leading Agile Retrospectives tutorial on Sonday, with Diana Larsen from the Agile Alliance.

I’ll probably also go and here Rene Løhde on Information cards and .Net - Cardspace, since I regularly follows his blog on Version2.dk… just get a feel for the man in person.

I know our local Sun Campus Ambassador at SDU is also going to participate, so he’ll probably also have some JAOO related stuff on his blog in a couple of days. It’ll be good for him to have something other than the iPhone prices to think about for once.

There is some videos, pictures and the source code for the robot available here

Can’t really say I enjoyed it, or even learned a lot, but at least it was a good opportunity to play with Lego.

When they say you can’t get to old to play with Lego, it’s only partly true. Sure, you still enjoy building stuff, but it comes together with a lot frustration when you can’t construct the things you designed on paper or in your head. You simply can’t remember what bricks are available, so you’re sort of building in the dark.On the other hand, the new generation of Mindstorm, the NXT, is a big step forward compared to the old RXT generation. The processing and wireless abilities makes the NXT much more “professional”, instead of the more toy-like RXT. And the new sensors enables you to build a whole different kind of robot. Much more realistic.

But building the robot is of course only half the fun. The programming is also challenging and (in some cases) rewarding. Unfortunately we managed to use most of the time available building, testing and re-building the robot, so only a small amount of time were left for programming the robot.We programmed the robot using BricxCC and the NXC programming language.

NXC is a lot like NQC and real easy to use if you know some C. There’s support for multi-threading, Bluetooth and all sorts of high-level functions for the sensors and motors. Even a PID regulator, which came in handy for us. The only thing missing is really professional debugger. That would have been nice.

So… I seem to have a couple of unfinished posts waiting in my drafts section. I’ll try to see if I can take some time before long, and really get some updates done.

In the mean time, I’m following the summer course AM36, at the institute, which takes up most of my time. The course is about basic robot construction, dynamical agents and the transferral of human activities to the robots. So far our practical work has consisted of designing and building a prototype robot, for sweeping Lego bricks of a whiteboard. The robot is build in Lego, using the newest type of Mindstorm, the NXT.

The robot features two wheels driven by a motor each, which propels and turns the robot. There is a small wheel on the backside of the robot, for supporting the upright position. The robot had some size requirements (20×20 cm), so we build the robot in an upright position, rather than horizontal. For sweeping we attached a propeller underneath the robot, between the two main wheels. The propeller is driven by a third motor, connected by a gear, so the rotation would be fast enough to shoot bricks off the field.

The test of the robot was done in competition with the other 5 groups robots. The main criteria was sweeping the board clear of all the bricks, in the shortest time.

Three heats was done, two with predetermined starting positions and directions, and one were the team could choose the start position and direction freely. Additionally the robot was judged by a number of criteria like aesthetics, robustness and morphology.

Disappointingly our robot ended at a total fifth place, mostly due to an unfortunate human error in the third heat, involving mixing up the wires for one of the wheels and the propeller.

Sweeper Robot Video 1 shows the first heat, where the robot completes in 43 seconds. Sorry about the pour quality of my mobile phone video camera.

The controlling program for the robot, was made in the Lego Mindstorm graphical language, and was very simple. We were only allowed two use the light sensors, so the robot is simply looking for the black border of the field, and reacting to it. Basically just running forwards with a slight right turn, and back again when detecting the black border of the field. We later found that if we are going to build and program more robots, we are definitly going to program them in NXC, which would have allowed us to access the build-in PID regulator of the NXT, and driving a much more precise route.

I’ve just added the report with my bachelor thesis to the projects page. It’s mainly an introduction to Wireless Sensor Networks (WSN) and to the techniques used by positioning systems like GPS and Ubisense.

WSN is introduced and some possible scenarios for use of WSNs are discussed. A discussion on the importance of the uses of automatic positioning systems, in relation to WSN is presented.

After that two positioning systems, GPS and Ubisense is introduced, and the technical functionality is briefly covered.

A common data storage structure for positioning data from the two different systems are investigated and a solution is proposed. The solution is implemented in a very basic form, and some tests are shown.

Read more here: Sensor Location in WSN

This project was made for the SSE03 course at SDU. It is an implementation of a language processor in Java for the language OBAS, which was constructed for the purpose of this project. The implementation is done in Java using Object Oriented techniques. The processor is specific for the OBAS language, but can be adapted to any language, if needed.

The processor developed consists of a lexical and a syntactical analyser, a translator and finally an interpreter. There is no contextual analysis, but the ground work needed for writing such an analyser, is covered in the code, so it should be no great problem to construct one if needed. The processor is based on examples and techniques discussed in the book Programming Language Processors in Java by David A Watt and Deryck F Brown. Information about the book and additional literature is listed in the bibliography of the report.

The report consists of several chapter describing each phase of the analysis, translation and finally interpretation. The OBAS language is described and some examples are shown in the report.

Java Language Processor Report

The archive file contains the source code, some what commented, for the OBAS language processor. The processor is written in Java, and a pre-packed jar file of the processor is included. There is some sample programs written in OBAS that can be tried.

Java Language Processor Source Code