Category: Random stuff

The last couple of weeks has been really intense since we’ve been busy preparing for IROS. Finally it’s here, and with it we’re releasing a few new products!

We’re excited to announce that during the fall we will be releasing the following new products:

  • Crazyflie 2.1: The Crazyflie 2.0 was released almost 4 years ago now. Over the years there’s been thousands of users and lots of feedback on the product. Most of it great, but there’s been a few things we’ve wanted to fix. Now with the updated 2.1 version we finally have the chance to do it. Here’s a quick list of the updates:
    • Better radio performance and external antenna support: With a new radio power amplifier we’ve improved the link quality and added support for dual antennas (on-board chip antenna and external antenna via u.FL connector)
    • Better power button: We’ve gotten feedback that the power button breaks too easily, so now we’ve replaced with a more solid alternative.
    • Improved battery cable fastening: To avoid weakening of the cables over time they are now run through a cable relief.
    • Improved sensors: To make the flight performance better we’ve switched out the IMU and pressure sensor. The new Crazyflie uses the drone specialized sensor combo BMI088 and BMP388 by Bosch Sensortech.
  • Flow deck v2: The Flow deck has been upgraded with the new ST VL53L1x which increases the range up to 4 meters
  • Z-ranger deck v2: The Z-ranger deck has been upgraded with the new ST VL53L1x which increases the range up to 4 meters
  • Multi-ranger deck: Finally the Multi-ranger deck is currently in production and will be available during the fall!
  • Mocap deck: The motion capture deck with support for easily attaching markers
  • “Roadrunner” (alpha): With TDoA3 to be included in the next firmware release we’re happy to release one of our LPS tags code named “Roadrunner”. The hardware is basically a Crazyflie 2.1 without motors and up to 12V input power.

In the upcoming weeks we’ll post more details about the products and when they will be available, so stay tuned!

We should also mention that we will showing off some awesome prototypes of products that are planned to be released next year, among them:

  • “RZR”: The long awaited Crazyflie + BigQuad stand-alone combo code-named “RZR” is making it’s way into production and we are aiming to release it during the beginning of 2019. Basically it’s a Crazyflie 2.1 where instead of motors you can directly connect ESCs to build bigger quads up to around 0.5kg.
  • Lighthouse deck: Our current prototype is now flying with both Lighthouse 1.0 and 2.0 and the performance is awesome! This is definitely the next product out the door after the list above and we’re aiming at having it available during the spring.
  • Raspberry Pi Zero power deck: This deck allows you to add a Raspberry Pi Zero to the Crazyflie 2.x and the “RZR”.
  • LPS tag: We’ve shown this tag before but now we’ve updated it to use the Crazyflie 2.1 IMU and to have proper mounting holes. We’re getting closer to release and this will hopefully be available during the spring.

During IROS this week we will be showing off all the products above (including the prototypes). So if you want to be one of the first to check them out drop by our booth nr 91.

We are working hard in the Bitcraze team to prepare and get ready for IROS 2018 in Madrid next week. As usual preparing for fairs and exhibitions make us add useful features and functionality that we might not had planned to implement but that we find useful or need. Even though some of it might be a bit hackish, most of it will add value to the project and will hopefully be useful to the community. Notable functionality that we are working on this time: 

  • design for a 3D-printable charging pad
  • basic support for the experimental Light House deck
  • support for the high level commander in the python lib
  • “app” for autonomous flying running in the Crazyflie

Charging pads

The plan is to fly a small crazyswarm with 6 Crazyflies using a motion capture system from Qualisys. Since we want to spend as much time as possible talking to people and minimize setup time, we were looking for a solution to automatically recharge the batteries between flights. We are planning to use Qi-charger decks for contact less charging with 3D-printed landing pads with slopes to make the Crazyflies slide into the correct charging position even if they land a few millimetres off. 

The Light House deck

Even though the Light House deck hardware still is very much experimental we have started to add support for it in the Crazyflie firmware. Hopefully we will be able to run our demos using either LPS or the Lighthouse to show the difference in performance.

Support for the high level commander in the python lib

The high level commander was contributed by Wolfgang Hoenig and James Alan Preiss (thanks!) an has been available in the Crazyflie firmware for a while. In an environment with positioning support it provides high level commands such as “take off” and “go to” as well as flying user defined trajectories and is used by Crazyswarm. We wanted to use the same functionality in our demo but running it stand alone in the firmware. The easiest way to get acquainted with the functionality was to play with it from python and as a side effect we implemented the API in the python lib for anyone to use. There is also an example script called autonomous_sequence_high_level.py in the examples directory.

App for autonomous flight

For ICRA last year we wrote code in the Crazyflie firmware to fly trajectories autonomously. At that point we simply fed setpoints to the PID controller to make the Crazyflie follow a preprogrammed path. Now we have more tools in the Crazyflie toolbox (the high level commander and the Mellinger controller) and by using them we have reduced the amount of code needed and complexity of the solution while the performance has been improved (code on github). 

E-store

Like we’ve mentioned a few times before it’s not always easy shipping batteries. Due to this we’ve unfortunately had to switch off checkouts containing batteries to some countries (like Canada, Australia and India). We’ve finally found a workaround for this, so today we’ve switched from using DHL to using FedEx in our E-store. As a positive side-effect of this most customers will also benefit from lower shipping rates on their orders. As always if there’s any issues with shipping or ordering please let us know and we’ll do our best to sort it out.

Loco node Rev.E

After receiving feedback from some customers that the micro-USB connector on the Loco nodes broke we’ve decided to update the design. So in the coming weeks we will start phasing in the new revision (Rev.E) of the Loco node and phasing out the old one (Rev.D). Aside from the updated micro-USB connector we’ve also connected more spare pins to the expansion connector on the board. For full details on the schematic changes have a look at the the Rev.E schematics over on the wiki. As a side-note it’s worth mentioning that the first batch of Rev.E Loco nodes have a dark blue silkscreen instead of the standard Bitcraze black silkscreen, this will be updated in future batches.

We started the work on TDoA 3 in May and it has been functional for a few months, but it is a bit cumbersome to make it work since it requires compiling firmware with special flags and running scripts to configure anchors. To rectify this and make it more accessible we are now working on integrating it just like the other positioning modes; TWR and TDoA2. 

Changes

The anchors already contained most of the required functionality. We have added support to change to the TDoA3 mode via LPP, that is using the Crazyflie as a bridge between the client and the anchors, transmitting data to the anchors via UWB.

In the Crazyflie TDoA 3 has been added as a third mode. This means that it is now auto detected when the Crayzflie is switched on and it can be selected from a client – no need for compile flags any more! We have also added a new mapping to the memory sub system to transfer anchor information for a dynamic number of anchors to a client. This means that instead of being available to the client as a long list of log variables and parameters, most of the TDoA3 information and configurations are available in a memory map using the same protocol we use to access real memory like the configuration EEPROM or the deck memories. This way we have much more freedom to define and transfer the data-structure to and from the Crazyflie.

The python client/lib is the piece of software that requires most changes. The UI (and implementation) was designed to handle 8 anchors, but with TDoA3 it must support a dynamic and larger number. The new memory mapping has of course to be implemented in the lib as well. The anchor position configuration part of the LPS tab will be separated into a dialog box to get more space for the controls. We also have some ideas for improvements in anchor position configuration (saving to file and sanity checking of configurations for instance) that will be easier to implement in the future as well.

Feedback

The driver for this work is of course to make the TDoA 3 technology available to anyone that wants to try it out. It is important to remember that it still is experimental and that we have mainly tested it in single room setups with a few anchors. Our hope is that more users will use it in various settings and that we will get feedback and contributions to iron out any remaining problems. We currently lack easy access to larger spaces which makes it hard for us to verify the functionality in a system with many anchors.

The code in the firmware for the anchors and the Crazyflie is mostly ready while there still remains some work in the lib/client, hopefully it can be committed and pushed during the week (see issue bitcraze/crazyflie-clients-python#349). If you want to try it out when the client is fixed, remember to upgrade the anchor firmware (including git sub modules), the Crazyflie firmware (including git sub modules), the python lib and the python client. Since this is still work in progress APIs and protocols may change until the first official release.

Log and param are the two Crazyflie subsystems that have become the core means of communication with the Crazyflie.

The Log is a subsystem that contains functionality to transfer values of variables in the Crazyflie to a client. The client can setup log blocks, which are a list of variables, and start logging this log block at a certain rate. The Crazyflie will then send radio packets at the requested rate with the current values of the variables, thus enabling the client to read changing variables in the Crazyflie in near realtime. It is very useful for monitoring the state of the Crazyflie and further more, any log variable can be graphed in the python client.

Param is a subsystem that contains functionality to get and set the values of variables in the Crazyflie. This is essentially the opposite of Log, it allows the client to read or write variables that are read-only in the firmware.

Both subsystems are based on a Table Of Content (the TOC): at connection time the client pulls the list of log/param variables. This means that there is no hard-dependency between client and firmware and that we can develop new functionalities in the Crazyflie, adding log and param variables to access it without modifying the client.

The Log and Param subsystems have served the Crazyflie community very well, allowing for quick development of experimental and new functionalities. There has been a limitation that has become more and more painful lately though; we were limited to 255 variables due to the protocol using only one byte to encode the variable ID. This issue has now been fixed in the Crazyflie firmware and in the Crazyflie ROS driver by a pull request from Wolfgang at USC. We have recently also implemented the required changes in the Python lib to make it available in the python client (and any other python script using the lib). In the process, some bugs unfortunately found their way into the code, but they have quickly been fixed by a pull request from simonjwright. Thanks to every one involved!

So now Crazyflie supports up to 65535 log and 65535 param variables. This time we should be good for the foreseeable future! ;-).

The summer has been unusually long and warm here in Sweden, with a never ending sun beaming on the Bitcraze team members enjoying our vacation. As usual, at least one of us has been in the office at any given time, but staffing has been sparse. We apologise for delayed answers to emails and similar.

Even though we have been enjoying some time off, we have also managed to do some clean up of tasks that have been long over due. For instance merging pull requests and fixing a few nasty bugs (for details please see github), and implementing long overdue functionalities like being able to have more than 255 log and param variable (when the Crazyflie firmware develoment started many years ago, we though that 255 variables ought to be enough for anybody).

Everyone will be back in the office this week but we plan to continue the cleaning a few more weeks. We hope to be able to do some work on TDoA3, the Crazyradio, impementing Crazyswarm functionality in the python lib and more generally everything we normally do not have the time to do.

We have some exciting projects coming up this autumn: In October we are going to IROS where we will try demo a swarm in 2x2x2.5m, we also have quite some hardware that is now very close to be finalized that we should be able to release and start shipping before the winter.

Stay tuned for more products and blog posts!

Last week we received the visit of Wolfgang from USC, he is the creator of the Crazyswarm project. It was great to have him here at the office. One of the subject of discussion was to prepare a demo for iROS 2018 on October 1-5 2018 in Madrid.

We will be in booth 91, if you are attending iROS 2018 feel free to pass-by and say hello. We are planning a couple of demos:

  • Crazyswarm with at least 6 Crazyflies flying in a Qualisys mocap system.
  • Running a fully autonomous Crazyflie with the Loco Positioning System.
  • Hopefully, some demo of autonomous flight using the lighthouse positioning. This is still not fully working but I have at least 2 full months to get something flying :-).

If you would like to see us demo anything more/else tell us in the comments and we will see if we can setup something.

We used Wolfgang’s visit to finalise the Qualisys support for Crazyswarm. It is now pushed and documented, this means that if you have a Qualisys system and a couple of Crazyflies you can now fly them autonomously using the Crazyswarm framework. It also means that we now have Crazyswarm up and running flawlessly at the office, it will help us testing related pull-request and supporting advanced functionality like the high-level-commander in the Crazyflie python lib.

 

As a side note, Bitcraze is spread very thin these weeks since most of us are in vacation (I am basically alone). We usually miss one Monday post per year, it was last week and the Wolfgang visit is my excuse :-). Sorry in advance if there is any delay to answer mail, forum or other requests. From next week, the rest of the team will slowly start to come back.

Like every summer, things slow down and people starts to go on vacation. This is a perfect time to sit down and start fixing various things that we never have time to fix. We call that the Summer cleanup. This summer there will still be a bit of development though as we are finishing the multiranger deck.

On the cleanup side, there is at least a couple of things we plan to look at:

  • Updating the virtual machine to the latest Ubuntu version
  • Looking at the Crazyflie firmware build system to make it cleaner and easier to expand for new platform. There is the RZR and the LPS Tag boards that will come later in the year and will need to be supported by the Crazyflie firmware.
  • Implementing a startup test that can detect bad propeller and bad batteries. This would improve a lot the experience of flying a Swarm of crazyflies.
  • We have been continuously improving the webpage last year, this will continue during the summer.

If you have any ideas of areas you feel we should focus on, even better if you want to help with some things and fix it together with us, just tell us in the comment.

A while ago we bought an HTC Vive for the Bitcraze office. This was partly for having fun with VR, but is was mostly because we had hope to use the vive tracking system with the Crazyflie. We are making progress with the idea and we just received our latest prototype:

The Lighthouse tracking system is the hardware component of steamvr tracking, it is used by the HTC vive to get the full position and orientation of the Vive VR head mounted display and game controllers. It has sub-millimeter precision and low latency, which is key to achieve immersive VR experience. The system works by having base-stations installed in the room. The base station sweeps two rotating infrared laser planes. A receiver is basically a photodiode, by detecting when the photodiode is hit by the sweeping lasers, the receiver can measure at which angle it is seen by the base station. With enough receivers and/or base-stations, it is possible to calculate the receiver position and orientation. If you want to read more about how lighthouse works, there has been awesome work of reverse engineering and documentation made by the open-source community.

As far as Crazyflie is concerned the lighthouse system has one major advantage: the position and orientation can be calculate in the tracked object which means that the Crazyflie can be completely autonomous and there is no limit in the number of Crazyflies that can be tracked at the same time.

Lighthouse has been my fun-Friday project for a couple of month and the early results are very encouraging.This is still very much work in progress, so stay tuned for future blog-posts about the subject :-).

A lot of awesome things have been going on at Bitcraze during the last couple of months (like TDoA3, Swarm shows and a new front page), but on the logistics side we’ve been struggling. Like we wrote a couple of weeks ago we’ve been having huge issues with out 3rd party warehouse supplier. Unfortunately the issues have continued and we’ve been working hard on patching things together to get orders to our customers as soon as possible, but it’s not a sustainable situation and some of our customers have unfortunately had to wait too long for their orders to arrive.

So a couple of weeks ago we took the decision to move handling of the E-store from the 3rd party in Hong Kong to our office in Sweden. This will initially mean more work for us, but we feel that it’s something we need to do in order to keep the level of service we want to give our customers. So for the time being orders will be shipped from our office in Sweden.

So what does this mean in practice? Except for things hopefully working much more smoothly there won’t be any noticeable change for non-EU customers. However for EU customers there’s a big improvement: previously our EU customers had to import the products into the EU where the orders where subject to VAT and import duties. With the E-store moved to Sweden these orders are now subject to Swedish VAT (25%) directly on the order and customers will not have to import the goods so no additional VAT or duties are added upon receiving the order. Since this makes things easier and faster for our EU customers we’re really happy about this. Note that for customers with valid EU VAT numbers the VAT can be deducted directly in the E-store, you can either enter your VAT number directly in the cart or in your account if you have created one.

We’re doing our best to sort out the new situation and if there’s any issues along the way please let us know so we can work on fixing them.