Sunday, May 31, 2015

Copyright violations bring Forth memories

Last week I found a couple of copyright violations. Am I upset? Not at all - actually I'm delighted that stuff I did in 1983 is alive and well on the Interweb thanks to the efforts of others.

The first is an online readable copy of my 1983 book The Complete Forth. It's a textbook on the programming language Forth that I was heavily into at the time. The book was first published by Sigma Press, then internationally by John Wiley, and was translated into both Dutch and Japanese. Someone - I assume from the Jupiter Ace archive - has gone to the trouble of scanning every page. Even the pull out reference card. Whoever you are, thank you.

Just before I wrote that book, I had developed a Forth programming system (a programming environment that integrates compiler and interpreter) for the NASCOM 2 Z80 micro computer. Myself and a friend then marketed Hull-Forth and, I recall, sold several hundred copies. Of course this was pre-internet so marketing meant small ads in the magazine Personal Computer World. What we actually shipped was a printed manual together with the code on a cassette tape. Floppy disks were hugely expensive and beyond the reach of hobby computers, so for saving and loading programs we used audio cassette recorders. They were slow and very unreliable; if there was a checksum error you just had to rewind, cross your fingers and try again. I can't imagine anyone feeling nostalgic for that particular technology.

This brings me to the second copyright infringement. By accident I discovered there is a webpage for NASCOM enthusiasts, and several emulators, so you can run a virtual NASCOM on your modern PC. Scrolling down the long list of software in the NASCOM repository, in the section Programming Languages, I find
Hah! Someone must have gone to alot of trouble to get the code from the original cassette*, recorded using the Kansas City Standard at, I think, 300 baud (so slow you could almost hear the noughts and ones!), to a .NAS file you can download into your NASCOM emulator.

Ok, now to get that NASCOM emulator running. It will be fun (and slightly absurd) to run Hull Forth again for the first time in about 33 years.


*I probably still have one of those cassettes in my loft**, but no way of reading the data from it.
**Along with stacks of punched cards, rolls of paper tape, and all kinds floppy disks.

Saturday, May 30, 2015

Forgetting may be important to cultural evolution

Our latest paper from the Artificial Culture project has just been published: On the Evolution of Behaviors through Embodied Imitation.

Here is the abstract
This article describes research in which embodied imitation and behavioral adaptation are investigated in collective robotics. We model social learning in artificial agents with real robots. The robots are able to observe and learn each others' movement patterns using their on-board sensors only, so that imitation is embodied. We show that the variations that arise from embodiment allow certain behaviors that are better adapted to the process of imitation to emerge and evolve during multiple cycles of imitation. As these behaviors are more robust to uncertainties in the real robots' sensors and actuators, they can be learned by other members of the collective with higher fidelity. Three different types of learned-behavior memory have been experimentally tested to investigate the effect of memory capacity on the evolution of movement patterns, and results show that as the movement patterns evolve through multiple cycles of imitation, selection, and variation, the robots are able to, in a sense, agree on the structure of the behaviors that are imitated.
Let me explain.

In the artificial culture project we implemented social learning in a group of robots. Robots were programmed to learn from each other, by imitation. Imitation was strictly embodied, so robots observed each other using their onboard sensors and, on the basis of only visual sense data from a robot’s own camera and perspective, the learner robot inferred another robot’s physical behaviour. (Here is a quick 5 minute intro to the project.)

Not surprisingly embodied robot-robot imitation is imperfect. A combination of factors including the robots’ relatively low-resolution onboard camera, variations in lighting, small differences between robots, multiple robots sometimes appearing within a learner robot’s field of view, and of course having to infer a robot’s movements by tracking the relative size and position of that robot in the learner’s field of view, lead to imitation errors. And some movement patterns are easier to imitate than others (think of how much easier it is to learn the steps of a slow waltz than the samba by watching your dance teacher). The fidelity of embodied imitation for robots, just as for animals, is a complex function of four factors: (1) the behaviours being learned, (2) the robots’ sensorium and morphology, (3) environmental noise and (4) the inferential learning algorithm.

But rather than being a problem, noisy social learning was our aim. We are interested in the dynamics of social learning, and in particular the way that behaviours evolve as they propagate through the group. Noisy social learning means that behaviours are subject to variation as they are copied from one robot to another. Multiple cycles of imitation (robot B learns behaviour m from A, then robot C learns the same behaviour m′ (m mutated), from robot B, and so on), gives rise to behavioural heredity. And if robots are able to select which learned behaviours to enact we have the three Darwinian operators for evolution, except that this is behavioural, or memetic, evolution.

These experiments show that embodied behavioural evolution really does take place. If selection is random, that is robots select which behaviour to enact from those already learned – with equal probability, then we see several interesting findings.

1. If by chance one or more high fidelity copies follow a poor fidelity imitation, the large variation in the initial noisy learning can lead to a new behavioural species, or traditions. Thus showing that noisy social learning can play a role in the emergence of novelty in behavioural (i.e. cultural) evolution. That was written up in Winfield and Erbas, 2011.

But it is the second and third findings that we describe in our new paper.

2. We see that behaviours appear to adapt to be easier to learn, i.e. better ‘fitted’ to the robot swarm. The way to think about this is that the robots' sensors and bodies, and physical environment of the arena with several robots (including lighting), together comprise the 'ecological niche' for behavioural evolution. Behaviours mutate but the ones better fitted to that niche survive.

3. The third finding from this series of experiments is perhaps the most unexpected and the one I want to outline in a bit more detail here. We ran the same embodied behavioural evolution with three memory sizes: no memory, limited memory and unlimited memory.

In the unlimited memory trials each robot saved every learned meme, so the meme pool across the whole robot population (of four robots) grew as the trial progressed. Thus all learned memes were available to be selected for enaction. In the limited memory trials each robot had a memory capacity of only five learned memes, so that when a new meme was learned the oldest one in the robot's memory was deleted.

The diagram below shows the complete family tree of evolved memes, for one typical run of the limited memory case. At the start of the run the robots were seeded with two memes, shown as 1 and 2 at the top of the diagram. Behaviour 1 was a movement pattern in which the robot traces a triangle path, behaviour 2 a square. Because this was a limited memory trial the total meme pool has only 20 behaviours - these are shown below as diamonds. Notice the cluster of 11 closely related memes at the bottom right, all of which are 7th, 8th or 9th generation descendents of the triangle meme.

Behavioural evolution map following a 4-robot experiment with limited memory; each robot stores only the most recent 5 learned behaviours. Each behaviour is descended from two seed behaviours labelled 1 and 2. Orange nodes are high fidelity copies, blue nodes are low fidelity copies. The 20 behaviours in the memory of all 4 robots at the end of the experiment are highlighted as diamonds. Note the cluster of 11 closely-related behaviours at the bottom right.

When we ran multiple trials of the limited and unlimited memory cases, then analysed the number and sizes of the clusters of related memes in the meme pool, we saw that the limited memory trials showed a smaller number of larger clusters than the unlimited memory case. The difference was clear and significant; with limited memory an average of 2.8 clusters of average size 8.3, with unlimited memory 3.9 clusters of size 6.9.

Why is this clustering interesting? Well it's because the number and size of clusters in the meme pool are good indicators of its diversity. Think of each cluster of related memes as a 'tradition'. A healthy culture needs a balance between stability and diversity. Neither too much stability, i.e. a very small number (in the limit 1) of traditions, or too much diversity, i.e. clusters so small that there are no persistent traditions at all. Perhaps the ideal balance is a smallish number of somewhat persistent traditions.

So far I didn't mention the no memory case. This was the least interesting of the three. Actually by no memory we mean a memory size of one; in other words a robot has no choice but to enact the last behaviour it learned. There is no selection, and no clusters can form. Traditions can never even get started, let alone persist.

Of course it would unwise to draw any big conclusions from this limited experimental study. But an intriguing possibility is that some forgetting (but not too much) may, just like noisy imitation, be a necessary condition for the emergence of culture in social agents.

Full reference:
Erbas MD, Bull L and Winfield AFT (2015), On the Evolution of Behaviors through Embodied Imitation, Artificial Life, 21 (2), pp 141-165. The full text (final draft) paper can be downloaded here.

Related blog posts:
Robot imitation as a method for modelling the foundations of social life
Open-ended Memetic Evolution, or is it?

Saturday, April 04, 2015

Yesterday I looked through the eyes of a robot

It was a NAO robot fitted with a 3D printed set of goggles, so that the robot has two real cameras on its head (the eyes of the NAO robot are not in fact cameras). I was in another room wearing an Oculus Rift headset. The Oculus was hooked up to the NAO's goggle cameras, so that I could see through those cameras - in stereo vision.

photo by Peter Gibbons
But it was even better than that. The head positioning system of the Oculus headset was also hooked up to the robot, so I could turn my head and - in sync - the robot's head moved. And I was standing in front of a Microsoft Kinect that was tracking my arm movements. Those movements were being sent to the NAO, so by moving my arms I was also moving the robot's arms.

All together this made for a pretty compelling immersive experience. I was able look down while moving my (robot) arms and see them pretty much where you would expect to see your own arms. The illusion was further strengthened when Peter placed a mirror in front of the NAO robot, so I could see my (robot) self moving in the mirror. Then it got weird. Peter asked me to open my hand and placed a paper cup into it. I instinctively looked down and was momentarily shocked not to see the cup in my hand. That made me realise how quickly - within a couple of minutes of donning the headset - I was adjusting to the new robot me.

This setup, developed here in the BRL by my colleagues Paul Bremner and Pete Gibbons, is part of a large EPSRC project called Being There. Paul and Peter are investigating the very interesting question of how humans interact with and via teleoperated robots, in shared social spaces. I think teleoperated robot avatars will be hugely important in the near future - more so than fully autonomous robots. But our robot surrogates will not look like a younger buffer Bruce Willis. They will look like robots. How will we interact with these surrogate robots - robots with human intelligences, human personalities - seemingly with human souls? Will they be treated with the same level of respect that would be accorded their humans if they were actually there, in the flesh? Or be despised as voyeuristic; an uninvited webcam on wheels?

Here is a YouTube video of an earlier version of this setup, without the goggles or Kinect:


I didn't get the feeling of what it is like to be a robot, but it's a step in that direction.

Saturday, February 21, 2015

Like doing brain surgery on robots

I spent a rare few hours in the lab the last few days, actually doing research. Or at least attempting to. Actually I made no progress at all. But did reach base camp: I managed to set up and run the ethical-dilemma robot experiment. And in the process refreshed my rusty command-line Linux. I was also reminded how time consuming, and downright frustrating experimental robotics research really is. Here's a taste: everything is set up and looks ok... but wait - the tracking system needs recalibrating; hmm... where's the manual? Ah, found it. Ok, wow this is complicated. Needs the special calibrating wand, and set square device... An hour later: ok ready now. Start everything up. But one of the robots isn't connecting. Ah, battery low, ok battery changed, now back up 4 steps and restart. And so it goes.

This is Swarmlab mission control. Three computers, three different operating systems;) The one in the middle (Windows XP) is running the Vicon tracking system, and monitoring via an overhead webcam. The laptop on the left (Ubuntu Linux) is running the four different processes to start and manage the three robots.
Here are the three e-pucks, each a WiFi networked Linux computer (Debian) in its own right. Actually each robot has two processors: a low-level PIC microcontroller to take care of motor control, managing the robot's sensors, etc. And an ARM processor for high-level control. The two interfaced via the SPI bus.







The setup is complicated. 5 computers in total, running a total of 9 networked processes. Here's a diagram showing those processes and how they are linked.

So, back to research.

The task I had set myself was to make some small changes to the high level controller. How hard can that be, you might think? Well it feels a bit like brain surgery: trying to tease apart code that I barely understand without breaking it. The code is well written and well structured, but it's in Python, which is new to me. It's only a couple of hundred lines, but like the neo-cortex - it's a thin layer at the top of a complex network of carefully choreographed processes and subsystems.







Acknowledgements: Christian Blum programmed the ethical robot experiments, supported by Dr Wenguo Liu who designed and setup the Swarmlab experimental infrastructure, including the e-puck Linux extension boards.

Wednesday, February 18, 2015

Surgical micro-robot swarms: science fiction, or realistic prospect?

Imagine a swarm of microscopic robots that we inject into the vascular system: the swarm swims to the source of the problem, then either delivers therapeutics or undertakes microsurgery directly.

That was how I opened a short invited talk at the Royal Society of Medicine on 5 February, at a meeting themed The Future of Robotics in Surgery. The talk was a wonderful opportunity for me to introduce swarm intelligence and speculate on the likelihood of surgical micro-robot swarms, while at the same time learning about robot surgery. Here are the slides from my talk (with links to YouTube videos where available).



The talk was in three parts.

First I introduced swarm intelligence, and its artificial counterpart swarm robotics. I showed, with examples from two of my students, how - with very simple rules - a swarm of robots can keep together as a swarm, while moving toward a beacon. Then, with a phagocyte-like behaviour, encapsulate the beacon. In our case these were lab robots moving toward an infra-red beacon, but it's not hard to imagine the same behavioural rules in a microscopic swarm swimming toward the source of a chemical marker (chemotaxis). I then gave two examples of the state of the art in swarm robotics: SYMBRION and (my current favourite) TERMES. I wanted to illustrate emergent physical interaction, in these two cases swarm self-assembly and swarm construction, respectively.

In part two I outlined what is by far the biggest problem: actually engineering robots at the micro-scale. Here I drew upon the examples from my book Robotics: a very short introduction; a section called A swarm of medical microrobots.  Start with cm sized robots. These already exist in the form of pillbots and I reference the work of Paolo Dario's lab in this direction. Then get 10 times smaller to mm sized robots. Here we're at the limit of making robots with conventional mechatronics. The almost successful I-SWARM project prototyped remarkable robots measuring 4 x 4 x 3mm. But now shrink by another 3 orders of magnitude to microbots, measured in micrometers. This is how small robots would have to be in order to swim through and access (most of) the vascular system. Here we are far beyond conventional materials and electronics, but amazingly work is going on to control bacteria. In the example I give from the lab of Sylvain Martel, swarms of magnetotactic bacteria are steered by an external magnetic field and, interestingly, tracked in an MRI scanner.

In the final part of my talk I introduce the work of my colleague Sabine Hauert, on swarms of nanoparticles for cancer nanomedicine. These 5 - 500nm particles are controlled by changing their body size, material, coating and cargo so - in true swarm fashion - the way the nanoparticle swarm moves and interacts with much larger normal and tumour cells is an emergent property of the way the nanoparticles individually interact and cooperate. Sabine and her collaborators have created an online tool called NanoDoc, which allows anyone to edit the design of nanoparticles then run simulations to see how their designs perform. In this way the task of searching the huge design space is crowd-sourced. In parallel Sabine is also running mesoscale embodied simulations, using the Harvard Kilobots.

I concluded by suggesting that engineering micro or nanobots is not the only major challenge. At least as important are: (a) how would you program the swarm, and (b) how would such a swarm be approved for clinical use? But a deeply interesting question is the nature of the human-swarm interface. If a swarm of surgical microbots should become a practical proposition would we treat the swarm as a microscopic instrument under the surgeon’s control, or a smart drug that does surgery?

Friday, January 30, 2015

Maybe we need an Automation Tax

Imagine this situation. A large company decides to significantly increase the level of automation at one of its facilities. A facility that currently employs a substantial number of men and women doing relatively low-skill tasks, which can now be done by a new generation of robots. Most of the workers get laid off which, for them and their families, leads to real hardship. The company was the only large employer in the area, which is economically depressed (one of the reasons perhaps that the company built the facility there in the first place), so finding alternative work is really difficult. And because most of those jobs were minimum wage, with little or no job security, redundancy payouts are small or non-existent and this of course means that the laid-off workers have no financial buffer to help them re-skill or relocate.

Now I am not anti-automation. Absolutely not. But I believe very strongly that the benefits of robotics and automation should be shared by all. And not just the shareholders of a relatively small number of very large companies. After all, the technology that such companies benefit from was developed by publicly funded research in university research labs. In other words research that you and I funded through our taxes. Ok, you might say, but companies pay tax too, aren't those taxes also contributing to that research? Yes, that's true. But large companies are very good at reducing their tax bill, multinationals especially. Our imaginary company may, in reality, pay most of its tax in a different country entirely from the one hosting the facility.

And of course it is we, through local and national taxation, who - as best we can - pick up the pieces to support the laid off workers and their families, through family tax credits, employment and support allowance, and so on.

Maybe we need an Automation Tax?

It would be a tax levied nationally, whenever a company introduces robotics and automation to one of its facilities in that country. But the tax would only be payable under certain conditions, so for instance:

  • If the new robotics and automation causes no-one to be laid off, then no tax is due.
  • If the automation does result in jobs becoming redundant, but the company re-trains and re-deploys those workers within its organisation, then no tax is due.
  • If the company does lay off workers but makes a tax-free redundancy payment to those workers - regardless of their contract status - sufficient to cover the full costs of retraining, upskilling, and - with all reasonable efforts - finding work elsewhere, then no tax is due.

Only if none of these conditions are met, would the automation tax be due. The idea is not to discourage automation, but to encourage companies to accept a high degree of responsibility to workers laid off as a result of automation, and more widely their social responsibility to the communities in which they are located. The tax would enforce the social contract between companies and society.

Of course this automation tax doesn't go anywhere near far enough. I think the best way of sharing the wealth created by robotics and automation is through a universal Basic Income, but until that utopian condition can be reached, perhaps an automation tax is a start.

Monday, December 22, 2014

Robot Bodies and how to Evolve them

Evolutionary robotics has been around for about 20 years: it's about 15 years since Stefano Nolfi and Dario Floreano published their seminal book on the subject. Yet, surprisingly the number of real, physical robots whose bodies have been evolved can be counted on the fingers of one hand. The vast majority of ER research papers are concerned with the evolution of robot brains - the robot's control system. Or, when robot bodies are evolved often the robot is never physically realised. This seems to me very odd, given that robots are real physical artefacts whose body shape - morphology - is deeply linked to their role and function.

The question of how to evolve real robot bodies and why we don't appear to have made much progress in the last 15 years was the subject of my keynote at the IEEE International Conference on Evolvable Systems (ICES 2014) in Orlando, a week ago. Here are my slides:



The talk was in three parts.

In part one I outlined the basic approach to evolving robots using the genetic algorithm, referring to figure 18: The four-stage process of Evolutionary Robotics, from chapter 5 of my book:

I then reviewed the state-of-the-art in evolving real robot bodies, starting with the landmark Golem project of Hod Lipson and Jordan Pollack, referencing both Henrik Lund and Josh Bongard's work on evolving Lego robots, then concluding with the excellent RoboGen project of Josh Auerbach, Dario Floreano and colleagues at EPFL. Although conceptually RoboGen has not moved far from Golem, it makes the co-evolution of robot hardware and controllers accessible for the first time, through the use of 3D-printable body parts which are compatible with servo-motors, and a very nice open-source toolset which integrates all stages of the simulated evolutionary process.

RoboGen, Golem and, as far as I'm aware, all work on evolving real physical robot bodies to date has used the simulate-then-transfer-to-real approach, in which the whole evolutionary process - including fitness testing - takes place in simulation and only the final 'fittest' robot is physically constructed. Andrew Nelson and colleagues in their excellent review paper point out the important distinction between simulate-then-transfer-to-real, and embodied evolution in which the whole process takes place in the real world - in real-time and real-space.

In part two of the talk I outlined two approaches to embodied evolution. The first I call an engineering approach, in which the process is completely embodied but takes place in a kind of evolution factory; this approach needs a significant automated infrastructure: instead of an manufactory we need an evofactory. The second approach I characterise as an artificial life approach. Here there is no infrastructure. Instead 'smart matter' somehow mates then replicates offspring over multiple generations in a process much more analogous to biological evolution. This was one of the ambitious aims of the Symbrion project which, sadly, met with only limited success. Trying to make mechanical robots behave like evolving smart matter is really tough.

Part three concluded by outlining a number of significant challenges to evolving real robot bodies. First I reflect on the huge challenge of evolving complexity. To date we've only evolved very simple robots with very simple behaviours, or co-evolved simple brain/body combinations. I'm convinced that evolving robots of greater (and useful) complexity requires a new approach. We will, I think, need to understand how to co-evolve robots and their ecosystems*. Second I touch upon a related challenge: genotype-phenotype mapping. Here I refer to Pfeifer and Bongard's scalable complexity principle - the powerful idea that we shouldn't evolve robots directly, but instead the developmental process that will lead to the robot, i.e. artificial evo-devo. Finally I raise the often overlooked challenge of the energy cost of artificial evolution.

But the biggest challenge remains essentially what it was 20 years ago: to fully realise the artificial evolution of real robots.


Some of the work of this talk is set out in forthcoming paper: AFT Winfield and J Timmis, Evolvable Robot Hardware, in Evolvable Hardware, eds M Trefzer  and A Tyrrell, Springer, in press.

*I touch upon this in the final para of my paper on the energy cost of evolution here.

Thursday, December 18, 2014

Philae: A proof of concept for cometary landing

The question Robotics by Invitation asked its panel in November 2014, was:

What does the first successful landing on a comet mean for the future of (robotic) space mining and exploration? What are the challenges? What are the opportunities?

Here is my answer:

The successful landing of Philae on comet 67P/Churyumov-Gerasimenko is an extraordinary achievement and of course demonstrates - despite the immense challenges - that it is possible. The Philae mission was, in a sense, a proof of concept for cometary landing and this, for me, answers the question 'what does it mean'. 

Of course there is a very large distance between proof of concept and commercial application, so it would be quite wrong to assume that Philae means that space mining (of planets, asteroids or comets) is just around the corner. Undoubtedly the opportunities are immense and - as pressure on Earth's limited and diminishing resources mounts - there is an inevitability about humankind's eventual exploitation of off-world resources. But the costs of space mining are literally astronomical, so unthinkable for all but the wealthiest companies or, indeed, nations. 

Perhaps multi-national collaborative ventures are a more realistic proposition and - for me - more desirable; the exploitation of the solar system is something I believe should benefit all of humankind, not just a wealthy elite. But politics aside, there are profoundly difficult technical challenges. You cannot teleoperate this kind of operation from Earth, so a very high level of autonomy is required and, as Philae dramatically demonstrated, we need autonomous systems able to deal with unknown and unpredictable situations then re-plan and if necessary adapt - in real-time - to deal with these exigencies. The development of highly adaptive, resilient, self-repairing - even self-evolving – autonomous systems is still in its infancy. These remain fundamental challenges for robotics and AI research. But even if and when they are solved there will be huge engineering challenges, not least of which is how to return the mined materials to Earth. 

Bearing in mind that to date only a few hundred Kg of moon rock have been successfully returned* and Mars sample-return missions are still at the planning stage, we have a very long way to go before we can contemplate returning sufficient quantities to justify the costs of mining them.

*and possibly a few grains of dust from Japanese asteroid probe Hayabusa.

Sunday, November 30, 2014

Robot simulators and why I will probably reject your paper

Dear robotics and AI researcher

Do you use simulation as a research tool? If you write papers with results based on simulation and submit them for peer-review, then be warned: if I should review your paper then I will probably recommend it is rejected. Why? Because all of the many simulation-based papers I've reviewed in the last couple of years have been flawed. These papers invariably fall into the pattern: propose new/improved/extended algorithm X; test X in simulation S and provide test results T; on the basis of T declare X to work; the end.

So, what exactly is wrong with these papers? Here are my most common review questions and criticisms.
  1. Which simulation tool did you use? Was it a well-known robot simulator, like Webots or Player-Stage-Gazebo, or a custom written simulation..? It's amazing how many papers describe X, then simply write "We have tested X in simulation, and the results are..."

  2. If your simulation was custom built, how did you validate the correctness of your simulator? Without such validation how can you have any confidence in the the results you describe in your paper? Even if you didn't carry out any validation, please give us a clue about your simulator; is it for instance sensor-based (i.e. models specific robot sensors, like infra-red collision sensors, or cameras)? Does it model physics in 3D (i.e. dynamics), or 2D kinematics?

  3. You must specify the robots that you are using to test your algorithm X. Are they particular real-world robots, like e-pucks or the NAO, or are they an abstraction of a robot, i.e. an idealised robot? If the latter describe that idealised robot: does it have a body with sensors and actuators, or is your idealised robot just a point moving in space? How does it interact with other robots and its environment?

  4. How is your robot modelled in the simulator? If you're using a well-know simulator and one if its pre-defined library robots then this is an easy question to answer. But for a custom designed simulator or an idealised robot it is very important to explain how your robot is modelled. Equally important is how your robot model is controlled, since the algorithm X you are testing is - presumably - instantiated or coded within the controller. It's surprising how many papers leave this to the reader's imagination.

  5. In your results section you must provide some analysis of how the limitations of the simulator, the simulated environment and the modelled robot, are likely to have affected your results. It is very important that your interpretation of your results, and any conclusions you draw about algorithm X, explicitly take account of these limitations. All robot simulators, no matter how well proven and well debugged, are simplified models of real robots and real environments. The so-called reality gap is especially problematical if you are evolving robots in simulation, but even if you are not, you cannot confidently interpret your results without understanding the reality gap.

  6. If you are using an existing simulator then specify exactly which version of the simulator you used, and provide somewhere - a link perhaps to a github project - your robot model and controller code. If your simulator is custom built then you need to provide access to all of your code. Without this your work is unrepeatable and therefore of very limited value.
Ok. At this point I should confess that I've made most of these mistakes in my own papers. In fact one of my most cited papers was based on a simple custom built simulation model with little or no explanation of how I validated the simulation. But that was 15 years ago, and what was acceptable then is not ok now.

Modern simulation tools are powerful but also dangerous. Dangerous because it is too easy to assume that they are telling us the truth. Especially beguiling is the renderer, which provides an animated visualisation of the simulated world and the robots in it. Often the renderer provides all kinds of fancy effects borrowed from video games, like shadows, lighting and reflections, which all serve to strengthen the illusion that what we are seeing is real. I puzzle and disappoint my students because, when they proudly show me their work, I insist that they turn off the renderer. I don't want to see a (cool) animation of simulated robots, instead I want to see (dull) graphs or other numerical data showing how the improved algorithm is being tested and validated, in simulation.

An engineering simulation is a scientific instrument* and, like any scientific instrument, it must be (i) fit for purpose, (ii) setup and calibrated for the task in hand, and (iii) understood - especially its limitations - so that any results obtained using it are carefully interpreted and qualified in the light of those limitations.

Good luck with your research paper!


*Engineering Simulations as Scientific Instruments is the working title of a book, edited by Susan Stepney, which will be a major output of the project Complex Systems Modelling and Simulation (CoSMoS).

Thursday, November 27, 2014

Open science: preaching what I practice

I was very pleased to be invited to Science, Innovation and Society: achieving Responsible Research and Innovation last week. I was asked to speak on open science - a great opportunity to preach what I practice. Or at least try to practice. Doing good science research is hard, but making that work open imposes an extra layer of work. Open science isn't one thing - it is a set of practices which range from making sure your papers are openly accessible, which is relatively easy, to open notebook science, which makes the process open, not just the results, and is pretty demanding. In my short introduction during the open science panel I suggested three levels of open science. Here are those slides:



In my view we should all be practising level 0 open science - but don't underestimate the challenge of even this minimal set of practices; making data sets and source code, etc, available, with the aim of enabling our work to be reproducible, is not straightforward.

Level 0 open science is all one way, from your lab to the world. Level 1 introduces public engagement via blogging and social media, and the potential for feedback and two-way dialogue. Again this is challenging, both because of the time cost and the scary - if you're not used to it - prospect of inviting all kinds of questions and comments about your work.  In my experience the effort is totally worthwhile - those questions often make me really think, and in ways that questions from other researchers working in the same field do not.

Level 2 builds on levels 0 and 1 by adding open notebook science. This takes real courage because it opens up the process, complete with all the failures as well as successes, the bad ideas as well as the good; open notebook science exposes science for what it really is - a messy non-linear process full of uncertainty and doubts, with lots of blind alleys and very human dramas within the team. Have I done open notebook science? No. I've considered it for recent projects, but ruled it out because we didn't have the time and resources or, if I'm honest, team members who were fully persuaded that it was a good idea.

Open science comes at a cost. It slows down projects. But I think that is a good, even necessary, thing. We should be building those costs into our project budgets and work programmes, and if that means increasing the budget by 25% then so be it. After all, what is the alternative? Closed science..? Closed science is irresponsible science.


At the end of the conference the Rome Declaration on Responsible Research and Innovation was published.