gronbaek.net

Det er muligt at forbinde til SDU’s netværk i Ubuntu via VPN. Denne guide er skrevet med henblik på brug af Ubuntu 8.04 og Gnome.

Der er nogle generelle oplysninger på SDU’s hjemmeside inkl. en installationsguide og en link til en Cisco klient der kan downloades. Det ser dog ikke rigtig ud til at der er nogen klient at downloade, men klienten skal heller ikke bruges her. I installationsguiden står der at man skal bruge et gruppenavn og gruppepassword, og at det kan fåes ved henvendelse i Helpdesken. Jeg har modtaget mit direkte fra mit institut, så jeg har ikke prøvet helpdesken, men man skal bruge begge dele for at guiden virker.

I Ubuntu skal man have installeret pakkerne “network-manager-vpnc” og “vpnc”.
sudo apt-get install vpnc network-manager-vpnc
Derefter er det nødvendig at genstarte network-manager og den nemmeste løsning er simpelthen at genstarte computeren.

Nu kan man konfigurere VPN forbindelsen ved at venstre-klikke på NetworkManager ikonet i statusbaren og vælge “VPN-forbindelse” og “konfigurer VPN”.

1. Vælg “Tilføj” og følg skærmene igennem.
2. Vælg Cisco VPN-klient.
3. Udfyld “Required” på det første faneblad. Mit gruppenavn er tekvpn, men det er afhængigt af hvilket fakultet man er tilknyttet.
4. Under “Optional” udfyld dit brugernavn (inkl. domæne på formen: “domæne\brugernavn”) og vælg “Brug domæne til brugerverification”. Mit domæne er “tek” men det er naturligvis afhændigt af fakultetstilknytning.
5. Sidst men ikke mindst skal man vælge “Enable weak single DES encryption”.

Så er det muligt at logge ind ved igen at venste-klikke på NetworkManager ikonet i statusbaren og vælge “VPN-forbindelse” og klikke på den nyoprettede VPN forbindelse og udfylde gruppepasswordet og det almindelige password man bruger til at logge på domænet.

Det er OK at bemærke det ironiske i at man skal sætte flueben i “Enable weak single DES encryption” når der på SDU’s oplysningsside står “Benytter 3DES kryptering (168bit) og betragtes som den mest sikre protokol”…

So, it’s been really long since I last put a new post up, and I’m going to try to remedy that in the near future, after my exams. I have a couple of post in queue right now:

• Part 2 of the Sokoban robot post, detailing the construction of a Sokoban game parser, an A* routine for finding paths written in Java, and a translator routine for the route, so the robot can follow it.
• A new AI post about implementing a Neural Network in Java. Used for playing LUDO, but probably general enough to be used for other things.

The post about using Sunbird and a SE phone generated a lot of traffic, so I’m going to try to follow up on that to, since people apparently like those kind of cookbooks. So more Ubuntu experiences coming up as I get my notes sorted out.

I’m going to start on my master thesis in a few weeks, and I’m going to use this blog as a sort of project journal. So hopefully I’ll have lots of stuff to post during the next 12 months :-)  This also means that I’m about done with the approximately one million projects we have undertaken during the years, so I’m going to try to sort through my archives, and see if there’s something that worth making publicly available, and commenting a bit on that.

Finally I just wanted to point to a small very intriguing game Cursor*10, which was also featured on digg a little while ago. Just goes to show, that as all computer gamers know, game play can be so much more important that graphics. I mean… it’s even in mono-chrome. Fantastic…

And lastly, the blogroll has been updated, since Lars has moved his blog, now that he was finally pressured into handing in his thesis. Congrats, Lars.

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.

So, just starting on a new course, on the basics of modern AI. Our first project is going to be an AI controlled robot, which is suppose to solve a Sokoban puzzle.

We are going to use classic AI techniques, GOFAI (Good Old Fashion Artificial Intelligence), which means that we are going to create a real world model, and then program the robot in offline-mode.

Once again the robot is going to be constructed from LEGO, and use a Mindstorms NXT as controller. Hopefully the construction phase is going to be a bit simpler than with Steve, the crocodile. And again, we are probably going to use the Not Exactly C (NXC) language for creating the software.

The controlling software, which we would like to concentrate our effort about in this project, is really going to be a multi-layered, multi-task software, instead of a huge block of functions performed in sequence, as it was the case with the crocodile. The software and structure is really going to be inspired by Rodney A. Brooks robot, Genghis, from 1989

There is more about Genghis at http://groups.csail.mit.edu/lbr/genghis/ including Brooks paper on the robot and the AI used.

More to come, as we get the robot constructed next week.

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