Author: Kimberly McGuire

Now it is time to give a little update about the ongoing ROS2 related projects. About a month ago we gave you an heads-up about the Summer ROS2 project I was working on, and even though the end goal hasn’t been reached yet, enough has happened in the mean time to write a blogpost about it!

Crazyflie Navigation

Last time showed mostly mapping of a single room, so currently I’m trying to map a bigger portion of the office. This was initially more difficult then initially anticipated, since it worked quite well in simulation, but in real life the multi-ranger deck saw obstacles that weren’t there. Later we found out that was due to this year old issue of the multi-ranger’s driver incapability to handle out-of-range measurements properly (see this ongoing PR). With that, larger scale mapping starts to become possible, which you can see here with the simple mapper node:

If you look at the video until the end, you can notice that the map starts to diverge a bit since the position + orientation is solely based on the flow deck and gyroscopes , which is a big reason to get the SLAM toolbox to work with the multi-ranger. However, it is difficult to combine it with such a sparse ‘Lidar’ , so while that still requires some tuning, I’ve taken this opportunity to see how far I get with the non-slam mapping and the NAV2 package!

As you see from the video, the Crazyflie until the second hallway. Afterwards it was commanded to fly back based on a NAV2 waypoint in RViz2. In the beginning it seemed to do quite well, but around the door of the last room, the Crazyflie got into a bit of trouble. The doorway entrance is already as small as it is, and around that moment is also when the mapping started to diverge, the new map covered the old map, blocking the original pathway back into the room. But still, it came pretty close!

The diverging of the map is currently the blocker for larger office navigation, so it would be nice to get some better localization to work so that the map is not constantly changed due to the divergence of position estimates, but I’m pretty hopeful I’ll be able to figure that out in the next few weeks.

Crazyflie ROS2 node with CrazySwarm2

Based on the poll we set out in the last blogpost, it seemed that many of you were mostly positive for work towards a ROS2 node for the Crazyflie! As some of you know, the Crazyswarm project, that many of you already use for your research, is currently being ported to ROS2 with efforts of Wolfgang Hönig’s IMRCLab with the Crazyswarm2 project. Instead of in parallel creating separate ROS2 nodes and just to add to the confusion for the community, we have decided with Wolfgang to place all of the ROS2 related development into Crazyswarm2. The name of the project will be the same out of historical reasons, but since this is meant to be the standard Crazyflie ROS2 package, the names of each nodes will be more generic upon official release in the future.

To this end, we’ve pushed a cflib python version of the crazyflie ros2 node called crazyflie_server_py, a bit based on my hackish efforts of the crazyflie_ros2_experimental version, such that the users will have a choice of which communication backend to use for the Crazyflie. For now the node simply creates services for each individual Crazyflie and the entire swarm for take_off, land and go_to commands. Next up are logging and parameter handling, positioning support and broadcasting implementation for the CFlib, so please keep an eye on this ticket to see the process.

So hopefully, once the summer project has been completed, I can start porting the navigation capabilities into the the Crazyswarm2 repository with a nice tutorial :)

ROScon talk

As mentioned in a previous blogpost, we’ll actually be talking about the Crazyflie ROS2 efforts at ROScon 2022 in Kyoto in collaboration with Wolfgang. You can find the talk here in the ROScon program, so hopefully I’ll see you at the talk or the week after at IROS!

In the first years that I started at Bitcraze I’ve been focused mostly on embedded development and algorithmic design like the app layer, controllers and estimators and such, however recently I started to be quite interested in the robotic integration between the Crazyflie and other (open-source) projects and users. This means that I’ll be dwelling more often in the space between Bitcraze and the community, which is something that I do really enjoy I noticed during the Grand Tour. It also initiated my work with simulators which I think would be very useful for the community too. The summer fun project that I’ve been now working on is to integrate the Crazyflie with ROS2 to integrate standard navigational packages, which will be the topic of this blogpost!

ROS2 Crazyflie Node

So first I worked on the ROS2 node that actually communicates with the Crazyflie directly. I think many of you are familiar with the USC’s CrazySwarm project, of which the ROS2 variant, CrazySwarm2, is already available for most functionalities. Even though the name says CrazySwarm, this can be very easily used for only one Crazyflie too. The CrazySwam2 is currently under more development by the IMRClab of TU Berlin, but please take a look if you want to give it a go!

For now while Crazyswarm2 is still under development, I used the Bitcraze Crazyflie python library to make a more hackish node that just publishes exactly the information I want. I am focusing on the scenario with the STEM ranging bundle, aka the Crazyflie + Flowdeck (optical flow + distance sensor) + Multi-ranger (5 x distance sensors) combo, where the node logs the multi-ranger data and the odometry from the Flowdeck with the Crazyradio and outputs that into necessary /scan and /odom topics. Moreover, it also outputs several tf2 transforms that makes it possible to either visualize it in RVIZ and/or connect it to any other packages and it should react to incoming twist messages as well.

Development with a Simulator

And of course… I went in head first and connected it directly with the SLAM toolbox. I have worked with ROS1 in the past, but I had my first experience working with that package in the course: Build Mobile Robots with ROS2 (by Weekly Robotic Newsletter’s Mat Sadowski), so I couldn’t wait to try it on a real platform like the Crazyflie. However, tuning this was of course more work than I thought, as the map that I got out of it first was mostly a sparse collection of dots. Of course the SLAM toolbox is meant for lidars and not something that provided sparse range distances like the Multiranger. Then I decided to take one or two steps back, and first connect a simulator to make tuning a bit easier.

Luckily, I’ve already started to look at simulators, and was quite far in the Webots integration of the Crazyflie. Actually… Webots’ next release (2022b) will contain a Crazyflie as standard! Once it is out, I’ll write a blogpost about that separately :). As luck has it, Webots also has good ROS2 integration as well, and even won the ‘Best ROS Software’ award by The Construct’s ROS awards! Another reason is that I wanted to try out a different simulator for ROS2 this time to complement what I’ve learned in the ROS2 course I mentioned earlier.

So I used the webots driver node to write a simulated Crazyflie that should output the same information as the real Crazyflie node, so that I can easily hack around and try out different things without constantly disturbing my cats from their slumber :). Anyway, I won’t go into to the simulator too much and save that for another blogpost!

Simple Mapping

I decided to also take another additional step before going full SLAM, which is to make a simple mapper node first! This takes the estimated state estimate of the Crazyflie and the Multiranger’s range values and it creates an occupancy grid type map of it. I do have to give kudos to the Marcus’ cflib Pointcloud script and Webot’s simple mapper example, as I did look at them for some reference. But still with the examples, integration and connecting the dots together is quite some work. Luckily I had the simulator to try things out with!

So first I put the Crazyflie in an apartment simulator, flew around and see if any decent maps comes out of it and it seemed it did! Of course, the simulated Crazyflie’s ‘odometry’ comes from near perfect position estimate, so I didn’t expect any problems there (and in such a situation you would actually not really need the localization part of SLAM). This still needs some improvements to be done, like now range measurements that don’t see anything are excluded from drawing, but still it was pretty cool to map the virtual environment.

So it was off to try it out on a real crazyflie. In one of our meeting rooms, I had one Crazyflie take off, let it turn around with a twist message in a /cmd_vel topic and made a map of the room I was currently in. The effect of the 4 range sensors rotating around and creating a map in one go, makes me think of these retro video transitions. And the odometry drift does not seem as bad for it to be possible, but I haven’t mapped our entire office yet so that might be different!

What’s next?

So I’m not stopping here for sure, I want to extend this functionality further and for sure get it to work with the SLAM_toolbox properly! But if the simple mapper already can produce such quality, I’m pretty sure that this can be done in one way or the other. What I could also do, is first generate a simple map and already have a go at the NAV2 package with that one… there are many roads to Rome here!

Currently I’m doing my work on my personal Github account in the crazyflie_ros2_experimental repository. Everything is still very much in development, hackish and quite specific for one use case but that is expected to change once things are working better, so please check the planning in the project’s readme. In the mean time, you can indicate to us in this vote if this is an interesting direction for us to go towards. Not that it will stop me from continuing this project since it is too much fun, but it is always good to know if certain efforts are appreciated!

Earlier this month, ICRA 2022 was in held in Philadelphia and in person this time! Unfortunately we were unable to attend ourselves but quite happy that there were still virtual attendance options available. So I followed quite some presentations and read through papers, trying to find out the latest in Aerial and Swarm robotics and if anybody was able to use the Crazyflie to good use for their research. I even had the opportunity to attend the Exhibition floor with a telepresence robot, which was a lot of fun!

We have covered IROS 2021 end of last year, and we even have started to publish Crazyflie related publications on social media to keep ourselves and the community up to date with any Crazyflie research work. So here we will list the ICRA 2022 papers we have found and write some observations.

Crazy Platforms

What I really noticed this year is that the Crazyflie has been used in more unconventional configurations and new platforms! IROS 2021 ready amazed us by a solar-powered Crazyflie and the 4 times Crazyflie combined quadcopter (which continued this conference by UCLA in (2). But we haven’t seen yet that a Crazyflie can jump! The PogoDrone by the Swarmslab of Lehigh university turned the Crazyflie into an autonomous jumping pogo stick (5)! Moreover, wheels were added by the Institute For Systems and Robotics (TU Lisbon) for increasing the flight/autonomy durability (7).

We also noticed 3 ICRA 2022 papers with Bolt-powered platforms, which is a huge increase compared to IROS 2021 which only had 1 Bolt entry. The MAVlab of the TU Delft compared the Crazyflie against a Bolt-powered Flapper-drone for flying against wind (see the presentation of Flapperdrone in our last MiniBam). Moreover, remember that saw the Science Robotics paper using a Crazyflie board for a dual wing rotating platform. The Engineering product development of SUTD took a similar design to the next level, building a single controllable rotating wing with a Bolt platform (3). Two of these can even work together cooperatively and fly stability, so it is no wonder that they won the ICRA 2022 Outstanding Dynamics and Control Paper Award.

List of ICRA 2022 Papers featuring the Crazyflie and Bolt

Here is a list of all the Crazyflie/Bolt papers featured in ICRA 2022 but let us know if we are missing any (⚡: Bolt, 🐝: Crazyflie). Mind that only Robotic and Automation Letter entries have been officially published on IEEE Xplore already, so from the proceeding papers I tried to share the ArXiv paper if available.

  1. ⚡ ‘Passive Wall Tracking for a Rotorcraft with Tilted and Ducted Propellers using Proximity Effects’ Ding et al. from City University of Hong Kong & Massachusetts Institute of Technology
  2. 🐝 ‘A Fast and Efficient Attitude Control Algorithm of a Tilt-Rotor Aerial Platform Using Inputs Redundancies’ Su et al. from UCLA
  3. ⚡x2 ‘Cooperative Modular Single Actuator Monocopters Capable of Controlled Passive Separation’, Cai et al. from Singapore University of Technology & Design
  4. 🐝’Optimal Inverted Landing in a Small Aerial Robot with Varied Approach Velocities and Landing Gear Designs’ Habas et al. from Penn State
  5. 🐝 ‘PogoDrone: Design, Model, and Control of a Jumping Quadrotor’, Zhu et al from Lehigh U.
  6. 🐝 ‘Clustering and Informative Path Planning for 3D Gas Distribution Mapping: Algorithms and Performance Evaluation’, Ercolani et al from EPFL
  7. 🐝 ‘A Bimodal Rolling-Flying Robot for Micro Level Inspection of Flat and Inclined Surfaces’ , Pimentel et al from Instituto Superior Tecnico
  8. 🐝x 2 ‘Collision Avoidance for Multiple Quadrotors Using Elastic Safety Clearance Based Model Predictive Control’, Jin et al. from USTC & Sina
  9. 🐝 + ⚡🦋 ‘An Experimental Study of Wind Resistance and Power Consumption in MAVs with a Low-Speed Multi-Fan Wind System’, Olejnik et al. from TU Delft
  10. 🐝x 6 ‘Formation-containment tracking and scaling for multiple quadcopters with an application to choke-point navigation’, Su et al. from The University of Manchester.

Updated

11. 🐝x 6 ‘Nearest-Neighbor-Based Collision Avoidance for Quadrotors Via Reinforcement Learning’, Ourari et al. from TU Darmstadt
ArXiv

12. 🐝x 6 ‘Safe multi-agent motion planning via filtered reinforcement learning’ Vinod et al. from Mitsubishi Electric Research Laboratories
IEEEXplore page

13. 🐝 ‘Event-Triggered Tracking Control Scheme for Quadrotors with External Disturbances: Theory and Validations’, Goa et al. from University of Shanghai for Science and Technology
Outstanding Coordination / Mechanisms & Design / Locomotion / Navigation Award Finalists
IEEEXPlore page

14. 🐝 ‘Watch and Learn: Learning to control feedback linearizable systems from expert demonstrations’, Sultangazin et al. from University of California
IEEEXplore page
15. ‘KoopNet: Joint Learning of Koopman Bilinear Models and Function Dictionaries with Application to Quadrotor Trajectory Tracking’, Folkestad et al. from Caltech
IEEEXplore page

Other Announcements: Bolt 1.1 and Dev meeting

Bolt 1.1

The Bolt is now back in stock and with two small updates making it the Bolt 1.1. Here are the changes listed:

  1. The board thickness has been reduced from 1.6mm to 1.0mm to save some weight, roughly 2 grams. This is handy for the slimmest and most lightweight designs.
  2. Motor signal output M4 has been moved from PB9 to PB10 to be able to support the DSHOT motor signal protocol in the future.

Other then that it is fully backwards compatible but make sure to use a recent enough firmware (2022.03) that has the Bolt 1.1 device support added.

Time and Date for Dev Meeting

In this blogpost we noted that we wanted to organize our first Developer meeting before the summer break. From this poll we saw that most of you that want to attend are currently located in Asia and Australia, so that is why this time we want to organize the meeting at:

13:00 CEST (Sweden time) on Wednesday 22th of June.

The topic will be about our new support platform and support handling in general, so I’m hoping for some fruitful discussions about that. Keep an eye on this discussion thread for any details for joining.

We have already announced it a bit on social media, but in this blogpost we are announcing it officially: we are moving our support to Github Discussions which can be reached by going to discussions.bitcraze.io. We will deprecate our old forum and lock it for new thread creation and user registration starting from week of the 6th of June.

Don’t worry! We don’t have any plans of removing the actual content of the old forum as this is much too valuable for support. But for most communication, support and discussions, we will only be using Github Discussions.

The Reasoning

Technically, there is nothing really wrong with the old forum! Bitcraze has used this phpBB-based platform ever since 2013 and has helped tremendously in support in all those years until now. For a long while, it also has been an active sharing medium next to support, where users could share their cool Crazyflie projects. So it was more than a support channel… it was a community watering-hole! Unfortunately, the backbone of the forum has not progressed in functionality, the categories style defeated it’s purpose and we found we had to constantly switch back and forth between the forum and Github issue list on a daily basis. So we have decided it is time for something else.

Moreover, the last few years we have noticed that the sharing of cool projects became significantly less, no more discussions were initiated and the forum was mostly used for only support and questions. As we missed seeing cool projects and discussing the Crazyflie (also due to Corona), we tried to open up a Bitcraze Discord channel (see this blogpost) to initiate more discussions and sharing as a supplement to the forum. Unfortunately, it did not really take off in terms of activity, and the content is not searchable without a discord account. After a unfortunate hack-attack last year we removed the invite link from our website.

We did get feedback that having 2 platforms separated for support and community was confusing to the users, as they didn’t know where to ask a question anymore. The ideal situation would then to be choose another platform where we can have all on there. Discourse we had our eyes on for a while, which has been used by other open source projects, and has integration support for Github so users didn’t have to make yet another account. Github itself introduced their Discussions feature 1.5 year ago and it was adopted by Crazyswarm (1 and 2). At that time it was only possible to have one discussion tab per repository, and with our 60 (!) repos this didn’t seem to be an option… until recently! Once they released their organization level discussion feature about a 1.5 months ago, we were sold. There is no better Github integration than being on Github itself and with our many repos, this is something we definitely need.

How to use Discussions?

The forum and discussions are quite different in style which takes a little getting used to. The old forum used a classic ‘thread’, which shows exactly the chronological way of the conversation. Discussions uses an approach similar to Stack Overflow, where you can also reply on intermediate answers in that thread.

Where to start a discussion?

If you see the discussion page, you notice a couple of categories. These are still the standards as given by github, but we think these will work for us as well:

  • Announcements: Here is where Bitcraze places announcements in regards of discussions. You can not add announcements yourself but you can reply to them, but do not start a generic support question here.
  • General: Just for generic discussions and saying hi!
  • Ideas: If you have any ideas for enhancements for the Bitcraze ecosystem, place them here!
  • Polls: Same as announcements from Bitcraze, but we will use these to poll a certain opinion.
  • Q&A: Here is were all the support questions go! Make sure to read the support rules for this.
  • Show & Tell: Show your awesome Crazyflie projects here!

Labels

We first had categories at the forum, which was supposed to separate the discussion in a functional way. In reality, sometimes it was difficult to really separate the issues in those very categories as it overlapped many functionalities. Now in Github discussions, we are able to label these based on the topic, and even add more labels if it indeed overlaps multiple topics. From this, we will also be able to filter out support question about a certain topic which will make it easier for us to have a good look of all support for a certain product or functionality.

So please try to label your support question! But if you haven’t, we will probably do it for you.

Issue or Discussion?

Especially since we are on Github discussions, it might be difficult now to determine when to start an issue at an individual repository and when to start discussion. I really like the explanation that Github itself used to explain the difference:

Discussions are great for questions and ideas that require team communication to make a decision, while Issues are defined pieces of work.

So if you know of a bug/problem, or you want to to propose an enhancement that you know the specific repository of, go ahead and make an issue right in that repo. If you have a problem and you are not sure what is causing it, discussions is the place to go (preferably in Q&A). If there is any ‘pieces of work’ that comes from that discussion, the maintainer can generate an issue in the related repository and link it to the discussion. Other way around, any questions in any issue list that we think is too generic, we will moderate and move it to the organization discussions.

Get involved!

Of course at Bitcraze we will try to help out, but what we really would like is for you to help with answering questions as well! Start up and chat with a topic that you are interested in, or show a small video of your Crazyflie doing something fun. One thing that we would love is the community to be as vibrant as it used to be, were we not only ask support questions, but to discuss and share! It doesn’t have to be big, like you can vote on this Poll to voice your opinion about our move, or vote up / add a smiley to any discussion that you find important.

Also we are planning to have a developer meeting in a few weeks, on the 22nd of June (just before the holidays), so please see the discussion/poll here for more information.

We have worked hard last week to get a new fresh release out before the summer months are on our doorstep. Not only that we would like to make sure that important bugs are fixed before some of us go on our holiday, but also to be able to display our new AI deck features! Here is an overview of what has been changed

AI deck over air flashing

As you can probably see in the release notes of both the python libraries and the firmware, most of our changes are focused on making it possible to develop for the AI deck without using a programmer all the time. If the STM and NRF firmware of the Crazyflie is fully updated, and the ESP firmware on the AI deck, it should now be possible to flash an AI deck example binary with a Crazyradio! For older versions of the AI deck 1.X (Rev A to C) it is unfortunately still necessary to use the JTAG programmer one last time to flash a bootloader on the GAP8, but after that it should not be needed anymore.

Please check out the new update AI deck tutorial for setting up the AI deck for this new functionality.

Crazyflie Packet eXchange (CPX)

In the light of the work we have done for the AI deck, we also have started to implement a new, inter MCU protocol called the Crazyflie Packet Exchange. Since with the AI deck, we are adding 2 additional microprocessors to the Crazyflie architecture, it was crucial to handle the communication between all platforms and communication channels properly. Currently the functionality is mostly enabled to tailor Wifi streaming and console printouts for the AI deck, but it is meant to be a generic protocol which in the future, should be able to handle more combinations like for instance, command messages through wifi?

You can read about CPX in the crazyflie-firmware repository doc and we will be writing a more detailed blogpost about this later.

Controller Python bindings

For the last part of the Grand tour trip, we had a hackathon with the IMRC lab of TU Berlin and our close collaborator Wolfgang Hönig, in which we managed to convert the PID controller, Mellinger controller and the motor mixing into python bindings, which can be used in the experimental simulator of the Crazyflie.

There is no Pypi release of these, you will need to pull the latest crazyflie-firmware repo and build the bindings with ‘make bindings_python’

Additional fixes

We have some additional fixes to both the python libraries and firmware. For the STM we have updated the STD peripheral library and solved several build issues. For the cfclient, we fixed a lot of issues that were caused by either the latest version of python, as it was more stricter with type definitions, and some issues QT. Moreover, the LED ring headlight functionality has been restored, and the cfbridge.py script, used for the PX4 crazyflie 2.1 tutorial, is re-added, since it suddenly disappeared a few releases ago.

Update and Feedback

Make sure to update your cfclient with ‘pip install cfclient –upgrade’ and to reflash the new stable firmware. For AI deck users, try out our our new tutorial to try out both CPX, the over air flashing and the wifi example. The new AI deck functionalities has been subjected to some limited testing so if there is anything wrong or unclear, please let us know in the forum! The feedback will help the AI deck to become a more stable product for development, so we would be very grateful if you would be able to help out with that.

If anybody noticed a delay of my response on emails, forum or Github, that might be due to the fact that I was on the road for Bitcraze for the last few weeks! I was invited to give a guest lecture for a course at EPFL, and of recent they have a CO2 reducing policy regarding travel. At Bitcraze we also aim for reducing our environmental impact, so hence the idea came forth to travel to Switzerland and visit our close collaborators that are nearby(ish)… all by train! Internally we dubbed this to be The Grand Tour.

The Itinerary

We kept the itinerary mostly within Switzerland and Germany, although I did pass the Netherlands a few days just to visit family. The full itinerary by train was:

Utrecht (NL) -> Lausanne (SW) -> Zürich (SW) -> Munich (GE) -> Berlin (GE) -> Malmö (SE)

The longest train ride was from Utrecht to Lausanne (9 hours), but all the others were well under 4 hours which was pretty comfortable. The nice thing about being in the train is that it quite easy to work on your laptop (although the wireless network + onboard WiFi was still patchy). Luckily I was able to actually phone in for Bitcraze’s morning meetings so that I wouldn’t miss a thing.

Here are some pictures of the in-between travels, with the views, trains and food. It was all awesome, but if I do have to make a confession… the train rides through Switzerland was the most beautiful of all!

Travelling through Switzerland and Germany

The People

The first two days in Lausanne went quite smoothly. Dario Floreano of the Laboratory of Intelligent Systems (LIS) invited us to give a Crazyflie 101 lecture to the students of the Aerial Robotics course, for which we are very grateful for the opportunity. It was great to do the talk in person this time and visit the EPFL campus, since the last two years I’ve given the same lecture from my own kitchen. I was able to see the students trying to start up the course themselves, and actually got to experience how they would install the Crazyflie framework. Next to my lecture, I was given a very nice tour through the offices, laboratories and work-spaces, where I had the possibility see all the nature inspired drone designs of the LIS-lab. In the meantime I also squeezed in a quick but fun visit with Cyberbotics, the creator of Webots, to discuss our latest efforts for a crazyflie simulator.

After a beautiful train ride towards Zurich, I first met up with the people of the Automatic Control lab (ACL), who made a video about how they handled education with the Crazyflie during the harsher COVID times. Now I got a chance to see the flight room where students are able control their Crazyflie down to the rate attitude controller. Moreover, I was treated to a full workshop, hosted by ETH Zürich’s Integrated Systems Lab (IIS) and Center of Project Based learning (PBL), joined by researchers from ETHZ, University of Bologna and IDSIA (Lugano) working on the PULP platform and/or nano-drones. The workshop consisted of them and us showcasing our current work, future plans and they showed me very impressive demos with both the AIdeck and their own prototypes decks! Complete that with a lunch with one of the best views any campus has to offer, coffee break talks, and you have a very inspiring day.

The third part of the trip took place in Germany! My first stop was near Munich, namely Hochschule Augsburg, where I visited the Cooperative Control Lab lead by Klaus Kefferpütz where we had great discussions about collaborative swarms and state estimators. They showed their lab with demos, and we spoke about positioning systems and how to improve their development experience. They are currently integrating the Bolt with a Raspberry Pi with the latest functionalities we implemented into our firmware, which we can imagine is a very wanted feature by the community! I also had a brief visit at TU Munich as well to visit my friend Sophie Armanini from the eAviation and Sustainable Flight Group, and to my surprise I got to fly with a Crazyflie Bolt fueled Flapper drone!

As my final stop, I visited Wolfgang Hönig from the Intelligent Multi-Robot Coordination Lab (IMRC) at TU Berlin. Here we discussed all about Crazyswarm, simulations and firmware python bindings among many things. Also, we had a successful hackathon where we managed to generate python bindings of the Mellinger & PID controller and the motor mixing. On top of that, we managed to fly with the PID binding in the Webots simulator, which has been on the wish list for a little while now. It was great working together again in person after 1.5 years!

Collection of the tours, the platforms and the people I’ve met!

The Insights

It was great to see all the different ways that our products are used and what matters to the community members were dealing with. I’ve visited labs that tweak the attitude rate controllers, trying to improve the quality of the state estimators, or experiment with the actual mechanics. However, it was clear to see that quite some were controlling the Crazyflies on a higher level of autonomy, either off-board or onboard. This is all spread out over education and research alike, so there is a very wide range of people that are working with the Crazyflie.

There is of course also a huge variety in their approach. Some used our internally development framework with the Cflib and cfclient, and I’ve generated quite some new Github tickets in those respective repositories based on the discussions I had. However, it was interesting to see that many have made their own clients to tailor more to their research and education objectives. Moreover, about half of the users I met used ROS to interact with the Crazyflies. Is it perhaps a sign that we should start to rethink the communication infrastructure and how it all fits together?

There was also quite the difference on how close these users were on our latest changes. It ranged from working on a branch forked 4 years ago to being on the very edge of the commits, which each have their pros and cons. Working on a stable branch that has been proven worthy might be beneficial with education classes, but also makes people miss out on new features like the new lighthouse integration. However, it is not all fine and dandy on the edge of development either, as I have heard of many having issues with the new kbuild intergration, installing the cfclient or our latest efforts of getting the AIdeck out of early access. That is something that these pioneers has to deal every time they merge the new master, so we need to find better ways to make it easier for them as well.

And last but not least, it seems that the simulation we have been working on has generated quite the buzz, as most of whom I spoke to were quite interested in it, or has used a different simulation for their purpose. It was clear that there is not yet a standard simulator for aerial robotics that can fulfill everybody’s requirements in terms of swarming, (vision-based) autonomy or control. Perhaps that is a good reason to promote the simulation work from Fun-Fridays to a regular day project and have some interesting future discussions with the community how to shape this to most of our needs.

The Conclusion

All and all, those were very inspiring 2 weeks of travel for me. Even though physically I was a bit exhausted afterwards, mentally it was very motivating and inspiring! After two of the worst years of the pandemic it was great to talk to people in person and I really feel stronger connections with those I visited than the remote video calls we have done before. It is so important to stay in touch with the community in person, after so long time of absence, as we get a better sense of what the needs are and how people are using the Crazyflie and its ecosystem. The Grand Tour was according to us a great success, and who knows…. perhaps we will do an 2023 edition as well :)

There is a new fresh release of both the firmware and the python library and client! The last release (2022.01) was from 2 months ago but we already added quite some extra functionality so we wanted to make a snapshot of this before continuing on other priorities.

Kbuild on CF firmware

One of the biggest changes that you will notice, is that there is now a new way to configure your Crazyflie firmware before building it. The old config.mk is gone and you will now need to either automatically generate a config file or generate one with the menuconfig, of which kbuild is most known for. For more information, please read the blogpost about this latest change, for the exception that we do prefer the users to use ‘make cf2_config’ as instructed in the 2022.03 version of the repo documentation.

Platform support for Bolt

We now defined the Bolt as a different platform. That means that for each release, there should now also be a bolt flavor zip file, next to the cf2 and tag zips, as you can see in the release page. Moreover, if you want to build the firmware to be Bolt compatible, you would first need to do ‘make bolt_defconfig’ to generate the needed configs with kbuild. For more information of how to add your own custom platform, please check out these instructions.

2+ Lighthouse base stations (experimental)

For those that feel constrained by the max 2 lighthouse base station support in the firmware and client, this functionality is now part of the release. This blogpost will explain more about this, and it is still experimental in nature, as you would need to reconfigure the firmware with… you guessed it: Kbuild! Also the geometry estimation needs to be done as a separate python script as well all from the Crazyflie python library. No worries, if you still prefer using the cfclient, it still uses the old way of estimating if you click the button, but just remember that you would need to do something extra in order to get 2+ base station support.

New VM release

We were also made aware of a pretty big error in the bitcraze VM, namely that we still used the old git:// type url for github repositories. IN the new release of the bitcraze VM this should be fixed, so please download the new one, or fix it yourself in your current VM by changing the remote URLs of the github repos you are working on to https://.

In December we had a blogpost where we gave an overview of existing simulation models that were out there. In the mean time, I have done some work during my Fun Fridays to get this to work even further. Currently I moved the efforts from my personal Github repo to the Bitcraze organization github called crazyflie-simulation. It is all still very much work in progress but in this blogpost I will explain the content of the repository and what these elements can already do.

Low Poly CAD model

The first thing that you will need to have for any simulation, is a 3D model of the Crazyflie. There is of course already great models available from the CrazyS project, the sim_cf project and the multi_uav_simulator, which are completely fine to use as well. But since we have direct access to the exact geometries of the real crazyflie itself, I wanted to see if I could abstract the shapes myself. And also I would like to improve my Blender skills, so this seemed to be a nice project to work with! Moreover, it might be handy to have a central place if anybody is looking for a 3D simulation model of the Crazyflie.

For simulations with only one or a few Crazyflie, the higher resolution models from the other repository are absolutely sufficient, especially if you are not using a very complicated physics geometry model (because that is where most of the computation is). But if you would like to simulate very big swarms, then the polygon count will have more influences on the speed of the simulation. So I managed to make it to 1970 vertices with the below Crazyflie model, which is not too bad! I am sure that we can make it even with lesser polygons but this is perhaps a good place to start out with for now.

In the crazyflie-simulation, you can find the Blender, stl files and collada files under the folder ‘meshes’.

Webots model

We implemented the above model in a Webots simulator, which was much easier to implement than I thought! The tutorials they provide are great so I was able to get the model flying within a day or two. By combining the propeller node and rotational motor, and adjusting the thrust and drag coefficient to be a bit more ‘Crazyflie like’, it was able to take off. It would be nice to perhaps base these coefficients on the system identification of the Crazyflie, like what was done for this bachelor thesis, but for now our goal is just to make it fly!

The webots model can found in the same simulation repository under /webots/. You can try out the model by

webots webots/world/crazyfly_world.wbt

It would then be possible to control the pitch and roll with the arrow keys of your keyboard while it is maintaining a current height of 1 meter. This is current state of the code as of commit 79640a.

Ignition Gazebo model

Ignition will be the replacement for Gazebo Classic, which is already a well known simulator for many of you. Writing controllers and plugins is slightly more challenging as it is only in C++ but it is such a landmark in the world of simulation, it only makes sense that we will try to make a Gazebo model of the Crazyflie as well! In the previous blogpost I mentioned that I already experimented a bit with Ignition Gazebo, as it has the nice multicopter motor model plugin standard within the framework now. Then I tried to make it controllable with the intergrated multicopter velocity control plugin but I wasn’t super successful, probably because I didn’t have the right coefficients and gains! I will rekindle these efforts another time, but if anybody would like to try that out, please do so!

First I made my own controller plugin for the gazebo model, which can be found in the repository in a different branch under /gazebo-ignition/. This controller plugin needs to be built first and it’s bin file added to the path IGN_GAZEBO_SYSTEM_PLUGIN_PATH, and the Crazyflie model in IGN_GAZEBO_RESOURCE_PATH , but then if you try to fly the model with the following:

 ign gazebo crazyflie_world.sdfCode language: CSS (css)

It will take off and hover nicely. Unfortunately, if you try out the key publisher widget with the arrow keys, you see that the Crazyflie immediately crashes. So there is still something fishy there! Please check out the issue list of the repo to check the state on that.

Controllers

So the reason why I made my own controller plugins for the above mentioned simulation models, is that I want to experiment with a way that we can separate the crazyflie firmware controllers, make a code wrapper for them, and use those controllers directly in the simulator. So this way it will become a hybrid software in the loop without having to compile the entire firmware that contains all kinds of extra things that the simulation probably does not need. We can’t do this hybrid SITL yet, but at least it would be nice to have the elements in place to make it possible.

Currently I’m only experimenting with a simple fixed height and attitude PID controller written in C, and some extra files to make it possible to make a python wrapper for those. The C-controller itself you can try out in Webots as of this commit 79640a, but hopefully we will have the python version of it working too.

What is next?

As you probably noticed, the simulation work are still very much work in process and there is still a lot enhancements to add or fix. Currently this is only done on available Fridays so the progress is not super fast unfortunately, but at least there is one model flying.

Some other elements that we would like to work on:

  • Velocity controller, so that the models are able to react on twist messages.
  • Crazyflie firmware bindings of controllers
  • Better system variables (at least so that the ign gazebo model and the webots model are more similar)
  • CFlib integration
  • Add a multiranger and/or camera.
  • and more!

I might turn a couple of these into topics that would be good for contribution, so that any community members can help out with. Please keep an eye on the issue list, and we are communicating on the Crazyswarm2 Discussion page about simulations if you want to share your thoughts on this as well.

I have returned from my family visit in California, who I’ve haven’t seen them in 3 years due to Covid. To spend the most possible time with them, the plan was that I would still work full time for Bitcraze from my father’s home. The problem became however, that it wouldn’t fit so well in our current way of work as I would miss all the morning stand up meetings due to the large time difference between Sweden and California (-9 hours). That is why we settled that I would work on separate projects/investigations during my time away. So I thought it would be a great opportunity to dig into ROS and 3D simulations again and see what the latest state of that is! So about the simulations is what I’ll be mostly talking about right in this blog post, in terms of what simulators are out there and what simulation development is currently ongoing.

Need for simulation?

Why would it be actually be necessary to have a simulation in our current frame work? Just to give an example, my new colleague Jonas recently tried out his hand on the CFlib swarm class for the first time for the BAMdays tutorials, and simulator would have been great during that initial porcess. Namely, most of the crashes were not necessary due to low batteries or bad communication, but mostly due to the fact that he was not able to double check his script beforehand. If one is able to check if all the programmed positions of the Crazyflies are implemented as they should before an actual flight, this would prevented a lot of broken propellers!

Just to note here that there are a lot of types of simulations that you can think of. Earlier this year had our ex-interns Max and Josephine finish an Renode simulation of the Crazyflie’s microcontrollers. We’ve also seen the word Simulink pop-up multiple times on the forum which indicates that quite some control classes are investigating the dynamic model of the Crazyflie. However, the type of simulation that I’m currently referring to are the 3D simulators in which a robot or quadcopter can move and interact with a virtual environment, with usually an physics engine in effect.

Crazyflie in Gazebo (+ROS)

During some initial investigation there were already some simulations that pop out. First of all I went and looked into what is available for Gazebo at the moment, which is:

CrazyS is based on the RotorS simulation with some additional off-board crazyflie controllers for position control. I wasn’t able to build it for my Ubuntu 20.04 just yet myself, but that there is ongoing work to port CrazyS to ROS Noetic. For now on a virtual machine with ROS melodic it build just fine! Note my laptop did had to work quite hard when I wanted to simulate more than 1 Crazyflie, but the physics and plugins that were made for Gazebo is enabling many to do a lot for their research. Please check out the core papers about CrazyS!

Sim_cf is perhaps a little lesser known, but the project does stand out as it has some interesting features to it. It is for instance, possible to use the actual c-based firmware in software-in-the-loop (SITL) mode, which controls the simulated Crazyflie. It is even possible to use an actual crazyflie with an hardware-in-the-loop (HITL) simulation. Eventhough the project is not actively maintained anymore, I did manage to build it from source for ROS Noetic and Gazebo 11, although I was not able to fly more than 4 do to errors.

Other Simulators

Ofcourse Gazebo is not the only possibility out there. I also had a quick go at another simulator called Webots, which is quite an interesting option indeed as well. Currently there is only one quadcopter model available, so it only makes sense for it to also contain an Crazyflie! They do use their own robotic format, so probably the easiest process would be, is to convert an existing model for Gazebo/ROS into an format that Webots can understand.

Also, quite recently, a trending tweet has brought us to the attention of a Rviz based Crazyflie simulation! This looks quite promising as well, so I will try this out quite soon too.

Screenshot from 2021-11-15 11-56-48
Crazyflie in Ignition Gazebo

Ongoing work in Ignition Gazebo

So in the future, the current Gazebo in its form will disappear and will be only be part of Ignition. So that is why it made sense for me to start playing with an separate Crazyflie model and plugins for the Ignition frame work instead. Moreover, it seems that quite some elements and plugins based on the RotorS simulation for the original gazebo, are now fully integrated within the Ignition gazebo framework, which should make it more easier to make quadcopter models fly. Currently it’s still work in progress, so right now is only to be found on my personal github repository, but as soon as it becomes more fleshed out and stable, this will probably transferred to Bitcraze’s github repos and we will write a more elaborate blogpost about it. For now, I’ll try to work on it further as my Fun Friday project!

In the mean time, we have started a simulation discussion thread in the Crazyswarm2 repository, which is an ongoing port of Crazyswarm to ROS2. It would be the ideal situation if we would be able to use this simulator for both Crazyswarm and our native CFlib! But I’ve mostly have used Gazebo in the past, so if there are any other simulators that we should try out too, please join the discussion and let us know!

Last week it was time for the International Conference on Intelligent Robots and Systems (IROS), which is one of the biggest yearly robotics conferences! In previous editions (see 2018 blog post, 2019 event page), we joined IROS’ exhibition and showed an autonomous demos for everybody to enjoy during the coffee breaks. Then… as everybody knows… the Covid-19 pandamic hit and we had to cancel our plans to go to the 2020’s Las Vegas edition. This year’s IROS was supposed to be held in Prague, but was very early announced that this was going to be an online edition.

Eventhough we considered joining IROS’s online exhibition, after our decision to organize the Bitcraze Awesome Meetup (BAM) days as a celebration to our 10 year anniversary (see this blo gpost), we wouldn’t have enough time to prepare for both. However, we still signed up for the conference itself, so we could see how and where the Crazyflie is used in the robotics community! So this blog post will give a list and small overview of the Crazyflie-fueled research with some highlights.

Crazyflie as a Demonstration Tool in Research

A common use-case that we saw is to use the Crazyflie as a research demonstration tool. In the case of designing algorithms for quadcopters, many of the researchers we heard from or talked to told us that there is significant added value to demonstrate their ideas on a real platform. Then it can be truly evaluated with real environmental issues and platform dynamics. For this, the majority of the papers have used the ROS package developed for the CrazySwarm project but some researchers has gone as far as implementing it fully on the Crazyflie’s MCU [6, 8]!

We also noticed the large spread of the Crazyflie-featured papers throughout the sessions of the conference. A bunch of the papers could obviously be found in Aerial System sub-sessions as in ‘Perception and Autonomy’ [1], ‘Applications’ [3], ‘Mechanics and Control’ [4 , 5], but many were spread out in areas like Reinforcement Learning [2], Localization [6] and Collision avoidance [7]. There were also some papers to be found in the Swarm Robotics session [8, 9], as well as in Distributed Robot Systems [10].

Note that there is usually quite some overlap between the different sessions, but it is still very exciting to see that the Crazyflie being used in so many fields!

Highlights and the Community

We saw lots of awesome applications but there are a few that we really like to highlight! There was a presentation of an actual solar-powered Crazyflie [2] which can literally fly forever. This research was done by the same group at the University of Washington that also was featured in a blog post last year, and who is responsible for the Smellicopter. Also, our jaw literally dropped at the sight of the 4 Crazyflie-fueled mega-copter by the University of California, Los Angeles [4, 5]. Last but not least, the fully onboard autonomous gas-seeking swarm, Sniffybug [8], from the MAVLab (TU Delft), never stops to amaze us. They wrote a blog post about their work on our website this summer!

We are hoping for more interesting blog posts related to the papers in the list below in the future. We also would like to invite all the researchers, who have been working with the Crazyflie, to join us for discussions at the Community Q&A at the BAMdays. Most of the amazing aspects of the Crazyflie in terms of autonomy, localization and swarming have all been contributions of the research community in the past. So join the discussion to continue that path in order to bring the Crazyflie to a new level!

List of IROS 2021 Papers featuring the Crazyflie

Here is a list of all the Crazyflie-related papers we could find, but please let us know if we are missing any!

  • [1] Target-Visible Polynomial Trajectory Generation within an MAV Team Yunwoo Lee, Jungwon Park, Boseong Jeon and H. Jin Kim
    • Lab for Autonomous Robotic Research (LARR), Seoul National University
    • Video
  • [2] Inclined Quadrotor Landing using Deep Reinforcement Learning Jacob E. Kooi and Robert Babuska
  • [3] Toward battery-free flight: Duty cycled recharging of small drones Nishant Elkunchwar, Suvesha Chandrasekaran, Vikram Iyer and Sawyer B. Fuller
    • Department of Mechanical Engineering, University of Washington
  • [4] An Over-Actuated Multi-Rotor Aerial Vehicle with Unconstrained Attitude Angles and High Thrust Efficiencies Pengkang Yu, Yao Su , Matthew J. Gerber, Lecheng Ruan and Tsu-Chin Tsao 
  • [5] Nullspace-Based Control Allocation of Overactuated UAV Platforms Yao Su, Pengkang Yu, Matthew J. Gerber, Lecheng Ruan and Tsu-Chin Tsao
    • University of California, Los Angeles
  • [6] A Computationally Efficient Moving Horizon Estimator for Ultra-Wideband Localization on Small Quadrotors Sven Pfeiffer, Christophe de Wagter and Guido C.H.E. de Croon
    • MAVlab, Delft University of Technology
    • Paper IEEExplore
  • [7] A Scalable Distributed Collision Avoidance Scheme for Multi-agent UAV systems Bjorn Lindqvist, Pantelis Sopasakis and George Nikolakopoulos
  • [8] Sniffy Bug: A Fully Autonomous Swarm of Gas-Seeking Nano Quadcopters in Cluttered Environments
    • Bardienus P. Duisterhof Shushuai Li Javier Burgues, Vijay Janapa Reddi and Guido C.H.E. de Croon
    • MAVlab, Delft University of Technology
    • Video playlist
    • ArXiv Preprint
  • [9] micROS.BT: An Event-Driven Behavior Tree Framework for Swarm Robots Yunlong Wu, Jinghua Li, Huadong Dai, Xiaodong Yi, Yanzhen Wang and Xuejun Yang
    • Artificial Intelligence Research Center, National Innovation Institute of Defense Technology, Beijing
  • [10] Neural Tree Expansion for Multi-Robot Planning in Non-Cooperative Environments  Benjamin Riviere, Wolfgang Honig, Matthew Anderson and Soon-Jo Chung

Update 21-10-6

  • [11] Trust your supervisor: quadrotor obstacle avoidance using controlled invariant sets Luigi Pannocchi, Tzanis Anevlavis, Paulo Tabuada 
    • University of California, Los Angeles
  • [12] Continuous-time Gaussian Process Trajectory Generation for Multi-robot Formation via Probabilistic Inference Shuang Guo , Bo Liu , Shen Zhan , Jifeng Guo and Changhong Wang
    • Harbin institute of Technology
  • [13] Non-Prehensile Manipulation of Cuboid Objects Using a Catenary Robot Gustavo A. Cardona , Diego S. D’Antonio , Cristian-Ioan Vasile and David Saldana
    • Lehigh University