Eureka moments

Citation

Loughlin, C. (2007), "Eureka moments", Industrial Robot, Vol. 34 No. 1. https://doi.org/10.1108/ir.2007.04934aaa.001

Eureka moments

I had two Eureka moments recently, both were within a few minutes of each other and both while listening to a Keynote presentation by Prof. Dr Ir H. Hirukawa of AIST in Japan at this year's CLAWAR Conference (Climbing and Walking Robots, Brussels, 11-14 September, 2006).

The title of the presentation was “Humanoid Robot that can move by arms and legs” and primarily concerned their HRP-2 humanoid robot which could climb up stairs, crawl and even fall over. The work he presented was truly remarkable and I was very impressed by the quality of the work and the progress that they have made over the years. Given this impression it is somewhat ironic that both of my Eureka moments were along the lines of “this is not the way it should be done”.

My first contrary realisation was to do with motive power. Most industrial and current humanoid/service robots are powered by stiff electrical drives with a more or less direct link between the servo motor and the joint concerned. This is fine, especially for industrial robots, that perform the same action over and over again in a highly structured environment – but I realised that for service robots a substantial amount of compliance is pretty well essential.

It was while they were trying to get the HRP-2 to fall over without breaking itself that the point really struck home.

We have all seen movies of humanoid robots being pushed by people and adapting their stance accordingly, but this is always done pretty slowly so that the robot has time to react. What happens however if the robot is hit by something or falls over?

Depending on the control system a robot will typically send commands to its joints about 100 times per second – which to be fair is pretty fast. However, a 2m high robot that falls over could hit the floor within a bit more than half a second with a velocity of about 6m per second. At this speed the robot covers 60mm in the time it takes for the control system to send an update to servo drives and this is just to start to take corrective action. Of course when the robot hits the ground its velocity basically becomes zero and so a lot of kinetic energy needs to get dissipated – which can easily lead to a broken robot.

Building robots with faster control systems does not really solve the problem – it helps – but the problem still remains.

Eureka No. 1. Service robots must be designed to include mechanical compliance.

The other Eureka moment occurred while the robot's software was being discussed. It was clear that as each new function, such as crawling, was added to the robot's repertoire then a whole new set of software routines had to be written with very complex recalculations of centre of gravity, etc. And even minor variations in a task could result in big changes in “special circumstances” which then needed new set of solutions.

Prof. Hirukawa is in good company with this dilemma. I can recall Joe Engelberger similarly recounting that his HelpMate robot had over 5,000 “rules” that told it how to behave in different circumstances – a lot were to do with obstacle avoidance. At the time I remarked that if you are asking a question that had 5,000 answers then you were probably asking the wrong question.

The problem with this sort of programming is very like the falling problem – you may be able to improve the robot's performance but there will always be a new set of circumstances that will cause it to fail – you simply cannot cater for all eventualities.

To be honest I am always a bit suspicious of neural networks and genetic algorithms – having often considered them to be little more than an interesting academic exercise for students who cannot afford real hardware. However, it is just possible that they could be the answer to the programming problem. After all; we as people learn by experience and I have no idea where my CofG is at any moment in time – so why not robots?

Eureka No. 2. Service robots need to “learn” how to move.

Clive Loughlin