Category: Crazyflie

We have been working with our indoor positioning system for over a year now and during that time the interest for the Loco positioning system have continuously been growing. Universities all over the world are already using our system and the attention we have received have been very encouraging. But the system has been a bit hard to set up and lacking in documentation. So we decided that this had to be fixed before we could leave early access.

So now we’re happy to announce that the Loco positioning system has reached a state where it’s out of “Early access” and we’re excited to see even more customers starting to use the system. We would like to thank everybody in the community that has been contributing to the project, this is what makes open source great!

Below are some of the steps we’ve taken to make it easier to use.

 

Getting started guide

We have created a brand new “Getting started with Loco positioning” tutorial that will replace the old “Getting started” video that we made. The tutorial contains a step-by-step guide for flying one Crazyflie 2.0 autonomously using two way ranging. The more advanced features such as TDoA is still considered as experimental and won’t be covered in this tutorial. We are very happy with the outcome of this tutorial but please help us out and try the tutorial and give us feedback.  

LPS tool

In order to easily configure and upgrade the firmware for the Loco positioning nodes we’ve created the LPS tool. With it you can set the address of the node, the mode and also upgrade the firmware easily. 

 

 

LPS tab

Up until lately there hasn’t been any support for the Loco positioning system in our Crazyflie Python client, instead we’ve been using ROS. It’s a great tool and very powerful tool, but ROS can be a bit complicated with specific requirements on the environment in which it runs. So we wanted to be able to perform basic use-cases directly in our client, like setting up the system, debugging it and flying with it. In order to achieve this we created the Loco positioning tab and a new flight mode called Position hold.

The Loco positioning tab is used to set-up the system and view it’s status. You can configure the position of the anchors, easily see which anchors you’re close to and if all the anchors are responding as they should. It’s also possible to see the layout of the system and the Crazyflies position in it.

For flying the Crazyflie we’ve added the Position hold mode. When enabled this will translate gamepad input into velocity control set-points that are followed using the positioning.

 

Wiki documentation

We’ve added technical documentation for the Loco positioning system to the wiki and we’ve also created product pages with schematics and details on the hardware for the Loco positioning node and deck. In the documentation you can find useful things like protocol documentation and details on our reference set-up that we use in our lab. Sine the system is still continuously evolving this is a working document that will continue to be improved over time and we hope to push the boundaries further for swarm flying and robotics in general.

ICRA

Finally a reminder, if your are attending 2017 IEEE International Conference on Robotics and Automation in Singapore you can meet us in booth C08 from 30/5 – 01/6. We will show autonomous flight with the Crazyflie 2.0 enabled by the the Loco Positioning System. Come by have a chat with us and see the Loco positioning in action!

You will also be able to attend the presentation of the paper “Crazyswarm: A Large Nano-Quadcopter Swarm” by researchers from USC during Wednesday 31/5 at 11:15.

Releases

To support the features mentioned above we’ve released version 2017.05 of the Crazyflie Python client and Crazyflie firmware.

 

 

A couple of weeks ago we played with recording and retracing trajectory directly from the Crazyflie using Loco Positioning System. The result was quite nice and resulted, a first for us, in a fully autonomous Crazyflie, no computer or controller required:

We decided to expand on this experiment for our demo at ICRA. We have modified the retracing code to accepts multiple modes, including running pre-programmed sequence. The plan for the demo is to have Crazyflies that can:

  • Record and retrace a manual trajectory
  • Record and replay in a loop a manual trajectory
  • Play a pre-defined trajectory in a loop
  • Land automatically when the battery level is low

With this we should be able to demonstrate quite well the capabilities of both the Crazyflie and the Loco Positioning system, and since we do not require a computer in the loop it simplifies a lot running the demo. Of course we keep the possibility to connect the Crazyflie with the Crazyflie client and with ROS while the crazyflie is flying.

Having a completly autonomous Crazyflie is also new to us and it brings its share of problems: how to we choose the working mode and how to we stop the flight if something happens (things tends to happen …).

To solve the former we have made a button deck that adds 2 push-button to the Crazyflie. One means “Start autonomous sequence”. The second means “Record trajectory”. If the recorded trajectory is a loop (if the end point is close to the start point) then the loop is played back as soon as the crazyflie is dropped, otherwise Crazyflie retraces the trajectory and stop.

We solved the later problem by making an autonomous emergency stop button that sends a radio watchdog signal. If the signal stops to be sent or if an emergency stop signal is sent (ie. by pressing the button), the Crazyflie will stop all motors and drop. The button is implemented using a Raspberry pi, a Crazyradio and an Arduino to interface the button:

If you are curious about code, we have created a github repos where we push all code we are making for this demo. As usual, this conference is an opportunity for us to hack new functionalities, though not everything can be done in the master branch. Later some things can be merged, others (like the retrace trajectory recorder/player that looks more like a user app.) will need much more though if we want to merge it in the Crazyflie firmware.

We are going to the IEEE International Conference on Robotics and Automation in Singapore. The exhibition is open Tuesday May 30 to Thursday June 1 and we will have a booth, number C08, where we will show demos and discuss our work, positioning technologies and quadcopters.

We have not finalized our demos yet but they will include autonomous flight with the Crazyflie and the Loco Positioning system. We also hope to show our brand new optical flow expansion deck that will enable positioning and autonomous flight when on a tight budget. We also plan to show integration with external computers running ROS or our own python library. If we are lucky there might even be a small swarm, even though the space is very limited.

We love to talk to people that are using our products or just interested in our technology, if you are at the conference please drop by and say hi and tell us what you are working on. We will arrive in Singapore on Saturday morning May 27, and if you want to hook up and say hi and have a coffee during the weekend, drop us an email.

See you in Singapore!

Ever since we released the Alpha round of the Loco positioning system we’ve been talking about designing a more generic tag that could be used together with other robotics platforms for local positioning. We did a quick design of a prototype that we tested, but with the workload involved in bringing the LPS out of Early Access, finishing the Z-ranger and lots of other stuff , it’s remained on the shelf. But recently we’ve been getting more and more requests for this kind of hardware, so we thought it might be time to dust off the prototype and try to release it. One of the blockers (except workload) has been that we’re not sure how the tag should look mechanically and how to interface it electrically for it to be as useful as possible for our community. This post is for detailing the current status of the hardware/firmware and to see if we can get some feedback on what our community would like the finished product to look like.

The hardware

To make use of the firmware that’s been developed so far for the Crazyflie and the Loco positioning we aimed at making something similar to what we already have but with another form factor and slightly different requirements. As you might know the Loco positioning node can be configured as a tag, but there’s two drawbacks that we wanted to fix. First of all the Loco positioning node might be a bit big to put on smaller robots. Secondly the Loco positioning node can only measure the distances to the anchors, it doesn’t have an IMU to get attitude of the board and doesn’t have the processing power to run the same algorithms we have on the Crazyflie 2.0.

So for our Loco positioning tag prototype we decided to fix these. The prototype has the same sensors as the Crazyflie 2.0: Gyro, accelerometer, magnetometer and pressure sensor. It also has the same MCU as the Crazyflie 2.0: STM32F405. In addition to this it has the DWM1000 module for the ultra wide-band radio (used for positioning). We’ve also added the interfaces we have on the Crazyflie 2.0: SWD debugging, micro-USB for communication and power as well as a button. Looking at the pictures below you might also notice that we’ve added the Crazyflie 2.0 deck connector. So does this mean you can connect it to the Crazyflie 2.0? No, well not this prototype at least. The reason for adding it was we wanted to be able to use the same expansion decks as for the Crazyflie 2.0. So it’s possible to add the breakout deck for breadboard prototyping or the LED-ring for visual feedback.

So what’s the status of the hardware? Even though it’s the first prototype it’s fully functional and will give you positioning and attitude. What’s left is defining the electrical interfaces and the form-factor of the board so it can easily be attached to what ever you might want to track. The images below shows a side-by-side comparison with the current Loco positioning deck.

Loco positioning tag (on the right) compared to Loco positioning deck (on the left) (FRONT)

Loco positioning tag (on the right) compared to Loco positioning deck (on the left) (BACK)

The firmware/software

Like I wrote above we wanted to reuse as much of the firmware and software as possible. So the firmware running on the prototype is just a scaled down version of the Crazyflie 2.0 firmware. As you might have noticed the prototype looks a lot like the Crazyflie 2.0, except that it’s not a quadcopter and doesn’t have the nRF51 radio. So by “scaled down” I mean we’ve removed the motor and radio drivers, that’s about it. So how do you communicate with it? Well you can use one of the protocol available on the deck connector: SPI, I2C or UART. But the currently implemented way is using USB. Since it’s basically a Crazyflie you can use our client and python libraries to set parameters and log data values from it.

Conclusion

The current prototype is basically a USB dongle where you get position and attitude. It could easily be connected via USB to a Raspberry Pi, Beaglebone or any other SoC based platform or a computer. You can also interface it from an Arduino using the peripherals on the deck connector. The firmware is working and using the python library (or any other of our community supported libraries) you can easily get the position and attitude of the board. But to be able to take the next step and make something our community could make the most of we would love some feedback on the prototype. What kind of electrical interfaces and form-factor would you like?

The past

The Crazyradio has been designed as a radio dongle to control the original Crazyflie 1. It is based on a Nordic Semiconductor nRF24LU1. It is basically the radio from Crazyflie 1, the nRF24L01, with a microcontroller and a USB device peripheral. Crazyradio has been designed from the beginning to be extended for other used: the code is completely open-source, can be powered with 12V and has an expansion port with possibility of implementing a serial port to communicate with the radio.

When we designed Crazyflie 2.0, we extended Crazyradio to make Crazyradio PA. It is basically the same hardware but we just added a power amplifier to make sure Crazyradio is transmitting with the same power as competing radio in the same 2.4GHz band: Wifi and Bluetooth. Crazyflie 2.0 is not using an nRF24 chip anymore but an nRF51822 which integrates a microcontroller and implements bluetooth low energy as well as nRF24 compatible radio.

 

The present

The Crazyradio (PA) has been used for a couple of hack like our glove controller. Another popular use has been by security researcher to experiment with the security of wireless mouse and keyboard. Indeed the nRF24 serie of chip is extensively used in wireless mouse, keyboard and even quadcopters ;).

We are often very quiet about the Crazyradio since ‘it just works’. It does not means that it is finished or perfect, there is actually a lot that was planned to make the radio link more efficient, to be able to control more Crazyflie per Crazyradio, etc… Some of this work has been done in the context of the Crazyswarm project by Wolfgang from USC but a lot more could be done. One of the main blockers for Crazyradio development is that it is based on a very old microcontroller, an 8051, and that it does not have a safe bootloader or (open) debugging access. It means that each modification is potentially a big commitment in time and since the radio already work quite well it is hard to put much time in it.

The absence of a safe bootloader means that if you flash a firmware that crashes, you will need an SPI programmer to recover the radio in working mode. This makes it quite stressful to work with the radio. However there are a couple of programmers made for this and we recently published a Hackster project about using a Raspberry Pi to recover the bootloader:

The future

We have been looking at making a Crazyradio with an nRF51-series chip, these chips have a Cortex-M0 CPU which means that they are much easier to program using a modern development environment. However none of the chip in the nRF51 series have USB which forced us to prototype the concept with an added microcontroller for USB. This creates a bigger and more populated Crazyradio:

We did not like this design very much since having 2 microcontrollers is always much more haste to program, debug and maintain. Thankfully Nordic semiconductor will release a nRF52 chip with USB support. Adding to that a powerful Cortex-M4 microcontroller, a lot of ram, still Bluetooth low energy and nRF24 radio compatibility but they also added iEEE802.15.4 2.4GHz (ie. the protocol used by Zigbee). This new chip is a very good candidate for the next Crazyradio.

We are very much in the pre-study phase for the next Crazyradio (and mass production for the new nRF52 is planned for Q4 2017 anyway…), so if there is functionality that you would like to see in a future Crazyradio it is time to speak up! Please tell us in the comment section bellow or in the forum ;-).

We are happy to announce that we have released new versions of the Crazyflie Firmware and the Crazyflie client, both are now in version 2017.4. The main feature of the release is support for the new Z-Ranger deck.

To support the Z-Ranger, a new flight mode has been added to both the firmware and the client: the Height-hold mode. This mode allows to fly with the Z-ranger deck at a fixed height above the floor.

There are also a number of other improvements and bug fixes in the releases, mainly related to the Loco Positioning system and autonomous flight.

On the client side, this new release is also a come-back of the windows build. It means that it is now easier to get started and fly your Crazyflie directly from Windows as you can install it as a native app. We really want to build the client for Mac OS too but have met some problems. If anyone has experience in building pyqt apps for mac OS, with your help we might be able to have a mac build for the next client version ;-).

For instructions on how to upgrade see the getting started guide.

Have fun!


For those of you out there that are new to flying drones the height is often the most difficult thing to control. One solution to that problem is our newly released Z-ranger deck that can precisely measure the distance to the ground. Using this information the drone itself can stabilize on a desired target high and therefore become much easier to control. The Crazyflie 2.0 will then behave similar to a hovercraft sweeping over the ground or climbing stairs which is a ton of fun. As an in-action example please check out the video below where a Crazyfie 2.0 with a Z-ranger e.g. follows a flight of stairs :-).

For information of how to activate the height hold mode have a look at the getting started guide and for further details please check out the Z-ranger wiki page.

At Bitcraze we have some history with trying to fly our Crazyflie autonomously. The most recent step is the Loco Positioning System that allows us, and you, to fly in a full room. The Loco Positioning system has boosted development of advanced algorithms for onboard position estimation and control.

Our earlier attempts where mostly based on different kinds of cameras, either a 3D camera like Kinect or regular webcams. Though, at that point, we only had the camera for position estimation and where doing the position control on the PC and not onboard the Crazyflie. This has the disadvantage to be brittle and requires a very high quality positioning from the camera: any frame where we loose the Crazyflie has a huge impact on the control behavior since the position controller relies exclusively on the camera detection.

With the Kalman filter and onboard position controller, the Crazyflie can now handle lost position information for at least a couple of seconds without big problems. This has the potential of making webcam-based position detector much more robust!

To test this theory we have grabbed the 2 years old crazyflie-ar-detector from the dawer github, updated it to OpenCV 3.2.0, and fed the position output to the Crazyflie 2.0 external position port. The crazyflie-ar-detector program is using ZeroMQ to communicate position and so we made a simple external position tab for the Crazyflie Client that receives position from ZeroMQ and sends it to the connected Crazyflie.

Using the new position-hold mode recently introduced in the client we can test and fly the Crazyflie under the webcam. We have taken a short video to show the performance. The result is promising and we will continue to play with ways to fly the Crazyflie autonomously.

Early on when we started to work on the Loco Positioning system, we came up with an idea of a Crazyflie autonomously flying into a light box, positioning it self for a few product pictures and then flying out again. The positioning system is now pretty mature and close to leave Early Access and this Friday we finally got around to do it. In this blog post we will share what we did and it also doubles as a brief howto on how to set up the system and fly a simple autonomous sequence.

We used a Crazyflie with a Loco Positioning Deck and eight Loco Positioning Anchors in our setup. Six anchors would have been fine too, but we happened to have eight in our flight lab.

When working with the Loco Positioning system the first step is always to make sure the anchors are set up correctly. We had an experimental version of the anchor firmware so we started out by pulling down the latest stock version of the source code and compiled it into a .dfu file. After that we fired up the brand new lps-tool that is used to flash firmware and configure the anchors. The anchors must be connected with a USB cable to the computer but the lps-tool reduces the flashing and configuration into a few clicks. When all anchors were updated we were ready for the next step.

The positions of the anchors are stored in the anchors them selves and the position is transmitted to the Crazyflie as a part of the ultra wide band messages used for measuring the ranges to the anchors. This way, the Crazyflie gets both anchor positions and ranges in the same process and has all the information needed to calculate its position. The second step is thus to store the positions in the anchors. In our “flight lab” we have fixed mounts for the anchors with known positions, so we could skip measuring the physical positions of the anchors.

We are working on making it possible to remotely configure the anchors to reduce the need to physically connect to them, and the position can now be set from the Crazyflie Client. We simply opened the “Loco Positioning” tab in the client, connected to a Crazyflie (with a Loco Positioning deck mounted), entered the anchor positions and hit the “Write to anchors” button. A few seconds later the anchor positions in the graphs were updated to indicate that the positions have been written to the anchors and then subsequently sent back through the ultra wide band messages to the Crazyflie.

Step three is to verify that the system is working as expected. First thing is to check that we did not mix the anchors up when configuring or placing them. In the “Loco Position” tab in the client, click the “Anchor Identification” button. In this mode anchors are lit up in the graphs when the Crazyflie gets close to them in the physical world. We went from anchor to anchor with the Crazyflie and checked that the correct anchor lit up on the screen. When confident that all was good we changed to “Position estimate” mode and verified that the estimated position matches the physical position of the Crazyflie. We have found that it can be very hard to understand, for instance that two anchors have been mixed up, by looking at the estimated position and that the “Anchor Identification” step simplifies the setup.

At this point we had a fully functioning Loco Positioning system ready for autonomous flight!

Now it was time to script a sequence. The easiest way to script a sequence is to start from the autonomousSequence.py example. Our intern Alfred took over at this point, he updated the uri to the correct settings and crafted a sequence to take off, fly into the light box, wait a while and then fly back out for a stylish landing in his hand!

Now we were ready for the actual photo shoot and Björn came down with the camera to shoot the product pictures. We hope you enjoy the results!

The Crazyflie client, the software running on a computer that is used to control and get telemetry from the Crazyflie, is written in Python and used PyQt4 as graphical user interface framework. This has worked quite well and has the advantage of running on windows/mac/linux without much effort. However Qt5 and PyQt5 have been released for a long while now and what should happen is starting to happen: PyQt4 is starting to get depreciated.

The first sign came from macOS, a ticket was reported on the Crazyflie client github indicating that it was not possible anymore to install PyQt4 using the Homebrew package manager. The problem was solvable since PyQt4 was still there but moved in the Homebrew ‘backyard’, so for the time being it still works but is a bit worrying. More recently Python 3.6 was release and there will apparently not be a release of PyQt4 for Python 3.6, this means that if we do not do anything the client risk to not be supported on linux anymore (the next Ubuntu LTS is planned to use Python 3.6).

This was enough to push us to port the client to the new Qt/PyQt5. The port was started by sighmon when the first macOS related ticket was reported but we had a bad bug with the Gamepad reading on macOS, this bug was the main blocker but has been fixed last week so we are now very close to having the port functional!

If you are curious about it, we have the port in a branch on github. We are planing on merging it in the following days and releasing a new version of the client in the process.

We are also planing on releasing a Windows build and installer this time. The Windows installer has been built automatically in AppVeyor for a couple of month now and it seems stable enough to become an official version. We still want to make a macOS app out of the client but are still blocked in doing so. If you have experience making macOS app out of PyQt5-based software, we would greatly appreciate some help in getting a mac build, we have a github ticket for it.