Keeping things in stock has not been easy the last couple of years due to the general problems with availability of components. We have been mitigating this by increasing stock volumes when it has been possible, but we have also looked at redesigns of some products to be able to switch to other components. A positive side effect has been that it also enabled us to do some small changes we wanted to do for a long time.
The decks we have updated are the Lighthouse, SD-card and BigQuad decks. There are no big functionality changes so the decks have not gotten any updated version only a new board revision.
Lighthouse (Rev.D -> Rev.D1) The outline of the PCB has changed a bit in the hope of protecting the photo-diode sensors a bit better during hard crashes.
SD-card (Rev.C -> Rev.D) Some solder bridges were added to the bottom of the PCB to make it easier to utilize the “hidden” SPI port. This can be useful if wanting to log a lot of values to the SD-card in combination with decks using the SPI port as well, such as the Loco or Flow decks. See the datasheet for more details.
Biq-Quad (Rev.C -> Rev.C1) The capacitor C1 was removed. This was used to filter the analog current measurement reading but also caused problem for the SPI bus on the deck port. The SPI bus turned out to be a more used functionality and therefore capacitor C1 was removed. If the analog filtering functionality is wanted, a 100nF 0603 capacitor can be soldered to C1.
From now on we ship the updated revisions if you order in our store.
Jonas is leaving Bitcraze
We are sad to announce that Jonas is leaving Bitcraze. He has been involved in a lot of Github management, setting up the Crazy Stabilization lab, and various improvements and tools within our eco-system. Although he will be missed, we are excited that he is able to start a new chapter in his live and hope the best for him in his future endeavors.
The Toolbelt has been around for a pretty long time but we have not been that good at promoting it and documentation is unfortunately a bit sparse. In this blog post we will talk a bit about the Toolbelt and how to use it.
The basic idea behind the Toolbelt is to provide an easy to access tool that helps the user to do common tasks in Bitcraze projects, without installing a lot of special tool-chains, libs or programs. The intention is also to harmonize the use in all our projects to make them as similar as possible and reduce the cognitive load when switching between repositories.
A functional view
After a standard installation (see below), the Toolbelt is available using the tb command and it is intended to be executed from the root of (almost) any Bitcraze repository file tree. You can run tools (commands) from the toolbelt with the extra spice that they run in the required environment, for instance when building the firmware the correct compiler is automatically available.
Without any arguments the Toolbelt will display a brief help. For instance if I run it in the root of the crazyflie-firmware repository I get this:
kristoffer@kristoffer-XPS-13-9310:~/code/bitcraze/crazyflie-firmware$ tb
Usage: tb [-d] tool [arguments]
The toolbelt is used to develop, test and build Bitcraze modules. When the toolbelt is called, it will first try to find the tool in the belt, after that it will try the tools in the moduleif the working directory is the root of a module. Module tools are executed in the context of a docker container based on the module requirements configured in the module.json config file.
-d: print the docker call that executes the tool
Tools in the belt:
help, -h, --help - Help
update - Update tool belt to latest version
version, -V, --version - Display version of the tool belt
ghrn - Generate release notes from github milestone
docs - Serve docs locally
Tools in the current module:
build
test
compile
check_elf
make
test_python
clean
build-docs
Code language:JavaScript(javascript)
We can see that there are two groups of tools; “Tools in the belt” that are available in all repositories and ” Tools in the current module”, these are tools that are specific to the current repository.
To run a tool, simply use tb and the command. To build the firmware for instance, you can use make
kristoffer@kristoffer-XPS-13-9310:~/code/bitcraze/crazyflie-firmware$ tb make
Running script tools/build/make in a container based on the bitcraze/builder docker image as uid 1000
Using default tag: latest
latest: Pulling from bitcraze/builder
Digest: sha256:bee591d94db757465b88338c69be847cdf527698f0270ea1a86a2ccaa3c9845d
Status: Image is up to date for bitcraze/builder:latest
docker.io/bitcraze/builder:latest
make: Entering directory '/module'
CLEAN_VERSION
CC stm32f4xx_dma.o
CC stm32f4xx_exti.o
CC stm32f4xx_flash.o
CC stm32f4xx_gpio.o
...Code language:JavaScript(javascript)
We can see that the firmware is built but we did not have to set our environment beforehand like instructed in the build/install page. The Toolbelt handled that by providing an precompiled development environment to do the firmware-compiling for us.
I will not go through all the tools but I’d like to mention the docs command. The docs command starts a web server and renders a simplified version of the documentation for a repository (in the docs directory). It is useful when browsing or editing the documentation.
Implementation
The Toolbelt is based on Docker and it runs in container. When executing a tool, the Toolbelt starts a second container where the tool runs. This second container is called a builder and it contains all the software required to execute the tool. There are a few different builders with tool-chains that are appropriate for various languages, CPUs and so on, luckily the Toolbelt picks the correct one automatically.
The directory that the tool is executed from is mapped into the docker containers and this is how the tools access the files, for instance when compiling.
In the example above we can see that the Toolbelt is pulling the latest version of the bitcraze/builder image from docker hub to have the latest and greatest builder when running make. It will take a while to download the builder image the first time (or when it has been updated) but usually this is not necessary and usually starting a tool takes only around 1 second.
The builder images are also used by our build servers for CI and release builds, this means that building with the Toolbelt replicates the exact same environment as on our builder servers.
The tools that are specific to a repository can be found in the tools/build and tools/build-docs directories. They are usually bash or python scripts and often they can also be executed without the toolbelt if you have the appropriate software installed on your system.
The source code for the Toolbelt is available on github. You can also find the source code for the builders on github, search for “builder”
Installation
The Toolbelt is mainly designed for Linux like environments and works on MacOS and in WSL (Windows Subsystem for Linux). Some operations are slowish on Mac as file access is a bit slower from docker containers.
To run the Toolbelt you need to have Docker installed on your system, after that installation is as simple as adding an alias to your .bashrc (or similar). For instructions run:
docker run --rm -it bitcraze/toolbelt
Native installation VS Toolbelt VS Virtual machine
There are three paths for building and working with Bitcraze source code; native install, the Toolbelt and the VM (Virtual machine). They all have their pros and cons.
Native installation
All build tools installed on the machine.
Pros: fast, access to USB and Crazyradio which enables flashing of firmware, can use your standard development environment
Cons: Possible compatibility issues with other software on the system. Must maintain installation and upgrade from time to time.
Toolbelt
Pros: highly separated from the OS, automatically updated with the appropriate tools and versions
Cons: can not access USB and the Crazyradio – flashing not possible. No access to GUIs – can not run the client
VM
Pros: Everything ready in one place, also supports USB, Crazyradio and flashing. Client works. Highly separated from the OS.
Cons: A bit bulky
Conclusions
The Toolbelt is an option for users that are interested in working with the source code for the Bitcraze ecosystem, but do not want to put too much time into installing tool-chains and setting up environments. It does not solve all problems but hopefully simplifies some tasks.
You might, or might not have heard about a tool called Wireshark, it is quite popular in the software development world.
Wireshark is a free and open-source packet analyzer. It is used for network troubleshooting, analysis, communications protocol development and education. It makes analyzing what is going on with packet based protocols easier.
Most often Wireshark is used for network based protocols like TCP and UDP, to try to figure out what is happening with your networking code. But! Wireshark also allows you to write your own packet dissector plugin, this means that you can register some code to make Wireshark handle your custom packet based protocol.
For the latest release of the Crazyflie Python Library we added support for generating a log of the Crazy Real Time Protocol (CRTP) packets the library sends and receives. This is the (packet based) protocol that we use to communicate with the Crazyflie via radio and USB.
We generate this log in the special PCAP format that Wireshark expects. And we also created an initial version of a dissector plugin, written in the programming language LUA.
When we put this two things together it turns into a pretty cool way of debugging what goes on between your computer and the Crazyflie!
What does it look like?
Wireshark gives you a graphical interface where you can view all the packets in a PCAP file. You will see the timestamps of when they arrived. Selecting a packet will give you the information that the dissector has managed to deduce as well as how the packet looked on the wire.
On top of that you get powerful filtering tools. In the below image we have set a filter to view only packets that are received or sent on the CRTP port 8, which is the port for the High level commander. This means that from a log file that contain 44393 packets we now only display 9. Which makes following what goes on with high level commands a bit easier.
Wireshark view of filtering out packets on CRTP port 8
The dissector knows about the different types of CRTP ports and channels and knows how to dissect an high level set-point, as seen by the image above.
What can this be used for?
This functionality is, we think, most useful for when developing new functionality in the Crazyflie firmware, or in the library. You can easily inspect what the library receives or sends and make sure it matches what your code indented.
But it can also be useful when doing client type work! We recently located the source of a bug in the Crazyflie client with the use of this Wireshark plugin.
It was when updating the Parameter tab of the client to handle persistent parameters, and to use a sidebar for extra documentation and value control. As I was testing the code I noticed that every time I changed the value of ring.effect to a valid integer and then disconnected and reconnected, the value was set to 0. Regardless of the value I had set.
I recorded a session using the PCAP log functionality:
$ CRTP_PCAP_LOG=ring.pcap cfclient
And the I fired up wireshark:
$ wireshark ring.pcap
It was now possible for me to track what the library and firmware thought was going on with the ring.effect parameter, by tracking the crtp.parameter_varid field using Wireshark. Filtering down from from 3282 packets to 12 packets.
I had earlier figured out that the varid of the ring.effect variable was 183. This is a quasi-internal representation of a parameter that we do not expose in a good way. In the future we will try to make this Wireshark tracking work with the parameter name as well.
Looking at the write parameter packet from USB #3 to the Crazyflie I could see where I set the value of the parameter to 5, so far so good.
Wireshark view of checking my setting of the ring.effect parameter to 5
The surprising part however was seeing a write further down setting the parameter to 0! This mean that something in the client was actually setting this to zero!
Wireshark view of something setting the ring.effect parameter to 0
After seeing this, locating the actual issue was trivial. I noticed that the Flight Control tab was setting the ring.effect parameter to the current index of the combo box in the UI. And when no LED-ring deck was attached, this amounted to always setting the value to zero.
But having confirmation that this was something happening on the client side, and not some kind of bug with the new persistent parameters was very helpful!
How do you use this?
We have added documentation to the repository documentation for the library on how to generate the PCAP log and how install the Wireshark plugin.
But the quick-start guide is this:
Copy the tools/crtp-dissector.lua script to the default Wireshark plugin folder
We’ve had an exciting year in 2021, and we’re eager to see what 2022 will bring ! Let’s see what’s in the pipeline and what we hope for this new year.
Products
The AI deck and Bolt out of Early Access
We’ve put a lot of efforts during these last months on working with the AI deck’s firmware and infrastructure. With great help of our intern Rik, we managed to make huge leaps, and hopefully sometimes in the coming months we’ll be able to share what we worked on. I can already tell you that the incoming release will bring some needed improvements on flashing on the GAP8 chip and improved image streaming! As the AI deck is one of the most challenging of our decks, we also hope to add an extensive tutorial (that we call the “mega tutorial”) to help you working with it.
Also we have started to push some framework changes to make it easier for you to make bigger drones with the Crazyflie Bolt. One of those are the persistent parameter system that we have recently implemented on the Crazyflie’s, so we will add more and more of these types of features. The hope is, is that we are able to provide some kind of assembly kit for a larger Bolt-based drone, of which we already did some initial battery investigations for.
Prototypes
Fun Fridays are usually our time to play around with new possibilities and prototypes. Marcus has already made great strides, and hopefully in 2022 we’ll be able to go even farther with those. Arnaud has also been working on the much waited new iteration of the Crazyradio, with a new chip and an improved communication protocol. Tobias, our dedicated hardware man, has also ideas down the pipes in the form of a brushless Crazyflie as we already showed in our future plans presentation of November’s BAMdays. Also we hope to initiate the design process of a new and improved version of the Crazyflie with more power and processing capabilities.
People and Collaborations
Last year we have continued our close collaboration with researchers at institutes and universities, to help them out with achieving their goals and contribute their work to our opensource firmware and software. It proves really fruitful, both for us and the people we talk to, so we hope 2022 will see yet again closer and newer connections.
We were really happy with our first own online conference, which helped us reconnect and talk to our community about all the awesomeness achieved with the Crazyflies. We hope to implement something similar on a more regular basis, to keep talking about collaborations, possibilities, and in general sharing all the work that’s been done on the platform. Those “lightweight” BAM should arrive soon, so keep updated if you want to join them!
Component shortage and productions issues
We expect to still deal with the component shortage, as it is expected to last for at least another year, even two. Production is therefore a continuous challenge, with a lot of unpredictability, and we will find better solutions to deal with it in 2022. Thankfully, we have good hopes on keeping good stock levels throughout the crisis, as we’ve increased our stock. We’ll of course keep you updated on any big updates regarding the crisis and how it is affecting it us.
Unfortunately, the component shortage also means that it’s harder to make prototypes. It’s difficult to find and/or buy just one chip, so it causes delays in our creative hardware developments. It is what it is… but we will sure be able to find solutions – as we did during our 10 years’ history!
Anything else?
Of course our heads are always full of ideas and we are passionate to work on anything! We have ambitions in developing a simulation for our users or CI, doing more measurements with the new thrust stand or adding further improvements to our documentation and tutorials. And we might also meet new interesting people (digitally or in person?) who might give us enough inspiration to start something completely new! Soon we will have our quarterly meeting, where we try to herd and select our passions and ideas into conceivable plans and actions.
With all these exciting projects, we’re really excited to see what 2022 has in store for us! I hope you too have an awesome year 2022.
2021 is coming to an end. As we’re about to flip the page on a new calendar, let’s take a look at what happened during this past year.
Community
It’s no news to you, but keeping in touch with our community during a pandemic has forced us to try new ways to meet and interact. The main event for us this year has been the BAM days: our first conference held entirely by ourselves, full of exciting talks and fun, and we’re very happy with how it went down! You can still watch the talks we hosted during those three days in our dedicated Youtube playlist.
Guest blogposts
Once again, we’ve had the honor to host some awesome guests on our blog, which you can read (or re-read) here:
Thanks to Jonas’ hardwork, we also set up a “crazy lab” here in Malmö. During Fun Friday, Arnaud has been experimenting with Rust, working on a webclient.
Hardware
We’ve been dealing since 2020 with a hardware crisis. The component shortage has made production erratic and difficult, and for the first time in Bitcraze’s history, we’ve had to increase our prices.
Lighthouse
The first part of the year was dedicated to the Lighthouse system. At the beginning of the year, we finally got it out of early access. We documented the new Lighthouse Functionality and even wrote a paper for ICRA about the Lighthouse accuracy with Wolfgang’s help. We created the Lighthouse swarm bundle, getting every element to fly a swarm with this positioning system.
AI deck
We worked a lot on the AI deck this year. We upgraded to the AI deck 1.1, with a gray-scale camera and a newer version of the GAP-8. Part of this work was also to improve the documention and informations we had on it. We had a workshop with PULP, and dreamed of a mega-tutorial.
Bitcraze has once again increased in numbers, as we welcomed into our ranks Jonas. We were also really happy to add Wolfgang to the team for a few months, as well as Rik, an intern from MAV-lab.
The biggest event this year for us was our 10 year anniversary. That’s right, Bitcraze turned 10 in September, and we tried to celebrate it as much as possible ! With a nice outing and with the BAM days, but also with a video trying to show what 10 years of Bitcraze looks like:
Christmas is just around the corner, and it’s time for the traditionnal Christmas video! This year, we wanted to use the AI deck as we’ve been working hard on this deck for some time now. Showcasing its new feature in this festive video seemed the best idea.
Santa this year needed help to find and get the presents delivered, so he asked for help from Bitcraze! Let’s see how it played out:
I’m sure you’re wondering how we managed to set this up, so let’s discuss how we did it!
Picking up the packages
The goal was to pick up some packages and place them in the sleigh, and it all worked out pretty well. All the flying in the video is scripted using the python lib and positioning is done using Qualisys’ motion capture system with Active marker decks. The trajectories are hard coded and with some careful adjustments we managed to lift and fly the 4 crazyflies attached to the same present, even though it was a bit wobbly from time to time. Getting the present into the sleigh was not as easy, and we might have taken some short cuts here as well as when attaching/removing lines.
Sometimes detangling the wires was a teamwork
Picking up the second package needed some precision, and it went incredibly well, on the first try! The present was very light and needed someone to hold it, to prevent it from moving when the Crazyflie approached.
Getting the sleigh off
Our first tries included 5 strings attached to the sleigh, but it was difficult to get the right tension at the right time to have the UAVs actually pull the weight. Here came the “rubber band solution”: we just attached all the strings to a rubber band, that was itself attached to the sleight. That way, the tension could get even when all the Crazyflies were in the air and ready to pull the sleight.
The rubber band
The AI deck camera/streamer
When we started this project, the intention was to run a neural network in the AI-deck to identify or classify the presents. We did not manage to get to a point where we had something that actually added value to the story, so we settled for just streaming the video from the AI-deck camera on the scouting drone instead.
The AI-deck example with color camera viewer is still under development, but if you want to give it a try you can take a look at the readme in the github repo.
Bloopers
And finally, as an added bonus, if you ever wonder how many tries it takes to make 5 Crazyflies pull a sleigh, here is a little behind-the-scenes video too!
I have returned from my family visit in California, who I’ve haven’t seen them in 3 years due to Covid. To spend the most possible time with them, the plan was that I would still work full time for Bitcraze from my father’s home. The problem became however, that it wouldn’t fit so well in our current way of work as I would miss all the morning stand up meetings due to the large time difference between Sweden and California (-9 hours). That is why we settled that I would work on separate projects/investigations during my time away. So I thought it would be a great opportunity to dig into ROS and 3D simulations again and see what the latest state of that is! So about the simulations is what I’ll be mostly talking about right in this blog post, in terms of what simulators are out there and what simulation development is currently ongoing.
Need for simulation?
Why would it be actually be necessary to have a simulation in our current frame work? Just to give an example, my new colleague Jonas recently tried out his hand on the CFlib swarm class for the first time for the BAMdays tutorials, and simulator would have been great during that initial porcess. Namely, most of the crashes were not necessary due to low batteries or bad communication, but mostly due to the fact that he was not able to double check his script beforehand. If one is able to check if all the programmed positions of the Crazyflies are implemented as they should before an actual flight, this would prevented a lot of broken propellers!
Just to note here that there are a lot of types of simulations that you can think of. Earlier this year had our ex-interns Max and Josephine finish an Renode simulation of the Crazyflie’s microcontrollers. We’ve also seen the word Simulink pop-up multiple times on the forum which indicates that quite some control classes are investigating the dynamic model of the Crazyflie. However, the type of simulation that I’m currently referring to are the 3D simulators in which a robot or quadcopter can move and interact with a virtual environment, with usually an physics engine in effect.
Crazyflie in Gazebo (+ROS)
During some initial investigation there were already some simulations that pop out. First of all I went and looked into what is available for Gazebo at the moment, which is:
CrazyS is based on the RotorS simulation with some additional off-board crazyflie controllers for position control. I wasn’t able to build it for my Ubuntu 20.04 just yet myself, but that there is ongoing work to port CrazyS to ROS Noetic. For now on a virtual machine with ROS melodic it build just fine! Note my laptop did had to work quite hard when I wanted to simulate more than 1 Crazyflie, but the physics and plugins that were made for Gazebo is enabling many to do a lot for their research. Please check out the core papers about CrazyS!
Sim_cf is perhaps a little lesser known, but the project does stand out as it has some interesting features to it. It is for instance, possible to use the actual c-based firmware in software-in-the-loop (SITL) mode, which controls the simulated Crazyflie. It is even possible to use an actual crazyflie with an hardware-in-the-loop (HITL) simulation. Eventhough the project is not actively maintained anymore, I did manage to build it from source for ROS Noetic and Gazebo 11, although I was not able to fly more than 4 do to errors.
Other Simulators
Ofcourse Gazebo is not the only possibility out there. I also had a quick go at another simulator called Webots, which is quite an interesting option indeed as well. Currently there is only one quadcopter model available, so it only makes sense for it to also contain an Crazyflie! They do use their own robotic format, so probably the easiest process would be, is to convert an existing model for Gazebo/ROS into an format that Webots can understand.
So in the future, the current Gazebo in its form will disappear and will be only be part of Ignition. So that is why it made sense for me to start playing with an separate Crazyflie model and plugins for the Ignition frame work instead. Moreover, it seems that quite some elements and plugins based on the RotorS simulation for the original gazebo, are now fully integrated within the Ignition gazebo framework, which should make it more easier to make quadcopter models fly. Currently it’s still work in progress, so right now is only to be found on my personal github repository, but as soon as it becomes more fleshed out and stable, this will probably transferred to Bitcraze’s github repos and we will write a more elaborate blogpost about it. For now, I’ll try to work on it further as my Fun Friday project!
In the mean time, we have started a simulation discussion thread in the Crazyswarm2 repository, which is an ongoing port of Crazyswarm to ROS2. It would be the ideal situation if we would be able to use this simulator for both Crazyswarm and our native CFlib! But I’ve mostly have used Gazebo in the past, so if there are any other simulators that we should try out too, please join the discussion and let us know!
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 Crazyflie Bolt kit
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:
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:
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.
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.
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!
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!
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.
4 segments (2xGND and 2x5V)
Two circles, one GND and 5V
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:
Updated charge pad design
Crazyflie on 3D printed charging pad
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.
Crazyflie on circular charge pad
Charge pads and decks
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.
2 versions of diffuse lens (3D printed)
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!
