Category: Crazyflie

Home / Blog

Working on CPX: Current status and future

  2022-06-27  |     |    Leave a comment

Last week we had the first ever Bitcraze DEV meeting! With about 10 participants, we covered a range of topics. The meeting was mostly focused around how to handle support and what the DEV meetings should be about. We also had a chance to get some feedback, and one of the points was sharing a bit more what we’re currently working on and what we might work on in the future. So in the light of that, this blogpost is about CPX (the Crazyflie Packet eXchange) protocol. We’ve mentioned CPX before (1, 2), but with this blogpost I want to share the current status and some thoughts on why we need something new.

As summer is approaching and things are winding down, I’m talking the opportunity to get back to the AI deck and CPX. The AI deck was officially released out of early access last month, but there’s still more work to be done with porting examples, adding some more functionality and increasing stability and performance.

For the AI deck we’re only supplying examples, there’s no functionality that will be used with the platform (except for the WiFi connection maybe). This is in contrast to for instance the Flow deck, where there’s a specified functionality the user can use and that should work. So in order to move forward I came up with a little demo that I want to get working during the summer. The goal is to make an application where I can fly around the Crazyflie with the keyboard and get a video stream back. To achieve this I’m using the Flow deck together with the AI deck and using WiFi for both CPX and CRTP (to send command and to get images and logging).

Why we need something new

I’ve written a post about CPX in the past (link) where I detailed the issues we are trying to solve. But in short we needed was a protocol that …

  • … could be routed though intermediaries to reach it’s destination
  • … could handle high transfer rates with large amounts of data as well as small messages
  • … could handle different memory budgets
  • … doesn’t drop data along the way if some parts of the system is loaded

As the Crazyflie echo system grows and becomes more complex we need new tools to work with it. When CRTP was implemented many years ago, the complexity we have today wasn’t something we could imagine. The Crazyflie had the only MCU and the hardware on the decks were used directly from it. Now we have multiple decks with more complex systems on them: AI deck (2 MCUs), Active marker deck (1 MCU) and the Lighthouse deck (1 FPGA). Looking forward these more complex decks might increase in the future. With more and more functionality in the Crazyflie and resources occupied, like DMA channels and pins, some functionality might need to move further out onto the decks.

For each deck new protocols are implemented and specific code is needed in the Crazyflie to handle it. Some things also become complex, like getting printouts from the different MCUs on the decks. So for the AI deck we wanted to test something new and more generic to see if it would be something we could use more in the future to talk directly to different MCUs in the system.

Will CPX replace CRTP? Probably not. We’re not sure what solution we will land in, but I think CPX is a good step in the right direction.

Current status

Back to my little demo. To reach the goal there’s a few things which needs to be fixed:

  • crazyflie-firmware/#1065: When starting to run CRTP over CPX (via WiFi) I’ve noticed that the UART2 driver was too slow, loading the system too heavily and creating problems down the line. So this is being worked on, and at the same time the old SYS-link over UART2 implementation is being moved to CPX instead.
  • aideck-esp-firmware/#12: We’ve had reports of intermittent performance issues for WiFi, which is also effecting.

Aside from the issues there’s also a few other features that are being added:

  • CRTP over CPX: Since I already have a connection for the images I also want to use this for controlling the Crazyflie. The latency is too high for controlling roll/pitch/yaw in real-time, but in my case I have the Flow deck for position control
  • CPX over CRTP: Although not part of the demo, this is interesting to look at for the future. One example is that right now we have an implementation where the Crazyflie firmware has a special implementation for the WiFi credentials. If we would like to set it from the ground we would first have to do CRTP to the Crazyflie, re-package it and then send it via CPX to the ESP32 on the AI deck. Instead I would like to send it via CPX directly from the ground, saving us extra work and complexity in the Crazyflie
  • Using Zeroconf/mDNS for finding AI decks: With this changes it will be possible to connect to the Crazyflie via the client, so we need a way to find the AI decks. For this Zeroconf/mDNS has been added, so AI decks will be automatically discovered on the local network.

The current status can be seen in the following draft PRs: crazyflie-firmware/#1068 and crazyflie-lib-python/#342. Note that until these are real PRs (not draft) they are not useful, so don’t try to use them yet.

CPX documentation

For more information on CPX and how it’s implemented, check out the documentation on our website we well as the specific documentation on using it from the GAP8.

The Loco positioning system

  2022-06-20  |     |    4 Comments

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.

Crazyflie with Loco deck

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.
  • Radio interference – other radio sources may interfere with the UWB radio signals and add noise or packet loss.

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.

Read more

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!

ICRA 2022: Crazyflie in Robotic Research

  2022-06-13  |     |    Leave a comment

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

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

Crazy Platforms

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

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

List of ICRA 2022 Papers featuring the Crazyflie and Bolt

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

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

Updated

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

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

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

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

Other Announcements: Bolt 1.1 and Dev meeting

Bolt 1.1

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

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

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

Time and Date for Dev Meeting

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

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

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

Digital Futures Drone Arena – a one-of-a-kind hackathon in Stockholm in June

  2022-05-23  |     |    Leave a comment

This week, we welcome Airi Lampinen from Stockholm University, to talk about the Crazyflie competition she’s organizing in Stockholm.

Welcome to our one-of-a-kind hackathon with Bitcraze’s Crazyflie in Stockholm, Sweden, on June 15-17, 2022! If you are curious about how technology and humans may play together, enthusiastic about the Crazyflie, or eager to learn how to use the Crazyflie, this event is for you.

Image credit: Paul Bechat, ETH Zurich

What, where, when? The Inaugural Challenge at the Digital Futures Drone Arena takes place on June 15-17, 2022 at KTH’s Reactor Hall – a dismantled nuclear reactor hall – which – especially if you haven’t been to this cool space before – makes attending the event worthwhile in its own right. In 2016, the reactor hall was used to film the music video for Alan Walker’s song Faded (Restrung).

Who can join? Anyone irrespective of age, profession and past experience with drones is welcome to participate. We welcome up to 10 teams of 2-4 people. We provide all the necessary drone hardware to the participants. We use the Crazyflie 2.1 and the Lighthouse positioning system. All that a team needs to bring along is a computer. Registration is open, with a final deadline on June 5 – we encourage those interested to sign up as soon as possible to secure their spot!

Program & prizes? On the first day of the hackathon, we will run short tutorials for those with no or little previous drone experience. The teams will then have access to the Reactor Hall to work on the challenge and conduct trial runs with their drone – we offer long hours but each team is free to choose how much they want to work. (The goal here is to have a good time!) The competition itself takes place on the third and final day. We’ve got exciting prizes for the most successful teams!

Read more about the challenge, the prizes, and how to sign up on our website: http://www.dronearena.info/

The event is organized as a part of the Digital Futures demonstrator project Digital Futures Drone Arena led by Luca Mottola from RISE and Airi Lampinen from Stockholm University.

Bitcraze Announcements

We have also some Bitcraze news to share with you:

Last wednesday, we had our very first mini BAM, and it led to 2 hours of interesting talks and exciting discissions ! If you’ve missed it, you can find the recordings in your Youtube Channel: here for Flapper Drones’ presentation, and here for Collmot‘s talk. We plan on having at least one another mini BAM before the end of the year, so stay tuned if you’re interested in those events.

Finally, as I talked about in this blogpost, we are looking for a new team mate to add to the Bitcraze crew. You’re interested? Check out our jobs page if you want to learn more !

Release 2022.05 with new AIdeck Functionality

  2022-05-16  |     |    5 Comments

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

AI deck over air flashing

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

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

Crazyflie Packet eXchange (CPX)

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

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

Controller Python bindings

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

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

Additional fixes

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

Update and Feedback

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

Debug Tools in the Client Console Tab

  2022-05-02  |     |    Leave a comment

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.

Example of the console tab

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.

Task dump

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
SYSLOAD: Load	Stack left	Name
SYSLOAD: 0.19 	205 		Tmr Svc
SYSLOAD: 83.70 	127 		IDLE
SYSLOAD: 0.01 	213 		CRTP-RX
SYSLOAD: 0.0 	54 		PWRMGNT
SYSLOAD: 0.70 	131 		LH
SYSLOAD: 0.0 	117 		CRTP-SRV
...Code language: CSS (css)

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)Code language: CSS (css)

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]Code language: CSS (css)

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.

The Plotter tab with the console as a toolbox

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:

The Grand Tour

  2022-04-25  |     |    Leave a comment

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

The Itinerary

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

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

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

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

Travelling through Switzerland and Germany

The People

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

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

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

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

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

The Insights

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

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

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

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

The Conclusion

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

Let’s welcome Victor ! (and some stock updates)

  2022-04-11  |     |    Leave a comment

A lot has happened at Bitcraze over the last months, which left us quite short-staffed. Thankfully, Victor has joined us again for a while. He mainly works on finishing his thesis with us, and we all agree that having an extra person at the office feels nice – especially considering the exciting stuff he’s working on! But let’s hear it from him first:

“Hi! I’m Victor, 26 years old, and studying towards a bachelor’s degree in Computer Science and Computer Engineering at LTH. I worked at Bitcraze during the summers of 2019 and 2020 and I’m now doing my bachelor’s thesis here.
During this thesis I will make a prototype deck that combines multiple ToF solid state lidar’s (more specifically, the new VL53L5CX). While there exists the Multi-ranger deck today, this new sensor outputs a matrix of distances, which opens up new possibilities that the Multi-ranger can not. Onboard the deck, there will also be an ESP32-S3, which will collect the data from the sensors and then send it to the PC, either through the Crazyflie, or through WiFi. This is all super exciting stuff and has endless potential, so let’s see how far I will get!”

Meet Victor!

I’m sure you will hear more on his progress in the next months, so make sure to keep updated!

Stock issues

We’ve been dealing with the component shortage as good as we can, but production is still unpredictable. Sadly, it means the impact on our stock is too. . The AI deck, the Bolt and the battery chargers are unfortunately out of stock right now. We had to change slightly the Swarm bundles to adjust to the lack of chargers. We’re also low on Multi Rangers, which are expected to run out of stock next week.

All those products are expected back by mid-May, if luck is on our side. It depends on our manufacturer in China, where there is sadly a new Corona outbreak, so it’s not easy to say for sure if this estimation is accurate. We hope that production and delivery stay unimpacted. Just know that we are working on getting everything back on stock as soon as possible. If you want to stay updated on the status of one of our out-of-stock product, you can choose to be informed by mail in our webshop. Just go to the product’s page, and put your email there: you’ll be the first one to know when it’s back in stock !

New release 2022.03

  2022-03-28  |     |    1 Comment

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

Kbuild on CF firmware

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

Platform support for Bolt

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

2+ Lighthouse base stations (experimental)

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

New VM release

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

Multiple base stations with Lighthouse

  2022-03-21  |     |    4 Comments

There has been some background work going on related to the Lighthouse system, as mentioned in a previous blogpost. The solution has been improved since that blog post and we believe the functionality is now on a level where it works pretty well and can add value to most Lighthouse users.

How to use it?

We have added a brief documentation to get you started. Though the solution has been stabilized, it is still a bit experimental and it has not been fully integrated into the client yet. The base station geometry estimator still has to be run as a python script from the command line, and a reconfigured version of the Crazyflie firmware has to be built and flashed.

We have added some improvements to the client thought to enable it to display base station status for 2+ base stations. This was the final part of the client UI that did not support 2+ base stations, and now remains only the possibility to run the new geometry estimation from the client.

Benefits

What kind of improvements does it bring?

First of all, the functionality to use more than 2 base stations and the possibility to cover a larger flight space. It also makes it possible to set up multi-room systems to support flight from one room to another.

Secondly an improved estimation of the base station geometry (also when using 2 base stations) that generally reduces the errors and improves the position estimation of the Crazyflie when flying. “Jumping” of the estimated position when one base station is occluded should be reduced. When following a trajectory that is straight line through space, the Crazyflie should now actually fly on a fairly straight line, previously the flown path might be a bit curved.

The new solution has a better match to the physical world and hopefully the estimated Z will be closer to zero when the Crazyflie is on the floor, with the “old” method, the solution sometimes is slightly tilted with a Z != 0 in some areas.

Problems

Most of the Lighthouse system works just like before, the new functionality is related to base station geometry estimation. The “standard” geometry estimation is still available in the client and if you continue to use this nothing is changed, the following list is for the new estimation method.

  • The new geometry estimation is a bit clunky to use and the user still has to rebuild the firmware and run a python script.
  • Lighthouse 1 is not fully supported
  • The new geometry estimation does not work with one base station.

We hope to address the above problems in future releases.

Release

Talking about releases, we are working on a new official release. If no unforeseen obstacles are found, we plan to make a new release within a week or two.

The functionality discussed in this blog post is still only in source code, on master or possibly in some pull requests. If you wait for the release all repositories should be syncronized and make it a bit easier to try out.

Feedback

As the environment of the system has an impact on this type of functionality, we would love to get feedback from you if you try it out. We’d love to hear how it works for you!