Crazyflie Brushless charging pad

2024-09-23 | Marcus | 1 Comment

Ever since we started going to fairs to show off the Crazyflies, we’ve been trying to push the boundaries for the demos. Often we’ve used the fairs as an opportunity to either develop new functionality or try out new ideas. Something we’ve always been interested in, especially for fairs, is autonomous flights. It’s hard to talk to people about the Crazyflie while trying to fly it at the same time. Back in 2015 we were using the Kinect for piloting the Crazyflie at the Bay Area Maker Faire. Although awesome, we had a slight issue: we needed to switch batteries on the Crazyflie each flight. We had a Qi deck for wireless charging but no positioning system good enough to use it for landing on a charger.

Latest iteration of the Crazyflie Brushless charger

In 2018 we were really excited when we got to borrow a motion capture system from Qualisys and could finally land on a Qi charger (3D printed base and an IKEA Qi charger). First time we showed this off was at IROS in Madrid 2018. The following year we improved the demo to have more Crazyflies and switched to the Lighthouse positioning system at ICRA 2019. Since then each year we have been improving the demo until we’ve reached the current state we showed off at IROS 2022 in Kyoto.

So since 2018 we’ve been using the Qi wireless charging for our demos. Many customers have purchased the Qi charging deck, but building a matching charging platform has always required some effort. So, a while back we started looking at something that could replace the Qi deck, with a lighter solution which would also allow users to have other decks with electronics facing downwards. The first prototypes were made with the Crazyflie 2.1 back in 2021 using decks, but they were a bit clumsy. For one thing you needed the charging solution to be integrated on each deck.

When work started on the Crazyflie Brushless we realized we had the possibility to integrate the charge points directly on the main PCB which meant we could still use any decks we wanted and get the charging. So the prototypes from 2021 were reshaped into something we could use with the Crazyflie Brushless. Although the prototypes worked well, they were pretty big and packed with features which weren’t needed for charging (like LED lights and WiFi). Another iteration and the chargers have now gone down in size and complexity. The latest iteration only has charging and is powered via our 12V power block or 5V USB-C.

Over the years lots of customers have asked us for buying the Qi charger, since many users do not have the capabilities to build their own. Unfortunately we’ve never gotten around to it, but with the release of the Crazyflie Brushless we would like to change this. The release is only a few months away so we’re short on time for remaking the design so it’s usable for plastic molding. Instead the plan is to make a limited amount of prototypes available to our users, based on the same 3D printed design and electronics we’re currently using in our flight lab, at the time of release. This will enable our users to easily try out the design and create their own autonomous demos which will keep flying for a long time.

Fun Friday project: Crazyflie command-line client

2024-09-16 | Marcus | 1 Comment

As you might expect, we use the Crazyflie python client a lot at Bitcraze. The client has a lot of features, ranging from setting up LPS/Lighthouse systems to turning on/off the headlight LEDs on the LED-ring deck. But some of the features we use the most is probably the console view as well as the logging/parameter subsystems. A lot of the time we modify firmware, flash it and want to tweak (via parameters) or to check if the changes are working as expected (via the console or logging). Then switching from the terminal, where we build/flash, to the Qt UI in the Crazyflie python client can be a hassle if you just want to do something quick. It would be great to be able to log/set variables directly from the terminal, well now you can!

Meet the Crazyflie command-line client, a fun Friday project I worked on a while back. The CLI is written in Rust and was made possible thanks to a previous fun Friday project by Arnaud on the Rust Crazyflie link/lib, which has now moved to the official Bitcraze repositories. The CLI project is still very limited, but has some basic functionality:

Scan for Crazyflies and pre-select one to interact with
List loggable variables, create log configurations and print their value
List parameters and get/set them
Show the Crazyflie console

Last week the first version, v0.1.0, was released on crates.io. So if you have Rust set up on your computer and want to test it out then all you need to do is to type “cargo install cfcli“. The CLI still only has some basic functionality, but hopefully it can be expanded in the future with more useful things! Feel free to leave any issues or comments you might have on the Github page.

Prototype of forward facing expansion connector

2024-04-29 | Marcus | 2 Comments

A great feature of the Crazyflie is its ability to keep evolving, both by using software but also through hardware expansions. Hardware expansions allow us and our users to keep exploring new problems and doing new experiments, without having to change the flying base. Over the years lots of new decks have been released and we’ve seen lots of users building their own custom electronics and attaching it to their Crazyflies. Although very versatile, the current deck system is limited to up/downwards facing expansions. Adding electronics that face forward, like a camera, has been harder and has required additional mechanics. Over the last couple of months we’ve been experimenting with a new expansion connector aiming at solving this issue. The idea is to be able to add a new class of expansions facing forward. This week’s blog post and next week’s developer meeting are about these experiments.

Goals and design

We’re always trying to find ways to make our platform more versatile, making it easier to expand and to be used in new ways. So we’ve been looking for a new way to be able to expand the platform even more, this time with electronics facing forward instead of up/down. The goal is to easily be able to add things such as cameras, ranging sensors etc. Making a custom deck with custom mechanics for each sensor hasn’t been a good solution, it takes lots of time and it doesn’t enable our users to do their own custom electronics. Finding a generic solution is hard since we’re constrained both in space and in weight. We need a solution which is very small and light, each gram adding cuts into the flight time. The solution also needs a way to handle the data generated from cameras/sensors as well as possibly to stream it over a faster connection than the Crazyradio.

Our current prototype is made of two parts, a new deck with WiFi and more computational power as well as several smaller expansions which can be added to it. The expansions fit straight into a small right angle connector, making it easy to change boards. The current connector we’re testing has 30 positions, of which 6 is used for power and 1 for 1-wire, leaving 24 pins for signaling. The 1-wire works the same way as our current decks, additional added hardware is auto-detected at startup and can be used without recompiling or reconfiguration.

The current prototype uses an ESP32-S3 and weighs in at 3.7 grams. Added to this there are a number of expansions that we’re evaluating:

OV2640 + VL53L5CX: RGB camera and ranging sensor (1.6 grams)
Flir Lepton 3.5: Thermal camera (2.1 grams)
MLX90640: Thermal camera (2.0 grams)

So the current prototype with RGB camera (and ranging sensor) weights in at a total of 5.3 grams (0.9 grams more than the AI deck).

Current status and continuation

We’re currently experimenting with connectors, modules and dimensions. In the coming months we will try to get more flight time to test the solution and we’re hoping to get some feedback from our users. So please post any comments and/or suggestions you might have.

If you’re interested in knowing more and discussing this then join our developer meeting next week on Wednesday. We will also be showing off the prototypes at ICRA, so make sure to swing by the booth if you’re attending.

Contact charging for Crazyflie brushless

2024-02-05 | Marcus | Leave a comment

If you haven’t seen it yet then check out our latest Christmas video! In it, we show off a bunch of new stuff, with the main ones being the new Crazyflie brushless and the Lighthouse V2 (which supports up to 16 base stations). But there were also a few other things featured in the video! One of them is the charging pad the Crazyflie brushless takes off from and lands on in the video. This weeks blog post is about the charger, how it came to be, how it works and what lies ahead.

Picture of the Crazyflie brushless on the charging pad

Some history

A while back I worked a bit on a contact charger for the Crazyflie 2.1. The idea was to try and make a design where small pogo-pins could be added to various decks which would allow the Crazyflie 2.1 to charge when lading on a charging pad. Some of the issues with the design was that the area was small (it had to fit on a deck), it put requirements on each deck and that some decks (like the Flow V2 deck) has components which are taller than the pogo-pins. So after the blog post back in 2021 this has been on the shelf, until recently when the Crazyflie brushless work has been moving forward.

With the new prototype design for the Crazyflie brushless being made, there was a chance to address some of the issues I’ve seen before and do another try. All we needed was to add some pads for soldering pogo-pins on the wings (which actually wasn’t as easy as one would think due to layout constraints). So now the charging points didn’t have to be on each deck, they are built into the Crazyflie BL base. The distance between the points is also larger, allowing for a bigger hole in the charging PCB and allowing for a higher variety of decks, like the LED ring with the diffuser shown in the video.

The last missing part of the puzzle was when we needed to do more flight testing with the Crazyflie brushless. We wanted to reproduce the infinite flight demo we previously had for the Crazyflie 2.1, but the current Qi charger pad didn’t work with the new Crazyflie brushless. Time for the next iteration of the charger prototype!

Under the hood

So how complex can you make a charger? Lots! When making a prototype I like to add as much ideas possible to the design. Missing something you wanted to test and doing a new version takes a lot of time but adding some extra crazy ideas might be pretty quick in the design phase. A lot of the time ideas are scrapped along the way, most of the time because of space- or price constraints. Sometimes they are just bad or too complex. Luckily in this case the charger has a large PCB with lots of space and it’s just an early prototype so there’s (almost) no bad ideas!

Under the hood (or 3D printed plastic in this case) there’s a bunch of stuff:

An WiFi/BLE module, the ESP32-C6-MINI
USB-C connector
USB-PD controller
6 DC-jack connectors and 5 terminals for connecting power
Measurement of charging current and supply voltage
12 WS2812B RGB LEDs for the outer ring and 12 for the inner one
20-to-5V DC/DC and 5-to-3V3 DC/DC
Some debugging LEDs and UART

Intended use

The idea with the contact charger has been to easily charge your Crazyflie without disconnecting the battery, plugging in the micro-USB connector or blocking the use of decks facing downwards like the Qi charger does. In addition to this I also wanted to try out some other ideas.

Chaining chargers: When we go to fairs we normally show a demo of 9 x Crazyflie 2.1 flying with decentralized decision making and the lighthouse positioning system. As you can see there’s a lot of power cords and charging pads laying around. The idea here was to chain the power supplies together and also attach the chargers to each other (hence the hexagonal shape).

WiFi: For a long time I’ve had a prototype of a server for connecting various hardware to (like a charger) so I wanted to try to connect it to this for monitoring.

BLE: The idea was that the Crazyflie could talk to the charger via BLE to for instance change the light effect.

LEDs (and lots of them): The idea was to give some feedback from the charging of the Crazyflie but also to give the charger the ability to act as something more, like lighting up when a Crazyflie decides to land on it.

USB-PD: This is connected to the chaining of power. The ideas was to connect a USB-C charger and distribute the power from it to other chargers via the DC-jack.

Rust: Like we’ve written about before, we’ve been trying out more and more Rust here at Bitcraze. This is yet another experiment, the firmware for the charger is written in Rust using Embassy.

Future

Currently the charger is an internal project, since we use it in our lab for the infinite flight. But it’s of course something that would be exciting to offer our users if there any interest. So let us know what you think!

Also, don’t forget to join us for this Wednesday’s dev meeting. the main topic will be about the Kalman filters however we can answer questions about the wireless as well!

Discussion – How to handle the increasing complexity of the expansion decks

2023-10-02 | Marcus | Leave a comment

For this months developer meeting we will be discussing the increasing complexity of the deck subsystem, talking about the challenges we see moving forward as well as discussing some possible solutions. In the blog post this week I’ll be discussing the first part, some of the challenges moving forward.

After releasing the Crazyflie Nano Quadcopter back in 2013 we realized we wanted something more than the small expansion connector we placed there. Sure, it was possible to attach more electronics (and we did) but mechanically, electrically, and software-wise it was a hassle. So when we got around to working on the Crazyflie 2.0 in 2014 we were really happy with the new expansion connector. The goal was to offer users new hardware solutions as they became available as well as giving the possibility to create customized hardware configurations. It supported multiple buses, different heights for the decks, top and bottom attachment, automatic detection, and last, but not least, it held the battery in place. Initially, we released a few decks, but over the years there have been many more. Some are very simple, like the breakout, and some are very complex, like the AI deck.

Although we’re still very happy with the deck subsystem, we’re starting to see some challenges moving forward as deck complexity increases. Some of these issues are:

Resource sharing in the STM32: Mainly DMA conflicts between different peripherals, like conflict for DMA using DSHOT on the Crazyflie Bolt and the WS2812b driver for the LED-ring.
Bus arbitration and performance: Some decks make excessive use of some buses, which can cause issues with certain combinations like the LPS deck and micro-SD card deck.
Deck combinations and pins: As more interesting decks are released and we’re able to carry more weight, users want to combine more decks. Although we try to be smart with pin allocation there’s a limit on how you can combine the decks.
MCUs on decks: With increased complexity also comes separate MCUs on decks. Although working well for offloading the main MCUs on the Crazyflie, the complexity quickly increases both for usage and for development. This is something we’ve seen with the AI deck for instance, which contains 2 MCUs.

The challenges above are something we discuss from time to time around the office, often ending up at a whiteboard pitching various ideas. The most popular solution (and therefore the most likely one becomes reality) is moving complexity off the Crazyflie and onto MCUs placed on the various decks. This would probably solve most of the challenges with the first three points, but obviously worsen the last point above.

So the question quickly becomes, how do we work with multiple decks with one (or more) MCUs without the situation becoming too complex? Something often heard in embedded is that for each MCU added the complexity grows exponentially. From experience, we can say that this isn’t so far off.

With the new Crazyradio 2.0 out, discussions on new protocols, the possibility of a library rewrite, new deck prototypes and more payload capabilities, it’s becoming more clear how this would fit in. We still haven’t decided on what solutions we’re using, but we do have a bunch of ideas that we think would fit together to meet these challenges moving forward. On Wednesday I’ll continue to discuss some of these challenges in our monthly developer meeting and also discuss some of the suggested solutions. We’re also more than happy to hear comments about this from our users. If you’re interested in joining the discussion you will find the link here. We hope to see you there!

New release: 2022.09

2022-09-19 | Marcus | 1 Comment

A new release of the Crazyflie firmware, client and library is out! There’s lots of new stuff included, below is a summary of the largest changes:

Full support for two more more Lighthouse base stations including a wizard for setting it up (blog post)
Added PID tuning for Bolt to the Client (blog post)
Many tabs in the Python client can now be used as toolboxes instead, which enables you to view multiple tabs at once
The Qualisys example scripts has been fixed
CPX improvements, including bug fixing and initial implementation of CRTP over WiFi (blog post)
Syslink over UART2 replaced with CRTP over CPX on UART2 (PR)
TDoA3 long range (documentation)
Token ring protocol for P2P (blog post) (documentation)
Bolt DSHOT support for ESCs configurable via Kconfig
ESC pass-though configuration via USB (virtual COM port)

For more information (and files for the release) see the release notes and files on GitHub, the releases of the different projects are listed below. As always, we’re really eager to get feedback, so let us know if you try it out and how it works!

Using the AI deck for CRTP over WiFi (via CPX)

2022-09-05 | Marcus | 7 Comments

Before the summer vacations, I had the opportunity to spend some time working on AI deck improvements (blog post). One of the goals I set was to get CRTP over WiFi working, and try to fix issues along the way. The idea was to put together a small example where you could fly the Crazyflie using the keyboard and see the streamed image along the way. This would require both CRTP to the Crazyflie (logging and commands) as well as CPX to the GAP8 for the images. Just before heading off to vacation I managed to get the demo working, this post is about the results and som of the things that changed.

Link drivers

When using the Crazyflie Python library you connect to a Crazyflie using a URI. The first part of the URI (i.e radio or usb) selects what link driver to use for the connection. For example radio://0/80/2M/E7E7E7E7E7 selects the radio link driver, USB dongle 0 and communication at 2Mbit on channel E7E7E7E7E7.

While working on this demo there were two major things changed in the link drivers. The first one was the implementation of the serial link (serial://) which is now using CPX for CRTP to the Crazyflie. The usecase for this link driver is to connect a Raspberry Pi via a serial port to the Crazyflie on a larger platform.

The second change was to add a new link driver for connecting to the Crazyflie via TCP. Using this link driver it’s possible to connect to the Crazyflie via the network. It’s also possible to get the underlying protocol, the CPX object, for using CPX directly. This is used for communicating with for example the GAP8 to get images.

In the new TCP link driver the URI starts with tcp:// and has either an IP or a host name, followed by the port. Here’s two examples:

tcp://aideck-AABBCCDD.local:5000
tcp://196.168.0.100:5000

Comparison with the Crazyradio PA

So can WiFi be used now instead of the Crazyradio PA? Well, it depends. Using WiFi will give you larger throughput but you will trade this for latency. In our tests the latency is both larger and very random. In the demo I fly with the Flow V2 deck, which means latency isn’t that much of an issue. But if you were to fly without positioning and just use a joystick, this would not work out.

The Demo!

Below is a video of some flying at our office, to try it out yourself have a look at the example code here. Although the demo was mostly intended for improving CPX, we’ve made use of it at the office to collect training data for the AI deck.

The Crazyflie with AIdeck during over WiFI controlled flight.

Improvements

Unfortunately I was a bit short on time and the changes for mDNS discovery never made it it. Because of this there’s no way to “scan” or discover AI decks, so to connect you will need to know the IP or the host name. For now you can retrieve that by connecting to your AI-deck equipped Crazyflie with the CFclient and look at the console tab.

A part from that there’s more improvements to be made, with a better structure for using CPX (more like the CRTP stack with functions) in the library and more examples. There’s also still a few bugs to iron out, for example there’s still the improved FPS and WiFi throughput issues.

IMAV 2022

Next week from 13th to 16th of September Barbara, Kristoffer and Kimberly will be present at the international Micro Aerial Vehicle Conference and Competition (IMAV) hosted by the MAVlab of the TU Delft in the Netherlands. One of the competitions is called the nano quadcopter challenge, where teams will program a Crazyflie + AI deck combo to navigate through an obstacle field, so we are excited to see what solutions will come out of that. If any of you happens to be at the conference/competition, drop by our table to say hello!

Working on CPX: Current status and future

2022-06-27 | Marcus | 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.

AI-deck improved infrastructure

2022-03-07 | Marcus | 2 Comments

During the last couple of months we’ve been working on getting the AI-deck out of early-access. One of the things needed for this to happen is an improved infrastructure for the AI-deck, like bootloading and how the deck fits into the rest of the eco-system. For this there’s two new repositories:

CPX (Crazyflie Packet eXchange)

With the addition of two new MCUs (ESP32 and GAP8) as well as the possibility to connect via the WiFi, we quickly run into the issue of how to communicate between the targets. Even more so since there’s no direct access between some of these (like the Crazyflie<->WiFi, Crazyflie<->GAP8, GAP8<->WiFi).

What 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

We decided to design and implement a new protocol, which we’ve named CPX (Crazyflie Packet eXchange). The protocol solves the issues above by:

Each packet has a source and destination ID, so it can be routed to (and from) the target of the packet
Each link between targets can have it’s own MTU, which allows each target to optimize memory usage. In order to handle this, intermediaries are allowed to split packages along the way, so data can be transferred in smaller pieces.
Instead of dropping packages if targets become overloaded, congestion in created in the system, where the sender will not be able to send more data until the receiver has been able to handle it.

Currently the new protocol is used for the GAP8 bootloader, for setting up the WiFi on the ESP32 and in the WiFi streamer example. But we’re hoping to expand it in the future to include more functionality, like logging and other plumbing that could be used in user applications.

WiFi configuration changes

With CPX it’s now possible to set up the WiFi from either the Crazyflie, the GAP8 or from the ESP32 itself. For doing this from the Crazyflie we’ve added the option of configuring this using KConfig, where we’ve added the following options in the expansion decks menu for the AI-deck:

Do not set-up the WiFi: Should be used if another target is setting up the WiFi, like the GAP8
Act as an access point: This will make it possible to connect to the AI-deck as an access point
Connect to an access point: This will connect the AI-deck to an access point using SSID/PASSWD entered in the menuconfig

GAP 8 bootloader

To make things easier for the user we want to remove the requirement of using a JTAG dongle to program the GAP8. In order to achieve this we’ve implemented a bootloader for the GAP8 which uses CPX, which means it can be used either from the Crazyflie or over the WiFi. We still haven’t had time to implement the Crazyflie part, where this will fit nicely together with the cload and client deck firmware upgrade, but it’s currently working via the WiFi. So until the implementation is done via the Crazyflie Python library, this script can be used to bootload and start your custom GAP8 firmware. Note though, that you will first have to flash the GAP8 bootloader and set-up the WiFi.

What’s next?

We’re continuing working towards getting the AI-deck out of early access. For CPX and the GAP8 bootloader there’s still a few bugs to iron out and examples to be updated as well as improved support for building using our toolbelt.

Fun Friday charging and lights

2021-11-15 | Marcus | Leave a comment

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

Contact charger and decks

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

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

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

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

Deck for segmented charger (with diode bridge on back)

Deck for circular charger (without diode bridge)

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

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

The Glow deck

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

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

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

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

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

Conclusions

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

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