Category: Random stuff

Home / Blog

Join the team at Bitcraze!

  2018-05-21  |     |    Leave a comment

 

Things are moving fast here at Bitcraze and we have lots of exciting things going on. So it’s time to grow the team and try to add one or two new team-members to increase the tempo and bring more awesome products to our customers. The normal case might be that you would post a job ad describing what kind of skill-set potential new members should have, but we would like to try something different. So today we added a jobs page describing a bit about how we work and what we do. Our goal is to give a picture of what it’s like to work at Bitcraze and try to find individuals who like what we do and how we work. If you would be interested in joining the team let us know on jobs@bitcraze.io who you are, what you like and how you think you could contribute.

New Front page!

  2018-05-14  |     |    Leave a comment

Returning visitors of our website might have noticed that we recently released a new and fresh design of our website’s front page.

The goal has been to make a front page that better reflects Bitcraze and what we do, so together with the updated design and new cool images (credit to USC) we have also added two new sections to the front page. First off we have extended the blog post section to show the three latest blog posts instead of just the latest one. Different users have different interests so by showing a bit wider range of blog topics the hope is that even more people will discover our blog and start following it. Our blog is a big part of how we communicate to the outer world so by adding a whole new section for the blog giving it more room on the front page feels exciting. 

The testimonials section is the second part that we have added to the new front page. Here we are finally taking the opportunity to show some of the amazing work our community members have been doing using our Crazyflie. Each testimonial consist of a guest blog post that people from our community have contributed. It is pretty cool to show how researchers around the world are basing their projects on our products. If it’s by adding wheels to the drone or making LED lit swarms we are always happy to promote and show how the community are using our Crazyflie.

Next step

Our website is under constant improvement and the grand master plan for the near future is to update the content and design of the different portals and clean up the website in general. If you have any suggestions on what kind of content you would like to see in the portals or otherwise please send us feedback. As I mentioned in the beginning of the blog post, the new beautiful open shutter swarming photos we use on the front page is contributed to us by the researchers at USC. If you have any cool photos of the Crazyflie we would be more than happy to use them.

 

 

 

 

Work on TDoA 3 started

  2018-05-07  |     |    1 Comment

First of all we are happy to announce that (almost) all products have been stocked in the new warehouse and are now shipping! The last orders that were on hold are on their way out and new orders placed in the store will now be shipped again within a few days.

We released the TDoA mode, a.k.a. swarm mode of the Loco Positioning System back in January. TDoA supports positioning of many Crazyflies simultaneously which makes it possible to fly a swarm of Crazyflies with the LPS system. The release in January was actually the second iteration of the TDoA implementation (the first iteration was never publicly released) and it is also known as TDoA 2.

TDoA 2 works well but there are a couple of snags that we would like to fix and we have now started the work on the next iteration, TDoA 3. 

Single point of failure

TDoA 2 is based on a fixed transmission schedule with time slots when each anchor transmits its ranging packet. All anchors listen to anchor 0 and use the reception of a packet from anchor 0 to figure out when to transmit. The problem with this solution is that if anchor 0 stops transmitting for some reason the full system will stop transmitting positioning information. This is clearly a property that would be nice to get rid of.

Limited number of anchors

The packets in the TDoA 2 protocol have 8 slots for anchor data that are implicitly addressed through the position in the packet. First slot is anchor 0, second slot anchor 1 and so on. This setup is easy to use but creates an upper limit of 8 anchors in the system.

The maximum radio reach of an anchor depends mainly on the transmitted power and the environment. This distance, in combination with a maximum of 8 anchors and that all anchors must be in range of anchor 0, sets an upper limit of the volume that an LPS system can cover, basically one large room. When we designed TDoA 2 we were happy to be able to support a swarm of Crazyflies and did not really bother too much about the covered volume. We get more and more questions about larger areas and more anchors though and it would be nice to have a positioning system that could be expanded.

The solution – maybe…

What we want to do in TDoA 3 is to transmit packets at random times and add functionality to handle the collisions and packet loss that will happen in a system like this. The idea is that the even if some data is lost, the receiving side will get enough packets to be able to calculate the distance to other anchors or a position as needed. By removing the time slots and synchronization to anchor 0, we get rid of the single point of failure. 

In the TDoA 3 protocol, we have added explicit ids to the anchor data, and thus removed the implicit addressing of anchors. We have 8 bits for anchor ids and the system will handle 256 anchors for sure. We do think that it will be possible to design larger systems though by reusing ids and making sure that the radio ranges of anchors with the same ids do not overlap.

The UWB radios have a nice property that makes this a bit easier to handle collisions than one might first think, if they receive two packets at the same time, they will most likely “pick” one of the packets and discard the other. The drawback is that it is likely that the receive time of the packet will be less accurate. We are not completely sure it will be possible to detect and handle the added noise in the time stamps but we have good hope!

The current state of the project

Last week we did a proof of concept hack when we modified the old TDoA 2 implementation to transmit at random times, as well as minor modifications to handle random receive order of packets. It all worked out beautifully and we could fly a short sequence in the office with the new mode. The estimated position was a bit more shaky which is not surprising, considering that the receive times are more noisy.

We have just started with the real deal.  We have designed a draft spec of the protocol and have also started to implement the new protocol on top of the old TDoA2 algorithms in the anchors and the Crazyflie to get started. Next steps will be to introduce random transmission times, dynamic anchor management and better error handling. The TDoA 3 implementation will exist in parallel with the current TDoA2 implementation and should not interfere.

If you want to contribute, are interested in what we do or have some input, please comment this blog post or contact us in any other way.

 

 

 

Warehouse issues and supply chain

  2018-04-30  |     |    5 Comments

Something we seldom write about on the blog is production and supply chain. It’s a big part of what we do, both in time and business wise. Even though we spend most of our time on firmware/software we’re actually only selling hardware. So this blog-post is about how we’ve set this up and the problems we’ve been facing the last month due to our 3rd party warehouse moving to a new location.

Photo by frank mckenna on Unsplash

The current set-up

Currently we’re using Seeedstudio for our manufacturing. They do varying batch sizes, but most of the batches we produce are between 300 and 2000 units. We’ve been experimenting a bit with varying size of batches, too large and you tie up too much funds in stock while with smaller batches you spend most of you’re time tending to manufacturing. Another issue with large batches are things like battery shelve life and changing market (i.e suddenly some parts are EOL or have been replaced when it’s time for the next batch).  Finding a good level for different products depending on production cost, complexity and shelf-life is tricky.

After production the goods are moved to a number of warehouses. Part of the goods are warehoused at Seeedstudio, part of them are sent to our 3rd party warehouse in Hong Kong serviced by Shipwire and a small amount is sent to our office for testing/development/customers. The products in Seeedstudio’s warehouses services a number of distributors though their wholesale channels as well as end-users though their Bazaar. We service our E-store though Shipwire in Hong Kong and a few customer though our Swedish office.

Scaling up

Since the end of last year we’ve seen an increase of sales, which we are of course really happy about! More sales will mean more resources for development which translates into more awesome products and features for everyone. The problem is that it takes time to scale up the supply chain on the back. Today we have have 27 SKUs and 7 bundle SKUs “virtually” made out of combining products into bundles. Out the 27 SKUs we control the manufacturing of 17 SKUs (like PCBs and plastic parts) and 5 SKUs are things we buy (like the USB-cable). Typically the lead time for simpler products is 1 month and more complex products 2 months, with an additional lead-time of at least a week to reach our Hong Kong warehouse and become available in the E-store. Creating bundles by “virtually” tying together a number of products is great since it gives us more flexibility but if one of the bundled SKUs is out of stock the bundle will also be our of stock.

Controlling this complex situation while scaling up for larger sales has proved challenging, also when everything works as expected (see below). Most of our customers have gotten their things in time, but we’ve had to put a lot of hours into juggling products around between warehouses to make it happen.

Warehouse issues

Back in February we were notified by Shipwire that they would be moving the operation to a new warehouse in Shenzhen/Hong Kong. The timeline that was communicated was that the inventory would be offline 3rd – 6th of April. This might seem optimistic for a warehouse that is  about 10 000 m2, but since they have a large amount of warehouses around the globe we assumed they would pull this off. Unfortunately this wasn’t the case, a number of factors played in to delay the move. Since the first week of delays the expected timeline has been “next week”, which unfortunately hasn’t held. Finally we’re at a point where our old inventory has been moved into the new warehouse and is available. The next problem we’re facing is getting our incoming goods into the inventory, which is currently expected to be finished by the end of this week. To say the least we’re unhappy about this situation, but unfortunately we have had very little control. We don’t have a large number of products available in any other warehouse so we haven’t been able to “switch over” to another solution. We’ve done our best to keep the effected customers updated on the situation and calling support every day to get an update.

Moving forward

We’re a small team of 5 people and we’ve always been most focused on product development. It’s what we like to do and it’s what we’re best at. So an easy way forward would be to pay someone else to handle all of the above. Unfortunately this has proven to be tricky for us. Basically handing over everything that generates revenue for our company to someone else is a huge risk, to say the least. So we’ve realized that this has to be a central part of what we do, just like development. This was the main reason for starting our own E-store last year and it’s something we’re continuously working on improving.

Moving forward the overall goal is to minimize the work spent on production and stock management while making sure to not run out of stock or tie up all our funds in stock. We think that one key to this is being proactive instead of reactive. So we have integrated this into our daily work just as much as development. Next to the “development” board with stories/tasks we have an even bigger kanban board with production/logistics/warehouses and it’s something that is constantly part of the planning/status meetings. We’ve also been gearing up for producing batches of popular products more often and increasing the batch sizes to meet the increased demand and to lower the risk of being out of stock. The last part is an internal system we’ve been developing during the last couple of years that keeps track of stock, production, customer shipments and stats in general. More on this in a future blog-post!

New Bitcraze VM development

  2018-04-23  |     |    Leave a comment

The Bitcraze Virtual Machine is designed as a quick and isolated way to start development with Crazyflie and other bitcraze projects.

The current VM is starting to get very old, even though we keep it updated it is based on XUbuntu LTS 14.04. This month Ubuntu LTS 18.04 is being release which is a good reason to upgrade the VM!

The main update will then to switch from XUbuntu 14.04 to XUbuntu 18.04. There is a couple more things that we are looking at updating:

  • Updating Eclipse and CDT to the latest version Oxygen.3a
  • Fixing Eclipse code completion and hinting configuration
  • Pre-configuring eclipse with gnu-mcu-eclipse to make it easier to flash and debug Crazyflie. 
  • Updating KiCad to the latest stable version 4
  • Fixing the virtual machine Crazyradio communication bugs

We are writing this blog post as a request for comment:

  • Is there anything else that you would like to add/remove in the new virtual machine?
  • Anything we could do to make it easier to start developing for Crazyflie?

The virtual machine is generated automatically using packer and VirtualBox, the code is hosted on GitHub. If you want to help making the VM or want functionality to be added to it do not hesitate to open a ticket in the bug tracker.

Heterogeneous Trajectory Planning with Crazyflie and BigQuad Deck

  2018-04-02  |     |    Leave a comment

Here at the USC ACT Lab we conduct research on coordinated multi-robot systems. One topic we are particularly interested in is coordinating teams consisting of multiple types of robots with different physical capabilities.

A team of three quadrotors all controlled with Crazyflie 2.0 and a Clearpath Turtlebot

Applications such as search and rescue or mapping could benefit from such heterogeneous teams because they allow for more flexibility in the choice of sensors and locomotive capability. A core challenge for any multi-robot application is motion planning – all of the robots in the team need to make it to their target locations efficiently while avoiding collisions with each other and the environment. We have recently demonstrated a scalable method for trajectory planning for heterogeneous robot teams utilizing the Crazyflie 2.0 as the flight controller for our aerial robots.

A Crazier Swarm

To test our trajectory planning research we wanted to assemble a team with both ground robots and multiple sizes of aerial robots. We additionally wanted to leverage our existing Crazyswarm software and experience with Crazyflie firmware to avoid some of the challenges of working with new hardware. Luckily for us the BigQuad deck offered a straightforward way to super-size the Crazyflie 2.0 and gave us the utility we needed.

With the BigQuad deck and off-the-shelf components from the hobbyist drone community we built three super-sized Crazyflie 2.0s. Two of them weigh 120g (incl. battery) with a motor-to-motor size of 130mm, and the other is 490g (incl. battery and camera) with a size of 210mm.

120g, 130mm

490g, 210mm

We wanted to pick components that would be resistant to crashing while still offering high performance. To meet these requirements we ended up picking components inspired by the FPV drone racing community where both reliable performance and high-impact crashes are expected. Full parts lists for both platforms are available here

Integrating the new platforms into the Crazyswarm was fairly easy. We first had to re-tune the PID controller gains to account for the different dynamics of the larger platforms. This didn’t take too long, but we did crash a few times — luckily the components we chose were able to handle the crashes without any breakages. After tuning the platforms behave very well and are just as easy to work with as the original Crazyflie 2.0. We additionally updated the Crazyswarm package to be able to differentiate between BigQuad and regular Crazyflie types and those updates are now available for use by anyone!

In future work, we are excited to do hands-on experiments with a prototype of the CF-RZR. This new board seems like a promising upgrade to the CF 2.0 + BQD combination as it has upgraded components, an external antenna, and a standardized form factor. Hopefully we will see the CF-RZR as part of the Crazyswarm in the near future!

Mark Debord
Master’s Student
Automatic Coordination of Teams Laboratory
University of Southern California		 Wolfgang Hönig
PhD Student
Automatic Coordination of Teams Laboratory
University of Southern California

 

Crazyflie clients

  2018-03-12  |     |    3 Comments

We though we could use this Monday blog post to do a small state of the Crazyflie clients. What we call a Crazyflie client is a piece of software that connects a Crazyflie and allows to control it and get telemetry back from it. In this post we will concentrate on single-crazyflie client we have on our GitHub page, there exists a lot of libraries and software to control one or many Crazyflies, we will write another blog post about them.

Crazyflie PC client

The Crazyflie PC client, is what we consider the reference client. It supports connecting one Crazyflie using the Crazyradio (PA) dongle or direct USB connection to Crazyflie 2.0. It supports the full Crazyflie telemetry (ie. log), parameters (ie. params) and firmware update. It has support for all the Crazyflie 2.0 deck that can use client support. It is updated each time it is needed when new functionalities are added in the Crazyflie which makes it actively developed and maintained by the community and Bitcraze. A bluetooth link has not been prioritize so far since its multi-platform implementation is non-obvious and bluetooth will introduce some latency and lower the radio bandwidth compared to Crazyradio. However, if anyone would want bluetooth support for the Crazyflie PC client, we welcome contributions :-). The Crazyflie PC client is using the crazyflie-lib-python to communicate with the Crazyflie.

We have three mobile clients on our Github. They have various level of functionality depending on community involvement. Our philosophy is to have the mobile clients at least able to control a Crazyflie, this allows to use them to test Crazyflies without requiring to setup a computer. We will help and support anyone that is interested in adding functionalities to the mobile clients but we generally do not have time to add much functionalities by ourselves.

The Andoid crazyflie client is currently maintained by Fred from the community. It is mobile Crazyflie client with the most feature. It supports both Crazyradio and Bluetooth link. Using Crazyradio it currently supports the part of telemetry and parameter required to support a couple of deck like the led-ring and buzzer deck and supports updating the firmware. Using bluetooth there is currently no telemetry, parameter or firmware update functionality so no deck support. Development is in progress to support more decks and to bring the bluetooth link to the same functionality as the Crazyradio link. The Android client is written in Java and Fred has developed a Crazyflie Java library that is used in the Android client but that can also be used in any other Java program.

 

Crazyflie Android client

The iOS Crazyflie client, works on iPhone and iPad. It supports bluetooth link. It does not have any telemetry or parameter support, so no deck control support. It has firmware update support over bluetooth. It has mainly been developed by me with great contributions from the community for, among others, the port to swift.  The iOS client is written in swift. The Crazyflie and Bluetooth part of the code could be a good starting point if anyone wanted to make a native mac Crazyflie client.

Crazyflie iOS client

Finally we have a prototype of a Windows UWP client developed by theseankelly. It supports Bluetooth low energy. It currently does not supports any telemetry or parameters. It is working both on Windows phone and on Windows 10 on computer, it is currently the only way to connect a Crazyflie using Bluetooth from a laptop. The windows client supports manual control of the Crazyflie using a gamepad or with gesture using HoloLens. This original set of functionality makes it both the most simple and the most advanced Crazyflie client :-).

If you are interested in developing for any of these client, of by making your own, feel free to make a ticket on the relevant github repo or open a thread in the forum. We migh not have much time to develop for the mobile clients, but we will always be glad to help and guide anyone that wants to implement software in relation with the Crazyflie. The Crazyflie clients (running in a computer or phone) and the Crazyflie firmwares (running in the Crazyflie itself) are open source and in active development, it means that is possible to modify both side, this makes it a great target to experiments and to play around with new ideas :-).

 

Collaboration with Udacity

  2018-03-05  |     |    2 Comments

We are excited to announce that the Crazyflie 2.0 and the STEM bundle has been chosen by Udacity for their Flying Car Nanodegree Program. For the students that want to try out their skills on a real world flying drone, the core curriculum has been augmented with supplemental lessons and Udacity announce that they will provide thorough instructions for the Crazyflie.

 

Udacity is providing on-line learning and their mission is 

“to democratize education through the offering of world-class higher education opportunities that are accessible, flexible, and economical”

We are super happy that Udacity likes the Crazyflie and that more people will have the opportunity to explore the world of robotics!

Merging Crazyswarm functionality into the official Crazyflie firmware

  2018-02-19  |     |    Leave a comment

We have seen a big interest in flying swarms of Crazyflies and there are many challenges in doing so. The USC ACT Lab has developed Crazyswarm, a collection of software and firmware that allows to fly big swarms of Crazyflie using a motion capture system. This project has been used by USC and other universities to fly the most impressive swarms of Crazyflie 2.0 to date. 

Picture from “Downwash-Aware Trajectory Planning for Large Quadrotor Teams” publication using Crazyswarm

We are very happy that we together with Wolfgang and James, the main developer of Crazyswarm, have started to merge the firmware part into the official Crazyflie firmware. Merging the code will have two great consequences: people will be able to use Crazyswarm with a Crazyflie 2.0 running the stock firmware and everybody else will be able to use functionalities that has been developed for Crazyswarm.

There is currently a couple of parts that are in the works. The state controller has been merged already. There is currently some discussion on Github on how to merge the high-level commander, a commander that would allow the Crazyflie to autonomously follow trajectories as well as other high level commands. Finally there will be some work required to adapt the Kalman filter to make it more suited to accepts measurements from a motion capture system. The Crazyflie was not developed as an autonomous platform from the beginning but it is becoming one in big part thanks to the great contributions from the community.

A great thanks to James and Wolfgang for their effort in merging CrazySwarm in the Crazyflie code-base!

Out of stock
Unfortunately we miscalculated how much China slows down during Chinese new year which has caused some products to become out of stock. One of them is the Crazyradio PA which is also causing some bundles to become out of stock as well. The good news is that the products are in transit to the warehouse and will hopefully be back in stock any day now. Until then you can use the “Item out of stock – notify me!” functionality to get notified as soon as the product is back in stock.

 

Multi-ranger deck update

  2018-02-12  |     |    9 Comments

During the fall we did two blog-posts (1, 2) about a new prototype named Obstacle Avoidance/SLAM deck, but since then it’s been a bit quiet about it. So we thought it was due for an update! First of all, after a lot of discussions, we decided to rename the deck to Multi-ranger. It better describes what the board does and matches the naming of the Z-ranger. We’ve sent out some samples to customers and so far the response has been great. So we’re pushing forward and preparing for production that’s estimated to begin in March. Below is a picture of the latest prototype.

The biggest change for the final prototype is adding a LDO regulator to power the sensors. We’ve seen that depending on the settings for the sensors they might consume a lot more than when we initially tested. Using the same settings as for the Z-ranger brings the consumption to 90 mA, which together with the Crazyflie 2.0 electronics, comes close to filling the power budget for the Crazyflie 2.0 VCC LDO regulator. Aside from that we’re making some minor changes to simplify production and testing.

We’ll keep you updated on the progress!