Category: Electronic

Home / Blog

New prototype: Obstacle avoidance/SLAM deck

  2017-09-18  |     |    7 Comments

At any given time we have a bunch of deck ideas floating around. Some of them might not be doable (or very hard), but still fun to discuss. Other we just never get around to since we’re always pressed for time. The “obstacle avoidance” deck is one of the latter ones.

The idea with the “obstacle avoidance” deck (current working name in lack of imagination) is to mount one of the VL53L0x ToF distance sensors, the same we have on the Z-ranger and the Flow deck, in each direction. This would allow you to keep a distance to the ground, avoid the walls (or any other obstacles you might fly into) and also keep away from the ceiling. Basically you could do a “turtle bot” that just flies around randomly without crashing. Another fun idea we’ve been discussing is being able to SLAM the room you’re flying in. If you can keep track of how you are moving around (with the Flow deck, Loco positioning system or any other means) while you’re measuring the distance on all sides you could make a map of the room.

After discussing this on and off for a some time, mainly focusing on mechanical and production issues of the design, we decided to just try out the concept with a simple prototype. The prototype, named “OA”, has daughter boards with VL53L0x sensors mounted front/back, left/right as well as one sensor facing up. It’s designed to be mounted on the top of the Crazyflie 2.0 and combined with the Flow deck which will give relative movement and also the sixth direction, distance to the floor. One of the issues with the design is that all the VL53L0x sensors are on the same I2C bus with the same address. To work around this the sensor has a nifty feature where you can re-program the I2C address. For this to work you need to release the reset of the sensors one by one: release the first reset, reprogram the address and then release the reset of the next sensor. The reset for the VL53L0x is not cabled on the Flow deck, so this is the first to be re-programmed. Then the reset will be released one-by-one for the sensors on the OA deck. In order to control the reset pins on the deck there’s a 8bit I2C GPIO expander. The reason for the GPIO expander is to use as few GPIOs on the deck connector as possible to keep the compatibility with other decks high. For instance the deck will work fine with the Loco positioning deck.

 

The goal with the prototype is to try out the concept of the deck and to see if it’s feasible. A few of the things we need to sort out is:

  • Mechanical solution for side senors (front, back, left and right)
  • Interference between sensors
  • Update rate when we have 6 sensors on the same bus which we might have to run one-by-one to avoid interference

The current status is that we’ve verified the electronics and written the I2C GPIO expander drivers to test all the sensors. The next step is to work on a new VL53L0x driver to allow multiple sensors running at the same time, which will force some refactoring of the firmware.  Once we’ve made some more progress we’ll do another post and report the results. If you have any feedback on the design/concept or have any ideas of what the deck could be useful for, don’t hesitate to drop a comment below.

Flow breakout

  2017-08-07  |     |    Leave a comment

Last week we released the Flow deck, it enables you to get really stable autonomous flight with the Crazyflie without requiring an external positioning system. We have been lucky to get access to the brand new Pixart PMW3901 optical flow sensor, the core of the Flow deck, very early and we wanted to bring this awesome functionality to everyone, including those without a Crazyflie. The solution is the Flow breakout board, it enables anyone to use this new optical flow sensor for any kind of motion tracking.

The flow breakout contains a PMW3901 optical flow sensor and a VL53L0x time of flight ranging sensor, the same sensors that are mounted on the flow deck. We have also added voltage translation logic that allows you to use the flow breakout with a system voltage of 3 to 5V that makes it possible to use it directly with any Arduino board and most embedded system. Further more we have written an Arduino driver for the PMW3901 optical flow sensor to make it easy to use the breakout deck. For the VL53L0x there are already a couple of drivers available out there.

The flow breakout is currently being manufactured and will be available in our shop in a couple of weeks. If you want to be notified of the Flow breakout board availability, please sign up in the shop or follow us on twitter.

Crazyflie-based quadcopter with Raspberry pi camera

  2017-07-31  |     |    6 Comments

There have been a few requests from the community for a brushless Crazyflie and we blogged about a prototype we are working on a few weeks ago. The most common reason for wanting brushless motors is to be able to carry more load, in most cases a camera. A camera could be used for FPV flying or open up various image processing use cases like understanding the would around the drone using SLAM. Image processing on-board requires quite a lot of processing power and the CPU in the Crazyflie could not handle that, so more processing power would be required for a scenario like that. It is summer time (with a slight touch of play time) so we wanted to see what we could do with the CF Rzr and if it would be a useful platform for these types of applications. We hope that we might get some insights on the way as well.

We set the goal to try to add a camera, a small “computer”, the Flow deck for assisted flying, FPV capabilities and support for a standard RC controller.

We chose the Raspberry pi zero-w in order to get video processing and video streaming from the quad as well as more computing power. The Raspberry pi zero is not the most powerful board our there but it has a couple of advantage for our prototype:

  • It has a readily available, good quality camera and good software support for it
  • It has an analog video output and hardware streaming support, which means that the quad could be flown FPV using the Raspberry pi camera
  • It has hardware JPEG and H264 encoders that will enable us to save and stream images and videos if we want to

Raspberry pi and camera mounted on the top part of the frame

For assisted flight and improved stability, the XY-part of the Flow deck works fine outdoors but the laser height sensor on the deck has a maximum limit of 1-2 meters, and further more it does not go well with direct sunlight. We decided to add an ultrasound sonar distance sensor to measure the height instead. The ultrasound sonar connects via I2C and was simply soldered to a breakout deck that plugs into the CF Rzr.

Crazyflie Rzr with ultrasonic sonar, breakout deck and flow deck mounted on the lower part of the frame

The first step is to see if we can physically fit everything on the frame. With some 3D printed mounts for the camera and the Raspberry pi, we think it starts to look pretty good. Next step will be to squeeze in the FPV video transmitter board, the RC receiver board and finally connect everything together.

The current setup with everything mounted

We are far from done but it is a good start, and it is fun.

Crazyflie 2.0 Flow deck

  2017-07-24  |     |    2 Comments

We are pleased to announce the release of a new expansion deck for Crazyflie 2.0: the Flow deck. The flow deck is a new expansion board for Crazyflie 2.0 that contains an optical flow sensor from Pixart and a ranging sensor. These two sensors allows the Crazyflie to understand how it is moving above the floor and using this information the Crazyflie can fly itself.

The Flow deck can be used for manual flight where it allows to super easily fly the Crazyflie: if you realease all joystick the Crazyflie just stays there and hovers! The flow deck is even more interesting when used in combination with scripting: it is now possible to script the Crazyflie movement to achieve autonomous flight without needing any external positioning system.

Link to video

The Flow deck is available in the Bitcraze shop and at Seeedstudio.

Multi-robot Path Planning for Flying-and-Driving Vehicles

  2017-07-06  |     |    Leave a comment

This week’s Monday post is a guest post written by members of the Computer Science and Artificial Intelligence Lab at MIT.

One of the focuses of the Distributed Robotics Lab, which is run by Daniela Rus and is part of the Computer Science and Artificial Intelligence Lab at MIT, is to study the coordination of multiple robots. Our lab has tested a diverse array of robots, from jumping cubes to Kuka youBots to quadcopters. In one of our recent projects, presented at ICRA 2017, Multi-robot Path Planning for a Swarm of Robots that Can Both Fly and Drive, we tested collision-free path planning for flying-and-driving robots in a small town.

Robots that can both fly and drive – in particular wheeled drones – are actually somewhat of a rarity in robotics research. Although there are several interesting examples in the literature, most of them involve creative ways of repurposing the wings or propellers of a flying robot to get it to move on the ground. Since we wanted to test multi-robot algorithms, we needed a robot that would be robust, safe, and easy to control – not necessarily advanced or clever. We decided to put an independent driving mechanism on the bottom of a quadcopter, and it turns out that the Crazyflie 2.0 was the perfect platform for us. The Crazyflie is easily obtainable, safe, and (we can certify ourselves) very robust. Moreover, since it is open-source and fully programmable, we were able to easily modify the Crazyflie to fit our needs. Our final design with the wheel deck is shown below.

A photo of the Crazyflie 2.0 with the wheel deck.

A model of the Crazyflie 2.0 with the wheel deck from the bottom

The wheel deck consists of a PCB with a motor driver; two small motors mounted in a carbon fiber tube epoxied onto the PCB; and a passive ball caster in the back. We were able to interface our PCB with the pins on the Crazyflie so that we could use the Crazyflie to control the motors (the code is available at https://github.com/braraki/crazyflie-firmware). We added new parameters to the Crazyflie to control wheel speed, which, in retrospect, was not a good decision, since we found that it was difficult to update the parameters at a high enough rate to control the wheels well. We should have used the Crazyflie RealTime Protocol (CRTP) to send custom data packages to the Crazyflie, but that will have to be a project for another day.
The table below shows the mass balance of our miniature ‘flying car.’ The wheels added 8.3g and the motion capture markers (we used a Vicon system to track the quads) added 4.2g. So overall the Crazyflie was able to carry 12.5g, or ~44% of its body weight, and still fly pretty well.


Next we measured the power consumption of the Crazyflie and the ‘Flying Car.’ As you can see in the graph below, the additional mass of the wheels reduced total flight time from 5.7 minutes to 5.0 minutes, a 42-second or 12.3% reduction.

Power consumption of the Crazyflie vs. the ‘Flying Car’

 

The table below shows more comparisons between flying without wheels, flying with wheels, and driving. The main takeaways are that driving is much more efficient than flying (in the case of quadcopter flight) and that adding wheels to the Crazyflie does not actually reduce flying performance very much (and in fact increases efficiency when measured using the ‘cost of transport’ metric, which factors in mass). These facts were very important for our planning algorithms, since the tradeoff between energy and speed is the main factor in deciding when to fly (fast but energy-inefficient) versus drive (slow but energy-efficient).

Controlling 8 Crazyflies at once was a challenge. The great work by the USC ACT Lab (J. A. Preiss, W. Hönig, G. S. Sukhatme, and N. Ayanian. “Crazyswarm: A Large Nano-Quadcopter Swarm,” ICRA 2017. https://github.com/USC-ACTLab/crazyswarm) has made our minor effort in this field obsolete, but I will describe our work briefly. We used the crazyflie_ros package, maintained by Wolfgang Hönig from the USC ACT Lab, to interface with the Crazyflies. Unfortunately, we found that a single Crazyradio could communicate with only 2 Crazyflies at a time using our methods, so we had to use 4 Crazyradios, and we had to make a ROS node that switched between the 4 radios rapidly to send commands. It was not ideal at all – moreover, we had to design 8 unique Vicon marker configurations, which was a challenge given the small size of the Crazyflies. In the end, we got our system to work, but the new Crazyswarm framework from the ACT Lab should enable much more impressive demos in the future (as has already been done in their ICRA paper and by the Robust Adaptive Systems Lab at Carnegie Mellon, which they described in their blog post here).

We used two controllers, an air and a ground controller. The ground controller was a simple pure pursuit controller that followed waypoints on ground paths. The differentially steered driving mechanism made ground control blissfully simple. The main challenge we faced was maximizing the rate at which we could send commands to the wheels via the parameter framework. For aerial control, we used simple PID controllers to make the quads follow waypoints. Although the wheel deck shifted the center of mass of the Crazyflie, giving it a tendency to slowly spin in midair, overall the system worked well given its simplicity.

Once we had the design and control of the flying cars figured out, we were able to test our path planning algorithms on them. You can see in the video below that our vehicles were able to faithfully follow the simulation and that they transitioned from flying to driving when necessary.

Link to video

Our work had two goals. One was to show that multi-robot path planning algorithms can be adapted to work for vehicles that can both fly and drive to minimize energy consumption and time. The second goal was to showcase the utility of flying-and-driving vehicles. We were able to achieve these goals in our paper thanks in part to the ease of use and versatility of the Crazyflie 2.0.

Prototype of a brushless Crazyflie

  2017-06-19  |     |    24 Comments

For a while now we have been selling the BigQuad deck which makes it possible to transform the CF2 to control a bigger sized drone. It does so by becoming the quadrotor control board, controlling external brushless motor controllers, which allows to scale up the size. This can be very convenient when trying out/developing new things as it first can be tested on the small CF2 and later scaled up by attaching it to a bigger quad. However for a more permanent setup it is a bit bulky, so we have been playing around a bit and designed something in the middle. The result is a stand alone control board targeting quads around 0.1 – 0.5kg.

We call it the CF-RZR as it is inspired by the smaller sized racers with some fundamental differences. It is designed with a higher level of autonomous functionality in mind and being easy to repair while still being fully compatible with the CF2 firmware and decks. Listing the biggest features of the current prototype:

  • Fully compatible with the CF2 firmware, expansion decks as well as radio.
  • Connectors to attach motor controllers (still possible to solder though) so it is easy to build and repair.
  • Power distributions built into controller board. (Max ~8A per motor controller though)
  • Motor controllers can be switched of by the system so the system can go into deep sleep and consume around 50uA.
  • Voltage input 1S-4S (3V to 17V)
  • Standard mounting (M3 mounting holes placed 30.5mm square)
  • External antenna for increased range

To summarize, the strength of the CF2 but in a little bit bigger package :-). Last week we got a chance to test fly it for the first time. We used a off the shelf racer frame, ESC and motors. At first it did not fly that well at all but after some PID tuning it became pretty stable and we had a lot of fun :-).

We would love your feedback, good/bad idea, what do you like/dislike etc!

Link to video

Loco positioning tag

  2017-05-08  |     |    6 Comments

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?

Crazyradio: past, present and future

  2017-05-02  |     |    9 Comments

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 ;-).

Z-ranger deck now availible

  2017-04-18  |     |    Leave a comment


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.

New decks and presentation at FOSDEM 17

  2017-01-30  |     |    Leave a comment

In this beginning of 2017 we are proud to announce that there are two new decks for the Crazyflie 2.0.

The first one has been in the works for quite some time, it is the Micro SD card deck. It enables read and write access to a SD-Card from the Crazyflie firmware (where we have also implemented FAT filesystem support). Our first use case for this deck has been to implement high speed logging of the IMU sensors: the SD-Card has much higher bandwidth than the radio so it allowed us to log all the sensor values for later analysis. Another use-case could be to read an autonomous sequence from a file on the SD-Card and implement fully autonomous sequencing in the Crazyflie when used in the Loco Positioning System for example. The SD-Card deck is already available on Bitcraze web-shop.

The Second deck is the Z-Ranger deck, it is a laser time-of-flight ranging deck that measures the distance to the ground. We talked about this deck in a previous post. The manufacturing of the deck should be finished soon and so it will be available in our shop shortly. When using this new deck, the altitude hold stability between 0 and 1.5 to 2m height is greatly improved.

On a final note, FOSDEM 2017 is this coming up this weekend and we are looking forward to meet you there. There will be two presentations related to the Crazyflie, if you want to meet us come at these presentations or get in touch in the comment or by mail. The two presentations are:

We hope to see you there!