It’s summer here in Sweden, which means a lot of sun, heat, and… well, right now, rain, but hopefully things will get better.
Credits: Silvia Man/imagebank.sweden.se
As every year, we try to enjoy it as much as possible. That means that some of us are taking off for well-deserved vacations. During the coming month, Bitcraze will be run by a skeleton crew of people.
That means that the office will get slower too. Now, keep in mind that in a company made by only 6 persons, 3 people going on holidays is taking half the workforce – so the remaining men and women are here to keep things afloat. We will still ship the orders regularly – in a huge part thanks to your new and improved packing system– and answer emails, helping you on Github discussions etc… on a regular basis. But our response time may be slower than usual – and some things will have to be postponed until the right person can get to it. We will, of course, always tell you what’s happening, and keep going with the Monday blogposts.
For us that are in the office, it is also the chance to focus on more personal projects. Often during the summer, when our colleagues are away, we grab the opportunity to develop ideas and projects that we usually don’t prioritize. Last summer, for example, Kimberly dig deeper into ROS2. I myself will try to make some changes to the office itself. We will also try to clean up- not only the office itself, but fixing various bugs that usually don’t get the highest priority. In general, we try to have a clean slate before things start to get back up again.
We hope that you can also enjoy a slower summer and some vacations!
Today, Lennart Bult from Emergent Swarns presents us with this project of a 24/7 swarming demo. Enjoy!
Over the last few months our team has been working on creating a 24/7 swarming demo. Initially tasked by Guido de Croon and Chris Verhoeven from TU Delft MAVLab and the TU Delft Robotics Institute, we set out to find our way within the Crazyflie ecosystem to gradually increase the size and capabilities of the swarm. In this article we will first talk about some of the work and methods that we used. After that, we will introduce the TU Delft Science Centre Swarming Lab and talk about some applications of swarming drones.
Developing the 24/7 swarm
The project started in February with the goal of creating a physical swarm capable of real-time collision avoidance with drones and static obstacles. We started out with three drones equipped with the Flow Deck, and by setting them up in a clever way we could perform the first collision avoidance and landing tests. We were impressed with the performance we got out of the Flow Deck, however, eventually, it is mostly a battle against the drift of the position estimate, that is, we could increase some of the margins on the collision avoidance only so far before we would either fly out of the test zone or collide with another drone. Luckily with short test flights, we were able to see some of the flaws in our algorithms and correct them before testing with the new setup.
Setup after the first expansion to eight drones.
After a few weeks of testing we got approved for the first swarm expansion, five more drones and a Lighthouse positioning setup. This is when we could do our first real tests with the collision avoidance algorithm, which, much to our own surprise, worked on the first try. This is also when we first posted a project update on LinkedIn. There were however a lot of bugs that still needed to be worked out, and a lot of system experience still to be gained. After flying for a bit longer we noticed that some of the drones would flip quite often, which is when we discovered that we needed the thrust upgrade to control the additional weight of the larger battery and charging deck.
For the charging setup we took inspiration from the Bitcraze IROS 2022 demo; we 3D printed sloped landing pads that we tape onto a wireless charger. After a few iterations we landed on a design that uses minimal printer resources and allows the Crazyflie to land a bit off-center. This last feature turned out to be quite useful considering the large amount of destabilizing airflow that is generated by 40 drones. After receiving the last order of drones we also expanded the charging setup, which at this point takes up quite a bit of floor space. There are some ideas to create a vertical landing pad stack, which would bring the additional challenge of missing the landing pad not being an option.
All 40 drones recharging before their next flight.
After prototyping the charging setup and building confidence with the initial setup, we were confident enough in our system capabilities to expand it to the point where a continuous demo of 5-8 drones is possible. Although the system integration of the previous expansion went without much trouble, we did encounter a few issues when expanding to 40 drones. The first issue of which was radio communication, we noticed that a delay in the radio communication would be present if we increased the update rate above a certain level for a specific number of drones per radio. The second issue we encountered were performance drops related to the violation of certain bounds in the collision avoidance algorithm. These two issues were very difficult to debug since it was not immediately obvious where the source of the issue was.
The third and last major issue was the increase in destabilizing airflow of 40 drones compared to 8. With 40 drones there is a noticeable breeze when you stand next to the drone cage, which is nice for summertime, but not so nice when drones need to land in a tight-packed configuration. To combat this issue there is a limit to the amount of drones that can land at the same time. There is also a minimum separation distance between two active landing pads, which reduced the severity of the induced turbulence. There are still ongoing efforts to increase the landing success rate, which is currently affected by drones running out of power during the landing procedure.
To control and monitor the swarm we designed a custom GUI, an impression of which you can see below. Although some of the buttons are still a work in progress, there are a lot of features that have already proven very useful, especially when testing a new feature.
V1 of the graphical user interface developed for the 24/7 swarm.
The code base that we created for the swarm will be largely open-sourced (only the collision avoidance will not be open-source) to provide researchers all around the world with the possibility to setup their own Crazyflie swarm for research. You can find the repository through this link. Note that the documentation and code base are still under development and might contain bugs/errors.
Human interaction
After creating all functionality to provide a continuously operating swarm demo, it was time to work on some of our stretch goals: 1. walking through the swarm whilst it is operating and 2. controlling the swarm using our arms. In the image below you can see an impression of precisely this functionality. The drones are following the operator’s gesture commands whilst performing live collision avoidance with an operator.
Team member Seppe directing the 40 drone swarm, see the full video here.
This demo requires multiple techniques and hardware elements working together to create a relatively low-latency, human-controlled swarm. We used a Kinect-like 3D sensor to perform human pose estimation, we subsequently used this data to create a dynamic obstacle in our collision avoidance software. An important element to consider here is the synchronization of the Lighthouse- and 3D sensor coordinate frames, i.e. without proper calibration the human will not be correctly positioned with respect to the drones and the drones will crash into the human. The interaction between the swarm control software and the human gesture commands also requires careful consideration, proper tuning is required to ensure a responsive system that is reliable and not too aggressive.
TUD Science Centre Swarming Lab
The next step in this project will be to set up the swarm at its new location, the TU Delft Science Centre. Here, the swarm will first and foremost be visible as a public demo, showcasing the capabilities of TU Delft state-of-the-art swarming research. There will also be a focus on developing the swarm as a research platform. This will allow TU Delft students and researchers to extend swarm functionalities and test their theory on a physical swarming system. Besides demos and academic research, there will also be worked on developing educational applications across the full educational board (primary school, high school and applied education). If you are interested in working on, or collaborating with the swarming lab on any of the above-mentioned tasks, feel free to email the lab management at operations.swarminglab@tudelft.nl.
The TU Delft Swarming Lab setup with 40 drones and charging pads for continuous operations and research.
Applications of Swarming
There are a lot of potential use-cases for fully autonomous drone swarms, ranging from indoor applications such as warehouse monitoring and factory inspection to outdoor applications such as search and rescue and surveillance. In our opinion, the true potential of drone swarms lies in applications where there is a significant need for a scalable system with a lot of built-in redundancy. A lot of additional use cases open up when we consider fully onboard autonomous systems, where the full benefits of decentralized swarming can be utilized. Currently, the size of drones needed to achieve such feats is quite large, though maybe in a few years, we could see more and more being done on drone platforms such as the Crazyflie.
A swarm inspection of an F-16 Fighting Falcon at Deltion College in Zwolle, the Netherlands.
An interesting area of application for drone swarms could be in the inspection of aircraft. Drone swarms provide a scalable and flexible means to perform a fast inspection of aircraft across an entire airfield or military base. To showcase that this can be done with any size of drone, we went to Deltion College in Zwolle to perform a mock inspection of an F-16 fighter jet. Above you can see an impression of the inspection. Another area of application is search and rescue, where there is a need for systems that can find people or objects of interest in unknown and cluttered environments. Furthermore, the area that needs to be searched is usually very large and sometimes difficult to travel on foot. A drone swarm could provide fast and reliable coverage of the area of interest, whilst providing full data traceability. Seppe and Lennart will work on creating drone swarms for these use cases with the start-up Emergent Swarms.
Did you know that all the items you receive when you place an order are actually from the Bitcraze office? In the beginning, we had the shipping handled by a third party, but it caused some problems and we decided to have this side of the business closer to us- namely, right here at the office in Malmö.
Our packing area
We have a “warehouse” with our products in our flight lab, and thrice a week someone takes the order, fulfills them, packs them and hands them over to FedEx. So how does this work exactly?
Well, a lot of this is possible thanks to our internal system, a Raspberry Pi, and three printers. When we fulfill your order, we have a lot of things to take into account. The weight of the shipment, the number of batteries it contains, what kind of shipment you ordered, the destination country, the kind of labels that are needed…. Thankfully, everything is handled by our internal system, and with one click we have everything we need. If you booked a FedEx shipment, our API books the FedEx shipment immediately and prints it.
We actually have three different printers. One prints the packaging list that we put in your package, along with one that helps us know what to pack. It’s a regular, office printer. The second one prints the shipping label. A third one is used for packages that contain batteries: those are, of course, heavily regulated, and we need to label them correctly to ensure the safest way to transport them. Hence the need for a third printer, which prints somewhat smaller labels. Some of us actually followed a course to be able to handle a shipment containing more than 2 spare batteries per drone… It is then considered a “Dangerous Goods” shipment by FedEx and has to be treated, labeled, and sent following a precise protocol.
Here they are in action:
Once everything is printed, the “only” thing left is to actually pack the box! It’s what takes up the most time. We select your items (without forgetting the stickers!), place them in the box that should be the right size, and try to pack everything so that it is safe to transport to the other side of the world. We then hand everything to FedEx which takes it from there. We try, as much as possible, to ship within 3 business days. That usually means packing and sending on Mondays, Wednesdays, and Fridays – though conferences or holidays can shake this up a bit.
The obvious advantage of having everything set up here is that we have a lot more control over this important side of the business. We have an eye on stock, on how the package looks like, and have an idea of where we actually send our products! The downside is that it takes a lot of time away from development. But these past couple of months, we’ve done a lot to improve our experience while packing. Those include an already filled-out Customs Notice for postal packages and a quicker way to handle packages that have more than 2 spare batteries. But the biggest change is that we have hired someone to help us part-time. Sofia started a week ago and she already has helped take care of the shipping part of Bitcraze. So welcome, Sofia, to the Bitcraze team!
As you may have noticed from the recent blog posts, we were very excited about ICRA London 2023! And it seems that we had every right to be, as this conference had the highest number of Crazyflie related papers compared to all the previous robotics conferences! In the past, the conferences typically had between 13-16 papers, but this time… BOOM! 28 papers! In this blog post, we will provide a list of these papers and give a general evaluation of the topics and themes covered so far.
So here some stats:
ICRA had 1655 papers accepted (43 % acceptance rate)
28 Crazyflie papers (25 proceedings, 1 RA-L, 1RO-L, 1 late breaking result postor)
Haven’t included the workshop papers this time (no time)
The major topics we discovered were swarm coordination, safe trajectory planning, efficient autonomy, and onboard processing
Additionally, we came across a few notable posters, including one about a grappling hook for the Crazyflie [26], a human suit that allows for drone control [5], the Bolt made into a monocopter with a Jetson companion [16], and a flexible fixed-wing platform driven by a barebone Crazyflie [1]. We also observed a growing interest in aerial robotics with approximately 10% of all sessions dedicated to UAVs. Interestingly, 18 out of the 28 Crazyflie papers were presented in non-UAV specialized sessions, such as multi-robot systems and vision-based navigation.
Swarm coordination
Swarms were a hot topic at ICRA 2023 as already noticed by this tweet of Ramon Roche. We had over 10 papers dedicated to this topic, including one that involved 16 Crazyflies [9]. Surprisingly, more than half of the papers utilized multiple Crazyflies. This already sets a different landscape compared to IROS 2022, where autonomous navigation took center stage.
In IROS 2022, we witnessed single-drone gas mapping using a Crazyflie, but now it has been replicated in the Webots simulation using 2 Crazyflies [23]. Does this imply that we might witness a 3D gas localizing swarm at IROS 2023? We can’t wait.
Furthermore, we came across a paper [11] featuring the Bolt-based platform, which demonstrated flying formations while being attached to another platform using a string. It presented an intriguing control problem. Additionally, there was a work that combined safe trajectory planning with swarm coordination, enabling the avoidance of obstacles and people [12]. Moreover, there were some notable collaborations, such as robot pickup and delivery involving the Turtlebot 3 Burger [22].
Given the abundance of swarm papers, it’s impossible for us to delve into each of them, but it’s all very impressive work.
Safe trajectory planning and AI-deck
Another significant buzzword at ICRA was “safety-critical control.” This is important to ensuring safe control from a human interface [15] and employing it to facilitate reinforcement learning [27]. The latter approach is considered less “safe” in terms of designing controllers, as evidenced by the previous IROS competition, the Safe Robot Learning Competition. Although the Crazyflie itself is quite safe, it makes sense to first experiment with safe trajectories on it before applying them to larger drones.
Furthermore, we encountered approximately three papers related to the AIdeck. These papers covered various topics such as optical flow detection [17], visual pose estimation [21], and the detection of other Crazyflies [5]. During the conference, we heard that the AIdeck presents certain challenges for researchers, but we remain hopeful that we will see more papers exploring its potential in the future!
List of papers
This list not only physical Crazyflie papers, but also papers that uses simulation or parameters of the Crazyflie. This time the workshop papers are not included but we’ll add them later once we have the time
Enjoy!
‘A Micro Aircraft with Passive Variable-Sweep Wings’ Songnan Bai, Runze Ding, Pakpong Chirarattananon from City University of Hong Kong
‘Onboard Controller Design for Nano UAV Swarm in Operator-Guided Collective Behaviors’ Tugay Alperen Karagüzel, Victor Retamal Guiberteau, Eliseo Ferrante from Vrije Universiteit Amsterdam
‘Multi-Target Pursuit by a Decentralized Heterogeneous UAV Swarm Using Deep Multi-Agent Reinforcement Learning’ Maryam Kouzehgar, Youngbin Song, Malika Meghjani, Roland Bouffanais from Singapore University of Technology and Design [Video]
‘Inverted Landing in a Small Aerial Robot Via Deep Reinforcement Learning for Triggering and Control of Rotational Maneuvers’ Bryan Habas, Jack W. Langelaan, Bo Cheng from Pennsylvania State University [Video]
‘Ultra-Low Power Deep Learning-Based Monocular Relative Localization Onboard Nano-Quadrotors’ Stefano Bonato, Stefano Carlo Lambertenghi, Elia Cereda, Alessandro Giusti, Daniele Palossi from USI-SUPSI-IDSIA Lugano, ISL Zurich [Video]
‘A Hybrid Quadratic Programming Framework for Real-Time Embedded Safety-Critical Control’ Ryan Bena, Sushmit Hossain, Buyun Chen, Wei Wu, Quan Nguyen from University of Southern California [Video]
‘Distributed Potential iLQR: Scalable Game-Theoretic Trajectory Planning for Multi-Agent Interactions’ Zach Williams, Jushan Chen, Negar Mehr from University of Illinois Urbana-Champaign
‘Scalable Task-Driven Robotic Swarm Control Via Collision Avoidance and Learning Mean-Field Control’ Kai Cui, MLI, Christian Fabian, Heinz Koeppl from Technische Universität Darmstadt
‘Multi-Agent Spatial Predictive Control with Application to Drone Flocking’ Andreas Brandstätter, Scott Smolka, Scott Stoller, Ashish Tiwari, Radu Grosu from Technische Universität Wien, Stony Brook University, Microsoft Corp, TU Wien [Video]
‘Trajectory Planning for the Bidirectional Quadrotor As a Differentially Flat Hybrid System’ Katherine Mao, Jake Welde, M. Ani Hsieh, Vijay Kumar from University of Pennsylvania
‘Forming and Controlling Hitches in Midair Using Aerial Robots’ Diego Salazar-Dantonio, Subhrajit Bhattacharya, David Saldana from Lehigh University [Video]
‘AMSwarm: An Alternating Minimization Approach for Safe Motion Planning of Quadrotor Swarms in Cluttered Environments’ Vivek Kantilal Adajania, Siqi Zhou, Arun Singh, Angela P. Schoellig from University of Toronto, Technical University of Munich, University of Tartu [Video]
‘Decentralized Deadlock-Free Trajectory Planning for Quadrotor Swarm in Obstacle-Rich Environments’ Jungwon Park, Inkyu Jang, H. Jin Kim from Seoul National University
‘A Negative Imaginary Theory-Based Time-Varying Group Formation Tracking Scheme for Multi-Robot Systems: Applications to Quadcopters’ Yu-Hsiang Su, Parijat Bhowmick, Alexander Lanzon from The University of Manchester, Indian Institute of Technology Guwahati
‘Safe Operations of an Aerial Swarm Via a Cobot Human Swarm Interface’ Sydrak Abdi, Derek Paley from University of Maryland [Video]
‘Direct Angular Rate Estimation without Event Motion-Compensation at High Angular Rates’ Matthew Ng, Xinyu Cai, Shaohui Foong from Singapore University of Technology and Design
‘NanoFlowNet: Real-Time Dense Optical Flow on a Nano Quadcopter’ Rik Jan Bouwmeester, Federico Paredes-valles, Guido De Croon from Delft University of Technology [Video]
‘Adaptive Risk-Tendency: Nano Drone Navigation in Cluttered Environments with Distributional Reinforcement Learning’ Cheng Liu, Erik-jan Van Kampen, Guido De Croon from Delft University of Technology
‘Relay Pursuit for Multirobot Target Tracking on Tile Graphs’ Shashwata Mandal, Sourabh Bhattacharya from Iowa State University
‘A Distributed Online Optimization Strategy for Cooperative Robotic Surveillance’ Lorenzo Pichierri, Guido Carnevale, Lorenzo Sforni, Andrea Testa, Giuseppe Notarstefano from University of Bologna [Video]
‘Deep Neural Network Architecture Search for Accurate Visual Pose Estimation Aboard Nano-UAVs’ Elia Cereda, Luca Crupi, Matteo Risso, Alessio Burrello, Luca Benini, Alessandro Giusti, Daniele Jahier Pagliari, Daniele Palossi from IDSIA USI-SUPSI, Politecnico di Torino, Università di Bologna, University of Bologna, SUPSIETH Zurich [Video]
‘Multi-Robot Pickup and Delivery Via Distributed Resource Allocation’ Andrea Camisa, Andrea Testa, Giuseppe Notarstefano from Università di Bologna [Video]
‘Multi-Robot 3D Gas Distribution Mapping: Coordination, Information Sharing and Environmental Knowledge’ Chiara Ercolani, Shashank Mahendra Deshmukh, Thomas Laurent Peeters, Alcherio Martinoli from EPFL
‘Finding Optimal Modular Robots for Aerial Tasks’ Jiawei Xu, David Saldana from Lehigh University
‘Statistical Safety and Robustness Guarantees for Feedback Motion Planning of Unknown Underactuated Stochastic Systems’ Craig Knuth, Glen Chou, Jamie Reese, Joseph Moore from Johns Hopkins University, MIT
‘Spring-Powered Tether Launching Mechanism for Improving Micro-UAV Air Mobility’ Felipe Borja from Carnegie Mellon university
‘Reinforcement Learning for Safe Robot Control Using Control Lyapunov Barrier Functions’ Desong Du, Shaohang Han, Naiming Qi, Haitham Bou Ammar, Jun Wang, Wei Pan from Harbin Institute of Technology, Delft University of Technology, Princeton University, University College London [Video]
‘Safety-Critical Ergodic Exploration in Cluttered Environments Via Control Barrier Functions’ Cameron Lerch, Dayi Dong, Ian Abraham from Yale University
As mentioned in a previous blog post, we have a both at ICRA in London this week. If you are there too, come and visit us in booth H10 and tell us what you are working on!
Barbara and Arnaud is getting the booth ready
We are showing our live autonomous demo and our products in the booth, including the flapping drone Flapper Nimble, don’t miss it!
The autonomous demo
The decentralized autonomous demo that we are showing is based on technologies in the Crazyflie ecosystem. The general outline is that Crazyflies are autonomously flying in randomized patterns without colliding. The main features are:
Positioning using the Lighthouse positioning system, all positioning estimation is done in the drone. The Lighthouse positioning system provides high accuracy and ease of use.
Communication is all peer-to-peer, no centralized functionality. Each Crazyflie is transmitting information about its state and position to the other peers, to enable them to act properly.
Collision avoidance using the on-board system without central planing. Based on the position of the other peers, each Crazyflie avoids collisions by modifying its current trajectory.
Wireless charging using the Qi-deck. When running out of battery, the Crazyflies go back to their charging pads for an automatic re-fill.
The App framework is used to implement the demo. The app framework provides an easy way of writing and maintaining user code that runs in the Crazyflie.
We are happy to answer any questions on how the technology works and implementation details. You can also read more about the demo in the original blog post by Marios.
Developer meeting
The next developer meeting is next week, Wed June 7 15:00 CEST and the topic will be the demo and how it is implemented. If you want to know about any specific technologies we used, how it is implemented or if you are just curious about the demo in general, please join the developer meeting. We will start with a presentation of the different parts of the demo, and after that a Q&A. As always we will end up with a section where you can ask any question you like related to our ecosystem. Checkout this announcement on our discussion platform for information on how to join.
In just about 2 weeks, it’s ICRA 2023, which, as you could guess from the title of the post, is in London. The ExCel venue will welcome the world’s top academics, researchers, and industry representatives from May 29 to June 2nd, and that’s something we don’t want to miss.
ICRA is a conference that we hold dear and attended quite a few times – whether in person or online. We’ll be holding a booth there so don’t hesitate to pass by to say hello and see our demo!
We will be using the same demo as the one from IROS 2022; a fully decentralized swarm with the Lighthouse system. What we changed is that now we will be using the Crazyradio 2.0. We’re working on updating the demo and seeing what can be improved in the time we have before the conference. As a bonus, we plan to bring some prototypes and surprises; just to show off all the work we’ve been doing since our last conference in Japan. We will also have Matej Karasek, our partner from Flapper Drones with us in the booth! A good occasion to see his Nimble + in action and ask him all your questions.
Additionally, on Friday afternoon there will be a half-day workshop called ‘The Role of Robotics Simulators for Unmanned Aerial Vehicles’ that we helped organized. This workshop gathers researchers who have struggled to find, customize, or design a robotic simulator for their own purposes or specific application; so don’t hesitate to join if you’ve worked (or plan to) with drone simulation. All the information are here, be sure to sign up for it at your ICRA registration if you’re interested. It can also be attended by a stream by signing up for the virtual ICRA conference.
So we hope to see you in London, at booth H10 for good discussions, interesting conversations, and eventually a cup of tea!
When designing flying robots like drones it is important to be able to benchmark and test the propulsion system which in this case is a speed controller, motor and propeller. As we at Bitcraze are mainly working with tiny drones we need a thrust stand designed for small motors and propellers. We have actually already designed our own system identification deck, which can measure overall efficiency, thrust, etc., but is lacking the ability to measure torque. Torque is needed to be able to measure propeller efficiency which is now something we would like to measure. Before we developed the system-id deck we searched for of the shelf solutions that could satisfy our needs and could not find any. This still seems true, please let us know if that isn’t the case.
Expanding the system-id deck to measure torque doesn’t work and building something from scratch was a too big of a project for us. Next natural option would then be to modify an existing thrust stand and our choice fell for the tyro robotics 158X series.
Looking at specifications, images and code we could figure out that replacing the load cells for more sensitive ones should be possible. The stock setup of 5kgf thrust and 2Nm of torque is just too much as we are looking for around 100 grams of thrust and around 10 mNm of torque. So we decided to give the replacement of load cells a shot! Assembly was quite smooth but we managed to break one of the surface mount load cell connectors off, luckily this was easily fixable with a soldering iron. With the stock setup we did some measurements with a 0802 11000KV brushless motor and a 55mm propeller in a pushing setup. It works but the measurements are noisy and repeatability is not great. Next thing would be to replace the load cells. The 158X uses TAL221 sized load cells which are available down to 1kg. We got those and with a calibration-allways-pass code we got from Tyto robotics we could make the calibration pass (note that modifying the thrust stand breaks the warranty). Now the thrust stability was much better but still the torque was a bit to noisy. We decided to go for even smaller thrust cells, the TAL220, and build 3D printable adapters to make them fit.
Now the torque noise level looked much better and so did the repeatability. By empirically measuring the thrust and torque using calibrated weights and by checking the measurements in RCBenchmark we got these values:
Thrust, calibrated weight [g]
Measured [g]
Noise [g]
200
200
1
100
100
1
50
50
0.5
20
20
0.5
10
10
0.5
0
0
0.5
Trust (calibrated using 200g weight)
Torque, calibrated weight [g]
Measured [mNm]
Noise [mNm]
200
257
2
100
128
1
50
64
0.3
20
25.7
0.3
10
12.7
0.3
0
0
0.2
Torque (calibrated using 200g weight)
Simple repeatability test
The thrust stand modification is still very fresh and we have to figure out some things but it all looks promising. For example we get 13% less overall efficiency when measuring it using our system-id thrust stand. Our guess is that it is due to that the Crazyflie arms in the system-id case blocks the airflow.
If you would like to do this modification yourself there are some simple instructions and STL files over at out mechanical github repository. Have fun!
I talked about it here already in October, but there is a lot we want to do here at Bitcraze- and not enough people to do it. So, we’re still looking for a new team member! You can read more about our requirements here; if you’re a polyvalent developer interested in hardware, with an open mind and the willingness to move to Malmö, don’t hesitate to apply by sending us an email: job@bitcraze.se.
We’ve actually also started the search for another job. But first a little background: each morning, on Mondays, Wednesdays, and Thursdays, we pack and ship our orders. Someone takes 1, 2, or even 3 hours to make sure every order passes the door. In 2022, the median time between when you would buy our products and the moment it’s shipped was 1 day. It’s something that is usually common in a big company with a whole warehouse and a team dedicated to that… But at Bitcraze, the warehouse is actually a space in our flight arena and we’re only 6 people. To have more time for development, we’re now looking for someone, ideally a student, to help us out a few hours a week packing and shipping. So if you happen to know anyone near Malmö that fits the description, send him this blog post!
And, since I don’t want to tell you the same thing that I talked about in my last blog post, and it’s International Worker’s Day, I’ve decided to make an extremely subjective list of all the awesome advantages there are working at Bitcraze. So here are perks that you get at Bitcraze that you’ll get nowhere else:
The flexibility to do what you’re most passionate about, and the encouragement to do so. You love printers? RUST? You get excited talking about a new LED or cool stickers? You’ll get the opportunity to fulfill your geekiest dream here (those are all examples I’ve witnessed)
The occasion to actually shape the company we’re working in. Your interests, your passions, and your knowledge will find their place and you’ll have the possibility to make decisions on the future of Bitcraze even after the first day- my first day working here was at a quarterly meeting where we decided on a lot of things I didn’t even understood yet.
Fun Fridays, where you get to work on whatever you fancy; one day a week where productivity is not a demand and you can just get going on creating the newest prototype – and if it doesn’t work, at least you learned something!
A demo every 2 weeks, where you can actually be impressed by a blinking LED (again, true story; and it was really impressive)
Awesome colleagues that will almost never steal the stuff on your desk (unless Kristoffer labels it, which is now known as the “please borrow me” label)
Falafel Tuesdays – when you can debate which is the best falafel in town while eating the best falafel in town.
Sometimes, there is karaoke or VR games or bowling – we usually invent a pretext to enjoy some after-work together.
Daily inspiration both from the way we work but also the awesome stuff people do with our products.
The occasion to learn at least a new thing a day – wether it’s how your body reacts to sugar, how FedEx handles the taxes in Japan or what is the best way to make your Crazyflie make a loop.
While this is not Bitcraze-specific, the Swedish coast – kind of like Palm Beach without the heat (and the palms) and the general nature surrounding Malmö. Or if you don’t like nature, the possibility to enjoy a big city (Copenhagen, across the bridge) while living in a quiet area.
I hope I picked your interest, or at least gave you some insights on what it’s really like to work at Bitcraze!
It is easy to forget that the reason why it is nice to develop for the Crazyflie is because it weighs only about 30 grams. In case something goes wrong with your script or there is a fly-away, you can simply pick it up from the air without worrying about the propellers hitting you. Moreover, when the Crazyflie crashes, it usually only requires a brush off and a potential replacement of a motor-mount or propeller. The risk of damage to yourself, other people, indoor furniture, or the vehicle itself is extremely low. However, things become very different if you’ve built a larger platform with the Bolt or BQ deck with large brushless motors (like with this blogpost), where the risk of injury to people or to the vehicle itself increases significantly. That is one of the major reasons why the BQ deck and the Bolt are still in early access and have been for a while. In our efforts to get it out of early access, it’s time to start thinking about safety features.
In this blog post, we’ll be discussing how other open-source autopilot programs are implementing safety features, followed by a discussion on current efforts for Crazyflie, along with an announcement of the developer meeting scheduled for May 3rd (see below for more info).
Catching the Crazyflie with a net
Safety in other Autopilots
We are a bit late to the game in terms of safety compared to other autopilot programs such as PX4, ArduPilot, Betaflight and Paparazzi UAV, which have been thinking about safety for quite some time. It makes a lot of sense when you consider the types of platforms that run these autopilots, such as large fixed VTOL or fixed-wing vehicles or 10-kilo quadcopters with cinematic cameras, or the degree of outdoor flight regulation. Flying a UAV autonomously or by yourself has become much more challenging as the US, EU, and many other countries have made it more restrictive. In most cases, you are not even allowed to fly if fail-safes are not implemented, such as what to do if your vehicle loses GPS signal. These types of measures can be separated into pre-flight checks and during-flight checks.
Pre-flight checks
Before a vehicle is allowed to fly, or even before the motors are allowed to spin, which is called ‘arming’, several conditions must be met. First, it needs to be checked if all internal sensors, such as the IMU, barometer, and magnetometer, are calibrated and functional, so they don’t give values outside of their normal operating range. Then, the vehicle must receive a GPS signal, and the internal state estimator (usually an extended Kalman filter) should converge to a position based on that information. It should also be determined if an external remote control is connecting to the vehicle and if there is any datalink to a ground station for telemetry. Feasibility checks can also be implemented, such as ensuring that the mission loaded to the UAV is not outside its mission parameters or that the start location is not too far away from its take-off position (assuming the EKF is functional). Additionally, the battery should not be low, and the vehicle should not still be in an error state from a previous flight or crash.
All of these features have the potential to be turned off or made less restrictive, depending on your situation. However, keep in mind that changing any of these may require recertification of the drone or make it fall outside what is required for outdoor flight regulation. Therefore, these should only be changed if you know what you are doing.
Now that the pre-flight checks have passed, the UAV is armed and you have given it the takeoff command. However, there is so much more that can go wrong during a UAV flight, and takeoff is one of the most dangerous moments where everything could go wrong. Therefore, there are many more safety features, aka failsafes, during the flight than for the pre-flight checks. These can also be separated into ‘triggers’ and ‘behaviors,’ so that the developer can choose what the UAV should do in case of a failure, such as ‘GPS loss’ to ‘land safely’ and so on.
Thus, there are triggers that can enable the autopilot’s failsafe mechanics:
No connection with the remote control
No connection with the Ground station or Datalink
Low Battery
Position estimate diverges or full GPS loss
Waypoint going beyond geofence or Mission is not feasible
Other vehicles are nearby.
Also, sometimes the support of an external Automatic Trigger system is required, which is a box that monitors the conditions where the UAV should take action in case there is no GPS, other aerial vehicles are nearby, or the UAV is crossing a geofence determined by outdoor flight restrictions. Note that all of these triggers usually have a couple of conditions attached, such as the level of the ‘low battery’ or the number of seconds of ‘GPS loss’ deemed acceptable.
Fail-safe behavior
If any of the conditions mentioned above are triggered, most autopilot suites have some failsafe behaviors linked to those set by default. These behaviors can include the following:
No action at all
Warning on the console or remote control display
Continue the mission autonomously
Stay still at the same position or go to a home position
Fly to a lower altitude
Land based on position or safely land by reducing thrust
No input to motors or completely disarming the motors
Usually, these actions are set in regulation, but per trigger, it is possible to give a different behavior than the default. One can decide to completely disarm the vehicle, but then the chances of the UAV crashing are pretty high, which can result in damage to the vehicle or cause harm to people or objects. By the way: disarming is the opposite act of arming, which is not allowing the motors to spin, no matter if it is receiving an input. If you decide to never do anything and force the drone to finish the mission autonomously, then in a case of GPS or position loss, you risk losing your vehicle or that it will end up in areas where it is absolutely not allowed, such as airports. Again, changing these default behaviors should be done by someone who knows what they are doing, and it should be done with careful consideration.
Fail-safes are measures that ensure safe flight. However, there will always be a chance that an emergency will occur, which will require an immediate action as well. If the vehicle has crashed during any of its phases or has flipped, or if the hardware breaks, such as the motors, arms, or perhaps even the autopilot board itself, what should be done then?
The standard default behavior for this is to completely disarm the vehicle so that it won’t react to any input to the motors itself. Of course, it’s difficult to do if the autopilot program is on, but at least it won’t try to take off and finish its mission while laying on its side. It might be that a backup system is connected to the ESCs that will take over in case the autopilot is not responding anymore, perhaps using a different channel of communication.
Also, the most important safety feature of all is the pilot itself. Each remote control should have a special button or switch that can put the drone in a different mode, make it land, or disarm it so that the pilot can act upon what they see. In case the motors are still spinning, have a net or towel available to throw over them, disconnect the battery as soon as possible, and make sure to have sand or a special fire retardant in case the LiPo batteries are pierced.
All of the autopilots have some tips to deal with such situations, but make sure to do some good research yourself on how to handle spinning parts or potential LiPo battery fires. I’m just giving a compilation of tips given in the documentation above here, but please make sure to read up in detail!
Safety in the Crazyflie Firmware
So how about the Crazyflie-firmware ? We have some safety features build in here and there but it is all over the code base. Since the Crazyflie is so safe, there was no immediate need for this and we felt it is more up to the developer to integrate it themselves. But with the Bolt and BQ deck coming out of early access, we want to at least do something. As we started already started looking into how other autopilot softwares are doing it, we can get some ideas, however we did notice that many of these are mostly meant for outdoor flight. The Crazyflie and the Crazyflie Bolt have been designed for indoor use and perhaps deal with different issues as well.
Current safety features
This is a collection of safety features currently in the firmware at the time of writing this blogpost. Most safety features in the Crazyflie are up for the developer to double check before and during flight, but these are some automatic once that are scattered around the firmware:
Watchdog, hard faults and asserts scattered throughout the firmware.
We might find more on the way…
However, if for instance your Crazyflie or Bolt platform loses its positioning in air, or doesn’t have a flowdeck attached before takeoff, there are no default safety systems in check. You either need to catch it, make it land or use an self-made emergency stop button using one of the emergency stop services above.
Safety features in works
As mentioned earlier, we have safety features spread throughout the code base of the Crazyflie firmware. Our current effort is to collect all of these emergency stops and triggers in the supervisor module to have them all in one place.
In addition, since indoor positioning is critical, we want to be notified when it fails. For instance, if the lighthouse geometry is incorrect, we need to see if the position diverges. This check was done outside of the Crazyflie firmware in a cflib script, but it has not been implemented inside the firmware. We also want to provide some options in terms of behavior for these triggers. Currently, we are working on two options: ‘turn the motors off’ or ‘safe land,’ with ‘safe land’ decreasing the thrust while keeping the drone level in attitude.
Furthermore, we want to integrate these features into the cfclient as well. For example, we want to add more emergency safety features to our remote control through the cfclient, and show users how to arm and disarm the vehicle.
These are the elements we are currently working on, but there might be more to come!
Developer meeting May 3rd
You probably already guessed it… the topic about the next developer meeting will be about the safety features in the Crazyflie and the Bolt! We will present the current safety features in the Crazyflie and what we are currently working on to make it better. In this sense, we really want to have your feedback on what you think is important for brushless versions of the Crazyflie for indoor flight!
The Dev meeting will be on Wednesday May the 3rd at 3 PM CEST. Please keep an eye on the discussion forum in the developer meeting thread.
Today, our guest Airi Lampinen from Stockholm University is presenting the second Drone Arena Challenge. Enjoy!
Welcome to the second Drone Arena Challenge, a one-of-a-kind interactive experience with Bitcraze’s Crazyflie! This year, the challenge is focused on moving together with drones in beautiful, curious, and provocative ways – without needing to write a single line of code!
Moving with drones. Image credit: Rachael Garrett.
What, when, where? The event takes place May 16-17, 2023 at KTH’s Reactor Hall in Stockholm – a dismantled nuclear reactor hall – which provides a unique setting for creative human–drone encounters. You don’t need your own drone or be able to program a drone to participate! We will provide the drone equipment (a Crazyflie 2.1 equipped with the AI-deck) and take care of everything necessary to make them fly. What you need to do is to be creative and move together with the drones to set up the best show you can deliver! There’ll be a jury judging the final performances and we have exciting prizes for the most successful teams!
Drone Arena in the Reactor Hall. Picture from the first challenge, held in June 2022. Picture credit: Fatemeh Bakhshoudeh
Who can join? Anyone irrespective of training, profession, and past experience with drones or performing arts is welcome to participate. Participants need to be at least 18 years old. If you are curious about how technology and humans may play together, enthusiastic about the Crazyflie, or eager to learn how to move with the Crazyflie, this event is for you. We welcome up to 10 pairs (teams of 2 people) to participate in the challenge.
Registration is already open, with only a few spots remaining. We encourage those interested to sign up as soon as possible to secure their spot!
Program & prizes? On the first day of the hackathon, we will host a keynote speaker and a short information session to explain what participants are expected to do and what support is available for them. The teams will then have access to the Reactor Hall to work on the challenge and explore moving with their drone – we offer long hours but each team is free to choose how much they want to work. (The goal here is to have a good time!) The competition itself takes place on the second day. We’ve got exciting prizes for the most successful teams!
