Powerful Persistent Parameters

2021-12-06 | Jonas Danielsson | 4 Comments

The Crazyflie parameter framework provides a way to get, set and monitor parameters in the quadcopter. Examples of a parameter include which effect the LED ring will display as well as which controller to use for flight.

The parameters have default values and up until now have been reset to those default values on each restart of the Crazyflie. This has not been seen as much of a problem (Or has it? Let us know!) since most use of the Crazyflie platform has been session based and the need for persistent parameters has been low. Our work with getting the Crazyflie Bolt out of early access has however changed this need.

The Bolt will need different values for the tuning parameters for controllers and being forced to set these on each boot would be pretty annoying. And since we want the Crazyflie Bolt and the Crazyflie 2.1 to share the same firmware, persistent parameters would come in handy.

Fortunately the Crazyflie includes an EEPROM (Electronically Erasable Programmable Read-Only Memory) which we can use to store parameter values and have them survive restarts of the quad.

So this means, with the latest branches of the firmware and the python library, you can set values of a persistent parameter, store it to EEPROM, and the parameter will keep its values across reset and even across firmware upgrades.

Persistent Parameter API

Not all parameters will be able to be persistent and stored in the EEPROM. We have added a way to declare a parameter as persistent in the firmware:

PARAM_ADD_CORE(PARAM_UINT8 | PARAM_PERSISTENT, effect, &effect)

This will allow the new API added to our python library to be used with this parameter. The API consists of three actions:

Getting the state of a persistent parameter
Storing the current value of a persistent parameter
Clearing the stored value of a persistent parameter

The state of a persistent parameter consist of three pieces of information:

Is the value stored or not
The default value of the parameter
The stored value of the parameter

Setting a value, using the regular parameter API, is not enough to store the value to the EEPROM for a persistent parameter, you need to be explicit. A special API call is needed to store the current value to memory. And to stop storing the value you need to use the clear API action.

Python API

The above choices corresponds to three methods in our Python API:

def persistent_get_state(self, complete_name, callback)
Code language: PHP (php)

Get the state of the specified persistent parameter. The state will be returned in the supplied callback. The state is represented as a named tuple with members: is_stored, default_value and stored_value. The state is None if the parameter is not persistent or if something goes wrong.

def persistent_store(self, complete_name, callback=None)Code language: PHP (php)

Store the current value of the specified persistent parameter to EEPROM. The supplied callback will be called with True as an argument on success, and with False as an argument on failure.

def persistent_clear(self, complete_name, callback=None)
Code language: PHP (php)

Clear the current value of the specified persistent parameter from EEPROM. The supplied callback will be called with True as an argument on success and with False as an argument on failure.

Example code

We have also added an example script that will showcase the functionality, it will list the state of all persisted parameters in the firmware, and will store and clear some of them. The output when run against current master is:

$ CFLIB_URI=radio://0/80/2M/E7E7E7E7E8 python3 examples/parameters/persistent_params.py 
-- All persistent parameters --
sound.effect: PersistentParamState(is_stored=False, default_value=0, stored_value=None)
ring.effect: PersistentParamState(is_stored=True, default_value=6, stored_value=2)

Set parameter ring.effect to 10

Store the new value in persistent memory
Persisted ring.effect!
The new state is:
ring.effect: PersistentParamState(is_stored=True, default_value=6, stored_value=10)

Clear the persisted parameter
Cleared ring.effect!
The new state is:
ring.effect: PersistentParamState(is_stored=False, default_value=6, stored_value=None)Code language: PHP (php)

You can count on more parameters to be marked as persistent in the near future. Hopefully this will be useful for you! Please report any issues you find!

Happy Hacking!

Semiconductor shortage update

2021-11-29 | Tobias | Leave a comment

The semiconductor/electrical components shortage has not gone unnoticed by now, especially with the news coverage it had so far. It’s effecting most industries dealing with electrical components such as car manufacturers, which seem to have an especially hard time. We have been doing our best to handle the crisis, often solving it by throwing money at the problem. When you are a small player like us, you just don’t get prioritized by the big electronics manufacturers, and paying more at the open market is most often the only solution. In the beginning of May this year we had to increase our prices to counteract our increased cost as communicated in this blog post. Hopefully we will not have to increase them more but the shortage is now estimated to last for yet another year or two, and who knows how it eventually will effect us.

Another outcome of the semiconductor shortage is that the manufacturing lead-times has become very long and uncertain, so stock management has become much harder. We have solved it partially by increasing our stock but that also requires capital, which is a limited resource. We think we have managed quite OK so far but as of now Crazyflie 2.1, Multiranger-deck and SD-card decks are out of stock. Crazyflie 2.1 will hopefully arrive at the end of this week and the Multiranger and SD-card decks at the end of December. Even though times are a bit tough right now we are positive and believe we will be able to keep good stock levels throughout the crisis. We might not be able to guarantee that no products will be out of stock, but we can promise to do our very, very best to stay on top of this situation!

Fun Friday charging and lights

2021-11-15 | Marcus | Leave a comment

During the preparations for BAM, for example the awesome demo that Kristoffer did (link to demo), we had a lot of discussions about landing on charging pads. The Qi deck is a good solution, but the design is a bit complex and makes it hard to have other electronics pointing dowards (although we’ve seen some solutions to this). So after spending a few days thinking about this, I set out to spend a few fun Fridays looking at solutions for this. The results (so far) are detailed in this post.

Contact charger and decks

The idea I decided to try out was something we’ve been discussion on-and-off for a few years, using contact charging instead of Qi. So I revived a few of our old ideas and starting looking for parts. This is always a fun phase of an idea, the sky is the limit! I’m kind of used to electronic parts, but I find looking for mechanical parts is a lot harder. I don’t really have the vocabulary for this and all the parts look the same size in the product photos…

Finally the solution I wanted to test was using small pogo-pins. The idea is that the pogo-pins could be included into any design of new boards and easily enable charging. With the parts found and the ideas fresh again, I jumped into KiCad (5.99) and started the design. Two different designs were made, pictured below.

Why two solutions? I wasn’t sure which one would work well. I suspected the 4 segments would be better, but I was hoping for the two circles, since you would not need additional electronics to handle 5V/GND switched depending on how you landed.

Since there was two solutions for the pad, there’s also two solutions for the deck. I wasn’t sure about what pogo pins to use, so there’s two different sets of pins (which makes it a bit confusing).

Deck for segmented charger (with diode bridge on back)

Deck for circular charger (without diode bridge)

With the components and PCBs in hand I started testing, and…the results were not promising. The design was made to work with our current Qi charging pad (link). Although the alignment for Qi is important, the tolerance was not as tight as what I needed. Back to the drawing board, this time the mechanical one. I used FreeCAD to create a new version where the Crazyflie would align better. After a few iterations with the 3D printer I ended up with this:

Putting it all together, the results were promising. With the new mechanical design the area the Crazyflie can land in is larger and the alignment much better. I think it’s good enough to show that the concept can work. The next step is to look a bit more at the pins, they might be a bit too easy to damage.

The Glow deck

I mentioned above that the idea was to be able to put charging on decks with other designs on them. To test out this concept I revived another old idea, the Glow deck! The Glow deck is a design where the LEDs are visible from the side and also a bit stronger. To achieve this a diffuse lens would be mounted on the PCB.

The first version of the Glow I made was years ago. It contained a high-power LED, which was really bright…and really warm. We stopped measuring the PCB temperature at 140 C, so that wasn’t something that was going to work out. It also only had one color and I wanted more.

This time around I decided to try two different versions. The reason for the two versions was that I wanted to see if more power actually added something (except complexity and price) when it came to visual effects while flying. One version uses 4xWS2812B LEDs (the same as on the LED-deck) while the other one uses a RGBW high-power LED. I quickly ran into the same problem as with the charging deck, mechanics. I wasn’t able to find a good size of a diffuse lens. Not wanting to be blocked by this I decided on designing one myself and printing it. Not sure how the size would affect the effect I designed two versions.

Left: WS2812B version, right: high-power RGBW version

I haven’t had the time to try out the high-power LED version yet, but the results for the WS2812B version with the diffuse lens looks promising. It’s hard to see the effect in the images, but at least it shows that it’s possible to see the LED from the sides.

Conclusions

I think both the contact charging and the Glow looks promising and I’m happy with the results so far. But making one prototype is easy, making something that can be manufactured and properly sourced is different. If any of these ever turn into a product, the challenge will be finding the right pins, lens, charge base etc.

For the next step, I’m excited to see the high-power version of the Glow in action. This time around I’ve added proper dimming and temperature measurement :-) If you have any ideas, comments or questions drop a line below!

Real-time control of a swarm of Crazyflies in artificial forests

2021-11-08 | Enrica | 4 Comments

This week we have a guest blog post from Enrica Soria from the Laboratory of Intelligent Systems Faculty of Ecole Polytechnique Fédérale de Lausanne (EPFL) . Enjoy!

From Star Wars to Black Mirror, sci-fi movies predict a future where thousands of drones will fill our sky. Curving sharply around trees or soaring over buildings, they fly just like a flock of starlings. To turn this vision into a reality, real drone swarms need to increase their autonomy and operate in a decentralized fashion. In a decentralized swarm, each robot makes its own decision based only on local information. Decentralization not only allows the swarm to be more robust to the failure of single individuals, but also removes the dependency from a single computing unit, thus making the swarm more scalable in terms of size.

We at LIS (EPFL) have shown that predictive controllers can improve the safety of aerial swarms by predicting and optimizing the agents’ future behavior in an iterative process. However, the centralized nature of this method allowed us to only control five drones and prevented us from scaling up to a large number of drones. For this reason, we have worked on a novel decentralized and scalable swarm controller that allows the safe and cohesive flight of aerial swarms in cluttered environments. In our latest article, published in IEEE Robotics and Automation Letters (RA-L), we describe how we designed the controller, show its scalability in size, and demonstrate its robustness to noise. We studied the swarms’ performance and compared how it changes in two different environments: a forest and funnel-like environment.

The Crazyflie 2.1 was the perfect platform for our experiments. They are lightweight, modular, and tough. This quadcopter can survive big hits when things don’t go as planned… and, if you work on swarms, things can go wrong!

*The fleet of Crazyflies equipped with a single marker.*

With our algorithm, sixteen robots were able to fly through an artificial forest that we set up in our indoor motion capture arena. In our previous work, we installed four markers on each quadcopter and used the rigid body tracking from Motive (the Optitrack software). The large volume of our experimental room required the usage of big markers for long-distance detection, which added considerable weight to the drone. Hence, in our new work, we use a single marker per drone. Tracking is supported by the ‘crazyswarm’ package and communication with the entire swarm only requires two radio links. However, despite our model being decentralized, in our implementation robots relay the information to an external brain, which does the computations for them. In the future, all the necessary code will be embedded onboard, removing the dependency on external infrastructure.

*Our predictive swarm of Crazyflies flying among obstacles in our indoor experimental room.*

Video about the article

This work is a step forward towards the fully autonomous deployment of drone swarms in our cities. By enabling safe navigation in cluttered environments, drone fleets will be able to integrate with conventional air traffic, search for missing people, inspect dangerous areas, transport injured people to hospitals quicker, and deliver important packages right to our doors.

For further details, check out our article here!

Improvements in documentation

2021-11-01 | Jonas Danielsson | 2 Comments

We have recently worked on functionality in our web site to generate documentation from source in a few ways that we hope will improve the quality as well as simplify maintenance. We have already written a bit about the log and param documentation in the crazyflie-firmware repository, but we now also added and API reference in the python library as well as generating a list of publications related to the Crazyflie.

The Log and Param documentation

Earlier this year we worked on generating documentation for Log and Params from doxygen comments. We will not dig deeper into this here, but you can read more about it in this blog post. The latest version is available on our web in the repository documentation for the crazyflie-firmware: logs and params

An API reference for our Python library

The Crazyflie Python library is what you might use to create programs that interact with the Crazyflie, for instance to manage small swarms. For a while we have had introductory documentation, and step-by-step guides to show you how to perform, what we think are, common tasks.

However along the way we have also added comments and examples to our code. And this, combined with the way we have structured the library actually enables us to automagically generate reference API documentation. That is, something that shows you everything that is possible to do with the library, all modules and classes, all methods and constants that the library offers.

After some recent work this is now happening and the documentation will now get generated each time we deploy our website!

The API reference documentation can be found in the repository documentation for the library. Please check it out! And be picky, complain where the documentation is lacking! Or if the formatting seems weird! We are trying to get the hang of this and we need you to push us!

Managing publications

Some years ago we started to add publication that are related to the Crazyflie to our Research page, we hope that it might be inspiring to read about all the awesome things that the Crazyflie is used for.

Until now it has been a simple list in markdown but with an increasing number of publications it has become harder and harder to maintain it, finally we have put the work into generating the list from a BibTeX (.bib) file instead. One advantage of the new solution is that BibTeX is a well known format to the research community with lots of tools around to manage BibTeX files while another improvement is that the list will be formatted in a consistent manner (which was not always the case earlier).

If you want to add a publication to the page, simply update the .bib file with your data and create a pull request with the changes. We will merge when appropriate and the publication will become visible on the web after the next deploy, usually within a few days.

Behind the scenes

The code for generating documentation from source tends to spread out over multiple repositories and creates some complexity with a multitude of tools for different languages. It should not be necessary to understand the details and we hope the system will be easy to use for contributors to the code base.

Any questions or comments are welcome.

Happy coding!

BAM days are a wrap !

2021-10-25 | Barbara | Leave a comment

The last week was epic. We had 3 days of our online conference, the BAM days – I’m sure you’ve heard of them by now.

We are really happy with how everything went down. During those 3 days, 142 people attended, which is a highest number than we could have expected. The Welkom platform we used was stellar, allowing us to use Mibo rooms for very fruitful discussions after each talk.

Quiz and community Q&A

We took the opportunity to talk to our community, which is something we didn’t have the opportunity to do in a long time. Your insights and feedback were greatly appreciated and we have a lot to think about in the next coming weeks on how to best use all the remarks we got.

We also had a short quiz about Bitcraze, and we were quite impressed with how you performed ! And interesting to note that the hardest question for you was how many decks we sell (it’s 16, if you want to cheat on our hypothetical next quiz)

As I’ve mentioned, after each event we gathered in Mibo rooms. Even though attendance there was not as high as we would have liked, we still got quality time with community members, speakers, collaborators, even first-timers that were interested in the Crazyflie. We really love this platform, making us feel almost like meeting in real life. We even had some karaoke in Mibo during the closing party (which MAY be a good excuse to end the day for those who listened)

Content

Our external speakers presented a lot of interesting work. It was a great pleasure and honor to welcome every one of them as they explained their latest work. I have to admit that it’s rewarding to see such smart people doing awesome and cool research with our products.

We did our share too, with workshops and demos. Kristoffer’s autonomous demo using distributed consensus required a lot of work but worked perfectly in the end. Here is a small excerpt:

What now?

Now, we’re feeling as everyone is feeling the day after a party: exhausted, happy, and wondering what to do next. Hopefully we have some plans for that !

If you missed the conference, we created a Youtube playlist where you can watch everything that you missed. During the next few days, we’ll update the event page with BAM’s presentations too so you will have the opportunity to catch up. Some of our workshops will also turn into tutorials or documentations of some kind, but we’re still just cleaning up.

We are so happy with how everything went that we are already thinking about a future BAM. This one was exceptional, of course, since it was at first to celebrate our 10 year anniversary (and I have to admit that we’re all a little bit tired after 3 intense days), so we’re not going to be able to top that. But we are considering making BAM a fixed point in our agenda (and yours, let’s hope). We don’t how, we don’t know when, but one thing is sure: BAM is just beginning.

Kimberly on a different continent

On a totally different note, Kimberly is flying to the US this week: if any of you America-based wants to grab the occasion to have a more time-zone appropriate conversation with one of us, you will have a few weeks to make it possible!

See you at BAM days!

2021-10-11 | Barbara | Leave a comment

The BAM days are coming up !

Only 8 days left before the first Bitcraze-organized conference ever. We are really excited about it, and this coming week is pretty much dedicated to organize the conference. We’re working hard on getting the best experience possible for there 3 days, both for us and for you. That means collaborating with great speakers, creating awesome workshops, but also think about the best way to come together – one of the main purpose behind the BAM days.

It’s been a couple of months since we decided that we wanted to organize our own conference. The main idea behind it was that we missed going to conferences, meeting people and talking with a lot of interesting persons.

Bitcraze turning 10 felt like a big occasion that we wanted to celebrate. And indeed we did, internally, but we wanted to share this accomplishment with you too. An online conference seemed like the best idea. So when time came to choose a platform for it, we looked for something which put emphasis on social experience. We finally went with the Welkom platform, from the Netherlands. It’s easy and natural to use, with a simple interface, and lots of options for us to organize different activities.

The Welkom platform we’ll use hosts two different Mibo rooms. It’s a spatial chat, where your avatar can run around a 3D world, discovering different environments. Your camera is your head, so you’ll need a webcam to join. There are some fun activities around, plenty interactive stuff, from chairs to basketballs. We have used it to for our coffee breaks when we were working from home, and had fun using this world: we’ll be happy to meet you there and hope you’ll find it fun too.

The plan is to have between each talk or workshop at least 30 minutes in Mibo to talk to the speakers, take a coffee break, discuss the exciting things that’s been happening, and generally catch up in ways we haven’t be able to the past year.

At the end of each day, we’ve programmed social events to gather together. On Tuesday, we’ll host a special quizz. Telling you its content may be a bit cheating, but if we’ve read our blogposts regularly, the questions should not seem hard to you. For the winner, a once-in-a-lifetime reward: a GoldenFlie ! You will be able to put it in your chimney mantle with your others awards, or actually use it – because, yes, it flies!

The second day, Wednesday, we’ll have a roundtable with Q&A. A perfect occasion for us to get feedback from you, and for you to ask us all the questions you have been burning to ask us.

The last day (Thursday), we’ll talk a little about Bitcraze and its future: where it is headed. We’ll then have a last party – in Mibo of course.

All the program and other useful information is in our event page. We really hope you’ll take some time to come by and say hello !

IROS 2021: Crazyflie’s adventures in Robotic Research

2021-10-04 | Kimberly McGuire | Leave a comment

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
- Cognitive Robotics, Delft University of Technology
- ArXiv Preprint
- Video
[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
- University of California, Los Angeles
- Paper IEEExplore
[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
- Paper IEEExplore
[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
- Robotics and AI team, Luleå University of Technology
- Video
- ArXiv Preprint
[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
- Aerospace laboratories, Caltech
- Video
- ArXiv Preprint

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
- Video

Do AI decks dream of tutorials?

2021-09-20 | Kimberly McGuire | Leave a comment

The AI-decks are back in stock! Also, last week we had our quarterly meeting, where we plan our focus for the next quarter. As it is also the start of the fiscal year, we also take this opportunity to update our 1 year and 3 year plans as well. We have a big plans coming up, but one of the important focuses that we will have this year, is to get the AI-deck out of early-access!

But what would be necessary for such a task? The AI-deck is one of the most complicated boards we have worked with, so do we have to evaluate its ‘out-of-readiness’ along the same standards than any of our other products.

Mega AIdeck Tutorial

So one of our idea is to be able to achieve a state of the AIdeck in order to write a mega AIdeck tutorial series. This implies that we are able to show how somebody could go from a datasets all the way to a flying aideck-crazyflie combo. Such a series could consist of the following topics:

How to go from a dataset of images to a (Deep) Neural Network
Testing the DNN on the computer with the Image WiFi examples
Converting the neural network to Tensorflow Light (with basics on Edge AI and quantizing neural networks)
AIdeck basics (How to access the camera, how to add the network to the cluster, how to send commands)
Build and flashing the AIdeck and testing it out in the hand
Attach the AIdeck to the crazyflie, make an app-layer application to fly and react on the image input.

From the first look of it, this sounds like it should be easy to do right? Actually, there are still much to be done in order to make this tutorial possible.

Replumbing the Communication

One of the more challenging aspects of the AIdeck as it now is, is that users need to buy a JTAG-enabled programmer in order to flash the GAP8 and the NINA module of the AI-deck. That is the reason why currently the AIdeck has these 2 x 10 pin jtag connectors attached, but ideally we would want to get rid of it completely. This means is that we need to have over air flashing of the GAP8’s binary and that the intercommunication of the NINA and AIdeck will become even more important.

Moreover, the communication protocol from the GAP8 to the STM32 of the Crazyflie is currently very basic, as of right now, it is only possible to send single characters. It might work in some situations, but what if you would like to send an array of values back to the Crazyflie, like the collision probability & steering angle like in PULP platform’s implementation of Dronet? And, would we like to keep on using two UART serial ports or perhaps just relay both NINA and GAP8 communication all through one? The later will make it easier for us to maintain the crazyflie-aideck communication but can perhaps introduce communication delays.

These are just a slice of the type of re-plumbing work for the AIdeck before we can even start our dream tutorial series, but at least it will give you an idea of what we are dealing with :)

Rik the Intern

From this week we have the honor of hosting Rik Bouwmeester for a couple of months. He is currently doing his Master Thesis at the MAVlab from the faculty of Aerospace Engineering of the TU Delft. Since he has experience of working the AIdeck before, he will be able to provide us with some user perspective and help us with the above mentioned issues. You can expect a blogpost from him soon!

Dealing with the Crazyflie inconsistencies

2021-09-13 | Jonas Danielsson | Leave a comment

The Crazyflie firmware is the result of a lot of engineering (Making It Work) effort over a long period of time, the first commit in the GitHub repository is from 2013.

There are issues, inconsistencies and pain points in our firmware that have been found along the way, things that are difficult to fix because they have, in some sense, become load-bearing.

An examples of an issue like this is our inconsistency in what units are used in the Crazyflie firmware, we would like to use SI units everywhere but today that is not the case. And converting everything is proving to be tough.

More examples can be found in Appendix A of the paper Development of a multi-agent quadrotor research platform with distributed computational capabilities (Ian Scott Mcinerney, 2017).

We would like to fix all of these, but, the problem is that we have APIs to consider. There are programs written that assume that the data received from the Crazyflie is in a certain way. If we were to switch to the, more correct, aerospace axes these programs might break. And worse, they might break silently, meaning there will be no error message.

Our APIs constitute some kind of promise between the Crazyflie ecosystem (firmware, python library, documentation) and our users.

Examples include the parameter- and logging API which today has ideas about which way the coordinate system points and what units are used for values. As well as the Commander Framework / API, since this API has opinions regarding what way X, Y or Z grows in relation to reality.

Our APIs exists both between the Crazyflie firmware and our Python library code and between our Python library code and our users programs, as visualized in the diagram below.

If we were to implement solutions to the known issues we need to take these API into consideration. There are applications, demos, scripts and research code out there that rely on these APIs to behave a certain way.

So what can we do? What are our options? We have tried to enumerate them below.

1. Go Ahead And Change Units and Coordinates – But Do Not Update APIs

We fix as much as we can of the unit, correctness and conventions bugs in the firmware, but we leave the APIs as they are. This means that we keep the name of the parameter- and logging variables and we keep the name of all Python classes and functions. This is the less amount of work, it only needs updates to the crazyflie-firmware repository.

All examples and programs will continue to run. But they might now operate under false pretenses, perhaps with no error messages. The programs might stop working because of the implicit change of API.

We will have to communicate loud and clear that this will happen beforehand.

2. Go Ahead And Change Units and Coordinates – And Update the APIs

We fix as much as we can of the unit, correctness and conventions bugs in the firmware, and we also rework our APIs! We will gather learnings from our years with the current CRTP and Python API and we update them to be more developer ergonomic as well as update the parameter- and logging variables to be more consistent in naming and SI units.

This will require quite a bit of work, both in the crazyflie-firmware repository and possibly in the the crazyflie-lib-python repository.

A big benefit of this would be that we are then open to change where the boundaries for our API lies, what we provide as libraries and what is applications responsibility. And we can address pain points that are deep and structural to todays APIs.

This will break all existing programs out there, they will no longer run. They will get error messages and will need to be updated to the new APIs. We might also get weird issues and scenarios where old library code try to interface with newer firmware. We could create policys on for how long we maintain the old API and try to have them side-by-side for a bit.

3. Go Ahead And Change Units and Coordinates – Keep Old API Forever and Add a New One

It is unclear if this is possible, if we have enough memory in the firmware as well as enough bandwidth to maintain two APIs.

We could in theory keep all of the user-facing Python API and attempt to translate between the old and new one in Python code. This might take a lot of work and effort to do, but it might be possible.

But. Fixing all the correctness, convention and units in the firmware might make it very difficult to support both APIs. It might also limit how creative and how different a new API could be, while still being translatable to the old API.

We could also investigate if it would be possible to keep the API between the firmware and the libraries (CRTP and paramter- and logging variables) but translate to be more correct in regards to Units and Conventions in our library.

Even if this was deemed possible it would not help anyone developing directly against the firmware, without using a Bitcraze library.

4. Do Not Change Units and Coordinates – Keep Old API

Accept that the crazyflie-firmware will not reach correctness in respect to units and conventions and close the issues above. We can make sure all new features going in respect SI units and convention, but consider what we have as a legacy. This is by far the one that requires the less work. zero. But it will keep the pain points and inconsistencies of the Crazyflie platform.

Conclusions

There are trade offs between all solutions. We need to decide what our current APIs are worth to us. And how painful it would be for our users to handle an API break.

Maintaining multiple APIs might be to big of an burden for both us and our code base though. This is very very tricky.

It would help us a lot to hear from our users!

If you are someone who develops or have developed against the Crazyflie ecosystem please get in touch, we have created an GitHub issue here. Tell us if you have hit any of the pain-points described in this post or how an API break would affect you.