The debate had been going on for more than two weeks. It was late summer 2017, and nine undergraduate engineering students had teamed up for their final project at the Swiss Federal Institute of Technology Zürich (ETH Zürich). They had agreed to spend the school year building a robot that could move swiftly over a flat surface and also climb stairs. But they couldn’t agree on the design. Several ideas ranked higher than others, including a tank-like bot with treads and two variations of a robot with windmill-like wheels that it could use to push and pull itself up a flight of stairs. With these, the students saw better chances for designing, building, and operating a working robot. But each device had its downside, such as being too bulky or too slow or too similar to a robot already built by other researchers.
The most innovative idea, a two-legged jumping robot with wheels instead of feet, was not a favorite. Everyone could see how difficult it would be to design and program such a machine. They’d have to overcome many engineering and software challenges to get it to balance while rolling, not to mention hopping. It seemed impossible. “I was against a jumping robot,” says team member Victor Klemm, a mechanical engineering student. “To execute a jump and regain stability on just two wheels, the robot must be extraordinarily agile and have cutting-edge motion-control technology.”
Suddenly team member Florian Weber spoke up. Mechanical engineering student Lionel Gulich recalls: “He said, ‘Guys let’s try the jumping one because although it’s probably the most difficult, it’s the coolest one, and this could be last time in our lives we will have the option of choosing.’ ” Gradually Weber convinced one student after another until everyone got on board.
That decision ultimately produced Ascento, a bipedal, 23-pound robot able to roll five miles per hour over flat terrain and jump 14 vertical inches without falling over. It can jump over obstacles and hop slowly up a flight of stairs. Onboard cameras and sensors create a 3D map of the surroundings and, when combined with vision and path-planning algorithms, enable the robot to drive autonomously.
“To execute a jump and regain stability on just two wheels, the robot must be extraordinarily agile and have cutting-edge motion-control technology.”Victor Klemm, mechanical engineering student at ETH Zürich
By the start of school in September, the nine engineering students had split into four subgroups according to their interest: electronics, software controls, construction and design, and perception and computer vision. They had five weeks to build a prototype and show their progress at the first of three intermediate presentations. Using available office space at ETHZ, they began meeting daily to sketch out ideas of robots that could scale staircases. They came up with 20 concepts and, using MATLAB® to evaluate basic movements, boiled them down to four options that seemed the most probable. From there, they built crude physical models from cardboard and LEGO® blocks and created 3D computer-aided design drawings. Ascento—a name suggested during these early days by perception and computer vision team member Nicola Küng—was starting to come together.
In a matter of weeks, the students had a solid design in hand and were able to 3D-print their first prototype of the robot’s body.
During these conceptual stages, it became apparent that if they wanted a lightweight, durable robot, they would need to keep onboard motors and electronics to a minimum. The students used an optimization tool in MATLAB to zero in on an unusual leg design that made it possible to have just one leg motor in each hip joint. The design is this: Each leg has one lower leg bone (between the knee and wheel) but two femur bones. One of the femurs connects to a motorized hip joint and a springy knee joint to control jumping. The other femur, which runs parallel to the first, connects to a pin joint and a second knee joint to stabilize the robot while it drives. The shape of the two femurs and their connection to the lower leg bone resembles a parallelogram. In a matter of weeks, the students had a solid design in hand and, with lots of help from Dominik Mannhart, a member of the construction and design group, were able to 3D-print their first prototype of the robot’s body.
It was October and the first intermediate presentation deadline loomed. Gulich and teammate Marcus Vierneisel, who were members of the software controls team along with Klemm, felt compelled to get the robot to balance on its wheels. They scavenged wheel motors, sensors, and other electronic parts from around the university, added them to Ascento, and hacked together a control system that kept the robot stable as it moved slowly forward and backward. It was a major accomplishment. In just five weeks, they’d gone from 20 different sketches of robots to a single working model able to balance on its wheels without tipping over.
“This gave quite a cool impression,” says Klemm. The team was ecstatic. “But it also proved to be a trap,” he says. The hacked balancing system wasn’t good enough to accommodate the faster, more powerful motors and the computer control systems Ascento would eventually need to remain stable as it drove and jumped. The next presentation was scheduled for just before Christmas, and the road ahead would be much longer than team members realized.
Because physics governs the dynamics of the system, getting a robot to work properly is a mathematical problem. Klemm was tasked with converting the physical system into a mathematical model. To do it, he used the masses of various structural elements, the inertia of moving parts, and other information to derive equations in MATLAB that described how the ideal robot would theoretically move. Next, he plugged those equations into Simulink® to build a computer simulation. There he not only ran tests that let him better understand the robot’s capability, but also prototyped algorithms designed to produce optimal movement. In the simulation for instance, the robot kept itself from falling forward by first sensing that its upper body was tipping forward and then accelerating its lower body to catch up.
A person does the same thing, says Klemm. “If you’re standing on your feet and you start to fall forward, you will step forward to regain equilibrium.”
The team used MATLAB and Simulink to tune the balancing algorithms and, once they worked well in simulation, transferred the tuned parameters over to the real Ascento robot. Near the end of December, the students had better, more powerful motors and sensors installed on a second iteration of the robot. But each time they ran a test, the robot toppled over. They would troubleshoot the mechanicals, retest the control algorithms in Simulink, convert the code, and reinstall it on the robot, and it would fall. It went on like this for weeks. “We were quite shocked. We thought, ‘Yeah, we got the new hardware, battery, sensors, we got a computer, we got expensive motors, now everything should be much easier than before.’ But on the contrary, it wasn’t,” says Klemm.
Days before the deadline for the second presentation, several of the students, including Klemm, Gulich, Corentin Pfister, and Alessandro Morra, pulled two all-night shifts, pushing hard to get the robot stable. It just wouldn’t balance. On the day of the presentation, the team presented their status and showed a short video of the robot wobbling back and forth like crazy. The team members were disappointed but determined. A friend asked Klemm if he was ready to give up. “I told him if I don’t get it to balance by May, I will quit my engineering studies,” says Klemm.
In the simulation for instance, the robot kept itself from falling forward by first sensing that its upper body was tipping forward and then accelerating its lower body to catch up.
In the spring of 2018, the robotics team was making progress. They’d implemented one big change that would improve their chances of success: they stopped using a USB port for sending commands to Ascento’s motors and switched to a communications protocol designed specifically for the task. The protocol, called a controller area network, is optimized for motor communication and high speeds. With it, they increased the number of commands going to the motors from 20 per second to 400 per second. The simulations weren’t wrong; the signals were taking too long to get to the motors. It was one of many learning moments. “In hindsight, using the USB port was naïve. No proper engineer would have done it that way,” says Gulich.
But even with the new protocol, they couldn’t get the robot to stabilize. Easter approached and the third presentation was due in two weeks. Gulich and some of his teammates went away for the holiday. Several others, including Klemm, stayed back to continue working on Ascento. Unable to solve the balancing problem, Klemm and Morra started asking other engineering students and faculty for advice. One Ph.D. student, who watched a video of the robot falling and reviewed some of the team’s data, said he thought the tilt sensor looked strange. Team members found that the settings had not been adjusted for balancing, which was throwing the reaction time off. They made the adjustment and within 20 minutes, the robot was stable.
“It was such a great moment. It was just one setting and we adjusted it and it balanced perfectly. We were super happy,” says Klemm.
They were three weeks from the final presentation, and they still had to refine the robot’s ability to drive around with rock-solid balance and to get the robot jumping. The controls team started taking shifts, sleeping for only six hours before returning to work. A couple of team members would spend the day making as much progress as possible and then hand it off to the next team. They got the robot to jump, but the landings were rocky. It would almost fall before one of the students would catch it.
It went on like this for days. And then one night, while Klemm and Gulich slept, team members, including Vierneisel and Ciro Salzmann, got the robot to jump and land squarely. Gulich woke to a video of it on his phone. Everyone on the team rushed to the office to see it for themselves. They opened a bottle of champagne they’d had in the refrigerator since the first week of the project.
“[The jumping robot] was the coolest of all of the ideas and now it’s two years later and we are still absolutely in love with the technology of wheels and legs and jumping.”Lionel Gulich, mechanical engineering student at ETH Zürich
When Klemm and Gulich look back on their experience, they both say they’re glad they chose the most difficult robot. “It was the coolest of all of the ideas and now it’s two years later and we are still absolutely in love with the technology of wheels and legs and jumping,” says Gulich.
If they’d chosen an easier robot, they’d have finished two years ago and would have all gone their separate ways, says Klemm. Although it can easily jump the height of stair, it needs a rolling start. They’d like to speed that up. Five of the nine students stayed on during their graduate studies to continue refining Ascento. All of them have focused some part of their university research around a technical aspect of the robot, published two academic papers, and presented at a handful of meetings and events.
The team sees the robot as a customizable platform that can support a range of sensors, such as thermal cameras, microphones, laser scanners, or chemical sensors, that can be swapped out depending on the industrial need. For instance, the compact robot could inspect warehouse inventories, seek out chemical leaks in industrial zones, or map new construction sites. It could even search disaster zones for survivors. The next version of Ascento, which they hope to have ready in three months, will more closely represent this ideal final product.
For Klemm, that day will be bittersweet. “There is so much to do and it’s such an interesting system,” he says. “I don’t want it to finish.”