# Category: Random stuff

Communicating with your Crazyflie is an important pillar for its operation. As more robots are controlled, the reliability of this communication link becomes more and more important, as the probability that there is no failure at any of the Crazyflies decreases exponentially with the number of robots. We have written about the low-level radio link before. Today, we focus on past, on-going, and future improvements to make the communication more reliable.

## Reliability Challenges

As part of doing research with the Crazyswarm, I noticed several issues:

1. Sometimes commands do not seem to arrive at the Crazyflie, especially when using unicast (i.e., direct) communication with a specific Crazyflie.
2. Sending ‘too much’ data while the Crazyflie is flying can cause catastrophic crashes. One example is trying to upload a trajectory, while flying in a motion capture space. However, this occasionally even happens if just trying to update a parameter.

The radio link has a feature called Safelink, which essentially guarantees that packets are send and received in order and no packet gets dropped. This feature never worked reliably in the crazyflie_cpp implementation and is therefore not used in the Crazyswarm. However, it is the default mode for cflib. The Crazy RealTime Protocol (CRTP) also has the notion of different communication ports in order to prioritize important messages such as control commands over less important ones such as trajectory upload. However, this prioritization was never implemented in any of the clients.

Another, non reliability related, issue always was that the performance of cflib is not stellar when connected to many Crazyflies. This is mostly because (C)Python has a Global Interpreter Lock (GIL), which prevents true multi-threaded operation. A common solution to allow true parallelism is multiprocessing or implementations in a language that compiles to machine code (native code).

The first native implementation is written in C++ and includes Python bindings using pybind11. The overall API is simple: A connection can be created given a URI, and data can be send and received. Internally, this library implements Safelink to guarantee packets are in order, uses priority queues to prioritize messages on important CRTP ports, and handles all multi-radio and multi-thread related synchronization issues. Unlike prior implementations, the bandwidth is shared uniformly between all connections, i.e., there is no race between different Crazyflies communicating over the same radio. We measured a 50% lower CPU utilization when connecting with the CF client, a 20% higher bandwidth, and a 20% lower latency compared to the pure Python implementation.

For now, this feature is experimental and needs to be enabled using an environment variable. If you want to give it a try, you can use

pip install cflinkcpp
USE_CFLINK=cpp cfclient

once everything is merged to master in the next couple of days.

The second native implementation is written in Rust. As it turns out, writing multi-threaded code in C++ is very difficult and error-prone, because it is up to the user to use the various synchronization primitives correctly. Rust, on the other hand, provides extensive compile-time checks to increase reliability by design. This implementation does not have quite as many features as the C++ version yet and requires a bit more work to be used with the client but it is going to be worked-on on Fridays. The goal is to reach functional parity with the other link implementations and be able to use the rust-implemented link with “USE_CFLINK=rs cfclient” in the future.

## Future Work

As part of the development process, we also wrote many system tests that verify correctness and measure performance of the various link implementations. We already found and fixed several firmware bugs (681 and 688). The major open issue is that there is no flow control on the system link (the connection between the NRF51 and the STM32), which still causes packet loss in some cases.

Hi!

Since the middle of January, Bitcraze has had two additional guests: us! We, Josefine & Max, are currently doing our master thesis at Bitcraze during our final semester at LTH.

Unfortunately, the pandemic means remote working which could have caused some difficulties with hardware and equipment accessibility. Fortunately, for us, our goal with the thesis is to emulate the Crazyflie 2.1 hardware in the open source software Renode. We can therefore do the work at home.

Since this is the first time either of us have tried to emulate hardware it is exciting to see if it will even be possible, especially as we do not know what limitations Renode might have. Thus far, four weeks in, there have been some hiccups and crashes but also progress and success. One example was when we got the USART up and running and it became possible to start printing debug messages and another was when the LED lights were connected and it was possible to see when they were turned on and off.

If all goes well, the emulated hardware could be used as a part of the CI pipeline to automatically hunt for bugs. Academically, it would be used to further study testing methods of control firmware.

Getting a glimpse into the workings at Bitcraze and the lovely people working here has been most interesting and we are looking forward to the time ahead. Until next time, hopefully with a working emulation, Josefine & Max.

The lithium polymer battery we use, as with basically all rechargeable batteries, suffers from degradation. That means that when using it, and as time goes by, its energy capacity as well as performance will degrade. The performance, which is very related to the batteries internal resistance, will result in that the Crazyflie will not be able to produce the same maximum thrust and it will not be able to carry as much payload. The loss of capacity is due to ageing and charge cycles, results in that the flight time will decrease. A common solution to monitor the degradation is to have a BMS, or Battery Management System, that constantly monitors the battery health. For the small type of battery that is used in the Crazyflie, this is not yet viable, but maybe there is something we can do to test part of the battery health anyway?

## Theory

Since the internal resistance will result in a larger voltage drop during load we can exploit this property and measure it. We will however not only measure the batteries internal resistance but the resistance of the complete power path as a result of the components we have at hand on the Crazyflie.

So what we do is to activate the switch (mosfet) so the load (motor) will pull power from the battery. The power drawn will result in a voltage drop compared to a no-load situation, which we can measure and compare to a healthy setup. Since the measurement point is at the PCB traces, any of the components before that point can be causing the voltage drop, however the battery and connector are most likely of doing so as they are most prone to ageing.

## Implementation

The load is achieved by, for a very short time, activate the motors at full thrust. We don’t want the Crazyflie to fly away as that would be a bit unhandy. Before activating the motors we measure the idle voltage and during load we measure the minimum voltage so we can calculate the voltage drop. This is pretty easy to do, the problem is to find a good level where we can distinguish a good battery from bad battery. Therefore this feature is pretty experimental. We tested many batteries and good batteries tend to yield a voltage drop between 0.60V – 0.85V while bad batteries go above 1.0V. Therefore the current threshold is set to 0.95V but it would be good to have more data so if you use this feature please give us feedback if the level is wrong. The testing was run on a “stock” setup with the standard battery, propeller and motors, and it is for these the level is set. A different setup will probably not work well and needs a different threshold. Also keep in mind that the connector can also be a “bad” guy as oxide can build up and result in a higher resistance. Often this can be solved with some e.g. WD-40 solvent or un-connecting/connecting the connector several times.

## Usage

This is not in the 2021.01 release so one would have to run the latest on the master branch on both the crazyflie-firmware and the Crazyfie-clients-python. The simplest way to test this feature is to launch the cflient, connect to the Crazyflie, open the console tab and press the battery test button.

When pressing the button the propellers will shortly spin and there will be an output in the console as highlighted in red. If the sag value is below 0.95V it will yield [OK] and if it is above it will say [FAIL].

A probably more useful use case is to test this automatically before taking of with e.g. a swarm. This can be done by setting the parameter health.startBatTest to 1 and after around 0.5s readout the result in the log variable health.batteryPass to check that it is set to 1. The health.batterySag log variable will contain the latest sag (voltage drop) measurement. Hopefully this experimental feature will be a good way of increasing reliability of flights.

We’re happy to announce the availability of the 2021.01 release! The release includes the Crazyflie firmware (2021.01), the python library (0.1.13.1) and the python client (2021.1). The firmware package can be downloaded from the Crazyflie release repository (2021.01) or can be flashed directly using the client bootloader window.

Most of the improvements have been done in the Crazyflie firmware and include:

The App API in the Crazyflie firmware has been extended and improved to be able to handle a wider range of applications. The goal is to enable a majority of users to implement the functionality they need in an app instead of hacking into the firmware it self.

We have improved the Lighthouse support in the firmware and both V1 and V2 are now working well. Even-though everything is not finished yet, we have taken a good step towards official Lighthouse positioning.

A collision avoidance module has kindly been contributed by the Crazyswarm team.

A persistant storage module has been added to enable data to be persisted and available after the Crazyflie is power cycled. It will initially be used to store Lighthouse system information, but will be useful for many other tasks in the future.

Basic arming functionality has been added for platforms using brushless motors.

In the client the LPS tab now has a 3D visualization of the positioning system and a new tab has been added to show the python log output.

Unfortunately we have run into some problems for the Windows client build which is not available for this release.

Finally we have fixed bugs and worked to improve the general stability.

We hope you enjoy it!

Hi, fellow Crayzflie’ers! I am Wolfgang Hönig and I am a visiting researcher at Bitcraze until early April. I am excited to be part of the team and will be working on making the Crazyflie (and its ecosystem) even more accessible, more robust, and versatile for other researchers and users.

I started working with the Crazyflie (1) back in 2014 as preparation for grad school. It was the only affordable, small, and open-source robot that I could find and helped me a lot to gain practical knowledge for controls, state estimation, and realtime systems. Now, 7 years later, it is still an exceptional product for the same reasons. During my PhD at the ACT Lab at the University of Southern California, I developed crazyflie_cpp, crazyflie_ros and, together with James A. Preiss, the Crazyswarm. The Crazyswarm in particular has helped me (& many other researchers) to validate robotics research (I worked mostly on multi-robot motion planning). After my PhD, I joined ARCL at Caltech as a postdoctoral researcher, where we used the Crazyflies for research in novel techniques that combine machine learning, motion planning, and controls (see GLAS and Neural-Swarm). Starting May 2021, I’ll be leading my own research group at TU Berlin.

At Bitcraze, I am looking forward to a close collaboration with the team. So far, we are planning to improve the low-level communication over the radio (joint work with Arnaud) and data collection and improvements to the state estimator by using the unique flight arena that has a motion capture, Lighthouse, and Loco Positioning system (joint work with Kimberly). If you are a researcher and have any other ideas, feel free to reach out via email or a comment!

Storage is one of these very simple functionality that actually ends up being quite hard to implement properly. It is also one of these functionality that is never acutely needed, it is possible to hack around it, so it gets pushed to be implemented later. Later is now, we have now implemented a generic persistent storage subsystem in the Crazyflie.

In Crazyflie 1.0, we originally stored settings in a setting block in flash and required the bootloader to change the settings. When designing Crazyflie 2.0 we added an I2C EEPROM to make it easier to store settings, though until now we only stored a fix config block very similar to the one stored in the Crazyflie 1 and that only contained basic radio settings and tuning. This implementation is hard to evolve since the data structure is fixed in one point of the code.

What is now implemented is a generic key-buffer database stored in the I2C EEPROM. From the API user point of view, it is now possible to store, retrieve and delete a buffer using a string as a key. This allows any subsystem, or apps, in the Crazyflie to easily store and retrieve their own config blocks. There is 7KB of space available for storage in the EEPROM.

The first user of this new storage subsystem is the Lighthouse driver. The storage is used to store lighthouse basestation geometries and calibration data, this allows to configure a Crazyflie for a system/lab and have it running out of the box even after a restart.

A future use-case would be to implement stored-parameters: we have been thinking about implementing optional persistence for the parameters for a long time. This would allow to modify and then store new default values for any parameters already present in the Crazyflie. This would allow to very easily implement things like custom controller tuning in a quad made from a bolt for example.

At low level, we where hopping to be able to find a ready-to-use library or file system to store data in our small EEPROM, but unfortunately we did not find anything that would fit our needs. We then had to implement our own storage format.

The low level structure is documented in the Crazyflie firmware repos. Basically the data are stored as a table of “length-key-value” entries with a possibility for an entry to he a “hole”. When new buffers are added they are added at the end of the table and when they are deleted they are replaced by a hole. When the end of the table is reached, the table is de-fragmented by removing the holes and moving the data as much as possible to the beginning of the memory. This structure works very well for an EEPROM and could even be adapted to work well on FLASH.

## New CI

When we started activating continuous integration/automatic build to our GitHub repos we did so using Travis CI for firmware builds and AppVeyor for windows builds. However, the GitHub CI offering, GitHub actions, has become quite complete lately and now supports Linux, Windows as well as MacOS builds.

We have now transitioned to GitHub actions for all our repos and we will also implement most of the release process using GitHub actions as well. This will hopefully streamline the release process and allow us to release new version of our projects more often.

With the raging pandemic in the world, 2021 will most likely not be an ordinary year. Not that any year in the Bitcraze universe has been boring and without excitement so far, but it is unusually hard to make predictions about 2021. Any how, we will try to outline what we see in the crystal ball for the coming year.

## Products

What products are cooking in the Bitcraze pot and what tasty new gadgets can we look forward to this year?

### Lighthouse

We did hope that we would be able to release the first official version of the Lighthouse system in 2020, but unfortunately we did not make it. It has turned out to be more complex than anticipated but we do think we are fairly close now and that it will be finished soonish, including support for lighthouse V2.

Once the official version has been achieved, we are planning to assemble an full lighthouse bundle, which includes everything you need to start flying in the lighthouse positioning system. This will also include the Basestations V2 as developed by Valve corporation, so stay tuned!

### New platforms and improvements

We released the AI-deck last year in early release, but the AIdeck will be soon upgraded with the latest version of the GAP8 chip. For most users this will not change much but for those that really push the deep learning to the edge will be quite happy with this improvement. More over, we are planning to by standard equipped the gray-scale camera instead of the RGB Bayer filter version, due to feedback of the community. We are still planning to offer the color camera on the side as a separate product for those that do value the color information for their application.

Also we noticed the released of several upgraded versions of sensors for the decks that we already are offering today. Pixart and ST have released a new TOF and motion sensor so we will start experimenting with those soon which hopefully lead to a new Multiranger or Flowdeck. Also we are aware of the new DWM3000 chip which would be a nice upgrade to the LPS system, so we will start exploring that as well, however we are not sure if we will be able to release the new version of LPS in 2021 already.

One of the field that we have wanted to improve for a while but have not gotten to so far is the communication with the Crazyflie. The Crazyradio is using a quite old chip and the communication protocol has hardly been touched in years. There now exists a much more powerful nRF52 radio chip with USB port so it can give us the opportunity to make a new Crazyradio and, at the same time, rework the communication protocols to make them more reliable, easier to use and to expand.

## People and Collaborations

Last year we have started several collaborations with show drone orientated business, which we are definitely moving forward with in 2021. For shows stability and performance is very important so with the feedback of those that work with that on a regular basis will be crucial for the further development and reliability of our products.

Moreover we would like to continue our close collaboration with researchers at institutes and universities, to help them out with achieving their goals and contribute their work to our opensource firmware and software. Here we want to encourage the community to make their contributions easy to use by others, therefore increasing the reproducibility of the implementations, which is a crucial aspect of research. Also we are planning to have more of our online tutorial like the one we had in November.

We also will be working with closely together with one of our very active community members, Wolfgang Hönig! He has done a lot of great work for the Crazyswarm project from his time at University of Southern California (USC) and has spend the last few years at Caltech. He will be working together with us for a couple of months in the spring so we will be very happy to have him. Moreover, we will also have 2 master students from LTH working with us on the topic hardware simulation in the spring. We are making sure that we can all work together in the current situation, either sparsely at the office or fully online.

In 2021, we will also keep our eyes open for new potential Bitcrazers! We believe that everybody can add her/his own unique addition to the team and therefore it is important for us to keep growing and get new/fresh ideas or approaches to our problem. Usually we would meet new people at conferences but we will try new virtual ways to get to know our community and hopefully will meet somebody that can enhance our crazy group.

## Working from home

Due to the pandemic we are currently mainly working from home and from the looks of it, this will continue a while. Even though we think we have managed to find a way to work remotely that is fairly efficient, it is still not at the same level as meeting in real-life, so there is always room for improvement. Further more the lack of access to electronics lab, flight lab and other facilities when working from home, does not speed work up. We will try to do our best though under the current circumstances and are looking forward to an awesome 2021!

2020 was not an ordinary year, and through its different roller coaster motions, we’re proud of what we’ve accomplished. As 2021 grows nearer, it’s time to look back at this year and appreciate our accomplishments.

## Community

The Crazyflie is still gaining a lot of interests in universities, and we’re always happy to discover what awesome things our users are doing with our products. One of our proudest moment was that a paper published in Science magazine used a Crazyflie in their research framework!

We actually made a montage of the different research videos where the Crazyflie, and we feel blessed to be part of those amazing feats. We were also quite surprised to see how the Crazyflie is implemented in different fields. Here is the video if you want to know more:

We’ve had stellar blogposts from guests this year, that you can read if you missed:

Of course, “community” this year means something different. We were sorry to not participate in the conventions and fairs where we usually meet a lot of interesting people, and had to find ways to do things differently. We now have a Discord server where people can join and discuss all things Bitcraze related!

## Hardware

In the beginning of the year, we started right by releasing the Active Marker deck. Thanks to our collaboration with Qualisys, this new motion capture sensor can estimate the full body pose of the Crazyflie without unique marker positions or known starting positions.

A great deal of work was dedicated to the release of the AI deck in early access. Thanks to our newest deck, super-edge-computing is now possible on your Crazyflie !

## Software

We improved our app API. We have seen it used more and more. Being able to add code to the Crazyflie without having to fork the code has proven to be quite useful and popular.

At the beginning of the year we finally managed to decode and use the Lighthouse V2 signals in order to get the Crazyflie to fly autonomously using lighthouse V2 basestations. Our focus for the end of year was to improve the Lighthouse V2, and thanks to some hard work, we managed to improve the calibration compensation for the newest version of Valve’s base station.

The client got a new facelift, as well as the python lib, and we released no less than 4 different new releases.

## Documentation

We tried as much as we can to improve our documentation, and working from home proved how much it is needed. Kimberly wrote some step-by-step guides that help you discover more hands-on how to use our python library and the motion commander.

We also tried a new way to connect with you, while improving our existing tutorials, by having an online tutorial. It proved quite successful and it was a great way to talk about all the possibilities (and difficulties!) of a swarm.

## The way we work

The biggest change was, as many of you, to learn to work from home. We managed quite well, learning to adapt our process. We now are experts in flying at home, and even though our flying arena is deserted, our kitchens are now more alive than ever.

I came in the company too, offloading the administration work, and we welcomed for some time our intern.

This autumn when we had our quarterly planing meeting, it was obvious that there would not be any conferences this year like other years. This meant we would not meet you, our users and hear about your interesting projects, but also that we would not be forced to create a demo. Sometimes we joke that we are working with Demo Driven Development and that is what is pushing us forward, even-though it is not completely true it is a strong driver. We decided to create a demo in our office and share it online instead, we hope you enjoy it!

The wish list for the demo was long but we decided that we wanted to use multiple positioning technologies, multiple platforms and multiple drones in a swarm. The idea was also to let the needs of the demo drive development of other technologies as well as stabilize existing functionality by “eating our own dogfood”. As a result of the work we have for instance:

• improved the app layer in the Crazyflie
• Lighthouse V2 support, including basic support for 2+ base stations
• better support for mixed positioning systems

First of all, let’s check out the video

We are using our office for the demo and the Crazyflies are essentially flying a fixed trajectory from our meeting room, through the office and kitchen to finally land in the Arena. The Crazyflies are autonomous from the moment they take off and there is no communication with any external computer after that, all positioning is done on-board.

## Implementation

The demo is mainly implemented in the Crazyflie as an app with a simple python script on an external machine to start it all. The app is identical in all the Crazyflies so the script tells them where to land and checks that all Crazyflies has found their position before they are started. Finally it tells them to take off one by one with a fixed delay in-between.

### The Crazyflie app

When the Crazyflie boots up, the app is started and the first thing it does is to prepare by defining a trajectory in the High Level Commander as well as setting data for the Lighthouse base stations in the system. The app uses a couple of parameters for communication and at this point it is waiting for one of the parameters to be set by the python script.

When the parameter is set, the app uses the High Level Commander to take off and fly to the start point of the trajectory. At the starting point, it kicks off the trajectory and while the High Level Commander handles the flying, the app goes to sleep. When reaching the end of the trajectory, the app once more goes into action and directs the Crazyflie to land at a position set through parameters during the initialization phase.

We used a feature of the High Level Commander that is maybe not that well known but can be very useful to make the motion fluid. When the High Level Commander does a go_to for instance, it plans a trajectory from its current position/velocity/acceleration to the target position in one smooth motion. This can be used when transitioning from a go_to into a trajectory (or from go_to to go_to) by starting the trajectory a little bit too early and thus never stop at the end of the go_to, but “slide” directly into the trajectory. The same technique is used at the end of the trajectory to get out of the way faster to avoid being hit by the next Crazyflie in the swarm.

### The trajectory

The main part of the flight is one trajectory handled by the High Level Commander. It is generated using the uav_trajectories project from whoenig. We defined a number of points we wanted the trajectory to pass through and the software generates a list of polynomials that can be used by the High Level Commander. The generated trajectory is passing through the points but as a part of the optimization process it also chooses some (unexpected) curves, but that could be fixed with some tweaking.

The trajectory is defined using absolute positions in a global coordinate system that spans the office.

### Positioning

We used three different positioning systems for the demo: the Lighthouse (V2), the Loco Positioning system (TDoA3) and the Flow deck. Different areas of the flight space is covered by different system, either individually or overlapping. All decks are active all the time and pick up data when it is available, pushing it into the extended Kalman estimator.

In the meeting room, where we started, we used two Lighthouse V2 base stations which gave us a very precise position estimate (including yaw) and a good start. When the Crazyflies moved out into the office, they only relied on the Flowdeck and that worked fine even-though the errors potentially builds up over time.

When the Crazyflies turned around the corner into the hallway towards the kitchen, we saw that the errors some times were too large, either the position or yaw was off which caused the Crazyflies to hit a wall. To fix that, we added 4 LPS nodes in the hallway and this solved the problem. Note that all the 4 anchors are on the ground and that it is not enough to give the Crazyflie a good 3D position, but the distance sensor on the Flow deck provides Z-information and the overall result is good.

The corner when going from the kitchen into the Arena is pretty tight and again the build up of errors made it problematic to rely on the Flow deck only, so we added a lighthouse base station for extra help.

Finally, in the first part of the Arena, the LPS system has full 3D coverage and together with the Flow deck it is smooth sailing. About half way the Crazyflies started to pick up the Lighthouse system as well and we are now using data from all three systems at the same time.

Obviously we were using more than 2 basestations with the Lighthouse system and even though it is not officially supported, it worked with some care and manual labor. The geometry data was for instance manually tweaked to fit the global coordinate system.

The wall between the kitchen and the Arena is very thick and it is unlikely that UWB can go through it, but we still got LPS data from the Arena anchors occasionally. Our interpretation is that it must have been packets bouncing on the walls into the kitchen. The stray packets were picked up by the Crazyflies but since the Lighthouse base station provided a strong information source, the LPS packets did not cause any problems.

### Firmware modifications

The firmware is essentially the stock crazyflie-firmware from Github, however we did make a few alterations though:

• The maximum velocity of the PID controller was increased to make it possible to fly a bit faster and create a nicer demo.
• The number of lighthouse base stations was increased
• The PID controller was tweaked for the Bolt

You can find the source code for the demo on github. The important stuff is in examples/demos/hyperdemo

## The hardware

In the demo we used 5 x Crazyflie 2.1 and 1 x Bolt very similar to the Li-Ion Bolt we built recently. The difference is that this version used a 2-cell Li-Po and lower KV motors but the Li-Ion Bolt would have worked just as well.

To make all positioning to work at the same time we needed to add 3 decks, Lighthouse, Flow v2 and Loco-deck. On the Crazyflie 2.1 this fits if the extra long pin-headers are used and the Lighthouse is mounted on top and the Loco-deck underneath the Crazyflie 2.1 with the Flow v2 on the bottom. The same goes for the Bolt, but here we had to solder the extra long pin-header and the long pin-header together to make them long enough.

There is one catch though… the pin resources for the decks collide. With some patching of the loco-deck this can be mitigated by moving its IRQ to IO_2 using the solder-jumper. The RST needs to be moved to IO_4 which requires a small patch wire.

Also some FW configuration is needed which is added to the hyperdemo makefile:

CFLAGS += -DLOCODECK_USE_ALT_PINS
CFLAGS += -DLOCODECK_ALT_PIN_RESET=DECK_GPIO_IO4

The final weight for the Crazyflie 2.1 is on the heavy side and we quickly discover that fully charged batteries should be used or else the crash probability is increased a lot.

## Conclusions

We’re happy we were able to set this demo up and that it was fairly straight forward. The whole setup of it was done in one or two days. The App layer is quite useful and we tend to use it quite often when trying out ideas, which we interpret as a good sign :-)

We are satisfied with the results and hope it will inspire some of you out there to push the limits even further!

The Holiday season is already in full gear here, with Christmas lights everywhere, and even though it’s not going to be an usual celebration for many of us, we’re trying to find ways to make it memorable.

Our first thought for preparing the year to come (other than hoping for less dire circumstances worldwide) is to find out how we can better your experience.

Since this summer, we’ve been wondering how to improve ourselves. We have made some great headways in stabilizing what we offer. Whether with our documentation (new step-by-step guides and online tutorials), our hardware (our new propellers work perfectly) or our software (a new client and app API), we tried to improve what we already have.

We pride ourselves in knowing our defaults, but we strive to correct them as much as we can. However, we’re aware that we’re not perfect, and have some blind spots. Be that as it may, improving ourselves means also knowing where there’s room for improvement! And that’s where you are needed.

We’d like to know your thoughts and feedback, and the best way to learn from you is to ask you questions. So we created a quick survey: it takes only 3 minutes to answer and would help us a lot. In fact, it will help us shape 2021, or at least the beginning of it, as we want to stabilize our portfolio and our documentation. The goal of the survey is to pinpoint the areas that need improvements and to gain general knowledge on our customers.