Improved app API

2020-11-02 | Kristoffer Richardsson | Leave a comment

As mentioned in this blog post, we added the possibility to write apps for the Crazyflie firmware a while ago. Now we have added more functions in the Firmware to make it possible to use apps for an even wider range of tasks.

The overall idea of the app API is to mirror the functionality of the python lib. This will enable a user to prototype an application in python with quick iterations, when everything is working the app can easily be ported to C to run in the Crazyflie instead. The functions in the firmware are not identical to the python flavour but we have tried to keep them as close as possible to make the translation simple.

An app is also a much better way to contain custom functionality as the underlying firmware can be updated without merging any code. The intention is that the api API will be stable over time and apps that work one version of the firmware also should work with the next version.

Improvements

We used our demo from IROS and ICRA (among others) with a fairly autonomous swarm as a driver for the development. The demo used to be implemented in a branch of the firmware with various modifications of the code base to make it possible to do what we wanted. The goal of the exercise was to convert the demo into an app and add the required API to the firmware to enable the app to do its thing. The new app is available here.

The main areas where we have extended the API are:

Log and parameters framework

The log framework is the preferred way for an app to read data from the firmware and this has been working from the start. Similarly the parameter framework is the way to set parameters. Even though this has worked, it broke a basic assumption in the setup with the client, that only the client can change a parameter. Changing a parameter from an app could lead to that the client and Crazyflie had different views of the state in the Crazyflie, but this has now been fixed and the client is updated when needed.

High level commander

The high level commander was not accessible from an app earlier and the functions in the python lib have been added to make it easy to handle autonomous flight.

Custom LED sequences

It is now possible to register custom LED sequences to control the four LEDs on the Crazyflie to signal events or state.

Lighthouse functionality

Functions for setting base station geometry data as well as calibration data have been added. These functions are also very useful for those who are using the lighthouse system as it now can be done from an app instead of modifying lighthouse_position_est.c.

Remaining work

We have taken a step forward with these changes but there is more to be done! The two main areas are support for custom CRTP packets and memory mapping through the memory sub system. There might be more, let us know if there is something you are missing. The work will continue and there might even be some documentation at some point :-)

Tutorial

One reason for doing this API work now was to prepare for the tutorial about the lighthouse 2 positioning system, swarm autonomy and the demo app that we will run this Wednesday on-line, don’t miss out! You can read more about the event here.

Behind the scenes: Our tool for handling production, sales and logistics

2020-10-26 | Marcus | Leave a comment

Back in 2014 a friend of ours dropped by our office to chat a bit about how things were going for Bitcraze. During the conversation we got a few questions that we should have been able to answer, but we couldn’t. Things like “How many Crazyflies have you sold?” and “To which countries do you mostly sell?”. We realized that we need some way of keeping track of things like this. Since I was mostly handling economics and admin, and also like developing things, this became the start of our internal “do a bit of everything” system.

At this point in time we were only selling our products though Seeedstudio, so the system was mostly used to keep track of the stock levels there. But as things at Bitcraze started to change, so did the system. Later that year our Crazyflie 2.0 was heading into production and we wanted a better way to keep track of production, so we modified the production scripts to upload the production test results to our servers. Now we had production stats and could trace returns from the field trough production using serial numbers.

Fast forward to 2016 and we’ve decided to start selling our products in our own E-store. We found a 3PL partner in Hong Kong to do our packaging and shipping. It was a big step for us and something we really liked since we got direct contact with our customers. But the amount of work quickly started to increase. Our main issue was that some customers were not keeping track of their shipments and the shipments would end up sitting in customs awaiting questions from the customers and would eventually be returned to us, and this was a big hassle. So the tracking of orders were added to our internal system, now it would keep track of the shipment progress and warn us if there were any issues.

Apart from the E-store we also had orders though our invoicing software. In order for us to get a unified picture of what was happening our internal system started to merge information from the different systems: our E-store, invoicing software and Seeedstudio.

At this point the system had grown so much that the architecture was a bit out of hand and we re-wrote the system from scratch to be able to handle more changing requirements. In hindsight was a good decision, since the next big change change was around the corner. In 2018 everything was running smoothly but our 3PL partner was suddenly moving the warehouse from Hong Kong to Shenzhen (blog post), something that was supposed to take a week and run smoothly. Unfortunately the move was everything else than smooth and after battling for months trying to get the operation back up again, we finally pulled the breaks and started to re-route newly produced units to our office in Sweden instead.

Now we had an office full of products and an E-store were things were being sold. But we didn’t have any solution for actually taking the orders and shipping them. At first we were booking everything manually, but as order counts increased this quickly became a problem. We looked at a few solutions but didn’t find anything that matched well for integrating all our systems. So our internal system once again got expanded to handle the warehouse part, print packing lists, book shipments and print labels (blog post).

As time passes (and more challenges pop up) we’ve been adding more and more functionality and have been able to quickly adapt to what’s been happening. While developing the system over the years, my overall goal has been to automate as much as possible of the admin/logistics in order to keep the workload the same even though sales increase. So far this has been successful!

Today we use this system for a wide range of administration, logistics and production tasks. Below is a list of some of the things it handles:

E-store and sales
- Live shipping quotes during checkout
- Requesting order quotes from the basket
- It handles all of the accounting from the E-store
- GMail plugin for easily accessing information
Logistics
- Warehouse functionality (stock, incoming products etc)
- Printing picking/packaging lists
- Warnings for shipments that are stuck or lost
- Booking and printing of shipping labels
Manufacturing
- Keep track of all tested units with all data from the tests
- Production planning and warning if things will run out of stock
Analytics
- Various harmonized business analytics from our different sales systems
- Harmonized data that is used for various analysis
Reminds us about various things like unpaid invoices

So have we made back the time we spent building the system? Probably not, but we will. There’s a lot of good solutions for similar systems out there, but the decision to make our own system came from not finding a solution where all our pieces fit. In order to minimize the work I’ve tried to use various external services to speed up development. In the end the list of systems that are used together is quite long:

Our production test software
Shopify (E-store SaaS)
Fortnox (Bookkeeping, invoicing and quoting SaaS)
Easypost (shipping API)
Riksbanken (for exchange rates)
Our printing station software for label/document printers
Slack for notifying us about various issues
Sendgrid for sending emails
Mondido (our payment gateway)
Google docs
Seeedstudio

Testing Crazyflie Bolt and 1 cell Li-Ion

2020-10-19 | Tobias | 17 Comments

Li-Ion batteries have packed more energy per gram for a long time compared to Li-Po batteries. The problem for UAV applications has been that Li-Ion can’t deliver enough current, something that is starting to change. Now there are cells that are supposed to be able to deliver 30-35A continuously in the 18650 series, at least according to the specs. Therefor we thought it was time to do some testing and decided to build a 1 cell Li-Ion drone using the Crazyflie Bolt as base.

Since a 18650 battery is 18mm in diameter and 65mm long, the size would affect the design but we still wanted to keep the drone small and lightweight. The battery is below 20mm wide which means we can run the deck connectors around it, that is nice. We chose to use our 3D printer to build the frame and use off the shelf ESCs, motors and props. After a couple of hours of research we selected 3″ propellers, 1202.5 11500kv motors and tiny 1-2s single ESCs for our first prototype.

Parts list:

1 x Custom designed 130mm 3D printed frame
1 x Crazyflie Bolt flight controller
4 x Eachine 3020 propeller (2xCW + 2xCCW)
4 x Flywoo ROBO RB 1202.5 11500 Kv motors
4 x Flash hobby 7A 1-2S ESC
1 x Li-Ion Sony 18650 VTC6 3000mAh 30A
Screws, anti vib. spacers, zipties, etc.

The custom designed frame was developed in iterations, and can still be much improved, but at this stage it is small, lightweight and rigid enough. We wanted the battery to be as central as possible while keeping it all compact.

Assembly and tuning

The 3D printed frame came out quite well and weighed in at 13g. After soldering the bolt connectors to the ESCs, attaching motors and props, adjusting battery cable and soldering a XT30 to the Li-Ion battery it all weighed ~103g and then the battery is 45g of these. It feels quite heavy compared to the Crazyflie 2.1 and we had a lot of respect when we test flew it the first time. Before we took off we reduced the pitch and roll PID gains to roughly half and luckily it flew without problems and quite nicely. Well it sounds a lot but that is kind of expected. After increasing the gains a bit we felt quite pleased with:

#define PID_ROLL_RATE_KP  70.0
#define PID_ROLL_RATE_KI  200.0
#define PID_ROLL_RATE_KD  2
#define PID_ROLL_RATE_INTEGRATION_LIMIT    33.3

#define PID_PITCH_RATE_KP  70.0
#define PID_PITCH_RATE_KI  200.0
#define PID_PITCH_RATE_KD  2
#define PID_PITCH_RATE_INTEGRATION_LIMIT   33.3

#define PID_ROLL_KP  7.0
#define PID_ROLL_KI  3.0
#define PID_ROLL_KD  0.0
#define PID_ROLL_INTEGRATION_LIMIT    20.0

#define PID_PITCH_KP  7.0
#define PID_PITCH_KI  3.0
#define PID_PITCH_KD  0.0
#define PID_PITCH_INTEGRATION_LIMIT   20.0

This would be good enough for what we really wanted to try, the endurance with a Li-Ion battery. A quick measurement of the current consumption at hover, 5.8A, we estimated up to ~30 min flight time on a 3000mAh Li-Ion battery, wow, but first a real test…

Hover test

For the hover test we used lighthouse 2 which is starting to work quite well. We had to change the weight and thrust constants in estimator_kalman.c for the autonomous flight to work:

#define CRAZYFLIE_WEIGHT_grams (100.0f)

//thrust is thrust mapped for 65536 &amp;lt;==> 250 GRAMS!
#define CONTROL_TO_ACC (GRAVITY_MAGNITUDE*250.0f/CRAZYFLIE_WEIGHT_grams/65536.0f)

After doing that and creating a hover script that hovers at 0.5m height and was set to land when the voltage reached 3.0V. We leaned back with excitement, behind a safety net, and started the script… after 19 min it landed… good but not what we hoped for and quite far from the calculated 30 min. Maybe Li-Ion isn’t that good when it needs to provide more current…? A quick internet search and we could find that Li-Ion can run all the way down to 2.5V, but we have to stop at 3.0V because of electronics and loosing thrust, so we are missing quite a bit of energy… Further investigations are needed.

Lighthouse 2 flight test

As a final test we launched some flight scripts to fly in a square and in a spiral so we would get a feel for Lighthouse 2 + Bolt with PID controller combination. We think it turned out quite nicely, and this with almost no optimization effort:

Summary

Li-Ion felt like it could be a game changer when it comes to flight time but was not as promising as we hoped for. It doesn’t mean we can’t get there though. More research and development is required.

Bitcraze is going Online!

2020-10-05 | Kimberly McGuire | Leave a comment

During the summer we were discusses at the office of what would be a good substitute of us not being able to go to conferences or fairs anymore (see this blogpost). We sparred with a few ideas, ranging from organizing an online competition to an seminar. Although we initially were quite enthusiastic about organizing the competition, the user questionnaire from the previous blog-post showed us that many of you are rather interested in online tutorials. Based on that we actually started to make some more step-by-step guides, however we definitely would agree that is not the same as meeting each-other face-to-face!

So now we are planning to organize one for real this time! So our first online live tutorial will be on:

Wednesday 4th of November, 18:00 (CET, Malmö Sweden)

Register for the first session here to indicate your interest and to receive up-to-date information. There are of course no cost involved!

First topic: Spiraling Swarm Demo (Live!)

The last couple of years we have been showing our demo at many robotics conferences and fairs, such as ICRA, IMAV and IROS. Since we do not have a opportunity to do that anymore (at least for the foreseeable future), we thought that a suitable first topic of the online tutorial to be about the Spiraling Swarm demo! We will go through the different elements of the demo, which includes the implementation details on the Crazyflie and the Lighthouse Positioning system. We hope to explain all of in about 20-30 minutes and that this would enable you to set the demo up yourself if you want.

We have been thinking about just doing a prerecorded tutorial, however we also really like to talk with our users about their needs and research topics. That is why we think it is important to do it live where we can answer your questions on the go or after the tutorial. This also means that we will be demonstrating the demo live as well! Afterwards we will have a social interaction where we have a friendly chat :)

Mozilla Hubs and Discord

There are so many options on how to exactly host this event, as there are a gazillion alternatives for video conferencing. Currently we have are looking at Mozilla hubs. which fits nicely with our interests in the lighthouse positioning system with the HTC Vive basestations. The nice thing aspect of Hubs is that you don’t need a fancy headset to join, since it is possible to join via your browser or your phone. Me (Kimberly) has joined a Virtual Reality seminar at the beginning of the pandemic, organized by Roland Meertens of pinchofintelligence.com, and it was definitely a very interesting and fun experience. When giving a presentation, it really felt like people were paying attention and were engaged. So, we recently recreated our own flight-lab in VR (using Hub’s environment creator Spoke) and tested it out ourselves. This way you will be able to see our workplace as well!

Of course, we can imagine not everybody is waiting to go full VR. That is why we will combine the online tutorial with Discord, where we will make a video channel where we will stream the live demo and tutorial. It will also be possible to send messages that are visible in both the VR space and the Discord chat channel with Hub’s discord bot. You can choose where to follow the tutorial — fully in VR, or first discord and afterwards socialize in VR — that is totally up to you.

We still need to figure out the specifics, but if you register with your email we will send all the necessary information for the first session to you directly.

IOT conference Malmö

Now something else: tomorrow, namely Tuesday the 5th of October, we will also present at the IOT conference 2020 in Malmö. It is free for participants and it is still possible to register! Come and join if you can not wait to see us until the 4th of November.

New Compilation Video

2020-09-21 | Kristoffer Richardsson | Leave a comment

It has almost been 2.5 years since we last made a compilation video about what has been done with the crazyflie 2.0 (see this blogpost). During this time we released several new products and many of you were able to achieve very cool and awesome applications so we thought it was time for a new research compilation video!

We have seen quite a lot of projects with swarms of Crazyflies, ranging from close proximity flight to autonomous exploration in a building. Some research groups have also been experimenting with controlling the Crazyflie with our own hands, either to control its position or to reach another state of mind entirely. Others have created their own deck in order to add their own sensors or cameras necessary for their application. One of those even led to the new AI-deck that we introduced in early release before the summer! Last but not least: we were shown that the low level control can be further improved and multiple crazyflies can be linked together and still fly!

We were overwhelmed by all the awesome things that the community showed us of what possible with the Crazyflie and this will inspire others to think of new things to do as well. We hope that we can continue with helping you to make your ideas fly, so that we are soon to be forced to make another completion video ;)

Here is a list of all the research that has been included in the movie:

Close proximity flight of sixteen quadrotor drones, CalTech: B. Rivière, W. Hoenig, Y. Yue, and S.-J. Chung (video, paper)
Pointing gestures, IDSIA: B. Gromov, J, Guzzi, L. M. Gambardella, A. Giusti (video, project)
Yaw actuation, Modlab UPenn: B. Gabrich G. LiM. Yim (video, paper)
Learning to seek, Harvard University: B. P. Duisterhof , S. Krishnan, J. J. Cruz, C. R. Banbury, W. Fu, A. Faust, G. C. H. E. de Croon, V. Janapa Reddi (video, paper)
Drone Chi, Exertion Labs and RMIT: J. La Delfa, M. Baytas, E. Luke, B. Koder, F. Mueller (video, project)
Generalization through simulation, Berkeley AI Research (BAIR): K. Kang, S. Belkhale, G. Kahn, P. Abbeel, S. Levine (video, paper)
Swarm exploration, TU Delft: K.N. McGuire, C. De Wagter, K. Tuyls, H. Kappen, G.C.H.E. de Croon (video, paper)
PULP-based autonomous drone, ETH Zürich: D. Palossi, F. Conti, and L. Benini (video, paper)
Networked Autonomous Aerial Vehicles, University of Klagenfurt, Austria: Research by Karl Popper Kolleg (video)
GLAS for Multi-Robot Motion Planning with End-to-End Learning, CalTech: B. Rivière, W. Hoenig, Y. Yue, and S.-J. Chung (video, paper)
Resilience by reconfiguration, USC: R. K. Ramachandran, J. A. Preiss, G. S. Sukhatme (video, paper)

New firmware release

2020-09-07 | Kristoffer Richardsson | Leave a comment

We are happy to annouce that we have released a new version of the Crazyflie firmware, version 2020.09. It is available for download from Github.

The new firmware solves an old compatibility issue when using the LPS and Flow deck at the same time and also improves stability. A list of all the issues that have been fixed can be found on the release page.

For users that have a LPS system, we have also made some improvements to the LPS node firmware and are releasing version 2020.09.

If you are building the Crazyflie or LPS firmware from source, remember to update the libdw1000 git submodule using

git submodule update

We are working on a release of the python client as well, but still have a few issues to fix so stay tuned.

Working at Bitcraze

2020-08-31 | Barbara | Leave a comment

It’s been more than 6 months now that I’ve joined Bitcraze and we are currently looking for more passionate people to join our team. So what is it like to work at Bitcraze? Here is my story.

First weeks

My first day of work was actually during one of our quarterly meetings, which means it was during a conference, in a good hotel with a nice spa and dinner, well needed after many hours of retrospective, brainstorming and planning. It was the perfect way to enter the Bitcraze world, and get to know my colleagues: it included serious talks, but also massages and board games. Did I get used to the good life? Well, I discovered that it was not all champagnes and jaccuzi: my first actual day at the office, I cut my finger pretty badly, spreading blood all over the kitchen. That’s fine, now everyone knows I’m not to be trusted with a knife! And I have a nice “Bitcraze” scar to show.

The on boarding itself included some education from our process guru, Kristoffer. I was excited and very curious to discover how a self-organizing company functioned, and I learned a lot during those sessions. I discovered a new way of working. It got some getting used to, but I got to really analyze and question my working habits and reflexes, which is always healthy. I am now an adept of lean and agile processes, and love being involved in the innerworking of the company and its processes.

Daily habits

As the days went along, I took my marks. I am everyday happy to get up and go to work. I especially love Mondays, that usually involve a nice morning chat, sitting on the sofa, discussing how the weekend was or the latest Netflix documentary, before beginning our weekly meeting. I discovered that Bitcraze is all about habits and routines, that I sometimes had to adapt to my non-geeky role. Tuesday for examples is usually dedicated to coding and programming: for me, it meant that’s the day I dig into the accounting!

We also have a tradition of “fun friday” that I really enjoy. The concept is simple: Fridays are dedicated to something that we love and have fun with. It allowed me to play around with my Crazyflie and its various decks, but also to work on my photographic skills or think about a more dedicated marketing strategy. It helps that usually, Fridays end with a nice chat around a beer and some VR games.

I love that I’ve got an independence to decide how my day is going to look like. My daily tasks include a lot of different things and areas. It’s a real luxury to me to be able to choose what I feel like tackling at any point. If I don’t feel like crunching numbers, I can deal with the shipments. Maybe today I’ll order those office supplies we need, or look into our social media statistics. When I first got recruited, the word “passion” came back a lot, and it didn’t disappoint: everything we do is driven by passion. I get to do and learn a lot of different things, and rarely get bored.

Global pandemic

Unfortunately, just as I begun to be comfortable on my new everyday routine, the world was hit by a global pandemic. Our habits were completely changed as we closed the door on the office and worked from home for 3 months.

I am actually really proud of how we handled it. Sure, the process and work flow changed drastically, but we kept on going, having faith in each other and in our capability in handling it. We kept the communication channels open, and produced the AI deck while working remotely.

For me, those times were though. I still needed the everyday guidance of my colleagues, which is trickier when they’re not sitting next to you. But it also gave me the opportunity to do more by myself, which ultimately led to learn things a lot quicker, I think. The hardest, though, was when everybody got to get back to the office, and I couldn’t: I belong in a risk group for Covid. I miss the fika with my colleagues, and working remotely seem pretty lonely.

Working as a non-tech

The trickiest part for everyone when I joined Bitcraze was to fit in the more technical aspects of the company. I only have a little programming and tech background, so including me in the geek discussions without using too much jargon was not easy for the guys. I learned a lot, in a short time. I still bug them with my questions and have a long list of terms and concepts I need to read about. But that’s ok, because my “cluelessness” actually provided good insights on the work we still have to do on documentation. And the work to understanding each other better actually flowed both ways: I had also sometimes to include my colleagues in more administrative aspects that they don’t know, or don’t care about. It’s interesting to try to adapt the Bitcraze process just because I’m here: it’s not only about developing tech anymore, we have to think about a way to involve administrative tasks to our methods.

All in all, working at Bitcraze is everything I thought it will be, and more: I love spending time with my colleagues. Each morning, I feel lucky to have joined a passionate and exciting company. I didn’t think I’ll be someone that happily turns her computer on a Sunday night to check what Monday will have to offer, but that’s what I end up doing most of the weeks.

That’s why my feelings today are mixed: I’m actually leaving the office to enjoy my generous Swedish maternity leave. Being pregnant and welcoming a new life is exciting, and I’m really happy to extend my family, but not working at Bitcraze will feel weird and I know I will miss it. Nevertheless, I know the guys will do fine without me, and I’ll be back in 2021 for more exciting news!

And if you’re interested in working at Bitcraze too, you’ll find more infos here !

Flow- and LPS-deck improvements in progress

2020-08-17 | Kimberly McGuire | 2 Comments

Now that we are all back from our summer holiday, we are back on what we were set on doing a while ago already: fixing issues and stabilizing code. In the last two weeks we have been focusing on fixing existing issues of the Flowdeck and LPS positioning system. It is still work in progress and even though we fixed some problems, we still have some way to go! At least we can give you an update of our work of the last few weeks.

Flow-deck Kalman Improvements

When we started working on the motion commander tutorials (see this blogpost), which are mostly based on flying with the flowdeck, we were also hit by the following error that probably many of you know: the Crazyflie flies over a low texture area, wobbles, flips and crashes. This won’t happen as long as you are flying of high texture areas (like a children’s play mat for instance), but the occasional situation that it is not, it should not crash like it does now. The expected behavior of the Crazyflie should be that it glides away until it flies over something with sufficient texture again (That is the behavior that you see if when you are flying manually with a controller, and you just let the controls go). So we decided to investigate this further.

First we thought that it might had something to do with the rotation compensation by the gyroscopes, which is part of the measurement model of the flowdeck, since maybe it was overcompensating or something like that. But if you remove that parts, it starts wobbling right away, even with high texture areas… so that was not it for sure… Even though we still think that it causes the actual wobbling itself (compensating flow that is not detected) but we still had to dig a bit deeper into the issue.

Eventually we did a couple of measurements. We let the Crazyflie fly over a low and high texture area while flying an 8 shape and log a couple of important values. These were the detected flow, the ground truth position, and a couple of quality measurements that the Pixart’s PMW3901 flow sensor provided themselves, namely the amount of features (motion.squal) and the automatic shutter time (motion.shutter). With the ground truth position we can transform that to the ground truth flow that the flowdeck is supposed to measure. With that we can see what the standard deviation of the measurement vs groundtruth flow is supposed to be, and see if we can find a relation the error’s STD and the quality values, which resulted in these couple of nice graphs:

Three major improvements were added to the code based on these results:

The standard deviation is the flow measurement is increased from 0.25 to 2.0 pixels, since this is actually a more accurate depiction of the measurement noise to be expected by the Kalman filter
An adaptive std based on the motion.shutter has been implemented (since there is a stronger correlation there than with motion.squal), which can activated putting the parameter motion.adaptive to True or 1. Its put by default on False or 0 since the heightened STD of the first improvement already increased the quality of flight significantly.
If the flow sensor indicates there is no motion detected (log motion.motion), it will now prevent to send any measurement value to the Kalman filter. Also it will adjust the difference in time (dt) between samples based on the last measurement received.

Now when the Crazyflie flies over low texture areas with the Flowdeck alone, it will not flip anymore but simply glide away! Check out this closed issue to know more about the exact implementation and it should be part of the next release.

The LPS and Flowdeck

Kalman filter conflicts

The previous fix of the flow deck also took care of this issue, which caused the Crazyflie to also flip in the LPS system if it does not detect any flow.. This happened because the Kalman filter trusted the Flow measurement much more than the UWB distance measurement in the previous firmware version, but not anymore! If the Flowdeck is out of range or can’t detect motion, the state estimation will trust the LPS system more. However, once the Flowdeck is detecting motion, it will help out with the accuracy of the positioning estimate.

Moreover, now it is possible to make the Crazyflie fly in and out of the LPS system area with the Flowdeck! however, be sure that it flies using velocity commands, since there are situations where the position estimate can skip:

1- LPS system is off 2- take off Crazyflie with only Flowdeck, 3 – turn on the LPS nodes
1- Take off in LPS, 2- fly out of LPS system’s reach for a while (position estimate will drift a bit) 3- Fly back into the LPS system with position estimation drift due to Flowdeck.

As long as your are flying with velocity commands, like with the assist modes with the controller in the CFclient, this should not be a problem.

Deck compatibility problems

The previous fixes only work with the LPS methods TDOA2 and TDOA3. Unfortunately, there is still some work to be done with the Deck incompatibility with the TWR method and the Flowdeck. The deck stops working quickly after the Crazyflie is turned on and this seems to be related to the SPI bus that is shared by the LPS deck and the flowdeck. Reading the flow sensor takes some time, which blocks the TWR algorithm for a while, making it miss an event. Since the TWR algorithm relies on a continues stream of events from the DWM1000 chip, it simply stops working if it does not … or at least that is our current theory …

Please check out this issue to follow the ongoing discussion. If you have maybe an idea of what is going on, drop a comment and see if we can work together to iron out this issue once and for all!

Python client improvements

2020-08-10 | Victor Krook | Leave a comment

Hello everyone, this is Victor and I’ve spent another internship here at Bitcraze. You can read my blogpost from last year here https://www.bitcraze.io/2019/08/summer-internship/. I have learned a lot since last year so it has been fun to put my skills to test!

This summer I have spent my time on improving the cf-client. I’ve fixed a few bugs but mostly it has been about making small changes that improves overall functionality.

Some of the improvements that I’ve worked on:

Flight-control tab: Added logging of x and y-axis and changed the columns to more suitable groups. Also improved UI for assist mode.
Flashing dialog: Added support to flash both of the MCUs individually as well as choosing which one to flash (previously you could only flash the stm32 or both). Created an automatic firmware-release-downloader, so that you don’t have to download the files manually.
Log-config: Added grouping of log-configurations, that allows you to group the configs into categories. Also added small functionalities like double-click to add, remove configs etc.
Added sort-support for all list/tables.
Removed traces from Crazyflie 1.0 and support for x-mode, since it is no longer supported by the client.
Removed traces from python 2.

I hope that the functionalities will help you and make your experience with the client better. If you have any tips for further improvements, you’re more than welcome to leave a comment or contribute yourself. This is my last week for this summer, but I hope to see you all again and until then, fly safe!

New Step-by-Step Guides

2020-08-03 | Kimberly McGuire | Leave a comment

As you probably already know we have been wondering how to best handle our documentation and how to provide information to new Crazyflie starters as easy as possible, as you can read in our blogpost of two weeks ago. In the mean time, we also had a chance to think about the results of a poll we had when we discussed about new ways on how to meet our users. We had about 30 responses, but it became clear that many of you are in the need of getting some more knowledge about working with the Crazyflie. The majority voted for online tutorials, and although it might be difficult to do those during the summer holidays, we already started to make step-by-step guides of various parts of the Crazyflie Eco-system.

Python Library Tutorials

Currently we have started with step-by-step tutorials of the CFLIB (the python library of the crazyflie). Usually we refer to the example pages of the CFLIB, however we feel that many users copy paste parts of these scripts for their own purposes, without understanding what is actually going on. Therefore, in order to move Crazyflie beginners to the starting developer phase, we have made these guides in order to teach exactly what is going on in each module, step-by-step.

These tutorials can be found in the python library documentation. The first tutorial focuses on connecting, logging and parameters, which guides you through the process of connecting the Crazyflie through a python script, starting up logging configurations in two ways (asynchronous and synchronous) and how to read and set parameters.

The second tutorial is about the motion commander and is a logical continuation of the first. A nice thing is that we also show how to build in some protection in your script as well. If the Flowdeck is not attached, you can check that and prevent the Crazyflie from taking off altogether if it does not detect the Flowdeck. This will be a life saver in your future endeavors, and trust me I know from experience ;). Afterwards it will go into how to take off – fly forward and go back to the initial position. The application of the end of the motion commander tutorial, is where we also use the logging functionality to get the actual estimated position of the Crazyflie. With this information, we show how to write an application that create a virtual bounding box where the Crazyflie can bounce around in (like the old windows screensaver).

The results of the motion commander step by step guide.

We are planning to finish this step-by-step guide by adding the multi-ranger to the mix, continuing on the bouncing ball example. After that we will probably start some tutorials on how to use the swarming functionality before moving on to the firmware or the client.

Work in Progress

The tutorials are still work in progress. So let us know on the forum, python library github repository or as a comment on this blogpost if you see anything wrong or if something is not very clear. This will improve the quality further so that other users can benefit as well. Also once the these step-by-step tutorials are finished we can start working on video based tutorials as well.

Remember, it is possible to contribute your own fixes (or tutorials) to our repositories if you want to. It’s an open source project after all ;)