RoboCup — KlodsHans

The robot

  • Technic Lego and custom made electronics.
  • Processors: 7 x Atmel AVR controllers: 12.5 MIPS total, 3300 instructions, 300 byte RAM and 170 byte EEPROM used for the software.
  • Communication: special 2-wire, full arbitrating, multimaster bus.
  • Steering control: Table based regulator.
  • Motor control: Propertional, Integral and Differential (PID)
  • Front wheel servo-steering.
  • 2 x Lego motors, internally geared, direct drive to rear wheels.
  • Line-sensor: 8 pairs of LED and photodiodes, modulated light @ 19KHz with a matching bandpass filter at the diodes.
  • 3 x infrared distance sensors (front and sides) for obstacle-detection and wall-following.
  • Odometers for dead-reckoning navigation.

KlodsHans were our first vehicle for the competition. And the name… Well, it had to have a name. Klods is the danish word for (Lego)brick, and Klods Hans is an adventure from H.C. Andersen. Its english title is: “Numskull Jack”.

The main design criteria was to show that it is not necessary to have massive processing power to have a fair chance in RoboCup.

One day we were thinking about the vehicles shape, so we dusted off some Lego bricks and started to put bricks together. Before we knew it, we had our vehicle. The Lego motors (with internal gearing) turned out to be perfect. One motor per rear-wheel, direct drive. Top speed: >2m/s.

The first two years (2001 and 2002), the front-wheel control was done by a PID regulator. We made some calculations, simulations and practical tests, which all showed us that a maximum speed of 1.2 m/s was obtainable if a minimum 50 cm turning radius was to be allowed.

The following year (2003) we changed the controller to a table based regulator, which increased the topspeed quite a bit. In addition we made an algorithm that reduced speed, when the tracked line came to far from sensor-center. These changes gave the vehicle an effective top speed of more than 2 m/s.

We thought the top-speed would be more than enough, but as our competitors showed us in 2004, it is not…


Some pictures


Electronics

Although KlodsHans is made mostly of Lego, the electronics are not:

The main purpose of the design was flexibility and a key design-method was divide and conquer. The divide and conquer was realized by identifying main responsibilities and allocate dedicated processors to them.
7 microcontrollers participated:

  1. Mission controller – Executing the mission.
  2. Steer controller – Controlling the front wheels (direction).
  3. Odometer control – Sampling the two odometers on the rear wheels.
  4. Right motor controller – Controlling the right motor.
  5. Left motor controller – Controlling the left motor.
  6. Sensor (range) controller – Controlling the aqcuisition of the distance sensors, collision sensors and push-buttons.
  7. Linesensor controller – Controlling the line detection.

The 6 first controllers are all located on the main-board, while the linesensor controller is located on a separate board. The line-sensor is actually connected via a communicationbus, that could handle additional controllers, if the need should arise.

Communication-bus

To enable 6+ controllers to communicate in a well-behaved timely manner, a full-arbitrating bus was deviced.

It consists of a clock-line and a data-line.

The clock-line is controlled by one of the microcontrollers. The clock-line is used to synchronize all communication by giving synchronization-gabs and write/read slopes. 1½ high-periods without changes denoted a frame-synchronization. A down-slope denoted a write signal, and an up-slope denoted a read-signal.

The data-line is driven as open-collectors with pull-ups. This method means that any controller pulling the line down, forces the bus to read “zero” for all.

The first 5 bits of a message gives the message-ID and the next 8 bits, the message itself.

The arbitration works by having a sender checking the actual line-value everytime it tries to send a “high” – If the line is still “low” it means that another controller is also active, and the controller sending the “high” withdraws. This means that the lowest message-ID will have precedence. Note that message-collisions are avoided by this scheme.

By carefully prioritizing messages (highest priority = lowest ID, etc.), we succeeded in making a deterministic communication, where messages were guarantied to reach its destination in time.

Linesensor

The linesensor is a differential reflective sensor (smart word, simple function). The LEDs are emitting modulated light at ~19KHz, and the photosensors output are put through a matched bandpass filter 6’th order. LEDs and photodiodes are activated in pairs, one pair at a time.

In that way we measure the difference between the “dark” and the “enlightened” return. This effectively filters out all indirect light. When adjusted correctly, the sensor works in the sunny noon as well as in complete darkness, and we can hardly see the difference on the measured values. The filter has a 3-4 cycle reactiontime, so flashlights from cameras is not picked up.

With 8 LED/photodiode pairs, one should think that the resolution of which it can detect the position of the underlaying line is pretty lousy… But no, by using weighted average on the measured (normalized) values, the resolution of the line position is as high as 224 positions.
The weights are set to 16 + (i * 32), where i is the LED/photodiode position (0-7). The result of the 8 measurements are then:sum(i=0;7, 16 + (i * 32)) / 8

The width of the line can then be found as the standard deviation of the 8 measurements. Simple and very effective.


Programming KlodsHans

KlodsHans is coded entirely in assembler. Actually with TAVRASM made by my friend Tom, who also happens to be my teammate on this project.

For the track-specific programming we made a macro-language that made it much easier to write the mission-code.
Example:

...
Trackline WHITE, RIGHT        // Track a white line, and go right in branches.
EventOnBranch                 // Send an event when we pass the branch.
SetSpeed 30                   // Start to drive with speed 30.
Wait                          // Wait for an event to happen (branch).
EventOnDistance 120           // Send an event when we pass a distance of 120 "ticks".
EventOnBranch                 // Dual event statement.
Wait                          // Wait on either event.
...

Team

Tom Mortensen and Per Dalgas Jakobsen

Results

2002: Design price

2003: Winner

2004: 3. place (?)