Pages

Saturday, February 21, 2015

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.

Wednesday, February 18, 2015

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 partof 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?