Category: Mechanic

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.

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.

A while ago I started working on a brushless motor control driver for the Crazyflie. I implemented most of it but did not really have time to test it. Recently we have gotten some request and questions about it so we took some time to do some further testing.

Implementing a brushless motor control driver can be done in many ways. If you have brushlesss motor controllers that can be controlled over I2C that could have been one way but usually the brushless motor controller (BLMC) take a PWM input. This is most commonly a square wave with a period of 20ms and a pulse width of 1-2 ms high, were 1 ms is 0%, and 2 ms is 100%. A period of 20 ms means a frequency of 50Hz. This is most often a high enough update rate for R/C electronics like servos etc. but when it comes to BLMC that is not the case. Therefore many new BLMC can read a much higher update rate of up to 400 Hz were the pulse still is 1-2 ms high. That way you can match the BLMC input to the update rate of the stabilization control loop and increase stability. In the code we added a define BLMC_PERIOD where this can be set.

To test this we wanted a frame which was quick to setup and found this. It is based of a PCB just like the Crazyflie and has the four motor controllers with it, perfect! The built in BLMC are based on an the Atmel MCU Atmega8 which is very commonly used in the R/C BLMC which means it is possible to re-flash them with the SimonK firmware. This is know to be a great firmware and enables fast PWM update rate etc. So we built and flashed the firmware configured for the tgy6a which is compatible and it worked right away, yay!

Now we only had to connect the Crazyflie to the BLMC:s on the frame. The BLMC electrical interface for the PWM signal is often a 5V interface but the Crazyflie runs on 2.8V. 2.8V would in most cases be treated as an high input and can probably be used directly but there is no simple way to connect this signal on the Crazyflie. Instead one way is to use the existing motor connectors and the pull-down capability that is already there. Then it is also possible to pull this signal to 5V with a resistor to get a 5V interface so this is what we did. To power the Crazyflie we took the connector of an old battery and soldered it the 5V output of the frame.CF to BL Frame connections

Now it was just a matter of testing it! However as size increases so does the potential damage it can make. We therefore took some precaution and tied it down. First we tested the stability on each axis using the stock values and it worked really well so we decided to not tune it further. The only issue was that suddenly one of the BLMC mosfets burnt. We replaced it and it worked again but don’t know why it burnt. Later when we flew it something was still strange so we have to investigate this.

We will upload the code as soon as it has been cleaned up. Please enjoy a short video of the journey 🙂

We hope everyone had a great holiday! We are really happy that some of you decided to join our holiday challenge. After looking though all of the submissions we finally decided on a result.

First of all there was the mechanical challenge of creating a hull or cover for the Crazyflie. When finding the winner we looked at features such as wight, design and manufacturing. After a long discussion we decided on Gottfried Dungl’s submission, the Crazysheild, that you can see below. Even though it might be tricky to manufacture/3D-print, it’s lighter than the other submissions while still being durable as he showed by crash simulations.

Crazyshield submitted by Gottfried.

Crazyshield submitted by Gottfried.

 

Secondly there was the free-fall detection and recovery. For this challenge we only got one submission and it’s from Oliver Dunkley. That doesn’t matter since his solution works really well and has great potential. The implementation is done in the Crazyflie client, where both free-fall detection and recovery is done. There’s lots more information about this solution which we will post on the wiki or forum during the week. You can have a look at the code here.

 

Great job and big thanks to everyone that participated! Gottfried and Oliver will receive a Crazyflie 10-DOF kit and we have also decided to reward all others that participated with a little gift so check you email ;).

 

With roughly one week to go until the holidays most people are still stressing about getting presents, food and trees. We have done our best to get into the holiday spirit, but December isn’t well known in the south of Sweden for delivering a white Christmas. So with no snow and +7ºC outside it’s a bit hard to get into the holiday spirit.

After the holiday stress has leveled out, you might find yourself having some extra time on your hands. Being off from work is great, but unless you get tech toys for Christmas you might get some abstinence being away from your high-tech things. At least we get this feeling. So this year we thought that we would try to help everyone that is a bit bored during the holidays, by announcing a little competition! We have two different categories of fun things to do: Mechanical and software.

  • Software: Controlled decent when free falling
  • Mechanical: 3D model for a plastic hull

For the first category the goal is to implement a controlled decent of the Crazyflie. The idea is to do this without any user interaction. Imagine dropping the Crazyflie from your hand and the controlled decent algorithm kicks in and lands it graciously without the user doing anything. Or why not throwing it away 🙂 This could be implemented using firmware, host software or a mix of the two. Here’s roughly what we had in mind:

  • Connect to the Crazyflie and enable controlled decent mode in free fall
  • Pick up the Crazyflie and drop it (preferably above a soft surface)
  • The free fall can be detected using the accelerometer. When in free fall all three axis of the accelerometer will be very close to 0 (see image below)
  • Control the decent of the platform and land graciously (unlike in image below 🙂 )
Crazyflie free fall

Plot of accelerometer before, during and after free fall from 1,5 meters

 

For the second category the goal is to create a nice looking body for the Crazyflie. A while back we put together a home made vacuum plastic molder (something similar to this). Our idea was to create a 3D model of a body and then use it as a base for the vacuum molding hack. The end result would be very durable and light. The only problem is that we are really bad at 3D graphics (and at graphics in general) so this has been a blocker for this hack. We need some help with creating the 3D model. If you don’t have a Crazyflie you can always have a look at the mechanics repository. It contains a great model of the Crazyflie that Erik did a while back.

Aside from satisfying the geek inside you during the holidays, we will also be awarding the winner of each category with a Crazyflie Nano Quadcopter 10-DOF with Crazyradio and additional spare parts! In order for the projects to be judged we will need some video/images and code/model. The projects will be judged on how good the solution works and also how good the implementation is. The competition will end on Sunday the 12th of January and we will announce the winners in our Monday post on the 13th of January.

So what will we be doing during the holidays? Well we had something else in mind. A couple of weeks ago we picked up a uBlox MAX 7 GPS breakout. It’s about 2.1 grams with a chip-antenna and is small enough to fit on the Crazyflie. We won’t exactly have path-following functionality after the holidays, but we are hoping for something that will report back the location to the client.

Happy hacking!

Edit: We forgot the most important part, where to submit your entries if you want to join in. Send them to holiday_hacking_2013@bitcraze.se before the end of 12th of January 2014.

We have been in need of a 3D printer for a while now, in order to print parts designed by community members and also prototype new parts. After talking about it for ages we finally got around to buying an Ultimaker. For now we have mostly been playing around (printing various things found online) but our plan is also to make some models that users can print themselves. Let’s see if we run out of plastic before we get that far 🙂

Below are some parts we printed. The Crazyradio cover designed by foosel and the frame designed by VGer.

Bitcraze Ultimaker

 

Thanks to some of the motor mount feedback we have now managed to improve the motor mount a bit. It now has a longer extruded cylinder and a larger stop to prevent the motor form popping out when landing hard. This should add a bit more protection but it is still a good idea to do one of the mods described in the wiki for even better protection, especially when expecting to do some hard crashes.

Motor mount v2

Motor mount v2

The improved motor mounts will be available in the next batch of kits, which is still scheduled to be ready in the end of June, and also as a separate spare part item. For the next batch the Crazyflie kit without the Crazyradio and antenna will also be available for ordering.

On another note we are planning on modifying our webpage a bit. We feel that when new people visit our webpage they get no overview of our projects. So we are planning a nicer landing page with some images and more general information. We will of course keep the blog and also keep updating it at least every Monday. Aside from this we are also planning on integrating the forum and wiki with the blog and also have the same theme. After doing a quick test with the forum we are pretty sure our green/black theme will look good, but we aren’t that convinced about the wiki…. Let’s see where we end up. If you have any suggestions or comments about the webpage and our plans then  don’t hesitate to leave a comment below.

Lastly we have also installed TapaTalk on our forum. So if you use the TapaTalk app you can find our forum in the directory by searching for Bitcraze.

After one week of flying the new copters we have to say that they are preforming very well. We’ve done a lot of crashes but only had one incident with a bent axis on one of the motors which we fixed by replacing the motor.

We have noticed that using some radio channels in combination with some link speeds causes too much packet drops when the motors are powered. It’s almost certainly the PWM that causes ripples on the power supply and that effects the radio transmission. It was by chance we saw this and changing the channel or speed works around the problem.

Currently we are working with Seeedstudio to sort out the details for starting up but we don’t have an estimate for when it will happen yet. But one thing is for sure, we will go with the rapid-prototype mounts for the first DIY kit. We are still working on the details for the molded motor mounts but since there’s a lot of leadtimes for this it would delay the kit with months and we really don’t want that. Since after the summer we have been using the same design for the rapid-prototype motor mounts and we have only had 2 that has broken.

The plan is to package 1 spare motor, 1 spare motor mount and 4 spare propellers with the kit. There will also be extra spare parts available for purchase.

On Wednesday we assembled and tested all of the kits in the pre-series. We ran though the production tests, that will be used once the kits are produced, as verification. Since we can’t test that they really can fly the test isn’t covering everything but it checks most of the components. One of the units had a solder-bridge between two of the MPU-6050 pins and our tests showed that the unit was faulty. We are glad our tests caught the problem and removing the short fixed it.

The assembly doesn’t take too long and once you have done a few it’s fairly quick. We timed the last one we assembled and it was finished in just under 10 minutes (including fixing errors that were made 🙂 ). And that time was done by the worst solderer of us! As long as you are a bit steady on you hand it should be ok. It was a really great feeling unpacking, assembling, testing and then directly flying them! We numbered all the units and will track them if there’s any problems. So during the next weeks we will be flying a lot :-). We cross our fingers that they will hold up to what we expect.

The change we did where, connecting the motors directly to the battery and not through the power management chip, turned out great and we could feel the 8% increased power difference (it might have been some placebo effect but it just feels great).

To sum it all up it was a great night and we are really happy with the results! We remember in the beginning when we had to be in a pretty big room to be able to fly the Crazyflie at all and now it’s so stable you can (if you are brave enough) hover it 10 cm in front of your face and then push the throttle and it swishes away!

As for the project progress we are now discussing with Seeedstudio on how to carry on and we are trying to sort out the motor mount problem and some smaller issues.

We’ve also spent some time creating a new page on the wiki describing the hardware. It’s still a work in progress, but there’s a lot of information. We will continue updating the wiki whenever there is time.

Head over to our Picasa albums for more pictures.

 

While we are waiting for the pre-series to arrive, which hopefully will be within 4-5 weeks, we have tested this idea we have had for a while. On the Crazyflie PCB we placed mounting holes in each corner for the possibility to add e.g. a landing gear, canopy or maybe a protective frame. The holes are about 0.9mm and plated so it is possible to solder something in it and a protective frame made of piano wire would be a good candidate.

We bought a couple of 0.8 mm thick 1m long piano wires at a nearby hobby store and got to work. On the first try we bend the wires into the shape solely by hand and it didn’t look or work well at all. We figured there must be some better way! And after searching the net we found this site explaining how to make your own DIY springs of different types. We however needed a circle with a much bigger diameter than normal springs use so it took us a while to find a tube with the right diameter to bend it around to get the right size. We found out that when bending the piano wire around a tube with the diameter of 20mm it ended up at about 55mm which was close enough to the 60mm we needed. Piano wire is a bit hard to solder but with plenty of solder flux it works well. We are pretty pleased with the result!

The piano wire frame itself weights about 3.5-4g so it is within the acceptable payload limit. The flight characteristics is changed a bit making it more controllable but less agile which is perfect for beginners. We have tested throwing it in the ground and crashing it several times and the Crazyflie just bounces so it works great. It might even be possible to go to a smaller piano wire diameter to save weight because now the frame is very stiff. Next step would be to come up with a design that could be attached/detached without soldering. It should also be cheap and easy to manufacture.