#! /usr/bin/php EllaSummer2018 | Biomimetics and Dextrous Manipulation Lab
Biomimetics and Dextrous Manipulation Lab


category: SummerBlogs

This creates a floating frame with caption below For best results, attach .jpg or .png which has been resized about right

Ella in BDML for summer 2018

Updated regularly during summer 2018 to keep track of my discoveries.

Bebop Setup and Programming

Day 1

Today Sam and Tony showed me their research and progress, which were quite exciting.

  • Sam was working on a teleoperated needle manipulator for real-time image-guided procedures in an MRI. He showed me several projects he had been working on towards this goal. One approach was using a rolling-diaphragm hydrostatic system to transmit force, but the downside was the diaphragm was too short to offer enough manoeuvring space for practical operations. To solve this, Sam tried glass-syringe which enabled him to exert a force along a curve, and also gave more room to operate. The latter approach also had less friction so that the operator could feel the response from the other end better.
  • He started with different directions to solve the problem and worked on smaller projects to resolve issues that were raised during his research. For example, for the active approach which needs the motor to be compatible with MRI machine, he has to use a pneumatic motor.
  • Tony also introduced me to the Gecko adhesive he was working on. It was quite intricate to machine, caste, assemble and CNC, but the application was impressive. The non-sticky flat adhesive relied on van der Waals force to provide pure sheer force to adhere to a surface. They will use it on a robotic gripper.

Day 2

  • Today I tried to set up Crazyflie client on my Mac so that I can control it. I first installed Virtual Box so that CFC could run in a virtual machine there. I also installed FTDI driver so that my computer could recognize Crazyflie. Then, I connected the video PA and game controller to my computer and also turned the Crazyflie device itself on. However, when I ran the client inside the VM, the radio PA didn't get recognized and I thus couldn't talk to the Crazyflie through the computer.
  • Mark and Stefanie helped me a lot today solving various problems that came up with setting up. We first thought that the radio PA was broke since the connection between the board and its USB port looked fragile. We then tried some other PAs on Stefanie's computer, and some of them worked. Mark also gave me another Mac running Linux to try to install VM again, but it also didn't work. He also suggested other methods that we could use to communicate with Crazyflie. I then tried to another way to install CFC, which is through its source code. I tried that and it finally worked, and I could control the Crazyflie with my computer.
  • During a day of setting up software, Tony showed me how he cast gecko adhesive. He took the mould and poured two-part silicone into it. The silicone had been vacuumed to remove bubbles so that the resulting film would be thin and smooth. The adhesive would attach to a layer of fibreglass, which had been put on top of the mold. After overnight curing, Tony would put the mold in water to separate the product.

Day 3

  • We started the day with a lab meeting, where Mark introduced to us an artificial crocodile a lab at EPFL made. He then compared it to the force control of a Stickybot, which simulated a gecko. After the meeting, we spent the majority of the afternoon cleaning up the lab. I chose a cabinet where all the mechanical parts like screws, fasteners, and springs were stored. Frances helped me with organizing all the parts and labelling the boxes. I realized that experience did help a lot in a task like this, as evidenced in that Tony could tell the size of a metric at first glance. We thus also recruited him to help us.

Day 4

  • Today we first had the SURI meeting where we talked about the final poster session where we were going to present our research at the end of the summer. Then back to the lab, Mark gathered Stephanie, Will, Matt, and I to start planning a new project where a drone could perch on vertical surfaces like a wall or tree trunk and branches, and potentially also the ceiling.
  • Will showed me our inventory of drones including Parrot Mambo, BeBop, Bebop2, Swing, AR2, etc. We tried to come up with the criteria for a drone that would fit our project. It couldn't be too large, otherwise, it would be hazardous to have it smashing into the wall. It couldn't be too small, like the Crazyflie, either. This is because the drone needs to carry sensing elements that would enable various applications. Also, smaller drones tended to be unstable, as we have seen with Crazyflie.
  • We also talked a bit more about the mechanical part and transmitting signals, where Stephanie and Will were skilled at after ME218.

Day 5

  • Today is mostly spent laying out the roadmap for the project. We first considered the weight and size budget for the drone including the sensors and batteries. The number finally came to be between 200-500 grams. We laid out other requirements for the quadrotor as well. We also examined vertical vs. horizontal grasping on the surface and the mechanism for perching. We were planning to do a 3D layout of the whole thing. We also talked about where sensing could come in the structure, including a laser for range sensing, and optical flow for stabilization.
  • We decided that the project could be divided into three parts that could be carried out in parallel. First is the platform part, where we were going to figure out the communication and the controllability of the quadrotor. Then, there's the sensing part, where we may use an Arduino program to communicate with the quadrotor. Lastly, the most complicated gripper part. We need to do a 3D layout to find the constraints and also get material build and test it. Eventually, we are going to integrate the communication and physical parts, and write a paper!
  • We also discussed some application ideas for this flying and perching robot, which might include environmental ones like humidity and air quality testing, and also surface roughness measurements.

Day 6


  • On our way to and from Portola Redwoods, I overheard the conversations between some PhD students, namely Tony and Wilson, about their qualification exam. I also heard discussions on robotic conferences, publishing papers, other labs, etc. It was quite fun to learn about the life of a PhD student, the dynamics in a lab, and various career paths people consider to take after graduation.
  • Mark also asked us to each jot down some goals for this summer. I found that contrary to what I thought, many people were actually working on several projects at the same time. I also learned that one's thesis was coming up with an overarching theme of all the noteworthy projects that one had done, and also a story to tell about it.

Day 7

  • Today I explored Paparazzi, a UAV simulation platform that allows you to build a flight plan under various conditions. I'm trying to virtually play with the drone while we are waiting for its battery to arrive.
  • We have another meeting with Will, Stephanie, Matt, and another SURI student Ryan, talking about the gripping part, the leg, etc., as well as the expectations from my end.

Day 8

  • Today we did another cleaning of the upper cabinets and the electronics. Knowledge of identifying resistance from the strips on the resistors got put into practice!
  • I got started with learning ROS, and the ROS package that people put up to control the Bebop, bebop-autonomy. Since our Bebop 2 can't run until next Thursday, I'm also starting with Sphinx, a simulator just for Parrot drones. I'm looking to resolve some technical difficulties that arise.

Day 9

  • I did some more research on ROS, and also shadowed Tony for a bit. He was making some water-soluble gel to use as backing for the gecko adhesive. Even though he looked like he knew his stuff really well, I learned that it was his first time doing that, and he had to ask Arual about how to carry it out. I felt that research as a PhD student was like exploring an almost-unknown territory, and you have to be open to experimentation and lots of failures, and also most importantly, learn from them.

Day 10

  • I met with Stephanie today to get into details on all of the communications going on with Bebop. This link that Mark shared with us guided us through installing quadrotor workspace on Linux. I followed the guide but got stuck with the node graph step. I'm going to follow up tomorrow.
  • Stephanie also showed me the gripper she was prototyping. She also put down the mapping for communication between the devices down for me

Day 11

  • We had lab meeting in the morning where Mark showed us all the great things happening in Switzerland.
  • We flew Bebop2 for the first time using my phone as a controller. It generated strong wings when taking off or even when hovering. It also drifted a bit when we didn't take controls, but definitely better than Crazyflie. We flew it in the small conference room in the lab but it moved really fast and also in a kind of unexpected way. When we tried to land the drone, it made contact with a box on the ground, and the battery dropped out. I felt it would be much safer to fly it outdoor.
  • I then tried to control the drone with a computer by first trying to connect Bebop's WiFi through the Linux MacBook. However, I found that connecting to WiFi on a Linux system wasn't as obvious as it sounds. I went through lots of posts and tutorials teaching us how to connect to WiFi using the command line, but none of them really worked.
  • Then Stephanie and I remembered that we still had another Linux computer, and we found that the connection part was such a breeze on that Dell, just like with any other normal computer. However, the problem was that when I saw the Ubuntu version on the Dell was 14, I thought it was too old, and began to upgrade it to 16. I then realized that 14 could still support ROS Indigo, which should satisfy our needs. I thus quit the installation process and carried on with ROS but it didn't work. Since I couldn't really tell whether the problem was from the tutorial or because I started but didn't finish the Ubuntu upgrade. I eventually decided to go with Ubuntu 16 and upgraded the computer, but the original Indigo onboard was no longer supported, and I had to install ROS Kinetic.
  • Things didn't settle so easily. The system seemed that it didn't want me to install Kinetic. I'm figuring this out right now.


  • Today I came in and found the Dell computer with Linux was completely dead(oops...). Neither the recovery mode or the normal mode could save it. I'm planning to get a bootable USB drive to reinstall Linux on it.
  • In all despair, I found that the Mac running Linux could magically connect to Bebop's WiFi! However it was quite unreliable, sometimes showing the selection like in the picture but sometimes doesn't. I had to restart the computer to have it working. I then started working on that system and tried to run Bebop_autonomy but there were some errors when I wanted to launch.

Day 17

  • I picked up some shell commands that I had forgotten after finishing CS107. Learned that emacs was really helpful as you could split window and edit the file while putting commands in the terminal. Mark very generously lent me an emacs manual from 1987 that covered basically everything I need to know for Linux.
  • more <filename> is a very helpful command, as it displays the contents of a file right in the terminal without actually opening it, which helps avoid unneeded meddling with the contents of the file.
  • We can put what we want the shell to execute into a .bash file, and then use chmod +x <filename> to change the file into an executable. After that, we could use ./ to execute this file.

Day 18

  • Got Bebop communicating with the PC via bebop_autonomy. The relevant processes are documented at the begining of this page under Bebop Setup.

Day 25

  • This week I've been working on sending commands and receiving commands from the Bebop. Stephanie recommended a ROS tutorial book, "A Gentle Introduction to ROS", to me. It was pretty accessible and also systematic. Will and Stephanie helped me write a python script that incorporated both publisher and subscriber functions. The code can be found here.

Bebop Publisher+Subscriber Code

Day 26

  • We used $rostopic echo to display the stage change messages of bebop. Using python script to fire and land bebop, we managed to calculate the latency between when we send in the commands and when the state of the drone changes.
 Takeoff.publish()State changed to 7State changed to 1
 Land.publish()State changed to 4

Day 27

  • I'm looking into writing a script to use ROS to control the drone. This tutorial looks helpful.

DAY 28

  • Stephanie and I tested the code from the link above to move the bebop and it worked. I'm starting to get the point of ROS: a node that is set up to control one thing can also be used to control something else without too many edits.
  • We tested the drone in 530 where there's more open space. We found that when we were testing moving in linear.z-direction, the drone doesn't move as smoothly as in x or y. Also for z-direction, we couldn't land the drone by putting the land command in the terminal: this worked for x and y-direction though.
  • Also during our testing, the drone accidentally crashed into one of the whiteboards. While it still worked and moved after the crash, the drone was making a loud noise. We later found the leg below one of the black propellers was shaking during flight. We are trying to work on it to figure out whether we could fix it or not.
  • It looks like the direction and the units for velocities and distance follow this convention of ROS. The linear velocity is in m/s while the angular velocity is in degrees/sec. The piloting section of this tutorial is also helpful with that.

Day 29

Day 32

  • We did more testing on the drone. We could have one tab open that asks the drone to move forward, and then we could close the tab, and open in another tab the same script, and let it move backwards.
  • If we just close the script move.py, the drone will just hover in the air.
  • The drone was drifting to the right a bit today. We found it was unstable under circumstances including but not limited to: the drone being tethered to a string; things on the ground move during drone's flight. We figured that the drone chose things on the ground as anchors and move with them.
  • We also wanted to test the crushability of the drone because eventually, it is going to perch on a wall. We hoped to see how it would perform when it's super close to the wall. So we intentionally let the drone crash into the whiteboard to see how it turns out.

Week 8

  • We developed our scripts to run the Bebop step by step. Firstly we had a script to move the drone in linear directions. Then we included takeoff and landing in the script as well.
  • We tested the drone with the gripper attached. The opposite-gripping gripper had spines on both top and bottom, but the bottom ones were not working. We also found that the spines, while strong enough to hold 500g weight, were not durable. They fatigued quickly after just five trials. Some fishhooks detached from the spring steel, and some were going to break in the middle.
  • We flew the drone numerous times to find that the drone got out of control as it approached a wall and we shut it down using the emergency landing. The fall was too sudden for the gripper to start functioning.

Week 9

  • We put magnets on the drone in place of the spines as the new ones are under development. However, we found that the drone started not to listen to the commands, and drifted at will. I realized that could have to do with the magnets and I was right.
  • We continued flying (and crushing) the drone. Now with the newly-designed spines that had its body laser-cut in one piece. We also put clothes on the whiteboard so that the drone will have a softer contact with the wall to avoid damages. As the emergency landing was too abrupt, we tried the normal landing but it didn't work. The drone tried to descend--which is not possible given that our goal was for it to perch on the wall, not go back to the ground. It was imperative for us to find a way to control the motors ourselves so that we can control the speed of the propellers
  • I started making a poster and presented my draft in the lab meeting. Stephanie helped me revise the draft before then. It was a good exercise for me to look back on what I did during the past two months, and summarize my progress. Mark gave me many incredibly helpful advice on how to improve on my poster. I modified the poster after the meeting.
Page last modified on August 22, 2018, at 10:17 AM