After several days on and off of tinkering, I have finally managed to create a complete Ubuntu package repository. There were several major steps/features required in this project:

1. Generating deb files


2. Generating repository file structure


3. Generating package files


4. Generating release files


5. Signing release files

Over the next few days I will attempt to explain how I achieved this, step by step so others can follow.

I built my repository mainly as a method of maintaining desktop machines and servers on my internal network. It includes a few packages that aren't in the Ubuntu repositories (libdvdcss2, w32codecs, gaim2beta5 etc.), as well as a set of custom built packages and meta (virtual) packages used to configure desktops and servers automatically (still under construction).

I used several sources during this project (unfortunately I haven't kept track of them), no one of them I found to be entirely fulfilling, perhaps there is a difference between pure Debian repositories and Ubuntu repositories, or perhaps the process/tools/format has changed since those documents were written. Anyhow, my setup is running fine on Ubuntu 6.10 server/clients, so I hope these posts will be useful to others trying to create their own repository.

Well, our new line following robot is done. With any engineering project, you can always do more, but after tidying up the program, and tweaking values for a few hours, we came up with a reasonable configuration, able to complete out test circuit in an average of 40 seconds.

The robot is much quicker making left turns than right turns (as shown in the video below). When the robot looses the line, it will turn left to try and find it. If the path leads left, the robot will find the line again very quickly, and continue. If the path leads right, the robot will try to seek left, fail to find the line within a pre-determined time, then seek left to find the line.

The following images show a summary of the program, as shown by the graphical programming environment supplied with the NXT.

For those unfamiliar with reading NXT programs, here is a pseudo-code version:

Wait until sensor sees black
loop forever:
  move forward
  wait until sensor sees white
  call seek_left
  if sensor sees white:
    call seek_right

seek_left:
  loop 10 times:
    pivot left (move left motor backwards, and right motor forwards)
    if sensor sees white:
      wait 0.01 seconds

seek_right:
  pivot right (move right motor backwards, and left motor forwards)
  wait until sensor sees black
  wait 0.02 seconds

All in all, not bad for a few hours tinkering, we certainly enjoyed it. For those interested in seeing more, we recorded a video of the robot in action, and are also providing the program we used.
Download Video (2.95Mb, slow connection, 109secs)
Download Program (339Kb)

Fun and games last night. Bradley Robinson (who absolutely refuses to have his photo taken) bought a Lego Mindstorms NXT kit. Brad has had it a few days before I had a chance to see it. When I first saw it it was configured as a walking bi-ped, though it more a shuffle than a walk. The system has four sensors:

• Ultrasonic distance and movement sensor
• Sound sensor, with sound pattern and tone recognition
• Light sensor, detecting light intensity
• Touch sensor (press/release/bump detection)

and also three servo motors with rotation sensors.

After some discussion, food, and music, we decided to revisit our Bilby Competition days, where in Newcastle in 2000 we won 2nd place in the competition with "Little Jim", an autonomous path following robot.

The NXT kit comes with a paper "field" with lines and patterns printed on it for testing and sensing. Printed on this field is an inch-wide oval circle. Using this path and the single light sensor we started to build our robot.

Much of the challenge was similar to the original bilby, determining the best sensor placement, and adjusting sensor sensitivity. An additional problem encountered due to the single sensor was the fact that while correcting the robot would miss the path if it was moving too quickly. After several attempts to increase the accuracy of the sensing (trying to sense more quickly) the final solution was simply to slow down the motors.

A further limitation was the programming interface, a graphical interface with simple programming constructs. It took some re-arrangement of our logic to code. The pseudo-code:

WAIT UNTIL (2 seconds pass) OR (sensor sees black)

required re-factoring as:

LOOP 20 times:
  if sensor sees white:
    WAIT 0.1 seconds

The language does not allow the use of any sort of variable or constant, re-usable functions of any type, or multi-parameter tests (with ORs or ANDs), but after some rearranging the few problems we found could be overcome.

After some research it seems there are several other programming interfaces available for the NXT. I haven't tried any, but of the ones I've found, the promising ones are:

• Bricx Command Centre, with available debugger
• NXT Python
• nxtC

The blog nxtacy has many links to other projects and seems about the best resource for the NXT hacker.

The practical result is, after 3 hours tinkering (before 1. flat batteries, and 2. sleep time) we had an almost functioning line following robot.

With any luck tonight we will have a chance to finish and fine tune it. I'll report back with the end results and programming ASAP.

This post is followed up by This Post.

When you declare war on the neighbouring dorm, make sure you have a weapon of mass hydration!

At short notice today we decided to build a machine to launch water balloons at the neighbouring building. With the aid of Levi, we designed, acquired parts, and assembled in a few hours a lethal water balloon launching sling shot.

The weapon consisted of the following parts:

• 4 metres of bungee cord @ 1.25/mtr
• 2 sections of scrap wood @ $1 ea
• 4 180mm long 10mm dia bolts, and nuts to match @ ~ $2 ea
• left over piece of shade cloth

and of course 1200 water balloons @ $2 per 200.

We eventually got the weapon capable of firing water balloons from the upstairs balcony, over the neighbouring building, and into the car park on the other side.

The construction:

• A frame was made with the wood, cut so we could place one piece on either side of the railing on the balcony. Held together with the bolts, formed the frame and supports for our catapult.
• two holes in each of the supports to feed the elastic cord through
• A roughly 200x120mm square of shade cloth, a few layers thick, with small holes placed in the corners to run the cord through
• The cord threaded through the holes in the supports with the shade cloth pocket threaded onto the cord between the supports
• Attach the supports about 1m apart

A few lessons learned:

• Water balloons burst very easily, if the sling is too tight, and places too much force on the balloon, it will burst on launch.
• the elastic we bought was probably too heavy (it was about 10mm dia), and put too much force on the balloon.
• To counter this, we found placing the supports only 1m apart, rather than keeping it tight at 2m worked better. It accelerated the balloons more gently.
• A single piece of elastic, or much smaller gauge elastic would have worked better. Weaker elastic with a longer stretching distance would give the balloon a much gentler acceleration, hopefully allowing a more powerful, or longer throw
• I don't recommend putting anything other than water balloons in the sling. Balloons don't do too much damage. With this sort of power, they do hurt if they hit you, but anything more solid would be downright dangerous.

Elsbeth, Sarah, Rob, Sarah and Carey, preparing amunition.

What a way to waste an afternoon. Enjoy kids.

A busy term is over. A term during which I watched helplessly as my in box filled up with unread news subscriptions. But its over now. Finished the subjects, finished the ITC307 projects, and 382 projects. Been back home for 2 weeks, been getting back into reading. Also been doing all those little things that need doing (well the bigger little things at least). Consolidated my web servers onto a single port (no more port 8080), trialling other Linux distros (Running Ubuntu currently, and liking it), and doing some small upgrades to various systems.

Also been thinking about the future of this blog. I had hoped to get more out of writing this blog than i have been, and i know, looking back over my entries, there is little useful content. I would therefore like to try a different method:
Currently, while doing the reading i try to do every day, i often find articles i know would interest certain people, and will often put them aside and email them out. Frequently i find a number of related articles and become interested in the subject, and end up writing a half page summary, interspersed with links and references.
I would like to try to approach this blog in that form, to write a weekly or fortnightly article on a particular topic. I enjoy the emails i write, and hope i will enjoy this also, despite the fact it will no longer be directed towards a known audience.