The Mighty Morphin Tower Arrangers are:

Chris Barlow

Darren Lewis

& Ted the Robot

About Us

The Mighty Morphin Tower Arrangers are a team entering into the competition, Eurobot 2009: Temples of Atlantis (see www.eurobot.org for details).

Darren Lewis and Chris Barlow are both BSc Engineering Product Design students from Middlesex University in North London, UK.

Although the task for this year's competition is a complex one, the Tower Arrangers' philosophy is to use as few moving parts as possible, and to use natural forces wherever they are available. This should result in an economical, reliable system designed to score a realistic number of points match after match.

This site will follow the team's progress from initial design to final build and our progress through the competition itself.

The Contest

"Eurobot is an amateur robotics contest open to groups of young people from around the world, organised in teams."

"The aims of the contest are to favour the public interest in robotics and encourage hands-on practice of science by young people. Eurobot is intended to take place in a friendly and sporting spirit."

"More than a simple championship for young people or a competition, Eurobot is a friendly opportunity to unleash technical imagination and exchange ideas, know-how, hints and
engineering knowledge around a common challenge. Creativity and interdisciplinary is necessary. Eurobot values fair play, solidarity, creativity and sharing of technical knowledge,
whether it is across technical realisations or project management."

"Eurobot takes place in Europe, but is open to teams from other continents. Countries with more than three teams interested in participating must organise a national qualification in order to select the three teams which will participate to Eurobot finals."

[www.eurobot.org, 2008-2009]

Thursday 19 March 2009

Problems, problems, problems

The last 5 days have been quite trying for the MMTA team. The on Friday, the bot developed a strange symptom that we still can't properly explain.

Firstly, during testing, every now and then the robot would start skipping a routine in its program. Carrying out a 'hard reset' on the Picaxe 28 main board seemed to temporarily solve this, and we put it down to 2 things: either noise from the DC motor driving the vertical lift, or an old, tired 28x1 chip. Noise suppression capacitors were fitted to the motor, and we atempted to change a chip over on the PicAxe 28 main board.

This was when the first major problem reared its head. Fitting any 28x1 chip other than the old one meant the robot refused to move! We eliminated all hardware problems, trying a spare board, about 5 or 6 spare chips, download cable and even a different laptop to put download the program! All to no avail! Eventually, the problem was traced to the communication between the board that operates the vertical lift and the main board. As the robot is traveling around the table, the board for the vertical lift is monitoring for when a disc passes beneath a downward-facing IR sensor. When it sees a disc, it waits for the disc to pass past the sensor and then tells the main board to stop the motors while the claw picks up the disc.

It was this communication that was broken, so the program on the main board jumped into the routine that stopped the motors straight away, hence it not moving. This problem was, eventually traced to the fact that the two boards are on different circuits, a pull-up resistor was fitted in the line, and it now works fine. Why this worked with the old chip, we aren't entirely sure. Perhaps the old chip was faulty in some way that conveniently made it work, or perhaps there has been a slight change in design in the internals for that particular chip. (if anyone has any suggestions, please leave a comment!).

Once we had it moving again things still weren't right. The robot was very rarely following the routines it was supposed to and would randomly spin on the spot, drive for too far, and generally mess up. By running a 'sertxd' command on the main board we were able to monitor the readings that we were getting from the encoders. We found that there were random fluctuations in the readings, where they would increase to over 65000, before returning to normal. An extra algorithm was added to the program to ignore these, but they were so frequent that it meant the robot would still not behave correctly. Eventually, yesterday, by eliminating everything else that we could have changed, we discovered that it was the noise suppression capacitors we fitted on friday that were actually generating noise and interfering with the communications between the main board and motor driver. Removing these capacitors, there are still the odd fluctuation, but nowhere near as bad as they were before.

We will look into other forms of sheilding to try and get rid of these, but for now, the robot is performing consistent enough to get it scoring points again.