Brad Nelson heads the Institute for Robotics and Intelligent Systems at ETH Zurich, where they focus on creating these nano devices inspired by the biological mechanisms of bacteria such as E. coli and salmonella.

Brad Nelson. Photo credit: ETH Zurich/Stéphanie Marie Couson

Brad Nelson is a Professor of Robotics and Intelligent Systems at ETH Zurich – The Swiss Federal Institute of Technology, Zurich. His primary research focus is on microrobotics and nanorobotics emphasizing applications in biology and medicine.

He has been the Department Head of Mechanical and Process Engineering at ETH, Chairman of the ETH Electron Microscopy Center, and is a member of the Research Council of the Swiss National Science Foundation. He is also a member of the board of directors for three Swiss companies.

More info:

Institute of Robotics and Intelligent Systems (IRIS)
Multi-Scale Robotics Lab (MSRL)
Brad Nelson’s Homepage
Brad Nelson’s TedX Talk

If you liked this article, you may also be interested in:

• Minimally-invasive eye surgery on the horizon as magnetically-guided microbots move toward clinical trials

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

UPDATE 04/03/2014:

In this video update, we show that a quadrocopter can be safely piloted by hand after a motor fails, without the aid of a motion capture system. This follows our previous video, where we demonstrated how a complete propeller failure can be automatically detected, and that a quadrocopter can still maintain stable flight despite the complete loss of a propeller. 

In the earlier video, we relied on an external motion capture system to measure the quadrocopter’s position and orientation.  By moving more of the algorithm onto the vehicle, the quadrocopter can now be piloted by hand after the failure. The algorithm is executed on the quadrocopter’s onboard micro-controller, and the only sensors required are the quadrocopter’s angular rate gyroscopes. We use blinking LEDs, mounted on the quadrocopter’s arms, to indicate a virtual yaw angle, so that the pilot can control the vehicle with the same remote control commands after the failure. As an alternative to the LED system, an onboard magnetometer could be used to track the vehicle’s yaw angle. Alternatively, by using more sophisticated algorithms, the system could be made to work using only the rate gyroscopes.

ORIGINAL STORY 02/12/2013

The video in this article shows an automatic failsafe algorithm that allows a quadrocopter to gracefully cope with the loss of a propeller. The propeller was mounted without a nut, and thus eventually vibrates itself loose. The failure is detected automatically by the system, after which the vehicle recovers and returns to its original position. The vehicle finally executes a controlled, soft landing, on a user’s command.

The failsafe controller uses only hardware that is readily available on a standard quadrocopter, and could thus be implemented as an algorithmic-only upgrade to existing systems. Until now, the only way a multicopter could survive the loss of a propeller (or motor), is by having redundancy (e.g. hexacopters, octocopters). However, this redundancy comes at the cost of additional structural weight, reducing the vehicle’s useful payload. Using this technology, (more efficient) quadrocopters can be used in safety critical applications, because they still have the ability to gracefully recover from a motor/propeller failure.

The key functionality of the failsafe controller is a novel algorithm that I developed as part of my doctoral research at the Institute for Dynamic Systems and Control at ETH Zurich. This new approach allows such a vehicle to remain in flight despite the loss of one, two, or even three propellers. Having lost one (or more) propellers, the vehicle enters a continuous rotation — we then control the direction of this axis of rotation, and the total thrust that the vehicle produces, allowing us to control the vehicle’s acceleration and thus position.

Even if the vehicle can no longer produce sufficient thrust to support its own weight, this technology would still be useful: one could, for example, try to minimize the multicopter’s velocity when it hits the ground, or steer the multicopter away from dangerous situations such as water, or people on the ground.

This control approach can also be applied to design novel flying vehicles — we will be releasing some related results soon.

This technology is patent pending.

For more information, have a look at the Flying Machine Arena website, the IDSC research page, or just post your question in the comments below.

If you liked this article, you may also be interested in:

• Three new quadrotor videos demonstrate agile control and the power of machine learning
• Live at TED Global 2013: Tweets, photos and video for quadrotor fans
• Behind the scenes at TED Global: Raffaello D’Andrea and team demo amazing quadrotor “athletes”
• Quadrocopters learn from prior experience to improve slalom flying

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

Microsoft has been investing in Swiss research for years, and now the US technology company is renewing its longstanding collaboration with EPFL and ETH Zurich. Microsoft will provide one million Swiss francs per year in funding for IT-related research projects at the two universities over a period of five years. The collaboration is a continuation of a project launched in 2008 that focused on embedded technology software solutions and prototypes. The new collaboration will now broaden the areas of computer science and deepen the collaboration between the three partners.

Scientists in Lausanne and Zurich submitted 27 proposals, seven of which were selected by the steering committee. Among the successful projects:

Interacting with flying robots

Otmar Hilliges, a 34-year-old assistant professor, is one of the successful project applicants. The young computer scientist from ETH Zurich studies the interaction between people and computers. For his project, he and Dr. Shahram Izadi from Microsoft Research are investigating how flying robots can work and interact with people in active scenarios. Specifically, they want to develop a platform that enables flying robots to do more than just recognise people and navigate their way around them. Thanks to their algorithms, the robots should be able to react to gestures and touch as well.

Energy-efficient memory systems

At the EcoCloud center at EPFL, Dr. Edouard Bugnion and Professor Babak Falsafi are carrying out research into energy-efficient memory architectures for data centres that can handle huge amounts of data. To do this, they are combining thousands of energy-efficient micro-servers in a way that enables them to access the memories of the other servers with a minimal time delay. The two computer scientists are working with Dr. Dushyanth Narayanan and other scientists from Microsoft Research in Cambridge to develop new applications for this system, known as Scale-out NUMA.

2022 update: A new, one-wheeled version of the Cubli has been developed. The one-wheel Cubli is a three-dimensional pendulum system that can balance on its pivot using a single reaction wheel, as it is shown in this article.

2014 update: My colleagues at the Institute for Dynamic Systems and Control at ETH Zurich have created a small robotic cube that can autonomously jump up and balance on any one of its corners .

This latest version of the Cubli (2014) can jumping up, balance, and even “walk”. This new version is self contained with respect to power and uses three slightly modified bicycle brakes instead of the metal barriers used in the previous version. We are currently developing learning algorithms that allow the Cubli to automatically learn and adjust the necessary parameters if a jump fails due to the deterioration of the brakes and changes in inertia, weight, or slope of the surface.

This robot started with a simple idea:

Can we build a 15cm sided cube that can jump up, balance on its corner, and walk across our desk using off-the-shelf motors, batteries, and electronic components?

There are multiple ways to keep a cube in its balance, but jumping up requires a sudden release of energy. Intuitively momentum wheels seemed like a good idea to store enough energy while still keeping the cube compact and self-contained.

Furthermore, the same momentum wheels can be used to implement a reaction-torque based control algorithm for balancing by exploiting the reaction torques on the cube’s body when the wheels are accelerated or decelerated.

Can this work?

The first step in creating the robot, therefore, was to look at the physics to figure out if a jump-up based on momentum wheels was possible. The image below shows some of the math to figure out the Moment of Inertia (MOI) of the wheel and full cube.

This mathematical analysis allowed a quantitative understanding of the system which allowed to inform design choices, such as the trade offs of using three momentum wheels vs. a design with a momentum wheel mounted on each of the six inner faces of the cube.

Another outcome of this analysis was a good understanding of the required velocities of the momentum wheel to allow the cube to jump up, and the torques required to keep the cube in balance. Both factors were critical for the next steps: Determining the required hardware specs.

Specs and hardware design
Given the required velocities and torques determined above, it was clear that the momentum wheel’s motor and gearbox would be a major challenge for creating the robot. Using the mathematical model allowed to systematically tackle this problem by allowing a quantitative analysis of the trade-offs between higher velocities (i.e., more energy for jump-up) and higher torques (i.e., better stability when balancing).

This mathematics-driven hardware design resulted in detailed specs for the robot’s core hardware components (momentum wheels, motors, gears, and batteries) and allowed a CAD design of the entire system.

Part of this step was the design of a special brake to suddenly stop a momentum wheel to transfer its energy to the entire cube and cause it to jump up.

The photo to the left shows an early design of this brake, consisting of a screw mounted on the momentum wheel, a servo motor (shown in black) to move a metal plate (in blue) into the screw’s path (in light brown), and a mounting bracket (in light brown) to transfer the momentum wheel’s energy to the cube structure. The current design uses a combination of hardened metal parts and rubber to reduce peak forces.

2D prototype
To validate the mechanics and electronics of the jump-up and balancing strategy and prove feasibility of the overall concept a one-dimensional version was built:

The results obtained with this 2D version of the cube were published in an IROS 2012 paper.

The final robot
Following successful tests with the 2D version, a full robot was built. The result is Cubli, a small cube-shaped robot, named after the Swiss-German diminutive for “cube”.

As you can see in the video, Cubli can balance robustly.

However, first jump-up tests showed that the stress resulting from a sudden braking of the momentum wheel led to mechanical deformations of the momentum wheels and aluminium frame. This made repeated jump-ups of the whole Cubli impossible without part replacement. It was therefore decided to tweak the structure and breaking mechanism to reduce the mechanical stress caused by the jump-up.

In addition to balancing, my colleagues are now investigating the use of controlled manoeuvres of jumping up, balancing, and falling over to make the Cubli walk across a surface.

Note 1: This post is part of our Swiss Robots Series. If you’d like to submit a robot to this series, or to a series for another country, please get in touch at info[@]robohub.org.

Note 2: This work was done at the Institute for Dynamic Systems and Control, ETH Zurich, Switzerland and was funded in part by the Swiss National Science Foundation (SNSF), grant number 146717.

Note 3: If you have questions, post them below and we’ll post answers.

Some more photos:

Thanks Gajan!

If you liked this article, you may also be interested in:

• Insect-inspired flying robot handles collisions, goes where other robots can’t
• The Distributed Flight Array: Modular robots that self-assemble, coordinate and take flight
• Designed to mingle: Rezero ballbot’s smooth moves can handle a crowd

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

The team at the ETH Flying Machine Arena has released three new videos, demonstrating quadrotors building tensile structures, tossing a ball back and forth, and refining a figure-eight trajectory using iterative learning. Worth the watch!!

Building Tensile Structures with Flying Machines

Federico Augugliaro: “This video shows quadrocopters assembling prototypical tensile structures. Part of a body of research in aerial construction – a field that addresses the construction of structures with the aid of flying machines – the video demonstrates that flying machines are capable of autonomously spanning a rope between two support points. They can also create surface structures by using already placed ropes as new support points. Furthermore, multiple machines can work together to extend the type of structures that can be created by this means. The project is a collaboration between the Institute for Dynamic Systems and Control and the Professorship for Architecture and Digital Fabrication, both from ETH Zurich, Switzerland.”

See Federico’s research paper, a collaboration with Ammar Mirjan, presented at the IEEE/RSJ International Conference on Intelligent Robots and Systems 2013.

Rapid Trajectory Generation for Quadrotors

Mark Mueller: “We have developed a method for rapidly generating and evaluating quadrocopter interception trajectories. Each trajectory goes from an arbitrary initial state (position, velocity and acceleration) to an arbitrary final state. The evaluation of the trajectory includes determining input feasibility, and state feasibility (e.g. that the position of the quadrocopter remains inside a box). Per trajectory, this requires less than two microseconds on a modern laptop computer.

The trajectory generator is used here to generate trajectories to hit a ball towards a target, and determines:

•  when to hit the ball
•  how high to return the ball
•  how much thrust to use at the end of the trajectory.

The trajectory generator is used in a receding horizon implementation, where the optimization is run in closed loop at 50Hz, and only the first part of the trajectory is used as inputs. This allows the system to cope with sensor noise, and deviations in the ball’s flight path.”

See Mark’s research paper, presented at the IEEE/RSJ International Conference on Intelligent Robots and Systems 2013.

Iterative Learning for Periodic Quadrocopter Maneuvers

Markus Hehn: “This video demonstrates an iterative learning algorithm that allows accurate trajectory tracking for quadrocopters executing periodic maneuvers.

The algorithm uses measurements from past executions in order to find corrections that lead to better tracking performance. In order to do this, we measure the tracking error over two laps of the maneuver. The new correction is then computed and applied. After waiting for one lap, we begin measuring again and the next learning step follows. For particularly dynamic maneuvers, we begin the learning process at lower execution speeds. This allows us to initially improve performance under safer conditions, and the algorithm provides a means to then transfer the learned corrections from the lower execution speed to higher speeds. The experience gained at lower speeds thus helps us when flying at high speeds, similar to how people learn skills such as martial arts or playing the piano. The method is also applicable to more complex tasks, shown here by the example of the quadrocopter balancing a pole while following a trajectory.”

See Markus’ research paper, presented at the IEEE/RSJ International Conference on Intelligent Robots and Systems 2013.

Generally, flying robots are programmed to avoid obstacles, which is far from easy in cluttered environments. At the Laboratory of Intelligent Systems, we think that flying robots should be able to physically interact with their surroundings. Take insects: they often collide with obstacles and continue flying afterwards. We thus designed GimBall, a flying robot that can collide with objects seamlessly. Thanks to a passively rotating spherical cage, it remains stable even after taking hits from all sides. This approach enables GimBall to fly in the most difficult places without complex sensors.

The concept
The inner frame comprises everything a flying robot needs to stabilize in flight: a coaxial motor, two control surfaces, the battery, an IMU and control electronics. In case of collision, GimBall’s spherical protective frame prevents obstacles from touching the inner frame and can passively rotate thanks to a gimbal system (hence the name). This way, the contact force does not affect the orientation of the inner frame, whose center of mass is also carefully centered. This allows the inner frame to always stay upright, and maintain the robot in stable flight.

The story
We have been designing flying robots capable of interacting with the environment for a while now. Our previous prototype, the AirBurr, was equipped with a protective cage and legs for uprighting.

This platform allowed us to realize that autonomous navigation was much simpler once you can afford collisions: advanced sensors are not required, and the obstacles can even be used to guide the robot. This idea of exploiting collisions was pushed further by integrating contact sensors to the structure itself. This way, the robot can be programmed to change direction once it detects a contact. We demonstrated that the robot could fly completely autonomously just based on tiny touch sensors (no other exteroceptive sensors whatsoever), as featured in the video below.

While the AirBurr worked well in the lab, where the environment is nicely flat and structured, we are now targeting much harder environments with the GimBall. For example, the robot could fly autonomously through a forest with a very simple strategy: fly straight. It made its way through the forest without any obstacle avoidance technique while experiencing multiple collisions.

We think that research on flying robots capable of interacting with the environment will enable new uses for UAVs. Currently, options for flight in cluttered spaces are limited, because obstacle avoidance methods cannot be trusted all the time. A robot that can survive collisions will be useful in cluttered disaster zones to find survivors or to inspect semi-collapsed buildings for example. Thanks to less stringent sensor requirements, these robots are lighter, faster and more robust than conventional platforms. Finally, they are very safe for operation close to people, since they won’t crash if you bump them and the propellers are enclosed in the protective cage.

You can find all relevant publications and more pictures or videos on our project webpage.

Coming to IROS next week? Comme see us at iRex, we’ll be running demos from Wednesday 6 to Sunday 9.

This research was supported by the Swiss National Science Foundation through the National Centre of Competence in Research (NCCR) Robotics.

If you liked this article, you may also be interested in:

• Fully autonomous flapping-wing micro air vehicle weighs about as much as 4 sheets of A4 paper
• First controlled flight of an insect-sized robot
• Parrot AR.Drone app harnesses crowd power to fast-track vision learning in robotic spacecraft
• Robots Podcast: Origami robots

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

A team of students from ETH Zurich and ZHdK have developed a prototype for a robotic ship inspection unit that is capable of conducting visual inspections of ship ballasts. Ballast inspection – which involves navigating hard-to-reach spots with no line of sight, often in the presence of intense heat, humidity, and hazardous gases – is normally done by human inspectors, and represents a significant cost to ship-owners who must pay for dry-docking and who face lost income when they cannot operate their ships during the inspection period. Because robotic ship inspection can occur while the ship is in operation, it could significantly reduce dry-dock time. The Ship Inspection Robot (SIR), which was developed in conjunction with Alstom Inspection Robotics and which uses magnetic wheels to navigate the I-beams and other awkward obstacles found inside ship ballast, is relatively compact and does not require any cables for power or communication, and thus offers significant mobility improvements over other robotic ship inspection prototypes. Project leaders anticipate that a per unit production cost could be as low as €4K, enabling shipping companies to operate several units in parallel as an additional time-saving measure. The robot was developed as part of a Bachelor-level project that aims to give students practical experience and promote contacts with industry.

Cargo ships, which transport everything from bananas, coffee, grain, coal, heavy equipment, chemicals, oil and gas, are the backbone of intercontinental trade, and the shipping industry represents an annual estimated average of more than €300bn worldwide. According to the International Shipping – Facts and Figures report published by the International Maritime Organisation, there were 103 392 commercial ships in service by January 2011. With an average age of 19 years and an expected lifespan of 25 years, regular inspection and repair is an important part of the global fleet maintenance.

The mechanical stress of loading and unloading, and the corrosive properties of seawater all take their toll on a vessel’s structure. This is especially true for a ship’s ballast tanks, which are filled with seawater to compensate for weight changes as cargo is loaded and unloaded. Located between the outer hull and the cargo holds, and consisting of beams and stiffeners separated by bulkheads, ballast tanks form much of a ship’s supporting structure.

The surface of ballast tanks is subject to saltwater exposure and algae accumulation, and as a result, must be inspected for damage every five years. A standard visual inspection, which can only be conducted with the ship in dry-dock after about a two-day venting period, serves as a kind of triage for determining what repairs are needed, and where. During inspection and repair, time is of the essence. Ship owners must pay for every day in dry-dock (€16K to €25K per day) and, in addition, they face loss of income when goods cannot be transported (€16K – €50K or more per day, depending on the value of the goods; oil and its derivatives, for example, can double in value within weeks in the event of a oil crisis).

Visual inspection is normally carried out by humans; however, intense heat and humidity, and hazardous gases make ship inspection a difficult and dangerous task. Ballast inspection is therefore an ideal task for robots, but the inside of the ballast, which has both convex and concave edges, as well as T-, L-, bulb- and I-profiles, presents a significant navigation challenge for any robotic inspection system. A few prototypes have been developed to date, however most of these systems have been large and heavy, and have required cables (for communication and power) that significantly limit their range and mobility.

The project
SIR was developed as part of an industrial-academic collaboration between Alstom Inspection Robotics, ETH Zurich and ZHdK. Alstom Inspection Robotics proposed a project that would result in a lightweight, low-cost robot for inspecting ships and similar structures, and provided some of the technology; a team of ten undergraduate students (six mechanical engineers and two electrical engineers from ETH Zurich, and two industrial designers from ZHdK) completed the project from concept to functional prototype as part of a nine-month bachelor-level focus project.

Developing the inspection scenario

In order to research the state-of-the-art of the ship inspection process, we went to a shipyard in Rotterdam to interview ship owners, inspectors, and maintenance workers, and to explore the inside of bulk carriers — SIR’s eventual workplace. This visit helped us to understand everyone’s priorities, how an inspection robot might be used to address them, and allowed us to develop, together with Alstom Inspection Robotics, a realistic potential inspection scenario that would serve as a guide for SIR’s eventual design. Here is the scenario we came up with:

As part of a round-the-year continuous inspection, the ship owner decides to use a four-day cruise to inspect part of the ballast tank. The inspection area is split into sections 3m wide and 50m long, which are bordered by stiffeners that can be climbed, but which limit sight. Calculations done on power consumption suggest a run time of about three hours; with an assumed average speed of 4.5 cm/s (calculated as a weighted mix of maximum and obstacle speed), ten of these sections could be inspected on a single battery charge.

Once inspection is complete, the data is analysed and suspicious areas are marked. Available data from earlier inspections is used to detect changes, and the damage map is updated. The next time a ship is due for inspection, the damage map is checked, and necessary equipment and material are ordered before the ship even enters the dry dock. 

Once in dry dock, the ship is vented and known repairs begin without delay at the same time as small or complexly shaped areas (like the bow) are manually inspected. A full inspection is shifted to the end of the dry-docking: since the inspectors already have access to the data, they can identify critical problems in advance and shorten the time they spend inspecting undamaged areas.

The prototype

The focus project resulted in a prototype for a relatively small, cable-less robotic ship inspection system that we call the Ship Inspection Robot (SIR). The prototype uses magnetic wheels to crawl along the metal ballast surface; SIR is controlled by a human inspector via wireless transmitter, and a powerful battery allows for approximately three hours of run time on a single charge. We envision that future prototypes will be able to map damaged areas. Below are some of SIR’s most important features:

1. Continuous inspection for early damage detection
   Because, unlike its human counterparts, SIR is immune to poor air quality and does not require scaffolding to climb, inspection could be undertaken while the ship is cruising. It could thus be used as part of an on-going year-round inspection program, allowing ship owners to identify and monitor suspicious areas, and order materials and plan repairs ahead of a scheduled dry-docking. While SIR is not meant as a replacement for a human visual inspection, it would allow human inspectors in dry-dock to focus on damaged areas, and on areas that are not accessible by robot, such as the ship’s bow.
2. Low cost of entry
   Because of its structural simplicity and its use of relatively inexpensive peripheral equipment, the target per-unit production cost of a commercially produced version of SIR is expected to be about €4K, allowing ship-owners or their subcontractors to treat them as a consumable rather than an asset. This low cost would allow operators to own and operate several units in parallel. The prototype cost about €12K to produce.
3. Low degree of autonomy
   Conceptually, SIR has a low degree of autonomy. Ship inspections are carried out according to very strict regulations and procedures, leaving no margin for errors, and one way to reduce errors is to keep things simple. This feel of being ‘in control’ also increases market acceptability.

How it works

SIR features four overlapping magnetic wheels, which allow the unit to maintain continual contact with the ship’s surface, even as it navigates sharp angles, vertical surfaces and overhangs. A gamepad allows the human operator to control the device, and a top-mounted camera and lighting system allow for visual inspection. The robot has almost no on-board computing power, making it lightweight and power efficient; almost all processing and control tasks (with the exception of a micro-controller for bundling sensor data) are executed on a base station that runs the Robot Operating System.

The robot uses four Sharp infra-red distance sensors for edge and obstacle detection, and an Invensense MPU 6050 IMU provides the operator with orientation data. These sensors are currently only used for user feedback. The camera used on the robot is a GoPro Hero 3 where it serves as a demonstrator for a visual sensor. It is assisted by three lights, one pointing in the viewing direction while the other two illuminate the ground in a flat angle, so as to make bumps and small edges more visible thanks to the longer shadow they cast on the ground.

Communication is carried out by two systems. The first system is an analogue wireless device. It uses the same 2.4GHz frequency as normal WLAN devices, however the signal is analogue, giving it more stability. It can be exchanged for an ethernet cable at any time. This device is used to control the robot, since delay through this channel is barely perceivable. The second system is a wireless video transmitter for the GoPro camera that is often used in model airplanes.

Performance
Working as part of an interdisciplinary team and organising a project all at once was certainly a challenge, however SIR proved itself to be a successful focus project. Not only did SIR perform as planned, it also showed that the mechanical and electrical design can be integrated into a robust and compact design; this was achieved by working closely together to integrate our various areas of expertise.

Our primary goal was for SIR to be able to overcome obstacles, and thanks to its compact wheelbase, SIR is able to do this with a high reliability, a thing no other robot known to us can do! Overcoming obstacles still needs some work in terms of reliability and smoothness, however, the robot never detached from the surface during a test and, in most cases, was recoverable without interaction from outside. We are proud that we were able to raise the bar in this respect.

So far, tests have shown that many of the other desired tasks can also be fulfilled by the current prototype, such as the ability to carry a variety of sensors.

SIR’s high range of mobility is the key value we added to the state-of-the-art of inspection robots, and thus the biggest achievement of our project. The ability to climb all these additional obstacles is not only beneficial for ship inspection, but also useful for many other robot applications such as power plant inspections.

Further development of SIR lies in Alstom Inspection Robotics’ hands.

Links
SIR website
Product Development Group at ETH Zurich
Alstom Inspection Robotics
ZHdK

If you liked this article, you may also be interested in:

• Ship hull cleaning & inspection – ideal for robots
• Beginner’s guide to the humanoid robot challenge (DRC)
• Underwater ROV keeps its eye on the target

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

Unlike larger robots, microrobots for applications in the body are too small to carry batteries and motors. To address this challenge, we power and control robots made of magnetic materials using external magnetic fields. Developed at ETH Zurich’s  Multi-Scale Robotics Lab (MSRL), the OctoMag is a magnetic manipulation system that uses electromagnetic coils to wirelessly guide microrobots for ophthalmic surgery. 

The OctoMag is capable of generating magnetic forces and torques in three dimensions, and is physically restricted to a single hemisphere to allow easy access for patients and physicians. Using an early OctoMag prototype, ex-vivo experiments were performed in pig eyes to study the navigation tasks required for retinal surgery. Following these experiments, a next-generation system was built to accomodate a small animal head, allowing for in-vivo trials. With this system, mobility experiments were conducted in which a microrobot with a diameter of 285 µm (about four times the width of a hair) was navigated reliably through the eye of a rabbit, demonstrating the feasibility of using this technology in surgical applications.

Robots are capable of exploring many environments that are difficult, if not impossible, for humans to reach; the edges of the solar system, the planet Mars, the inner depths of volcanoes, and bottom of the ocean are just some examples. The goal of these robotic explorers is to obtain knowledge about our universe and to answer fundamental questions about the nature of life on Earth. Recently, micro- and nanotechnologies have fueled an exciting expansion of this field by allowing scientists to use robots to probe life at much smaller scales. Nanorobotic systems for exploring the structures of biological cells, and robotic motion planning strategies for the investigation of protein folding, are two compelling examples of the intermarriage between robotics and nanotechnology. Such efforts and others like them illustrate how several areas of science and engineering are rapidly converging to create a new, interdisciplinary approach to research that promises to revolutionize our understanding of the world around us.

While many envision a future in which intelligent nanorobots navigate throughout our bodies searching for and destroying disease, researchers are still far from realizing such advanced technologies.  However, progress is being made, and the past decade has seen impressive advances in the fabrication, control, and delivery of power to tiny motile devices.

The MiniMag is a research tool for studies at the micro scale. As a scaled-down version of the OctoMag, the MiniMag can be integrated into an upright or inverted microscope. The eight electromagnetic coils are slightly tilted and can be positioned very close to each other due to their smaller size, and, by reducing the magnetic workspace to one cubic centimetre, much higher forces can now be achieved. Combined with high-resolution optics, the MiniMag system allows for single cell manipulation and studies at the tissue level in 3D.

From the microscale to the nanoscale
As size decreases to the nanoscale, wireless magnetic manipulation becomes increasingly challenging. The magnetic force drops by a power of three as it scales with volume, and fluidic drag forces begin to dominate as inertial forces become negligible. While a number of robotic swimming methods have been proposed to aid mobility at relatively small scales, many of these methods rely on reciprocating motions and do not scale downwards.

More than three billion years ago, bacteria evolved a swimming strategy at micrometer dimensions that nature has had difficulty improving upon, and in 1973, H.C. Berg and R.A. Anderson first described a swimming technique that uses rotating helical flagella. Inspired by this work and the flagellar motion of bacteria such as Escherichia Coli, we have recently developed artificial bacterial flagella (ABF). Our ABF represents the first demonstration of wireless swimming microrobots similar in size and geometry to natural bacterial flagella, and are many orders of magnitude smaller than existing artificial helical swimmers. With the help of 3D-laser-nanolithography, arrays of thousands of such swimmers can now be fabricated. A careful choice of materials allows for cellular interaction, and fluorescent labeling of the device assists with localization and tracking. We are pursuing applications such as the treatment of breast cancer and cerebral infarctions.

The potential impact of this technology on society is high, particularly for biomedical applications, though many challenges remain in developing micro and nanorobots that will be useful to society. An overarching requirement for achieving breakthroughs in this area is the need to bring together expertise from a wide variety of science and engineering disciplines.  Robotics brings expertise in the planning and control of mechanisms with many degrees of freedom in uncertain environments. Nanotechnology teaches innovative approaches to fabricating nanoscale machines. In addition, biomedical imaging advances are needed, as is fundamental insight into the nature of fluid dynamics at very small scales.  Medical professionals must be tightly integrated into the development cycle, and experts in developing business models and intellectual property must be closely consulted.

About the researchers
Brad Nelson’s Multi-Scale Robotics Lab (MSRL) at the Institute of Robotics and Intelligent Systems, ETH Zurich, Switzerland, is a highly multi-disciplinary research group that leverages advanced robotics techniques to create intelligent machines that operate at micro- and nanometer scales.  At the MSRL, a team of nearly 30 scientists pursues a dynamic, robotics-oriented research program involving several emerging areas of science and technology.  The technical backgrounds of the scientists in the lab span such diverse fields as materials science, physics, biology, electrical and mechanical engineering, and computer science.

The materials scientists in the lab focus mainly on developing the tools and processes required to fabricate and assemble microscale robots and nanoscale robotic components.  Many of these systems are then used in the study of biological environments, including the investigation of molecular structures, cellular systems, and organism behavior.  Other members of the MSRL research team are focused on the design and implementation of systems that wirelessly control these microrobots.  Potential applications are numerous and diverse, including microrobotically-assisted surgery, magnetic micromanipulation at the cellular level, low Reynolds number locomotion, wireless power delivery, electrostimulation of biological materials, and micro- and nanostructure fabrication and characterization.

The MSRL develops systems for controlling micro- and nanorobots in liquid and pursues various applications for these devices.

[Edited by Hallie Siegel]

If you liked this article, you may also be interested in:

• Crowdsourcing new strategies for cancer treatment: Towards swarming nanobots
• Medical robotic systems market to reach $13.6 billion by 2018
• Robots Podcast: Curved Artificial Compound Eye
• Micro-robotics and medicine: Interview with Toshio Fukuda

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

“The whole is greater than the sum of its parts” — a catch phrase that aptly expresses the Distributed Flight Array: a modular robot consisting of hexagonal-shaped single-rotor units that can take on just about any shape or form. Although each unit is capable of generating enough thrust to lift itself off the ground, on its own it is incapable of flight much like a helicopter cannot fly without its tail rotor. However, when joined together, these units evolve into a sophisticated multi-rotor system capable of coordinated flight and much more.

In the beginning
In the summer of 2008, Professor Raffaello D’Andrea at the Institute for Dynamic Systems and Control at ETH Zurich envisioned an art installation consisting of single-rotor robotic units that would self-assemble on the ground and then perform a joint task that would otherwise be impossible to achieve on its own — flight. This modular flying vehicle would then break apart in the air and then repeat the process over again, but in a new randomly-generated configuration.

Feasibility study
The number of challenges faced in designing and implementing such a system are many. We first wanted to be sure, however, that the concept was indeed feasible. Making some realistic assumptions about the system we performed some back-of-the-envelope calculations and created a linear dynamics model of the vehicle in order to provide us with some intuition about its physical dynamics. From this, a control strategy was devised. We then simulated the closed-loop system under a variety of disturbances, providing us with a general understanding of the physical requirements needed to successfully execute the project.

Design and implementation of the physical system began in the fall of 2008 as part of a design project class at ETH Zurich. The class consisted of eight graduate-level students from mechanical, electrical, and software engineering, as well as technical staff and instructors, including myself. Our task was to design and build a functional prototype that would demonstrate three key abilities of the system: (1) docking, (2) coordinated ground mobility, and (3) coordinated flight. In accomplishing each of these tasks, we would in turn validate our model and control strategy, and likely discover limitations to the system we did not foresee.

The project was no doubt challenging, and the timing constraints imposed by the class did not work in our favour. Our initial hope was to demonstrate each of the key abilities using a single set of vehicles and to demonstrate coordinated flight in several configurations. Our goals were too ambitious under the framework of this class and therefore loosened our requirements. By the summer of 2009 (a few months after the class had ended), we succeeded in demonstrating each of these key abilities, and ultimately, the project’s feasibility.

Towards the end of the above video, you will notice one of the many limitations of the system: its inability to control its altitude (or height off the ground). You may also notice that both flying and driving capabilities were separated in order to make the vehicle lighter for flight. Its primary limitation, however, was its inability to demonstrate coordinated mobility for randomly assembled configurations. The units themselves lacked the ability to communicate on each of their sides, and even if this were possible, we did not yet have any way of automatically generating the appropriate control strategy for the assembled configuration. For our demonstration, each unit was pre-programmed for a particular configuration and the controller was tuned by hand. This, however, was just the tip of the iceberg for the long list of requirements needed to successfully achieve our final goal.

Design iterations
With the design project class under wraps, and feasibility of the system demonstrated, the next step was to engineer a truly modular system capable of coordinated mobility — both on the ground and in the air. This was by no means a straightforward process; if it was, it wouldn’t be considered research. One additional revision of the vehicle was created prior to arriving at the current design.

In designing Revision 1, one of our major goals was to integrate both driving and flying capabilities. This required us to rethink the mechanical chassis and to design with a sufficient thrust to weight ratio in mind. Although light-weight and mechanically robust, the ethyl polypropylene foam chassis we used in the proof-of-concept vehicle was difficult to manufacture and our experience led us to switch to a different material. We opted instead for constructing the chassis out of laser-cut acetal plastic, a higher-powered flight motor, and a new propeller. This resulted in a very robust chassis, which was easy to fabricate in-house, and it provided sufficient thrust for the purposes of lift and control effort. What we failed to consider, however, was the stiffness of the chassis and manufacturing variability of the rotors. Only after completing the design of Revision 1 and producing several units did we discover that the vibrating modes in the chassis caused by aerodynamic turbulence from the propellers saturated the onboard rate-gyroscope sensors, which was needed for closed-loop control.

It was also important in this revision to demonstrate communication on each of its six sides. We successfully accomplished this using infrared transceivers mounted to each connection interface. However, we later discovered interference issues when conducting experiments with our vehicle within the environment of a 3D motion capture system (needed for ground truth measurements), which uses a similar frequency of infrared light to illuminate markers that it tracks in order to estimate the pose for the object of interest.

On top of this was the need to shrink the size of the electronics such that it would fit within the protected volume of the chassis. We were motivated by recent manufacturing possibilities in creating flexible printed circuit boards, and locked on to this scheme. When it came around to producing the boards, however, the lead-time for such services in relatively small quantities was much too long for our requirements — we wanted to be able to prototype and have a quick turn-around on our designs. We therefore had to redo parts of the design for a standard printed circuit board.

There was also the suggestion to first fly the system using a 3D motion capture system for measurement feedback. Since these measurements were very precise and relatively fast, we could by-pass the onboard estimation problem and focus only on the control problem. This, in fact, worked against us for two major reasons: (1) as described before, the infrared light from the 3D motion capture system interfered with inter-communication; and (2) measurement information (or control information) needed to be transmitted to the vehicle wirelessly for control purposes, which at the time of development (using WiFi) generally incurred a lot of latency and packet loss.

There was a lot that needed to be redesigned, a lot that was assumed, and there was pressure to get research publications out. In Revision 1, we tried to jump over too many hurdles at once and what we delivered was a semi-functional system — functional under optimal operating conditions, but failed to work most of the time. However we learned many things, in particular it focused our attention on parts of the design that we overlooked. This laid the ground work for Revision 2.

In Revision 2, we redesigned the chassis and thrust generation unit (i.e. propeller and flight motor) from scratch, but kept most of the power and control electronics the same. Using some of the most recent advances in manufacturing technology, the chassis was 3D printed this time around, enabling us to design with very little fabrication constraints and has a relatively quick turn-around time. The first factor was very important because of the number of tightly integrated components held together within a single unit. The second factor enabled us to quickly test a design and re-iterate as necessary.

This time around, we stepped through each phase of the design systematically. The new flight motor and propeller was tested to ensure that it produced a sufficient amount of thrust and produced little vibration within the chassis, which we tested using the rate-gyroscope sensors from Revision 1. Using two units and electronics from Revision 1, we tested the closed-loop behaviour around a single axis of rotation by mounting the two units on a horizontal pivot. This alone required a few iterations of the chassis, which in the end we managed to get right.

Ignoring the intercommunication problem, we ploughed ahead and constructed six complete units for flight. In this revision, we demonstrated coordinated flight for a variety of configurations. The flight controller was computed ahead of time and sent wirelessly to each unit prior to flight.

Knowing that the chassis and thrust generation unit was sound, we then went ahead and integrated driving capabilities and intercommunication into the units. In terms of the latter, we redesigned the intercommunication scheme, employing a hard-wired interface instead of an infrared wireless link and utilized an electrical bus to clean up the mess of communication lines we had in Revision 1. A detailed description is given in the next section.

Designed from the ground up
Each unit uses a single 32-bit 72 MHz microcontroller to interface with all of the onboard sensors, actuators, and communication peripherals. The same microcontroller is also used for performing all of the computation necessary for estimation and control — there is no computation that is performed offboard. An interchangeable wireless module (either WiFi or proprietary frequency hopping spread spectrum) allows us to communicate with each unit (e.g. telemetry and user commands); in the case where external sensors are used (e.g. 3D motion capture system), the data can be sent to the units over this wireless link.

Standard on most aerial vehicles is a 3-axis rate-gyroscope, which is used for measuring body angular velocities, as well as estimating the attitude of the vehicle in flight. An infrared distance measurement sensor is used for measuring the distance of a unit to the ground. Not only is this used for estimating the altitude of the vehicle, but if units share their distance measurements with one another they can also estimate the vehicle’s tilt when flying over a flat surface.

We have designed each unit with magnetic interfaces, located along each of its six sides. This allows a unit to passively self-align with its connected peers. The connection strength, however, is in fact not very strong. This was intentional, as it clearly demonstrates the need for cooperation between individual units in order to achieve flight — without it, the vehicle would simple rip itself apart before take-off. To successfully accomplish this, the flight control strategy must minimize the shear forces occuring between interconnected units during flight.

Also located on each of its six sides are three gold push-pins. Together with the magnets, this interface behaves similarly to the Apple MagSafe power connector, except that this interface is used to provide a means for hard-wire communication between neighbouring peers. With this, we developed our own network layer to handle inter-unit communication, as well as algorithms for routing packets, time synchronization, information fusion, etc. on a resource limited embedded system. Units are also able to communicate with one another in plane at a distance using infrared wireless transceivers, which is primarily employed for self-assembly purposes.

Each unit is equipped with three omni-directional wheels, allowing it to move on the ground with a high degree of maneuverability and to be able to move when assembled together. One of the nice things about using 3D printer technology is that the omni-wheels could be printed as a single piece, without having to assemble any components.

Positioned at its centre is a fixed-pitch propeller, capable of generating enough thrust to lift a single unit off the ground. All units are physically identical except for the handedness of its propeller. Some are clockwise and some are counterclockwise — this is needed in order to cancel out the aerodynamic torques in flight. Finally, a high energy-density Lithium-Ion Polymer battery is used to power all the electronics and actuators contained onboard.

Coordinated flight
The units can move around on the ground, self-assemble, generate an adhoc mesh network in order to communicate with one another, but the most striking feature of the Distributed Flight Array is its ability to fly in an unlimited number of configurations.

Recall that the units are being held weakly together with magnets. Thus, each unit is generating the appropriate control effort necessary to keep the vehicle in flight while minimizing the shear forces between individual units. What is most surprising is that the units themselves do not necessarily need to communicate with one another during flight.

The only information that a unit needs for flight is its local sensor data and its position with respect to the vehicle’s centre of mass. This can be computed if each unit knows the physical configuration of the vehicle. In order for a unit to determine this on its own, each unit can work out its relation to neighbouring units by sharing appropriate information. By forwarding this information around the network, each unit can arrive at the physical configuration of the vehicle, much like how one might establish his/her family tree.

Assuming a rigid body for the vehicle, which was taken into account when designing the chassis, local sensor information provides a unit with a rough estimate of the vehicle’s tilt and altitude. And knowing its position with respect to the centre of mass, it’s straightforward to work out the appropriate control effort needed to counter-act any disturbances. We avoided using a linear quadratic regulator or other optimal control strategies in favour of something much more straightforward, and as it turns out the method is also scalable. We employ a cascaded parameterized controller, consisting of tuning parameter that are physically intuitive (i.e. closed-loop natural frequency and damping ratio) for each degree of freedom.

Now, it wouldn’t be reasonable to hand-tune the controller for each and every configuration. We instead developed a means for automatically computing the tuning parameters for any flight-feasible configuration of the vehicle that would result in best flight performance. In carefullly analyzing the parameters obtained for a variety of configurations, we then developed a scalable method for mapping the configuration of a vehicle to its approximated optimal control tuning parameters.

Rewards and reality
A lot challenges, a lot of frustration, but also a lot of reward. What started as an idea is now a reality. Although we have not necessarily shown it to reenact the Concept Animation shown above, it is certainly capable of performing each of those tasks. What we have here is a piece that suitably demonstrates cooperative behaviour.

The success of this project would not have been made possible without support from the Swiss National Science Foundation, as well as the countless number of hours spent by students and technical staff — they all deserve as much credit. The Distributed Flight Array is currently being used at the Institute for Dynamic Systems and Control at ETH Zurich as a modular robotics platform for investigating algorithms in distributed estimation and control. Updates regarding the project’s status and a list of those involved with the project can be found on its home page.

Who’s Currently Involved: Raffaello D’Andrea, Maximilian Kriegleder, Igor Thommen, and Marc A. Corzillius

Photo credit: Raymond Oung

Note: This post is part of our Swiss Robots Series. If you’d like to submit a robot to this series, or to a series for another country, please get in touch at info[@]robohub.org.

If you liked this article, you may also be interested in:

• Insect-inspired flying robot handles collisions, goes where other robots can’t
• The Distributed Flight Array: Modular robots that self-assemble, coordinate and take flight
• Designed to mingle: Rezero ballbot’s smooth moves can handle a crowd
• Cubli – A cube that can jump up, balance, and walk across your desk

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

A quadrocopter swoops through the air to serve a glass of water without spilling a drop. Another gets two of its propellers cut off, yet still easily flies across the arena. “It looks like magic!” says ETH Zurich‘s Raffaello D’Andrea, but it took a lot of research, hard work and planning to bring this ‘magic trick’ to TED Global.
This post is part of Robohub’s TED Global 2013 coverage.

D’Andrea’s talk is about “Machine Athleticism” — the ability of machines to perform dynamic feats that fully exploit their physical capabilities. Part  of a session called “Those Flying Things” (which also features the work of drone ecologist Lian Pin Koh, airborne logistics activist Andreas Raptopoulos and sci-fi author Daniel Suarez), D’Andrea delves into what it takes to make a machine athlete:

We use something broadly called Model Based Design: we first build physics-based models that roughly capture the behavior of the machine; these models are then leveraged by a branch of mathematics called Control Theory to synthesize algorithms for controlling them.

He goes on to show a series of pretty amazing quadrotor feats that would be impossible without sophisticated automatic feedback. TED just posted an update on their blog about the demo here, and we will link to the video of the talk as soon as it goes online.

Clearly a lot of work has gone on behind the scenes to get D’Andrea and his team to TED. It’s taken years of research and a whole crew of PhD and Master students to develop the infrastructure and algorithms that make this demonstration possible — and that was just to get to the point where they could do the demos in-house.

D’Andrea and his team usually research and demo their quadrotor tricks at the ETH Flying Machine Arena — a 10x10x10m airspace dedicated to the study of control algorithms, and featuring a high-precision motion capture system, a wireless communication network, and custom software for executing estimation and control. Though the FMA normally lives at its home base at the Swiss Federal Institute of Technology (ETH) in Zurich, it was designed from the outset to be portable, and TED Global is not the first time it has taken to the road:
In 2011 they set up at the FRAC Centre in Orléans, France to create a six metre-high tower – the first architectural installation built by flying machines (see video). Last year the team showed their work at the world’s largest industrial fair, Germany’s Hannover Messe and at Google’s annual flagship conference Google IO in San Francisco.

Still, it takes a lot of time and careful planning to recreate the set up at a new site, and on this occasion they were planning a video shoot as well as a live audience. Says Mark Mueller, one of the team members onsite at TED, “Since April, all of us here have been working full-time, 100% on TED,” referring to all the various administrative hurdles they had to cross, such as planning logistics and agreeing on the space, in addition to rehearsing the demo itself. And then there was the packing to do: “It boils down to fifteen cases, boxes and bags,” says Dario Brescianinini, another member of the crew.

D’Andrea and his team arrived in Edinburgh, Scotland (the host city of TED Global 2013) late Saturday afternoon ahead of most other TED speakers, and started setting up almost right away in a dedicated room where the talk was filmed and where all their demonstrations will take place throughout the week. According to Brescianini and Mueller, it took about three-and-a-half hours to get the first quadrotor hovering. On Sunday they rehearsed the talk — and especially the transitions between each demo — in preparation for the video shoot, which was done in advance of the live talk.

Despite a few hiccups (two quads were damaged during setup and some repairs had to be done on the fly), Monday’s shoot went pretty smoothly. “It took about two-and-a-half hours, but we did one talk without breaks and had most of the things filmed after twenty-five minutes,” says Brescianini. It was a busy set, with fifteen TED crew members, seven people from D’Andrea’s team and one photographer. All in all, it took two fixed cameras (4k HD), one Steadicam, and three GoPros (one in the corner on the floor, one on the ceiling facing downwards, and one flying GoPro attached to a quad) to document D’Andrea’s TED talk. An additional camera shot a “making of” video as well. “It’s pretty busy, and we’re all really relieved after the successful filming.”

Want to learn more?
Check out the pages of ETH Zurich’s Flying Machine Arena team and more Robohub articles on how quadrocopters learn acrobatic maneuvers, cooperate to throw and catch balls, perfect air racing, and throw and catch an inverted pendulum.

Full disclosure: Markus Waibel works with Raff D’Andrea and the Flying Machine Arena team at ETH Zurich’s Institute for Dynamic Systems and Control.

See all the posts in Robohub’s TED Global 2013 coverage.

If you liked this article, you may also be interested in:

• Three new quadrotor videos demonstrate agile control and the power of machine learning
• Live at TED Global 2013: Tweets, photos and video for quadrotor fans
• Video: Throwing and catching an inverted pendulum – with quadrocopters
• Quadrocopters learn from prior experience to improve slalom flying

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

The Airburr, a light-weight flying robot from the Laboratory of Intelligent Systems (my PhD lab) at EPFL, was designed to fly in cluttered environments. Unlike most flying robot, which avoid contact at all cost, the Airburr interacts with its environment to navigate. Just like you might trail your hand along a wall to find your way in the dark, the robot can bounce of walls or follow them without crashing to the ground. In case of a crash, it also has a mechanism to pick itself back up and fly away. I’ve added past videos of the Airburr in action below.

The Airburr can now perch, thanks to a gecko-inspired adhesive pad that is mounted on a mechanism within the structure of the robot. This work was presented last week and ICRA (read the paper here). The gecko pad can be deployed on demand when perching is initiated. Perching allows the robot to power down and save energy, while still providing an aerial perspective that is useful for real-world missions such as search and rescue.

The work was done in collaboration with Mettin Sitti from Carnegie Mellon University, an expert in dry adhesive materials, and was inspired by the hairy feet of geckos. Rather than using claws or sticky substances to climb up walls, geckos use van der Waals forces between the tip of each hair and the surface to cling to. The artificial hairs used on Airburr have a diameter of 40um and a height of 100um with mushroom tips of 80um.

Airburr Crash Recovery

Uprighting Mechanism

How do you like to go up in a swing,
Up in the air so blue?
Oh, I do think it the pleasantest thing
Ever a child can do!

Child’s Garden of Verses by Robert L. Stephenson

If you’ve ever been a child, chances are that you’ve spent some of your childhood on a swing. And at some point during that time you have probably found out how to move your arms, legs, and body to go higher and higher, without any external help from a friend or parent pushing you – you learned how to pump a swing.

Flavio Fontana, Master student at the ETH Zurich’s Institute for Dynamic Systems and Controls, has taken this concept and used it to control a robot. To make things more challenging, his robot does not just swing, but simultaneously juggles a ball. And, using some neat math to push the idea even further, he and his supervisors Philipp Reist and Raffaello D’Andrea have designed the robot to swing and juggle without cameras – and without ever dropping the ball.

The result of their research is the Swinging Blind Juggler, a robot that juggles a ball from side to side with an actuated paddle attached to a pendulum. The robot is called “blind”, because it has no cameras to “see” the ball. In fact, the Swinging Blind Juggler has no sensors to detect the ball at all.

Here is what Flavio has to say about his video:

In this video, we propose an elegant control strategy for a Swinging Blind Juggler. The key idea is to exploit the dynamic coupling between the motion of the paddle and the pendulum. Children on a swing intuitively use this dynamic coupling to control their amplitude. In a similar way, we control the pendulum with appropriate paddle motions.

So how does this work?

Flavio explains that four conditions must be met for successful juggling:

• First, the paddle used to juggle the ball must have a specific concave shape. This shape will always push the ball back towards the ideal flight path if the ball impact happens to be off-center.
• Second, the paddle has to decelerate as it strikes the ball. This helps to keep the ball bouncing at a consistent height: If the ball flies too high, it will hit the paddle later and hence at a lower speed. Conversely, if the ball flies too low, it will hit the paddle earlier and hence increase the ball’s height on the next bounce.
• Third, the paddle always has to strike the ball at right angles. This ensures that the ball always flies off into the right direction, towards the other side of the swinging motion.
• And fourth, the pendulum must be synchronized to the ball motion. In other words, the pendulum has to reach the peak of its swinging motion at the right time to strike the ball.

To guarantee all of the above, the researchers first derived a mathematical model of the desired motion. Based on these models, they came up with a hardware design that includes a parabolic plate to stabilize the ball’s impact points on the paddle (the first condition), a decelerating paddle motion that stabilizes the ball height (the second condition), and a mechanical mechanism based on four linked bars that automatically tilts the paddle to the right angle for all juggling amplitudes (condition number three).

To meet condition four (to swing back and forth at the right rhythm to hit the ball) the robot can use the same linear motor used to create the decelerating paddle motion for condition two – as long as it still strikes the ball with the right decelerating motion at its peaks. Similar to a child on a playground swing, the robot must raise its body as the swing passes through the lowest point and lower it near the extremes of the motion to pump the swing and swing higher.

The result of the precisely designed hardware setup and control algorithms is a complex motion that’s beautiful to watch – and that blindly juggles a ball from side to side.

To learn more about blind juggling robots, have a look at www.blindjuggler.org.

Note: This post is part of a series that decribes robots developed in Switzerland. If you’d like to contribute a robot to this (or another country’s) series, get in touch at info[@]robohub.org. Like this series? Read more about Swiss Robots!

Designing robots that can function outside of controlled, factory environments isn’t easy. When those environments have people in them, they are especially unpredictable and difficult for a robot to navigate.

Enter Rezero: a compact ballbot that can fluidly drive in any direction without prior orientation. Similar in size and shape to a human, Rezero can stabilize, instantly accelerate, avoid obstacles and turn around its own axis. It can also be programmed to follow a path, or a person at a constant distance, and it can even recover from jostles, making it ideal for navigating crowded environments like tradeshows, restaurants, offices and airports.

Possible Rezero applications: personal mobile medical device, telepresence tour guide, personal transportation.

It’s easy to imagine it one day being used to unobtrusively serve drinks at a cocktail event, as a personal mobile device for intravenous equipment at a hospital, or topped with a telepresence device and acting as a museum tour guide. Rezero could even one day rival the Segway as a personal transportation device.

A master of fluidity

Like an inverted pendulum, Rezero (left) balances on a spherical ball; three omniwheels (right) transfer motor action to the ball below.

Rezero’s agility comes from a propulsion and stabilization mechanism that keeps the device balanced on top of a single spherical wheel, like an inverted pendulum; it’s kept from falling over by constantly moving its contact point below its center of gravity.

A sensor called an Inertial Measurement Unit (IMU) measures Rezero’s tilt angle, which is used by an onboard stabilizing controller to compute what kind of motor action is required to keep the system stable. Instructions are then sent to electric motors that actuate three special wheels (called omniwheels), which in turn transfer forces to the sphere below: forces are applied in the rolling direction, but allow for free motion in the lateral direction; opposing each wheel is an arrestor that keeps the ball tightly in place. This process of measuring, computing, and actuating happens 160 times per second, and the underlying controller is key to achieving robust and dynamic movement.

Its ability to quickly respond to a changing environment is what makes Rezero so suitable for human environments, and according to Rezero’s creators, achieving this robustness was their most challenging task. Rezero’s controller is derived from a three-dimensional mathematical model of the system, and can combine complex and fluid movements around all axes. Compared to other ballbots, which can only lean a few degrees, Rezero can tilt up to 17 degrees as it leans into a curve at high speeds.

But getting there wasn’t easy. Rezero was developed in 2009/2010 as an educational project at the Autonomous Systems Lab at ETH Zurich,  and the 13 undergraduate students on the team were responsible for everything from concept to engineering, manufacturing and budgeting.

According to project leader Péter Fankhauser:

“It was the moment we got Rezero to balance for the first time that struck me the most. We got to know the system and work with it and were able to observe how its capabilities improved every day.”

Michael Neunert, his fellow founding team member agrees:

“The development phase was a very intense time. We only had nine months to sketch out our ideas and build Rezero as we see it today.”

Rezero continues to evolve even though some of the original team members have already graduated and moved on. The current team has just finished a new version of the omniwheel, which they have made available to other research groups. They are now working to improve Rezero’s robustness so that it can better manage obstacles in an everyday environment.

Key infos

Robot name: Rezero
Mechanical engineering: Simon Dössegger, Péter Fankhauser, Corsin Gwerder, Jonathan Hüssy, Jérôme Käser, Thomas Kammermann, Lukas Limacher, Michael Neunert
Electrical engineering: Samuel Schüller, Swen Wigert
Industrial design: Jessica Baumgartner, Tu-Van Giang, Claudio Maestretti
Project supervisor: Prof. Dr. Roland Siegwart, Director of the ASL at ETH Zurich
Websites: http://rezero.ethz.ch, TED Talk
Status: Ongoing research project

Photo credits: Rezero in Motion (first photo): Karl-Heinz Hug, Ringier AG; Rezero in the Studio (third photo): Gerhard Born, Ringier AG.

Note: This post is part of our Swiss Robots Series. If you’d like to submit a robot to this series, or to a series for another country, please get in touch at info[@]robohub.org.

What about Cloud Robotics?

The following video briefly explains the general motivation:

Generally, a robotics application interacts with its environment using sensors and actuators. This implies that the data produced by the sensors has to be processed and is normally used as feedback to determine the next action. For actions without hard real-time requirements, processing can be moved to the cloud. This reduces the necessary computing power on the robot, which can improve operation duration for mobile systems and may decrease costs.

Simplified cloud model: Each robot is connected to its own clone in the cloud (rectangular boxes), which are tightly interconnected with each other and with the databases (circular disks).

Many common high-level robotics tasks, such as planning or mapping, don’t require hard real-time. Mapping, for example, involves storing a reusable description of the environment to allow the robot to localize a landmark or itself. Additionally, maps can be used on a large scale to plan trajectories for moving to a landmark or on a small scale to grasp an object, which in turn might include querying an object database for grasp points to get the best position to grab the object. Because planning can be done ahead of time (i.e. act instead of react), it has no hard real-time constraints.

The advantages of offloading computation to the cloud can be even more pronounced when considering collaborative robot scenarios. For example, sharing data when creating a common map, or negotiating a cooperative plan when performing a common task can be more easily achieved with a centralized architecture with powerful computational capabilities.

RoboEarth allows robots to share knowledge in a centralized knowledge base. This centralized approach has the advantage of avoiding duplicate information and the necessity to constantly exchange newly generated knowledge to avoid duplicate learning. However, to benefit from the full potential of this approach not only requires a centralized storage of knowledge, but also centralized reasoning, i.e. a framework for cloud computation for robots.

The missing piece

Until now, RoboEarth only provided data storage for robots. With the introduction of Rapyuta, the RoboEarth Cloud Engine, the missing piece in the cloud infrastructure for robots is added. Rapyuta provides a platform where robots can create computing environments to offload there heavy computation into the cloud. These computing environments can either function as a personal cloud for individual robots or be shared by multiple robots. Additionally, computing environments have high-bandwidth connections to the RoboEarth database, allowing their processes to quickly access knowledge.

Technical aspects

Simplified overview of Rapyuta: The robots are connected to Rapyuta’s communications module in the cloud. Similarly, the cloud applications running inside the computing environments (LXC) are also connected to the communications module. The module manages communications from and to all connected elements.

To simplify the deployment and interaction of the cloud applications Rapyuta, similar to the Google App Engine, defines a protocol for cloud applications. However, in contrast to Google’s model where only web requests are used to communicate directly with the cloud application, Rapyuta introduces an additional layer. This means, a robot does not communicate directly with a cloud application, but uses Rapyuta as a medium. This model gives more flexibility and control over the system. For example, Rapyuta can be used as a relay to communicate directly between robots without the creation of a computing environment. Furthermore, the additional layer implies that Rapyuta allows to run multiple processes using sockets to communicate with each other. Google’s App Engine, however, prevents this, because web applications have no need for communicating processes to service web requests.

On the robot side Rapyuta uses common web protocols that allow access via a web browser. Like rosbridge and ros.js, Rapyuta uses WebSockets for persistent connections and JavaScript Object Notation (JSON) compatible strings for messages. However, because rosbridge provides only a subset of the functionality of Rapyuta the two protocols are not compatible. The main reason for this is that Rapyuta allows the client to interact with more than one ROS environment, i.e. computing environments, over the same connection, which leads to a more complex protocol for Rapyuta.

On the cloud application side the message system defined by the Robot Operating System (ROS) is used. This allows to deploy and run most of the more than 3’000 existing ROS packages (i.e., ROS applications) with minimal to no changes in the RoboEarth Cloud Engine.

To separate the ROS nodes, i.e. the cloud applications, for different users, Rapyuta provides individual computing environments. A robot can have many computing environments and a computing environment can be used by many robots, which allows a variety of deployment models. Linux Containers (LXC) were chosen for the implementation of computing environment to securely control all operational aspects such as communication as well as CPU, RAM, and disk usage. Additionally, Rapyuta allows different computing environments to communicate with each other using the ROS messaging system.

Rapyuta is open source. The Rapyuta Alpha release is available on github under the Apache License, Version 2.0.

For more information have a look at the Rapyuta documentation.

Further reading:

• Analysis: Robot learning in the cloud

Two of the most challenging problems tackled with quadrocopters so far are balancing an inverted pendulum and juggling balls. My colleagues at ETH Zurich’s Flying Machine Arena have now combined the two.

As part of his Master thesis Dario Brescianini, student at ETH Zurich’s Institute for Dynamic Systems and Control, has developed algorithms that allow quadrocopters to juggle an inverted pendulum . If you are not sure what that means (or how that is even possible), have a look at his video “Quadrocopter Pole Acrobatics”:

(Don’t miss the shock absorber blowing up in smoke at 1:34!)

The Math

A quadrocopter with a plate for balancing the pole. The cross-shaped cut-outs are used for easy attachment to the vehicle and have no influence on the pendulum’s stability.

To achieve this feat, Dario and his supervisors Markus Hehn and Raffaello D’Andrea started with a 2D mathematical model. The goal of the model was to understand what motion a quadrocopter would need to perform to throw the pendulum. In other words, what is required for the pendulum to lift off from the quadrocopter and become airborne?

This first step allowed to determine (theoretical) feasibility. In addition, it showed the ideal trajectory in terms of positions, speeds, and angles the quadrocopter needed to follow to throw a pendulum. And it offered an insight into the throwing process, including identification of its key design parameters.

Reality Checks
The main goal of the next step was to determine how well the theoretic model described reality: How well does the thrown pendulum’s motion match the mathematical prediction? Does the pendulum really leave the quadrocopter at the pre-computed time? How does the pendulum behave while airborne? How well do assumptions for catching the pendulum (e.g., completely inelastic collisions, completely rigid pendulum, infinite friction between quadrocopter and pendulum when balancing) hold?

This second step involved multiple tests with the physical system, including throwing the pendulum by hand to study its aerodynamic properties and precisely timing the quadrocopters’ and pendulum’s motions during the maneuver.

Analyze, Experiment, Repeat

The shock absorber at the end of the pendulum is a balloon filled with flour and attached to a sliding metal cap with zip ties.

Armed with a good theoretical model and knowledge of its strengths and limitations, the researchers set out on a process of engineering the complete system of balancing, throwing, catching, and re-balancing the pendulum. This involved leveraging the theoretic insights on the problem’s key design parameters to adapt the physical system. For example, they equipped both quadrocopters with a 12cm plate that could hold the pendulum while balancing and developed shock absorbers to add at the pendulum’s tips.

This also involved bringing the insights gained from their initial and many subsequent experiments to bear on their overall system design. For example, a learning algorithm was added to account for model inaccuracies.

Dario writes:

This project was very interesting because it combined various areas of current research and many complex questions had to be answered: How can the pole be launched off the quadrocopter? Where should it be caught and – more importantly – when? What happens at impact?

The biggest challenge to get the system running was the catching part. We tried various catching maneuvers, but none of them worked until we introduced a learning algorithm, which adapts parameters of the catching trajectory to eliminate systematic errors.

The long and iterative process of this third step resulted in the final successful architecture to repeatedly throw and catch the pendulum on the real system, including three key components:

First, a state estimator was used to accurately predict the pendulum’s motion while in flight. Unlike the ball used in the group’s earlier demonstration of quadrocopter juggling, the pendulum’s drag properties depend on its orientation. This means, among other things, that a pendulum in free fall will move sideways if oriented at an angle. Since experiments showed that this effect was quite large for the pendulum used, an estimator including a drag model of the pendulum was developed.
This was important to accurately estimate the pendulum’s catching position.

Another task of the estimator was to determine when the pendulum was in free flight and when it was in contact with a quadrocopter. This was important to switch the quadrocopter’s behavior from hovering to balancing the pendulum.

Second, a fast trajectory generator was needed to quickly move the catching quadrocopter to the estimated catching position.

Third, a learning algorithm was implemented to correct for deviations from the theoretical models for two key events: A first correction term was learnt for the desired catching point of the pendulum. This allowed to capture systematic model errors of the throwing quadrocopter’s trajectory and the pendulum’s flight. A second correction term was learnt for the catching quadrocopter’s position. This allowed to capture systematic model errors of the catching quadrocopter’s rapid movement to the catching position.

The Result
As you can see in the video embedded above, at the end of Dario’s thesis two quadrocopters could successfully throw and catch a pendulum.

Many of the key challenge of this work were caused by the highly dynamic nature of the demonstration. For example, the total time between a throw and a catch is a mere 0.65 seconds, which is a very short time to move to, and come to full rest at, a catching position.

Another key challenge was the demonstration’s high cost of failure: a failed catch typically resulted in the pendulum hitting a rotor blade, with very little chance for the catching quadrocopter to recover. A crashed quadrocopter not only entailed repairs (e.g., changing a propeller), but also meant recalibration of the vehicle to re-determine its operating parameters (e.g., actual center of mass, actual thrust produced by propellors) and restarting the learning algorithms.

Says Markus Hehn:

This was a really fun project to work on. We started off with some back-of-the-envelope calculations, wondering whether it would even be physically possible to throw and catch a pendulum. This told us that achieving this maneuver would really push the dynamic capabilities of the system.

As it turned out, it is probably the most challenging task we’ve had our quadrocopters do. With significantly less than one second to measure the pendulum flight and get the catching vehicle in place, it’s the combination of mathematical models with real-time trajectory generation, optimal control, and learning from previous iterations that allowed us to implement this.

Note: The Flying Machine Arena is an experimental lab space equipped with a motion capture system.
Full disclosure: I work with Dario Brescianini, Markus Hehn, and Raffaello D’Andrea at ETH Zurich’s Institute for Dynamic Systems and Control.

More photos:

Credits: Carolina Flores, ETH Zurich 2012

If you liked this article, you may also be interested in:

• Three new quadrotor videos demonstrate agile control and the power of machine learning
• Live at TED Global 2013: Tweets, photos and video for quadrotor fans
• Behind the scenes at TED Global: Raffaello D’Andrea and team demo amazing quadrotor “athletes”
• Quadrocopters learn from prior experience to improve slalom flying

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

Manual programming of robots only gets you so far. And, as you can see in the video, for quadrocopters that’s not very far at all (see the “Without Learning” part starting at 1:30):

On its first try to navigate the obstacle course, the flying robot attempts to navigate based on a pre-computed flight path. The path is derived using a basic mathematical (“first principles”) model. But quadrocopters have complex aerodynamics – the force produced by the propellers changes depending on the vehicle’s velocity and orientation, and thus the actual amount of force produced is quite different from what the simple math describes.

What’s worse, these flying vehicles use soft propellers for safety, which bend differently depending on how much thrust is applied and wear rapidly with use (and even more rapidly when crashing).

Even with continuous feedback on the robot’s position from the motion capture system, manually programming the robots with a control sequence that takes all these imperfections into account is impractical.

My colleague Angela Schoellig and the Flying Machine Arena team here at ETH Zurich have now developed and implemented algorithms that allow their flying robots to race through an obstacle parcours – and learn to improve their performance.

Here is how Angela described the process to me:

The learning algorithm is applied to a quadrocopter that is guided by an underlying trajectory-following controller. The result of the learning is an adapted input trajectory in terms of desired positions. The algorithm has been equipped with several unique features that are particularly important when pushing vehicles to the limits of their dynamic capabilities and when applying the learning algorithm to increasingly complex systems:

1. We designed an input update rule that explicitly takes actuation and sensor limits into account by solving a constrained convex problem.
2. We developed an identification routine that extracts the model data required by the learning algorithm from a numerical simulation of the vehicle dynamics. That is, the algorithm is applicable to systems for which an analytical model is difficult (or impossible) to derive.
3. We combined model data and experimental data, traditional filtering methods and state-of-the- art optimization techniques to achieve an effective and computationally efficient learning strategy that achieves convergence in less than ten iterations.

The result is a robot that learns and improves each time it tries to perform a task.

In this example the robot races through a pylon parcours, calling to mind air races, such as the Red Bull Air Racing Championships or the Reno Air Races – except that there are no human pilots that spent their life learning to fly – here it’s robots doing the learning. And they are efficient, taking less than 10 training sessions to find the optimal steering commands!

Moreover, the learning algorithms are not specific to slalom racing, they can be used to learn other tasks. As Angela points out:

Our goal is to enable autonomous systems – such as the quadrocopter in the video – to ‘learn’ the way humans do: through practice.

The videos below show how learning algorithms can be used for other robotic tasks:

Full disclosure: Angela and the Flying Machine Arena team work in the same lab as I. Also, I’m working on RoboEarth, trying to allow robot learning on a much larger scale.

 
My colleagues at the ETH Zurich’s Flying Machine Arena have just released a new video. Here is what Robin Ritz, Lead Researcher on the project, has to say about it:
 

This video shows three quadrocopters cooperatively tossing and catching a ball with the aid of an elastic net.
 
To toss the ball, the quadrocopters accelerate rapidly outward to stretch the net tight between them and launch the ball up. Notice in the video that the quadrocopters are then pulled forcefully inward by the tension in the elastic net, and must rapidly stabilize in order to avoid a collision. Once recovered, the quadrotors cooperatively position the net below the ball in order to catch it.
 
Because they are coupled to each other by the net, the quadrocopters experience complex forces that push the vehicles to the limits of their dynamic capabilities. To exploit the full potential of the vehicles under these circumstances requires several novel algorithms, including:
 

1. an optimality-based real-time trajectory generation algorithm for the catching maneuver;
 
2. a time-varying trajectory following control strategy to manage the forces on the individual vehicles that are induced by the net; and
 
3. learning algorithms that compensate for model inaccuracies when aiming the ball.

 
For more information on this and related work, have a look at the Flying Machine Arena’s website or tune in to Prof. Raffaello D’Andrea’s ROBOTS Podcast interview.
 
Some photos of the robots in action:
 

 

 

Thymio II was introduced at the 2011 EPFL Robotic Festival. Now, with the introduction of Aseba, the creative toolset associated with it is complete. Aseba allows even younger children to animate their creations by programming Thymio II. Developed within the framework of the Swiss National Center for Competence in Research Robotics, by a team of the Ecole Polytechnique Fédérale de Lausanne (EPFL), the Ecole d’Art de Lausanne (écal), the Eidgenössische Technische Hochschule Zürich (ETHZ) and the Mobsya association, Thymio II has been distributed to more than 1000 Swiss children. Examples of what they’ve done with it can be found on the Aseba website. Thymio II is available for 99 Swiss Francs, plus 32 Francs for shipping and administrative costs (totaling just over US $140), from the mobsya association.

Link to audio file (38:04)

Link to transcript

In today’s episode we speak with Matthias Kohler, faculty at ETHZ and renowned architect, about his work in robotic architecture at the Future Cities Laboratory (FCL) which is part of the Singapore-ETH Centre for Global Environmental Sustainability (SEC) in Singapore.

We hear how he first got interested in robotics and automated architecture, and what the future plans are for his lab.

Matthias also talks about how the design of buildings and the urban landscape will change when the construction process becomes automated. The history of modular and automated building is not exactly filled with success. We discuss why that is, and why it is likely to be different this time around.

The issues of safety, compliance with building codes and quality control are other interesting topics that we get to hear more about in this interview.

If you are interested in automated building, you might be interested in our previous interview with Radhika Nagpal, where she talks about the TERMES project that aims to develop an automated building system that mimics termites and how they build their impressive mounts.

Matthias Kohler
Matthias Kohler is an architect with multi-disciplinary interests ranging from computational design and robotic fabrication to material innovation. In 2000, he founded the architecture practice Gramazio & Kohler in conjunction with his partner Fabio Gramazio, where numerous award-wining designs have been realized, integrating novel architectural designs into a contemporary building culture. Trained at the Swiss Federal Institute of Technology ETH Zurich, his integral approach to practice and research focuses on the interplay of digital design and material processes through advanced construction methodologies.

Since 2005, Gramazio & Kohler hold the Chair for Architecture and Digital Fabrication at the Swiss Federal Institute of Technology ETH Zurich. Founding the world’s first architectural robotic laboratory, the pioneering investigations of Matthias Kohler concentrate on non-standardized architectural design and additive fabrication processes through the customized use of industrial robots. A significant amount of research has been accomplished addressing scales ranging from 1:1 prototypical installations to the design of robotically fabricated high-rise buildings. Currently Matthias Kohler’s research is focusing on adaptive design strategies for constructive material systems and in-situ robotic fabrication.

In Matthias Kohler’s practice, emphasis is placed on understanding construction and materialization as fundamental to the design of architecture. Gramazio & Kohler demonstrates a profound architectural expertise, considering the building process in all its cultural, constructive and sensual dimensions. Built work ranges from international exhibitions, private and public buildings to large-scale urban interventions. Projects include the Gantenbein vineyard façade, the Tanzhaus theatre for contemporary dance, the Christmas lights for Bahnhofstrasse, the sWISH* Pavilion at the Swiss National Exposition Expo.02 and the Private House in Riedikon.

Matthias Kohler’s innovative explorations have contributed to numerous exhibitions around the world such as the 2008 Architectural Biennial in Venice and the Storefront Gallery for Art and Architecture in New York 2009. His work has been published in a large number of journals, books and mass media and is further documented in the book Digital Materiality in Architecture, which outlines the theoretical context for the full synthesis of data and material in architecture.

https://www.youtube.com/watch?v=JnkMyfQ5YfY

Links:

• Download mp3 (24.2MB)
• Subscribe to Robots using iTunes
• Subscribe to Robots using RSS
• Architecture and Digital Fabrication
• Future Cities Laboratory
• Gramazio & Kohler

Link to audio file (20:43)

In this episode, we discover an aerial modular robot called the Distributed Flight Array. To talk about this, we have Raymond Oung from the Swiss Federal Institute of Technology in Zürich.
Then, to celebrate aerial robotics, we’re holding a contest on flying robot noises for a chance to win a WowWee Bladestar.Raymond Oung

Raymond Oung is lead researcher of the Distributed Flight Array project at the Swiss Federal Institute of Technology in Zürich under the supervision of Prof. Raffaello D’Andrea (see previous ROBOTS interview).

The idea behind this project is to design a set of vehicles equipped with a single propeller and wheels that can drive around in search for fellow modules with whom to dock. Single modules are not stable but once assembled, the flight array is able to take-off and achieve coordinated flight. Modules then detach in-air, fall to the floor and repeat their search for other propellers.

The main challenge in this system is to come up with a distributed controller that can allow modules to work together to achieve coordinated flight. Because of its endless number of configurations, the distributed flight array is the perfect research and pedagogical testbed to study control theory for complex systems.

Contest

We were trying to imagine the sound of all of these propellers and then realized it would be fun to record the sound of some of the flying objects here at EPFL. If you manage to match the sound with the correct robot picture, we’ll be sending you a Wowwee Bladestar. If multiple correct answers are received, the winner will be selected randomly. The contest ends on the 27th of August and answers can be sent via email to info@robotspodcast.com or can be posted below this episode in the comments section. WowWee Bladestar Audio: Noises of Flying Robots Images: 1: Eyebot 2: Airburr 3: SMAV 4: Blimp 5: WowWee DragonFly 6: Eyebot

The correct answer was:
1 -> F
2 -> B
3 -> A
4 -> C
5 -> E
6 -> D

Links:

• Download mp3 (11.5 MB)
• Subscribe to Robots using iTunes
• Subscribe to Robots using RSS
• Distributed Flight Array Website

Latest News:
For more information and videos of Ishiguro’s Telenoid R1 and the F1 Robocoaster in action, have a look at our forum.