From the beginning of the company, we’ve always loved to join in at conferences. Only at a conference do you get the opportunity to show our products, meet our users or other tech-oriented people, learn about what others are doing, and let’s not forget the chance to discover a new place!
This year, we’ll be present at ICRA Yokohama – it’s in just 3 weeks. We’ll have a booth there (IC085 if you’re looking for us). We’ll be showing our autonomous demo with a twist just like we have shown last time, so please check the event page. This demo is extremely impressive and we’ve been improving on it each time we’ve shown it – beginning in our latest Japan trip and lastly at the last ICRA too. What’s new?
… and perhaps some more prototypes of whatever we managed to bring in our suitcase!
We’re really excited to be showing that and receive feedback, but also in hearing about what our users have been doing. ICRA is always a perfect place to catch up on all the amazing papers and publications featuring our hardware, and we couldn’t be prouder of all the cool stuff we’ve seen so far. We’re so proud, in fact, that we want to be able to show off! So, if you have a paper or a publication featured at ICRA, let us know – you can write us an email at contact@bitcraze.io, leave a comment below this post, or pass by our booth.
In fact, we’re prepared to make a deal. If you have a nice poster featuring our products and don’t know what to do with it once you’ve presented it, pass by our booth! We’re ready to swap them for something extra special. We plan to have a “hall of fame” at the office featuring your awesome work – in fact, it’s an idea we had last ICRA when someone just offered us their posters. Now, we’d like to cover our walls with them!
The corridor leading to the kitchen – we have space to show off the awesomeness!
So, whether you’re a seasoned conference-goer or a first-time attendee, don’t hesitate to wsing by our booth, say hello, and discover our newest demo! We hope to see you there.
Dev meeting
Next developer meeting is going to be on the 8th of May – we traditionally have a dev meeting every first Wednesday of the month, but this time it happens to be on the 1st of May which is a holiday here in Sweden. So already prepare your calendar for the 8th of May at 15.00 CET, and stay tuned for more info on which topic we’ll talk about!
Crazyflies back in stock !
You may have noticed that the Crazyflies have been out of stock for some time now. After some adventures, we are now fully back in stock with most of our bundles and products available in the shop!
Simulators are one of the most important tools used in robotics research. They usually are designed for different purposes with different levels of complexity. For example, simulators with low computational overhead that are parallelizable are mainly used for either training reinforcement learning algorithms or Monte Carlo sampling for verification of task completion in a nondeterministic environment. Some simulators also use rendering engines for the graphical display of models and the environment or when cameras are intended to be used in the robotics platform. Simulation is also useful for the development and deployment of new robotics firmware features where the firmware is compiled on a test machine and run in the loop with a simulated sensor suite. This simulator configuration is known as software-in-the-loop (SITL) because the vehicle firmware is intended to be run in the loop with the simulated vehicle physics and/or rendering engine. This feature is supported by autopilot suites such as PX4, ArduPilot, CogniPilot, and BetaFlight. This feature is not officially supported yet for Crazyflies because it requires a large overhaul of the firmware to be able to compile on a desktop machine and interact with different simulators such as Gazebo, Webots, PyBullet, CoppeliaSim, Isaac Sim, or Unreal Engine.
CrazySim
Last summer I began working with Crazyflies and noticed this Crazyflie simulator gap. I stumbled on a community-developed project for Crazyflie SITL called sim_cf. This project is exactly what I was looking for. However, the firmware used by the project is from July 2019 and the official firmware has had over 2000 commits made since then. The project also uses ROS 1, Gazebo Classic, and doesn’t support the Crazyflie Python library (CFLib). Using this project as a starting point I set out to develop CrazySim–a Crazyflie SITL project that doesn’t require ROS, uses Gazebo Sim, and supports connectivity through CFLib. Using CFLib we can connect the simulator to external software such as Crazyswarm2 or the Crazyflie ground station client. Users test their control algorithms in the external software using the simulator interface before deploying to real flight hardware.
An example of offboard model predictive control design and deployment workflow using CrazySim.
Using the Crazyflie Client for PID Tuning
We have also provided a modified Crazyflie client for CrazySim support. The Crazyflie client is a cool tool for testing a single drone in hardware. We can perform command based flight control, look at real time plots, save log data, and tune PID values in real time. The PID values are typically tuned for an out of the box Crazyflie. However, when we modify the Crazyflie and add extra weight through batteries, decks, and upgraded thrust motors then the behavior of the Crazyflie will change. If a user wants to tune a custom Crazyflie setup, then they can add additional models in this folder with their own motor and mass properties. Then they just need to add it to the list of supported models in either of the launch scripts. There is already an example model for the thrust upgrade bundle. Documentation for installing the custom client can be found here.
PID tuning a simulated Crazyflie using CrazySim on the Crazyflie PC client.
Crazyswarm2
We can now connect to the simulated Crazyflie firmware using CFLib. Therefore, we can set up a ROS 2 interface through Crazyswarm2 for swarm command and control through ROS 2 topics and services. To do this we first startup the drones using any of the launch scripts.
Then, we bring up Crazyswarm2 after setting up the configuration file for the number of drones chosen.
ros2 launch crazyflie launch.py backend:=cflib
We demonstrate an example of how we can control a swarm of drones using Crazyswarm2 GoTo service commands.
Crazyswarm2 GoTo service commands using CrazySim.
ICRA 2024
CrazySim is also being presented as a paper at the 2024 IEEE International Conference on Robotics and Automation in Yokohama, Japan. If you are attending this conference and are interested in this work, then I invite you to my presentation and let me know that you are coming from this blog post after. For the paper, I created a multi agent decentralized model predictive controller (MPC) case study on ROS 2 to demonstrate the CrazySim simulation to hardware deployment workflow. Simulating larger swarms with MPC may require a high performance computer. The simulations in this work were performed on an AMD Ryzen 9 5950X desktop processor.
Model predictive control case study for ICRA 2024 paper.
Hey folks! I’m Tove, and I’m thrilled to be part of the fantastic team at Bitcraze.
Bitcraze had me at “open source, self-organizing, and drones!”. The way of working, using modern software practices and the fact that the company isn’t a corporate behemoth but still packs a punch in innovation really spoke to me.
I come from the world of radio modules and Internet of Things (IOT), building software and customer applications at u-blox. u-blox is also where I wrote my thesis that wandered into indoor positioning territory, which is another reason why I was immediately drawn to Bitcraze once they entered my radar. I studied computer science with an emphasis on embedded systems at Malmö University.
When I’m not working with tech, you can find me playing board games, reading fantasy novels or working on silversmithing projects. I’m also a big fan of being out in nature, especially sailing, and even used to study environmental science before I switched over to ones and zeros.
I’m excited to learn about the great world of drones and robotics. I mean, who has not dreamt about that at some point in their life?! I’m a very poor drone flyer, but I guess some training in that department will help. I love working with tests and software quality to make sure everyone can feel comfortable and focus on developing new exciting features, while being sure nothing breaks in the process!
Looking forward to getting into the team and making things happen together!
Today, we’d like to take the opportunity to spotlight a feature that’s been in our code base for some time, yet hasn’t been the subject of a blog post: the Python bindings for our Crazyflie firmware. You may have noticed it mentioned in previous blog posts, and now we’ll delve into more detail about what it is, how we and others are utilizing it, and what its future holds.
What are the Python bindings?
Language bindings, in essence, are libraries that encapsulate chunks of code, enabling one programming language to interface with another. For instance, consider the project Zenoh. Its core library is crafted in Rust, but it offers bindings/wrappings for numerous other languages like Python, C/C++, and so on. This allows Zenoh’s API to be utilized in scripts or executables written in those languages. This approach significantly broadens the functionality without necessitating the rewriting of code across multiple programs. A case in point from the realm of robotics is ROS(1), which initially created all of their APIs for different languages from scratch—a maintenance nightmare. To address this, for ROS 2, they developed the primary functionality entirely in C and provided wrappers for all other programming languages. This strategy eliminates the need to ‘reinvent the wheel’ with each iteration.
Rather than redeveloping the firmware in Python, our esteemed collaborators Wolfgang Hönig and James Preiss took a pragmatic approach. They selected parts of the Crazyflie firmware and wrapped them for Python use. You can see the process in this ticket. This was a crucial step for the simulation of the original Crazyswarm (ROS1) project and was continued for its use in the Crazyswarm2 project, which is based on ROS 2. They opted for SWIG, a tool specifically designed to wrap C or C++ programs for use with higher-level target languages. This includes not only Python, but also C#, GO, Javascript, and more, making it the clear choice for implementing those bindings at the time. We also strongly recommend checking out a previous blogpost by Simon D. Levy, who used Haskell to wrap the C-based Crazyflie Firmware for C++.
Where are the Python bindings being used?
As previously mentioned, the Crazyswarm1 & 2 projects heavily utilize Python bindings for testing key components of the firmware (such as the high-level commander, planner, and controller) and for a (hybrid) software-in-the-loop simulation. During the project’s installation, these Python bindings must be compiled so they can be used during simulation. This approach allows users to first test their trajectories in a simulated environment before deploying them on actual Crazyflies. The advantage is that minimal or no modifications are required to achieve the same results. While simulations do not perfectly mirror real-world conditions, they are beneficial because they operate with the same controller as the one used on the Crazyflie itself. In our own Crazyflie simulation in Webots, it’s also possible to use these same bindings in the simulator by following these instructions.
Three controllers (PID, Mellinger, and Brescianini), intra-drone collision avoidance, and the high-level commander planner have all been converted into Python bindings. Recently, we’ve added a new component: the Extended Kalman Filter (EKF). This addition is ideal as it allows us to test the filter with recorded data from a real Crazyflie and experiment with different measurement models. As we discussed in a previous blogpost, estimators are complex due to their dependence on chance and environmental factors. It’s beneficial for developers to have more control over the inputs and expected outputs. However, the EKF is deeply integrated into the interconnected processes within the Crazyflie Firmware. After a significant refactoring effort, these were added to the bindings by creating an EKF emulator (see this PR). This enabled Kristoffer to further enhance the TDOA outlier filter for the Crazyflie by emulating the full process of the EKF, including IMU data.
In addition to SITL simulation and EKF development, Python bindings are also invaluable for continuous integration. They enable comprehensive testing that encompasses not just isolated code snippets, but entire processes. For instance, if there’s a recording of a Crazyflie flight complete with sensor data (such as flow, height, and IMU data), and it’s supplemented with a recorded ground truth (from lighthouse/mocap), this sensor data can be fed into the EKF Python binding. We can then compare the outputted pose with the ground truth to verify accuracy. The same principle applies to the controllers. Consequently, if any changes are made to the firmware that affect these crucial aspects of Crazyflie flight, these tests can readily detect them.
If you like to try the python bindings tests for yourself, clone the Crazyflie-firmware repo and build/install the python bindings via these instructions. Make sure you are in the root of the repository and run: python3 -m pytest test_python/. Mind that you might need to put the bindings in the same path with export PYTHONPATH=<PATH_TO_>/crazyflie-firmware/build:$PYTHONPATH (please see this open ticket)
The next steps of the python bindings
We’ve seen how Python bindings have proven to be extremely useful, and we’re keen to further expand their application. At present, only the Loco positioning system has been incorporated into the EKF part of the Python bindings. Work is now underway to enable this for the Lighthouse system (see this draft PR). Incorporating the Lighthouse system will be somewhat more complex, but fortunately, much of the groundwork has already been laid, so we hope it won’t be too challenging. However, we have encountered issues when using the controller bindings with simulation (see this open ticket). It appears that some hardware-specific timing has been hardcoded throughout the PID controller in particular. Therefore, work needs to be done to separate the hardware abstraction from the code, necessitating additional refactoring work for the controller.
Recent projects like Sim_CF2 (see this blogpost) and Crazysim (see this discussion thread) have successfully compiled the Crazyflie firmware to run as a standalone node on a computer. This allows users to connect it to the Crazyflie Python library as if it were an actual Crazyflie. This full Software-In-The-Loop (SITL) functionality, already possible with autopilot suites like PX4 and Ardupilot, is something we at Bitcraze are eager to implement as well. However, considering the extensive work required by the aforementioned SITL projects to truly separate the hardware abstraction layer from the codebase, we anticipate that refactoring the entire firmware will be a substantial task. We’re excited to see what we can achieve in this area.
Indeed, even with a more comprehensive Software-In-The-Loop (SITL) solution, there’s no reason to completely abandon Python bindings. For developments requiring more input/output control—such as the creation of a new controller or an addition to the Extended Kalman Filter (EKF)—it’s beneficial to start with just that portion of the firmware code. Python bindings and a SITL build can coexist, each offering its own advantages and disadvantages for different stages of the development process. By leveraging the tools at our disposal, we can minimize the risk of damaging Crazyflies during development. Let’s continue to make the most of these valuable resources!
Dumping and loading persistent parameters to and from a file
We have a small quality-of-life update that will allow users to dump and load persistent parameters to and from a file that has recently been merged #PR443 and #PR706. A new persistent parameter management area is introduced to the parameters tab of the client, with buttons for dumping and loading persistent parameters, as well as clearing all stored persistent parameters from the Crazyflie. The persistent parameters are stored in .yml format, allowing for manual editing if desired. If you have any improvement suggestions please drop us a comment!
A new persistent parameter management area is introduced to the parameters tab of the client, with buttons for dumping, loading and clearing stored persistent parameters.An information dialog notifies users of the dumped persistent parameters and their values. Loading parameters will result in a similar pop-up.A confirmation dialog prevents accidental clearing of persistent parameters.
System-id code merged to master
Back in 2021, we created the system-id deck which we talked about in this blog post. It has not been officially released but a few users have gotten some PCBs and built it themselves. The functionality for the system-id deck has previously been in a branch, but as code in branches tends to become outdated, we have now moved this into the master branch utilizing the kbuild system instead. Building for the system-id deck is now as easy as doing “make sysid_defconfig” and then compiling. While talking about the system-id deck, let’s check the interest of releasing it as a product. It can help with system identification, tuning of controllers, improving efficiency etc. With enough interest there might be an economy in manufacturing it.
Out of stock
Unfortunately, we’re out of stock of Crazyflies at the moment. We expect some at the end of next week, so hopefully, you should be able to find them back in the store quickly.
Developer meeting
The next developer meeting will be on the 6th of March 2024, Arnaud will talk about the Crazyflie Client past, present and future, based on its last blog post. The client is still very useful but starts to show its age so we are looking at what should be kept, what should be improved and what should be removed. We will present what we have in mind, please come and discuss with us so we can shape the next 10 years of Crazyflie client!
The Crazyflie client has a quite long history, like a lot of things in the Crazyflie ecosystem it has been started when the Crazyflie was used alone using mainly manual control. It has evolved to follow new use-cases of the Crazyflie but it still has traces of its origins and some limitation are still there with us. Moreover, the Crazyflie client and lib are written in python, one the main goal was to make it easily cross-platform. Unfortunately making a cross platform graphical program that accesses hardware in Python has proven to be quite challenging and we feel Python is not the way to go anymore. In this blog post we would like to discuss a bit the current state of the Client and what we are looking at for the future.
A Crazyflie connected to the CFclient
The Crazyflie client was originally design to be able to fly, inspect and work with one Crazyflie. It still serves this purpose quite well: with the client you can connect your Crazyflie, observe graphs of internal log values in real time, setup different decks and sets and store parameters. It is a very good tool to explore and work with the Crazyflie.
However, it is only working with one Crazyflie at a time will take over the radio, so another script cannot talk to the Crazyflie at the same time using the radio. Unless the script uses the ZMQ API that allows an external program to control client and so to control the Crazyflie while the client is connected and active. This functionality can be very useful but, since it is disabled by default, has not seen a lot of use.
The worst, for us, in the current client state is Python and PyQT distribution situation: we used to have an easy-to-use installer on windows, a Linux Snap package and plan for a Mac App. All these have been pretty much abandoned because they kept breaking down over time and the support weight for us was too big. So the only way to install the client is via Pip, the python package manager. This means that you already need a well setup Python environment to run the client. That is nice unless you have a Mac or a Raspberry pi: the latest MacOS broke part of the client that prevents it to run and there is no PyQT build for raspberry-pi available on PyPi. This is the kind of paper-cut that keeps happening at regular interval with distributing a Python application and that we keep having to look at.
So, we have been looking at ways to improve the situation. The Crazyflie client is more than 10 years old now, so a rewrite would not be such a crazy thing to consider. There are at least 2 angle of attack to make a new client better suited for the next 10 years of Crazyflie development:
Multi-platform and distribution
Making a multi-platform program is and will always be challenging. However, we have discovered that doing it in a dynamic interpreted language like python is even more so. The main challenge come from the fact that things tend to break on the user side depending of the user configuration: we all run a slightly different version of python, python evolve and package management evolves as well, so when things break it breaks at random depending of how up-to-date a particular system.
One solution would then be to switch to a compiled programming language. This increases the probability of finding problem at compile time and not at runtime, which means that we will hopefully be the first to know then Apple decided to change the location of one fundamental piece of library and so allow us to hopefully fix the problem before any user is impacted (assuming we can run CI on the latest version of MacOS early enough…).
So, as you might have guessed, our current idea is to write the client in Rust. We are currently looking at Tauri for the UI which is Web based. We still have ideas of also making a web-client so having a web-based IU on PC would simplify development of that.
We are not letting Python go away though, the idea is still to support Python, but to use it for what it is good at: a great language for developer and experimentation. Rust has great bindings to python so in this plan, the python lib is backed by the Rust lib.
Modularity
The other side of the current client limitation is the fact that it connects one Crazyflie taking over the radio. We actually love using the client to observe and poke the state of a Crazyflie so it would be really great to use it when writing a script or controlling a swarm with Crazyswarm. The current ZMQ implementation was designed to solve this issue, but it goes at it the wrong way around: the client becomes the gateway to the Crazyflie and must always be ON. It would be much nicer to be able to launch the client to connect and inspect a Crazyflie currently control by a script.
One design we are currently looking at would be to use use a protocol like Zenoh between the client and the lib. Basically, when connecting a Crazyflie, be it from a script or from the client, a server would be launched in the background that would handle the connection. All communication would pass through this server and so multiple programs would be able to communicate simultaneously with the Crazyflie.
This would allow us to build easily bridges to ROS to get the client to communicate with a Crazyflie currently connected in ROS. And since ROS2 is working on supporting Zenoh officially a bridge might not even be required.
As an added bonus, the Crazyflie server idea would greatly improve the situation when it comes to supporting Virtual Machines and WSL on Windows: it would move the USB connection handling to a Windows program and only require fast network connections which is something that works really well on WSL or VMs.
Conclusion
In this blog post I have tried to describe our current challenges and some way forward we see. The main message though is that we want to change things when it comes to the client, if you have wishes or ideas now is a good time to get in touch. Let’s make the next 10 years of Crazyflie client problem-free.
This week it will be a bit of a different blogpost than you are used to read from us. Usually we talk about cool prototypes, explain bits and pieces from the Bitcraze ecosystem or let external parties/researchers show case their awesome work that they’ve done on the Crazyflie. Today’s blogpost will be more about a societal topic that plays a big part within the robotics world: diversity! Bitcraze is helping out with the Diversity Scholarship of this year’s ROSCon, which we’d like to advertise about, but is also complimented by some words about diversity in robotics and how this topic is reflected upon within Bitcraze itself.
Diversity & Robotics
It’s widely acknowledged that the field of robotics lacks diversity. While there have been improvements, significant underrepresented groups remain, including women, individuals in LGBTQIA+ communities, people with disabilities, and those from racial and/or ethnic minorities. There are some interesting communities to look into if you are part of these groups yourself. However, if you know of any other ones that are interesting, of course, let us know.
Other than these earlier mentioned groups, we do not regard ourselves as the absolute expert on diversity in robotics, but we have perhaps a simple but interesting statistic to share from our experience. We usually receive requests for guest blog posts on our website from external researchers and engineers looking to showcase their work with the Crazyflie. We thought it would be interesting to graph the gender distribution of these guest bloggers:
Gender of our guest blogposters on bitcraze.io
As you may have noticed, before 2020, all of our guest bloggers were male, and only in recent years has that changed. It’s also worth mentioning that to our knowledge, none of the bloggers has openly identified as anything other than cis-gender male or female. While this shift represents progress, it’s important to acknowledge that there is still room for improvement. Additionally, it is essential to recognize that this tiny statistic does not fully reflect the diversity of the robotics community but rather (perhaps) pertains to a specific subset, such as aerial robotics.
Diversity & Bitcraze
So let me just cut to the chase, Bitcraze is a very small company with currently only 6 full-time employees. Currently, we don’t have any formal policies on hiring and promoting diversity. However, we do have a very open culture within the company where we can discuss these topics at our coffee breaks without restrictions or judgment. There is a genuine interest in sharing and discussing negative experiences related to the lack of diversity at previous workplaces, so we do talk about it a lot.
In terms of our impact internally and externally, for now, we don’t come across enough hiring opportunities to implement diversity policies. We can perhaps also invite more diverse guest bloggers to contribute to our website, or make our developer meetings more welcoming. However, there is only a limited influence that we can exert here with our small company. Therefore, the choice to support other communities we love to improve diversity is perhaps the most we can do to contribute to this cause.
We are already involved in the ROS community by helping out with the ROS aerial community working group (blogpost1, blogpost2) and we loved the atmosphere during ROSCon when we were in Kyoto. When the opportunity arrived to be a co-chair of the diversity committee of ROSCon 2024, together with Belén Torres from Wymaq, we gladly took it and are hoping that is were we can make more of a difference.
Diversity Scholarship at ROSCon 2024
This year’s ROSCon will be held in Odense, Denmark, between October 21st and 23rd. Since 2016, the ROSCon organization has launched a diversity scholarship opportunity, and this year’s event is expected to be the biggest one yet. Individuals belonging to the underrepresented groups in robotics, as mentioned earlier, are invited to apply for the scholarship. The deadline is April 5th, so please don’t wait too long to apply. Check here for the ROS discourse post and here for the diversity scholarship application on the ROSCon website.
Today we have a guest blogpost by Simon D. Levy (Washington and Lee University) about using Haskell to warp parts of the Crazylife-firmware. We also have some announcements from Bitcraze itself at the bottom. Enjoy!
As Richard Feynman famously said, What I cannot create, I do not understand. My less ambitious version of this motto is What I can translate into another language, I might better understand.
In order to better understand the Crazyflie firmware, I first undertook to translate the C-based firmware into C++. By separating out the general-purpose algorithmic code (state estimator, closed-loop control) from the Crazyflie-specific / Hardware Abstraction Layer (HAL) component of the firmware, I ended up with a nice, header-only C++ library of algorithms that can work with both a simulator like Webots and on a Crazyflie 2.1 or Crazyflie Bolt flight controller (with the remaining Crazyflie firmware translated into the standard C++ .h/cpp format).
As a fan of functional languages like OCAML and Haskell (and Rust, which was strongly influenced by their approach), I wondered whether I couldn’t push this idea further, to get an even higher-level implementation of the algorithms. Having played a bit with Rust and encountered issues getting it to work efficiently with C++ (something that is thankfully now being addressed), I thought it might be work trying NASA Copilot, a Haskell extension that compiles Haskell into C with a fixed memory footprint (i.e., no malloc() or garbage-collection).
My efforts paid off, resulting in a Haskell library of algorithms for closed-loop (PID) control and motor mixing that works with both my modified version of the Crazyflie firmware and with a simulator like Webots. For anyone wondering “why Haskell”, I refer you to this excellent discussion on the language’s advantages (purity, elegance), as well as this classic presentation on why the functional programming offers a better solution to complex tasks than object-oriented approach. For example, the code in the LambdaFlight core module cleanly reflects the dataflow (input/output) diagram for a standard flight controller:
Here is the Haskell code corresponding the component labeled Core in the diagram:
— Clock rate is 500Hz for Crazyflie, 100Hz for sim
dt = rateToPeriod clock_rate
— Make a list of PID controllers based on application order
pids = [positionPid resetPids inHoverMode dt,
pitchRollAnglePid resetPids inHoverMode dt,
pitchRollRatePid resetPids inHoverMode dt,
altitudePid inHoverMode dt,
climbRatePid inHoverMode dt,
yawAnglePid dt,
yawRatePid dt]
— Run PID controllers on open-loop (stick) demands to get demands for motor mixer
demands’ = foldl (\demand pid -> pid vehicleState demand) openLoopDemands pids
— Adjust thrust component for hover mode
thrust” = if inHoverMode then ((thrust demands’) * tscale + tbase) else tmin
— Run motor mixer on closed-loop demands to get motor spins, scaled for CF or sim
motors = quadCFMixer $ Demands thrust”
((roll demands’) * prscale)
((pitch demands’) * prscale)
((yaw demands’) * yscale)
By adjusting the values of the clock rate and scaling coefficients (tscale, tbase, prscale, …), the same PID controllers (with same Kp, Ki, Kd constants) can be used for both the simulation and the actual Crazyflie.
Two pieces complete the picture.
First, how can a pure functional language like Haskell, lacking mutation/side-effects, support an algorithm like PID control, which requires keeping state variables (error integral, previous error) across iterations? The answer to this question comes from an ingenious part of the NASA Copilot framework, namely, streams. A stream (which is similar to a lazy list in Haskell), can come from an module of the program written in C (for example, the vehicle state obtained by state estimation) or from a previous value passed into the function. This feature allows Copilot to have functions that possess state while still being “pure” in the sense of being amenable to formal verification (mathematical proof of correctness; see this thread for a discussion). Although I don’t have the mathematical background to do formal verification proofs, the ability to prove the code correct is an extremely powerful feature of languages like Haskell and is what led NASA to develop the Copilot framework for its space missions.
Second, how can Haskell be combined with C/C++ without running into the performance issues typically encountered in calling code in one language from code in another? As I alluded to before, NASA Copilot solves this issue nicely, by compiling the Haskell code to C code with a fixed memory footprint. Declaring certain C/C++ variables to be global makes them accessible to the Haskell code as streams, and causes them to be compiled into the resulting C code, which can then be compiled and linked to the Crazyflie (or simulator) C/C++ code in the usual way (thanks to the Crazyflie Makefile’s use of the Kbuild system). Hence, to compile the whole project into a form suitable for flashing with make cload, requires just the following chain of commands (where make links creates links to some external libraries I wrote for the sensors):
make cf2_defconfig && make links && make copilot && make -j 32
My current work focuses on two directions: first, I am translating Crazyflie’s Kalman filter into Haskell — a more ambitious undertaking, but one that I feel more confident in undertaking now that the core control algorithms are completed. Second, I am looking for ways of modifying the most popular robotics simulators (Webots, Gazbeo) to work with dynamics (physics engine) code custom-written for quadcopters and other aerial vehicles (like the dynamics code I wrote for this simulator), as well as faster control loops.
Announcements
There are some announcements that are not part of this guest blogpost that we’d like to share.
The 350 mAh batteries are out of stock and unfortunately have a very long lead time at our manufacturer, so you can expect them to be back in stock early May. Please take a look this blogpost which also compares this battery to the Tattu alternative, if you can’t wait and need to have a similar battery now.
We have a Bitcraze developer meeting this Wednesday to talk about the supervisor safety functionalities in the crazyflie-firmware. Please keep an eye on the GH discussion thread for information on how to join.
There is a new release of the firmware, version 2024.2. The main change, and almost only change, in this release, is the Bluetooth stack that was updated from the Nordic’s semiconductor S110 to S130, which affects the firmware on the NRF51 on the Crazyflie. This was mainly done to be able to pass the listing requirement on Bluetooth SIG, but it will also have beneficial technical effects on the Crazyflie radio communication state of affairs.
The new stack and bootloader are distributed in the normal release .zip, which means that it can be updated from the client as normal. Please note that the latest lib and clients are required as we have had to implement new procedures to flash the bootloader and stack.
First of all, let’s define what is a soft device. Nordic semiconductor radio chips are awesome in the way that the radio hardware is fully documented, this means that we can implement our own radio protocols but we would also be able to implement our own Bluetooth stack (I have attempted that a long time ago with some success, the nRF5 radio hardware is really powerful and can be set up to do much of the work!). However, backing your own Bluetooth stack would require passing a full suite of validation at the Bluetooth SIG to prove the stack conform to specification. In order to avoid that, the usual strategy is to buy a Bluetooth device and to talk to it over UART. What Nordic did is to implement a “Softdevice”, a binary blob that runs in the same CPU as the user application and that talks to the application using software interrupt. This keeps the application completely separated from the Bluetooth stack and so means that we get the benefits of a pre-qualified Bluetooth stack that has already been tested and approved.
Currently, we have ported the bootloader and the nrf firmware to the new S130 stack. This opens a lot of potential benefits for the future:
The new stack should be at least 6 times faster than the old one. This makes implementing BLE communication for the Crazyflie to a PC/Chromebook much more appealing and should allow to make the existing mobile client more full features.
We are now able to update the bootloader, so we can make a new improved version of it in the future (ie. with safe link, swarm optimization, much faster Bluetooth boot loading….)
The new stack supports device and host mode. So things like pairing a gamepad with the Crazyflie becomes a technical possibility! (actual implementation is left as an exercise for the contributor ;-).
One very important thing to note is that working on the bootloader requires a debugger: if you flash a bugged radio bootloader you need a SWD debug probe to be able to fix your Crazyflie. The bootloader+softdevice flashing procedure is very safe, as long as you flash a working firmware.
This change should open quite new exciting possibilities. It will be interesting to see what we can achieve with BLE and updated bootloaders in the future. Please note that we had to make a change to both the Crazyflie python library and the CFclient in order to flash this new firmware so make sure that you update those as well to try out this new release.
Developer meeting
The next developer meeting will be on the 6th of March 2024, we will talk about the Crazyflie Supervisor subsystem… We have made some changes to the supervisor recently, and we will continue working more on it in the next couple of weeks mostly preparing for the arrival of the Brushless Crazyflie. We will talk about the current state and what we are working on. Follow the thread on Bitcraze Discussions to be up to date on how to join!
You may have noticed that the HQ propellers, which are a part of the thrust upgrade bundle, have been out of stock for quite some time now. I know that many of you are relying on those propellers for the additional 20 grams of thrust they allow, so I have some news – some good, some bad.
Let’s start with the bad news: our partner and manufacturer, unfortunately, faced some problems with the mold they were using for these propellers- we prepared to face the fact that having our thrust propellers as they were before was not possible anymore. With the mold in this state, we could never go back to the same version of those propellers. To be a little dramatic, the high-quality propellers have taken their final spin. We knew it could take some time to find a good solution, and were prepared to communicate about a long-time shortage of the item.
But now for the good news! Thankfully, the replacement mold our partner used proved to be as good as the previous one – and faster than scheduled. Now back in stock, the HQ propeller can fly as well as its predecessor. We tested it and it showed the same characteristics that we’ve come to expect from the thrust upgrade.
So, what’s the real difference? Well, since it maintains the same level of performance, agility, and stability, not much. They have an updated design and have an added “ultralight” in the name (which sounds cooler, doesn’t it?). Those of you with a keen sense of observation will also notice that they have a new SKU – as well as the thrust upgrade bundle.
All in all, this change will have minimal impact on your flying if you’re used to the thrust upgrade bundle. Don’t hesitate to try out this new version and give us some feedback if you have any!
