YorkTalks 2020: Engineering a positive future for robotics

Computers say no. Many of you will
have heard that. And my bet is that if you
ever use the computer, it will have said no
to you at some point. It’ll have presented
with a problem. There is the dread blue screen. There is the situation
when you’re typing and nothing is happening. The screen is frozen. And that’s what I mean
by the computer says no. It behaves in an unexpected
and an unhelpful way. What about robots? Can we trust that robots will
always behave as expected? Can we trust that robots
will always say yes to us? There is a lot of interest
in robotics in the media. If you remember that the
autonomous vehicles are robots? I think that’s clear. The UK government has identified
eight great technologies that will have profound impact
on our economy in the future. And robotics is one of them. There are several
predictions for the size of the robotics
market in the future. And they are all of the order
of billions and billions of pounds. So what’s going on? Basically, at the moment,
robots are working normally in factories, inside
cages, away from humans. But there have been
extraordinary advances in electronics, in mechanics,
and artificial intelligence. And we are now
developing applications where the robots are coming
to work near us, sometimes in collaboration with
us– with humans. And robots can be very useful
in environments where humans cannot be– nuclear reactors, the
deep sea, the space. But they can also be
very useful near us. For example, a medical
robot can operate with a precision that’s not
possible for the human hand. Robots have the possibility
of improving our environment in offices, in
hospitals, in airports. Robots have the possibility
of providing assistive care for the elderly. Robots have the
possibility of providing education and entertainment
for our children. But in all the situations where
the robots are working next to us, there is a
concern about trust. There is a concern about
safety, for example. If a robot is strong enough to
help an elderly person to get up from a chair, the
robot is strong enough to hurt that person. And we cannot have that. So what can we do about this? What is the position
that we are? There are several issues
related to establish the trustworthiness of a robot. And what I’m going to
talk to you about today, this is related to the software
that controls those robots. A piece of software is
a engineering artefact, just like a car or a
building or a laptop. But as a society, we have a
very lax view of software. If a bridge collapses, there is
a public outcry, most likely, even legal action. If I buy a laptop and– I don’t know– the screens
cracked, I want my money back or I want a new laptop. But if the software
that’s running that laptop doesn’t work, I’m
very happy to say, ah, perhaps I need to
reset it, or perhaps there will be an update. And updates come
over and over again. My whole career as a
researcher has been about changing this situation. Why cannot software engineers
provide the same sort of guarantees that a civil
engineer can give, for example. What’s the problem? Blame the tools
not the engineers. Our software
engineering community is extremely successful. Our society depends on our
software infrastructure very fundamentally these days. I’m guessing that most of
you have a smartphone on you. You are carrying a lot
of software on you. If you’ll go and
buy a pint of milk, you are relying on a lot
of software infrastructure. All the way from
the farm, farmers are using automated machines
controlled by software to milk the cows. To the shop, when software
allows you to pay for milk, allows the shopkeeper to
control their stock, interact with the delivery system
that uses lots of lorries, where a lot of
software is running. If the software
infrastructure in our society overnight stopped
working, society would go to a
standstill very quickly. And this reflects the brilliance
of our software engineers. So what’s the problem? The problem is that
they need models. They need to work with models– mathematical models that
underpin that practice, just like any engineer. You cannot imagine– it’s
inconceivable to think that a civil engineer is going to
start the project of a new building by laying some bricks. And laying bricks is
to civil engineering like writing lines of code,
writing programs, developing, actually, creating the software
is to software engineering. That’s not where we start. So a civil engineer,
we know how they work. They write some plans. They build some markets. And they use those to
discuss their design with their stakeholders but
also to analyse and predict the properties of their designs
to make sure that the building is not going to collapse. That it’s going to provide
adequate services, water, electricity, and so on. And software engineers
can work like that. The mathematical principles that
underlie software engineering are already known. In many areas of
application, they are used. The techniques based on
these mathematical principles are tackled. Formal methods are
used very successfully. And the trick is
specialisation, specialisation for the domains of application. And roboticists do not have that
specialised the techniques yet. How the roboticists work? Roboticists use extremely
advanced techniques when it comes to the
development of the electronics and mechanical aspects
of their artefacts. When it comes to the
software engineering, the practice is very outdated. They basically start by writing
code, laying some bricks. Many start writing simulation. And you could say a
simulation is a model. But it’s not a
mathematical model that allows you to reason
about your artefact. It is code, right? And so that’s how they
start, not using models. And in that situation,
they may face problems, as you can expect if
civil engineers started laying some bricks. That’s not how you do it. And what do they then have? The goal is the only
thing they have in hand. They write it. And they try it. They try it in the robot– lab conditions or in the
real world if possible, it’s not always possible. They observe the behaviour. If there is a problem, they
go back to the code change and try again and
again and again. In the end, what can they say? What can they assert? All they can say is that I
didn’t find a situation where a problem occurs. They cannot say there is no
situation where the robot is going to misbehave. They cannot even say these are
all the situations in which the robot will not misbehave. And therefore, these are the
situations in which I can guarantee the
behaviour of the robot. They don’t have that. For that, they need models. And what does a model for a
software engineer looks like? It looks like a recipe. A step by step
description of what the software of what the
robot should be doing. And now, with
discretion of recipes, I’ll run a parallel
with my mother’s recipe. I have to be very
careful about what I say about my mother on record. She has lovely recipes that
she kindly shares with me. They are not precise. They say things like cook
until it’s a little brown or put a pinch of salt. And often, I have to call her
and ask, what do you mean? Even worse, sometimes, I don’t
realise that I have to call her. And here’s what I get
instead of that lovely cake that I wanted to do. And roboticists have
the same problem. Many try to write the
recipe for their robot. Here’s an example. I don’t need you to understand
the details of that diagram. But that diagram is an
attempt of colleagues. This is taken from a paper
in the area of robotics. It is an attempt to
describe the recipe, the step by step behaviour of
the software for the robot. But it’s not a model. It’s not precise. It’s not backed
up by mathematics. We try to use that. And we couldn’t understand what
that diagram is presenting. If a civil engineer
picks up a piece of paper and sketch some plan of a
building, that’s not a model. That cannot be used by the civil
engineer to show or provide evidence that their
building will be good. It is just the drawing. So my work and the work
of my research group called Robostar is to
develop notations, tools, and techniques that allow
a roboticist to write their models in a precise way
and with strong mathematical underpinnings. So that’s an example. Again, I don’t need you to
understand the details of that. But it’s an example
of a model that you can write for a robotic
software using our annotations. Because it’s precise, it
can be backed up by a tool. Because it has
mathematical underpinnings, you can be sure
of the properties that we can deduce from
the use of those models. So we are developing
tools for these notations that we are defining. We are embarking on a
10 year program funded by the UK Research
Council, the PSSC, and that by the Royal Academy
of Engineering to a value of more than 5
million pounds at the moment. And our remit is to specialise
techniques, specialise the mathematical
principles to allow us to use software
engineering techniques in the area of robotics. So I have their video with a
demonstration of [INAUDIBLE] as it exists now. There are very challenging
and very exciting issues that we need to
address in this robotic area. A robotics software does not
run on a desktop or on a laptop. It runs on a robotic platform
that influences and is influenced by the environment. And the environment is no longer
the environment of a factory, is no longer the
environment that is static and well organised. There is a lot of uncertainty in
the environment of our streets, of our hospitals, of our home. And that uncertainty
makes the mathematics that we need to reason
about this software using this context extremely
challenging but extremely exciting. So we are, now, a
group at the moment, moving to work and cater for
the mathematical foundations to deal with the
robotic platform, to deal with the environment. And the two that’s been
demonstrated there, it can already cater
for the software. So it can already,
in an automatic way, directly form the models that
the roboticists write, develop, provide automatically
reports like that that’s shown there for you. Those reports, they are
showing that for properties that have been
identified as important for that particular
software, it is showing that those
properties are valid. And that’s before
we even started writing any line of code. We know that those
properties will hold. Sometimes, the report comes back
and says, no, they don’t hold. So again, before I
wrote any line of code, I say, OK, there is a
problem in my design. I need to revise
my design, which is much cheaper than trying
to rewrite code, right? And I get that
feedback automatically. These techniques
can also provide you with all the important artefacts
for software engineers. It can automatically
give me the simulations. It can automatically
give me the tests. It can automatically give me
even a sketch for the code that we would eventually use. So this is the
future that we see. As we evolve and we can cater
for more and more aspects of the robotic system,
our expectation is that roboticists
will be able to provide consistent good outcomes. They will get the recipes
right and get for us good systems, good robotic
applications that we can trust. They will never go back to
be writing lines of code as the very first step. And in that situation where
we can provide evidence that we can trust the
systems that I’ve introduced, we will then be comfortable to
have these robots around us, helping our elderly
with day to day tasks, perhaps, interacting
with our children, helping others in the offices,
around the university, in our homes, everywhere. And in that context, the
robots will always say yes. Thank you. [APPLAUSE]

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *