# Category: Random stuff

Our Ultra Wide Band (UWB) based positioning system, the Loco Positioning System, has been around for a long time and is still going strong! In this post we will tell you a bit about how it works (for those that don’t know about it yet), what research that is on-going in the field and new developments.

## Basics

UWB is using high frequency, low power, wide band radio where one of the most important properties is that it is possible to detect when a packet is received with very high accuracy. Combining this with very high frequency clocks, opens up the possibility to measure the time it takes for a radio packet to travel from a transmitter to a receiver. Since radio waves propagates with the speed of light in air we can convert the time into distance, and this is the basic idea in UWB positioning.

Not only is it possible to measure the timing of transmissions, the packets can also contain data, like in other radio standards. This property is extensively used to include time stamps of when a packet is sent, and also for instance the time stamp of when the transmitter received other packets or the position of an anchor.

This sounds pretty straight forward, but there are (of course) some complications. We will mention some of them but not go into the details.

• Reflections – radio waves bounce around on walls and objects. Luckily, the nature of UWB actually uses this to its advantage and works better indoors than out side.
• The clocks in the transmitter and receiver are not synchronized – the Time Of Flight can unfortunately not simply be measured by subtracting reception time from transmission time as the time stamps originate from two different clocks. The problem can be solved by sending some more packets back and forth though.
• Packet collisions – two transmitters can not send at the same time, one or both packets will be lost. Transmissions must be scheduled or packet loss must be handled.
• Obstacles – obstacles between the transmitter and receiver changes the transmission time.
• Antennas – the propagation time through the antenna is substantial and changes depending on the angle to the transmitter/receiver.

## Modes

The Loco Positioning System can run in two fundamentally different modes: Two Way Ranging (TWR) and Time Difference of Arrival (TDoA).

### Two Way Ranging (TWR)

In TWR the Crazyflie measures the distance to one anchor at a time, over and over again. Each measurement in initiated by the Crazyflie and requires 4 messages to be sent between the Crazyflie and the anchor, two request-response pairs. The position is estimated by pushing the measured distances into the kalman estimator.

This mode only supports one Crazyflie, but has the advantage of being very robust and also works pretty well some distance outside the system.

### Time Difference of Arrival (TDoA)

In TDoA the setup is different, the anchors are transmitting packets while the Crazyflie is passively listening to the traffic. From the received information it is unfortunately not possible to measure the distance to the anchors, but what we can get is the difference in distance to two anchors. For example, we might know that we are 0.54 meters closer to anchor 3 than anchor 6, or similar. It is possible to calculate the position from this information and similarly to TWR the measurements are pushed to the kalman estimator for further processing.

This mode supports unlimited numbers of Crazyflies (swarms) but is less robust compared to TWR, especially outside the system. TDoA is similar to how GPS works.

## Research

There are many researchers that use the Loco System, some use it as a positioning system and investigate topics like path planning or similar, while some others are looking at different questions related to the UWB positioning itself. We will not try to mention everyone, we probably only know of a small fraction of what is going on (please tell us!), but would like to point out two areas of research.

The first is related to improving the estimated position by handling measurement errors and the environment in a better way. Examples of this is to compensate for differences in reception angle or handling of obstacles in the space. We would like to mention Wenda Zhao’s work at the Dynamic Systems Lab, University of Toronto. He has contributed the robust TDoA implementation in the kalman estimator (blog post) as well as a public TDoA data set.

The second is inter drone ranging, that is measuring the distance between drones as an addition to, or instead of drone-to-anchor measurements. Examples in this are are the work by Dr Feng Shan at School of Computer Science and Engineering Southeast University, China (blog post) and professor Klaus Kefferpütz, Hochschule Augsburg, work on “Crazyflie quadcopter in decentralized swarming” as presented on the BAM days last year.

## Experimental functionality

Even though there has not been a lot of code committed lately in our repositories related to the Loco Positioning System, it has been simmering in the background. We would like to mention what is cooking in the pots and some of the stuff that has been discussed or tested.

### System size

An 8 anchor Loco Positioning System can cover a flight space of around 8×8 meters, but from time to time we get the question of larger systems. TDoA3 was designed with this in mind and supports up to 255 anchors, which in theory would make it possible to build larger systems. This functionality was implemented 4 years ago but we never really tested it(!). Finally we collected all anchors in the lab an set up 20 anchors in the same system, and it worked! This should make it possible to extend systems to at least 15×15 meters, but maybe even more with some clever radio cell planing.

Another possibility to enlarge a system is to tweak the radio settings to make them reach longer. There is a “Longer range” mode in TDoA3 that lowers the bit rate, but again it has not really been verified. This was also tested in the latest Loco frenzy and with some minor modifications it worked the way we hoped, with 20 anchors! The tests mainly verified that the anchors play nicely together, and we are not sure about the maximum range (to be tested) but we believe distances of up to 40 meters between anchors is possible. To use this feature you should make sure to use the latest firmware for the Loco Nodes as well as the Crazyflie.

The two features mentioned above should hopefully make it possible to go big and we hope it could be used for shows for instance.

### TDoA3 hybrid mode

If one looks at the messages sent in a TDoA system, the anchors are actually doing TWR with each other, while the Crazyflie(s) are just listening to the traffic and that the possibility to extract the position is a nice “side effect”. Now imagine if the Crazyflies were to send some messages from time to time, then they could act as “dynamic” anchors, or do inter-drone ranging with each other. This is something we call TDoA3 hybrid mode.

Currently there is no official implementation of the Hybrid mode, only some experimental hacks. Some researchers have done their own implementations, but we hope, at some point, to generalize the functionality and integrate it into the firmware.

If you are interested to read more about positioning and the Loco system, you can take a look at the following link list.

## Summer time!

Summer is coming and with that vacations, yeay! There will always be someone at the office to help you if you need help, and we will handle shipping through out the summer, but it might take a bit longer than usual.

We hope you all have some great summer months!

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
• ICRA 2022 Outstanding Dynamics and Control Paper Winner!
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.

Update

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

## 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.

Hello everyone, I am Marios from Greece studying towards my MSc in Electrical and Computer Engineering at the University of Patras.

Since last year I have been working on the Collaboration of 2 Crazyflies into handling flexible objects in collaboration with the Robotics and AI group at the Luleå University of Technology, Sweden and the University of Patras, Greece. In this research the aim was to utilize a link like rope, that was attached below them and to navigate the vehicles in tight spaces or moving obstacles, while keeping a successful lift

I am also a member of the UoP Racing Team from the University of Patras where we build an Electric Formula car in order to compete in the worldwide Formula Student competition. My responsibilities include the development of the code for the ECU and the other peripheral microcontrollers communicating with the whole car.

During this summer I will be working on improving and updating the Autonomous swarm demo by adding dynamic collision trajectories for each crazyflie and then hopefully making it completely autonomous without the need of a Master PC using the already implemented peer to peer protocol (P2P).

I would like to thank all of the people here and I am very excited to be part of this amazing company!

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?

## 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’

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.

Since the pandemic, having a close relationship with our contributors, partners, distributors and generally speaking, users, have been a challenge. We tried to keep in touch as much as possible, by organizing our own conference, visiting labs in Europe, or asking for feedback.

Now that it seems the situation has gone back to almost normal (and I’m crossing all my fingers as I’m writing that, which makes typing difficult), we have exciting plans for the coming months for getting closer to the community. Here are some of the things we are cooking up:

## Mini BAM

The closest one is actually next week ! We are hosting a short webinar where 2 of our close collaborators will present what they’ve been working on. Matěj Karásek from Flapper Drones will talk to us about his Bolt-based drone, that is set up with flapping wings. We got to try it out in our lab last week, and it looked amazing: we’re excited you’re getting a look too!

Matej will be followed by Gábor Vásárhelyi from Collmot that will introduce us to Skybrush, its platform for any kind of swarm/fleet/multi-UAV mission control.

We’re really grateful that Flapper Drones and Collmot will join us for our very first Mini Bam to talk about drones in show! Here are the details:

It starts at 15.00 CEST on May 18th.

You’ll get an invitation to join the webinar.

## IROS 2022

After 2 years of online or hybrid conferences, we’re really excited to join the next one. And it’s a big one: IROS 2022, which will be held 23-27 october in Kyoto, Japan. We’re actually so excited about it that the whole company should be joining, if logistics and Corona let us. The situation in Japan is still uncertain, the country being still closed for tourism, but we are optimistic and hope for a week full of conference, meeting new people, and of course discovering a beautiful city all together. We’re planning on having a booth there, so if you plan also on visiting IROS, be sure to pass by and say hello !

## We’re hiring

Of course, all of those plans take time… And we’re a little bit short on that, since (as I maybe mentioned before) we’re a little short handed right now. With only 6 people at Bitcraze, we’re getting frustrated: we have many projects, and too little time to work on them ! That’s why we have begun actively looking for a new Bitcrazer to add to our ranks. A job offer should be posted soon on our page: if you’re interested, keep an eye out for this, and be sure to let us know if you fill the profile (or someone who does!). We know it will be a long process to find the right fit for us, but we’re hopefully we will discover the person that will help us achieving all those plans – and even more!

We recently added improved support for assert information in the client and wanted to take this opportunity to describe some of the features in the console tab of the client that are useful for debugging and profiling.

The console tab in the python client is where you can get real time logs from the Crazyflie when connected. Any DEBUG_PRINT() statements in the Crazyflie firmware will popup here and is obviously a simple way of adding debug information to your firmware. The console logs are buffered in the Crazyflie and dumped to the client when you connect, this is why you will see the start up information when connecting to a Crazyflie. If too much information is logged and the buffer is full, you will unfortunately loose some of it but you will be notified by a “<F>” marker in the console window.

On the right side of the console tab window you will find some useful buttons, the first being the “Clear” button that simply clears the console window.

The “Task dump” button will print a list with information about the FreeRTOS tasks running in the system, for instance something like this.

SYSLOAD: Task dump
...

The “load” column contains how much of the total time that was spent in each task, since the previous measurement (or boot). To get useful values when performing some task, you probably want to make a dump at the start of your measurement and a second one at the end to get the average during this specific time.

The “Stack left” shows how many bytes of stack that is left for each task, this is the worst recorded number in the period. Stack size is recorded at task switch time which means it is possible that more stack actually was used at some point, but it should give a good indication if a task is running out of stack.

## Assert info

Next up is the new “Assert info” button, it will dump assert or crash info to the console. When the STM CPU encounters a hard fault or some other condition that resets the CPU, it will record some basic crash information in a specific part of the RAM. This special RAM is not reset when the STM re-boots and it will automatically be dumped to the console log for investigation during the start up sequence. The “Assert info” button simply dumps the same information again, which may not sound very useful. But in some cases a client may auto-reconnect to a crashed Crazyflie, consume the console log and dispose of it before a human had the opportunity to look at it. In this case you can simply connect the client to the Crazyflie and click the “Assert info” button to get the information again.

## Propeller test

The “Propeller test” button runs a automated test of the propellers and measures vibrations in the platform to determine if they are well balanced or not. The result is printed in the console window, like this: (looks like it is time to change one of my propellers!)

HEALTH: Acc noise floor variance X+Y:0.004469, (Z:0.002136)
HEALTH: Motor M1 variance X+Y: 4.17 (Z:0.55), voltage sag:0.35
HEALTH: Motor M2 variance X+Y: 0.22 (Z:0.42), voltage sag:0.37
HEALTH: Motor M3 variance X+Y: 1.23 (Z:0.21), voltage sag:0.35
HEALTH: Motor M4 variance X+Y: 1.09 (Z:0.17), voltage sag:0.31
HEALTH: Propeller test on M1 [FAIL]. low: 0.0, high: 2.50, measured: 4.17
ESTKALMAN: WARNING: Kalman prediction rate low (82)

## Battery test

The final button is the “Battery test”. It tests if the battery is worn out by spinning the motors and measuring the drop in voltage. A drop in the voltage indicates that the battery probably is bad, but it can also be caused by other sources of extra resistance in the power path, for instance oxide on the battery connector. Use it as an indication only!

Note: Only use this test for the Crazyflie 2.x, not the Bolt or BigQuad.

The result of this test is printed in the console log:

HEALTH: Idle:4.15V sag: 0.67V (< 0.95V) [OK]

## The console side-by-side other tabs

It is possible to add the console log as a tool box at the bottom or one of the sides of the client. In the “View” menu, choose “toolboxes” and click “Console”. A toolbox window with the console log will appear at the bottom of the screen which can be handy as it will be visible even if you switch to another tab.

## Other debug tools

This post has been focused on the console tab, but there are of course other functionality that is useful when debugging your system. We will end by quickly mention some of them:

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!

## 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!

## 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 :)

I know a lot of you will be too distracted by chocolate to read this post, so I will make it short.

As I mentioned earlier, we’re a little under-staffed right now. Jonas left us for new adventures, and Arnaud is enjoying some time with his baby (here in Sweden parental leave is thankfully long for dads too). On top of that, Kimberly was away the last two weeks to visit various labs in Europe. She will talk to you about it once she’s back, I’m sure. But with just 4 people at the office, time is a valuable resource. So what are we doing with it?

Well, a lot of that has been dedicated to the AI deck, but that’s not the only thing we’ve been working on. Recently, we had the visit of one expert on dangerous goods shipment. During 2 days, we got to learn about how to properly send the batteries we have, the regulations that are involved and what we have to implement to ship them. It may sound boring… and honestly, it was not the most interesting. But we got a certification out of it, that now allows us to ship as many batteries as we want with your order ! The 2 batteries only restriction that we have on the shop should be lifted – but please be aware that if you exceed 2 batteries per Crazyflie, the shipping cost will be higher, because of the fee Fedex imposes on dangerous goods shipments.

And speaking of Fedex, there are some problems right now on their air routes. Avoiding Ukraine and dealing with some strikes for air traffic operators in Europe has not been easy on their infrastructure, and we have experienced some delays in deliveries unfortunately. It seems to go back to normal gradually, so let’s hope their usual speediness resumes soon.

We’re also working on the Mini BAMs, which is on the 18th of May and will talk about drones for aerial show. Our special guest speakers are from Collmot and Flapper Drones, make sure to answer this survey if you want to participate ! You will get more informations soon.

And if want to play around with the AI deck, you will have an interesting occasion in September. IMAV launched a competition, where the goal is to have the Crazyflie equipped with the AI deck perform vision-based obstacle avoidance at increasing speeds. Deadline for registering are Mid-May, you can find more informations here.

We are now enjoying a long Easter week-end, recharging our batteries with families (and chocolate!), hoping that the Swedish spring finally settles here. I hope you’re enjoying it too !

You surely remember that last fall, to celebrate our 10 year anniversary, we organized a 3 days online conference on our own. We actually loved it, and you seemed to like it to. So we’ve been contemplating the possibility of having another, on a smaller format.

And after some thoughts, we are glad to announce the Mini BAMs! As the name implies, they are shorter (maximum 3 hours if the discussions get lively), with a simplified platform (to be determined yet), but still with interesting talks, and a lot to discover from speakers and the community. Each Mini BAM will be dedicated to a specific subject, with one or two guest speakers, followed by discussions.

We already have a session programmed, so let’s see what we have in store for our very first Mini BAM!

When? The 18th of May, in the afternoon (CEST)(the exact time will be determined shortly)

What ? Our focus this time is shows in the sky! You surely couldn’t have missed that drones are getting more and more involved in shows and productions. But while aerial entertainment is getting popular, its implementation is not easy. At Bitcraze, we try to accompany artists to help them create a unique experience, but it’s not our main area of expertise. that’s why we’re turning to 2 close partners for those shows in the sky. Which lead me to….

Who ? We will have two distinguished speakers with us this afternoon.

Gábor Vásárhelyi was born in Budapest, Hungary, in 1979. He received his MSc in engineering-physics from the Technical University of Budapest, Hungary, in 2003, and his PhD in technical sciences (info-bionics) from Péter Pázmány Catholic University, Hungary, in 2007. Since 2009 he is with Eötvös University, Department of Biological Physics as leader of the Robotic Lab at Tamas Vicsek’s Research Group on collective motion. Since 2015, he is the CEO of CollMot Robotics Ltd., a spinoff dedicated to multi-drone services. His research fields are connected to the collective motion and collective behavior of animals and robots (drones). He received many awards, for exemple: Junior Prima Award, category of informatics (2007), Magyary Postdoctoral Grant (2013), Bolyai János Research Scholarship (2015), ELTE Innovative Researcher Award (2021).

You may recognize Gabor as the author of this post. For this Mini BAM, he will present us with Skybrush, his very clean platform for any kind of swarm/fleet/multi-UAV mission control.

We will also be joined by Matěj Karásek.

Matěj Karásek studied mechanical engineering and holds a PhD in engineering sciences. He spent 10 years in the academia (ULB Brussels, TU Delft) researching animal flight and developing bioinspired flying robots. He is a founder of Flapper Drones, a startup company developing bird-like robots for research and entertainment applications.

Matej will talk to us about his Bolt-based drone, that is set up with flapping wings!

You will have time to ask them questions, and be sure to stay afterwards for discussions about show drones, the Bolt, and Skybrush!