We have a busy schedule in the fall, since we are planning to travel all around the world for all kinds of awesome conferences and symposia. Here is a quick overview of where we are planning to go in October and November.
IMAV Madrid 1/10-4/10
We will attend the IMAV 2019, and this time it is in Madrid (Spain) from the 1th to the 4th of October. This is a conference for anything related to micro-aerial vehicles and also includes an awesome indoor and outdoor competition. Arnaud and Kimberly will be present at both the indoor and outdoor fair, where we will show some demos with the lighthouse system and show off our new Crazyflie Bolt!
In collaboration with our partner CLRobur, we will have a symposium in Seoul (Korea) on the 14th and 15th of October. Kristoffer will explain the attendees all about positioning systems, and show off the LPS and our new lighthouse deck.
Sign up here or send an email to clrobur@naver.com
IROS Macau 4/11-8/11
Last but not least, we will be there at IROS 2019 as well! This is one of the flagship robotics conferences of IEEE. In Macau (China) from the 4th till the 8th of November, Marcus and Tobias will show some awesome demos with the lighthouse system and hopefully we will present the new AI deck!
We have so many interesting things we want to do, but too little time to do it. Now we are looking for more talented people to join our team to help us create awesomeness!
We don’t have a clear description of exactly what we are looking for but there are some properties that we think are important:
You are interested in technology
You are passionate
You want to learn new things and evolve your skills
Hello everyone, I’m Victor and you probably haven’t heard of me yet but I’ve got the awesome opportunity to spend some weeks during this summer working at Bitcraze. Working… Well, I’ve spent the majority of my time here getting invaluable experience, programming, flying with drones, eating incredible falafel and having fun so it’s really been a pleasure.
I’m quite new to both programming and electronics, so while I haven’t created any huge masterpieces of code yet, I did make a small program with a GUI that let you test the health of motors and propellers of the Crazyflie. You can run multiple ones simultaneously (I’ve tried up to 8, which works fine, even with a single radio, and you should be able to run many more) and it relies on using either Lighthouse or a Flow deck for positioning. The propeller-test is essentially the same test as the one integrated with the cfclient, however the motor-test checks the thrust-levels of the motors (by hovering in the air for x seconds) to see if any of them are off and ranks them as good/bad. The default threshold is 15% but can be changed according to needs. The program is written in Python and uses tkinter to run the GUI application and the cflib to communicate with the Crazyflie. The script can be found here.
In the end of August I’m going to study Computer Science and Engineering which I’m extremely thrilled about and this has really been a perfect preparation for that! In the future I hope to contribute to the Crazyflie projects and learn more from the great team here at Bitcraze.
The High-level Commander has been part of the Crazyflie firmware since the 2018.10 release. In combination with a positioning system, it can fly the Crazyflie along a trajectory that is either defined in the firmware or uploaded through the python lib. It originates from the Crazyswarm project and we have used it in various demos since it is possible to make trajectories that are very fluid and looks really cool. The trajectories are defined as 7th degree polynomials describing segments executed one after each other.
The controller gives full control of position, velocity, acceleration and jerk, the only problem is that it is non-trivial to generate the polynomials. We have wanted to simplify the creation of trajectories for a long time and have finally had some time to play with it. In this blog post we will describe how it can be done with Bezier curves and show some examples.
Each segment in a High-level commander trajectory is defined by four 7 degree polynomials, one for x, y, z and yaw. There is also a scaling parameter that tells the controller the time scale to use when executing the segment. Using polynomials of degree 7 makes it possible to design trajectories that are continuous in position, velocity, acceleration and jerk when changing from one segment to the next, which is important to get a smooth and controlled flight.
Bezier curves are common in many graphics applications and are probably known to most users. They are parametric curves defined by control points, usually three or four. Bezier curves can also be expressed as a polynomial, and this is what we will use in this case. To get a correct mapping to the desired polynomials we need some more control points and will use 8 per segment. The basic idea is to define the trajectory as Bezier curves and make sure the control points are placed in such a way that the continuity requirements are satisfied.
Bezier curve with 8 control points
On this page from University of Cambridge, there is a good explanation on continuity across the joins between curves and formulas for c0, c1 and c2 continuity. We also need c3 continuity which can be calculated in the same manner
With these formulas it is possible to set the handles of the Bezier curves to make sure we get a smooth ride.
We have added a python example that implements the ideas above. You can find it in crazyflie-lib-python/examples/positioning/bezier_trajectory.py. The design is based on Nodes that represents the connection points between bezier curves (called Segments). The Nodes has a set of handles that are shared between the Segments that use the Node. If not all handles are set the implementation will set them to appropriate values, see the comments in the code for more details. The Node API only allows the user to set handles on one of the Segments, the handles for the other segment are automatically set to generate a continuous trajectory.
The example uses nodes in the corners of a square and contains three parts:
No velocity in the nodes. The Crazyflie stops in the Nodes. Similar to calling go-to in the HL commander.
Velocity in the nodes. A fluid motion all the way around.
Velocity in the nodes. A fluid motion all the way around.
A bit more aggressive settings to get a little action.
Finally a video showing the full sequence, we use the Lighthouse for positioning.
A lot of you are using our forum on a regular basis. From our point of view, we prefer giving support and guidance on our forum instead of by email, since solutions we provide to our users can be found by others as well. However, we are experiencing some spam-related issues with the forum!
Somewhere last week, our forum started getting some weird posts, including some links to websites that are…. not exactly Bitcraze or Crazyflie related… We didn’t think about it too much, so we cleaned the forum, deleted the users responsible and moved on. But the very next day more spam post appeared, and it was getting so bad that we changed our sign-up from the regular security question to Captcha. Unfortunately, spambots are way too smart these days, so that didn’t work either… By the end of the weekend we had to remove over an hundred spam accounts and 500 spam posts!
The forum is experiencing a major spam attack at the moment and the usual security measures are not helping. Since yesterday, we enabled manual activation of new users (meaning that we physically need to approve each account), since currently this is the only way to catch the dodgy new accounts (we already caught over 100 in one day alone !!). This week we will look into other measures and plugins to better secure our forum, so we don’t have to manually go through all the newly registered users to see if they are not spam bots. We heard about Cleantalk by one of our users, so we probably will give that a go!
However, please be contact us if the following occurred or is occurring to you in our spam removing frenzy:
If we accidentally removed a post of you
If we removed or banned your account
If we are not activating your new account
Also make our lives a bit easier this week, and send us an email straight away if you have just have made a new account on the forum. Send an email to: contact@bitcraze.io with your username and a sentence about why you are using the Crazyflie (so we know that you are real).
This is only a temporary solution, so hopefully at the end of this week or the next we will not need to worry about this anymore :).
Our usual blog posts usually consists of the awesome new products and demos that we make here at Bitcraze, but now we will talk about… documentation! Alright alright, it is maybe not the most thrilling topic, however you should be excited about it! Good documentation about the Crazyflie and its tools will not only enable you to recreate the demos and the work of others, but also to implement your own ideas and to contribute to our open-source firmware.
In the years that Bitcraze has been around, there has been quite the build-up of information, which can be either found on the main website, the wiki, the github repositories, and in bits & pieces on the forum. Although we try to provide all the information necessary for getting started with development, it is currently quite a clutter. If we at Bitcraze already have difficulty of finding and maintaining all the documentation, we can only imagine how difficult it would be for a starting developer. We therefore would like to improve the flow of information dramatically!
Here are some ideas of what we would like to do with the documentation:
Moving product information to the shop.
LED ring expansion deck in the main website, shop, and wiki.
Currently there are three different locations where you can find information about physical Crazyflie, localization systems or expansion decks, which is the main website, the online store and the wiki. We see that a lot of electronic and hardware shops usually put all the details of the product directly on the product page of their shops. We aim to do that as well, since there will only be one page for users to go to for schematics, specifications, instructions and more, and for us it will be also easier to maintain and update any product information
Moving Software Info to GitHub
There is a lot of bits and pieces of information to handle the firmware on the Crazyflie and all the tools in the tutorials on our main website, wiki and Github repository. This again makes a lot of duplicate information, which is difficult for us to maintain and therefore gets easily outdated. We could put all the information on the wiki, but what if somebody changes something in the code which requires a change in the procedure as well?
Create a /doc folder on the repositories to better structure all the information
Add more Doxygen comments to all the function in the the codes and automatically generate documentation for this.
Restructuring the Wiki Content
After moving all the hardware- related content to the shop, and moving all the firmwar- related info to the Github repositories, we will need to think about what we want to do with the Wiki! You would think that there is nothing left to put on the wiki anymore after the replacement of the earlier documentation, but we beg to differ! For instance, there is so many Github repositories that there is a really a need for an overview. The wiki can educate developers on which tools we have an how to properly use them. Of course, we already have the getting started tutorials, but we want to also provide a more in-depth explanation of the overall structure and how the different repositories would need tho work together, like this .
This does mean that we would need to restructure the wiki entirely and only focusing on topics like:
System Architecture Crazyflie
Communication protocol between STM and the NRF
Communication protocol between the Python library and the Client
Overview Github-repositories
Projects and hacks
etc etc
What do you think?!
Of course we can change all we want in the documentation, but you guys are the ones who actually use it! We are very curious of what what you think of the plans and give us more tips or suggestions on how to improve the overall documentation experience. Please leave a message below or express your opinion on this forum thread.
Many of our users are flying larger and larger swarms and we’ve been getting some feedback that there’s communication issues when connecting to many Crazyflies. So during the last weeks we’ve been looking at this. Among the things we’re doing is building a test rig where we can automate the communication testing (last weeks blog post). We’ve also fixed a few communication issues listed below.
One of the issues causing problems is dropping packages coming in to the Crazyflie. If the flow of packages was too high to one CRTP port these would start dropping. This has now been fixed by increasing the length of the queues for each port. (GitHub issue)
Another issues has been logging data piling up after disconnect. The detection for the radio disconnection was boken so logging data would continue to be generated and pushed into the communication stack. This has now been fixed so logging will be reset which should clear up he congestion on the next connect. (GitHub issue)
Lastly we also fixed the USB communication issue with dropped packages and crashing when the USB was disconnected. (GitHub issue)
We’ve already noticed a few other issues when using the rig so there should be more fixes coming soon. In the meantime test out the new firmware and let us know if there’s still issues.
3 of us where at ICRA 2019 in Montreal last week, where we met a lot of interesting people and a lot of Crazyflie users. Thanks a lot to everyone that drop by our booth, and for the ones that missed it we are planning on being at iROS2019 later this year so we might see you there :-).
We have already described our demo in a previous post, now that we run it we can update on how it went. We are also updating the ICRA2019 page with the latest source code and information so that anyone interested can reproduce the demo.
In its final state at the conference, the demo contained 8 Crazyflies 2.1 equiped with Lighthouse deck and Qi charger deck. There were 8 3D-printed charging pads on the floor with Ikea Qi wireless chargers and two HTC Vive base stations (V1) on tripods. The full system was contained in a cage, built from 50 cm-long tubes or aluminium and nets.
The full setup of the booth took us about 4 hours, this included about 3 hours for the cage, 15 min for the demo including calibration of the lighthouse base-station geometry and the rest to fine-tune things. This is by far our best setup time, we still need to prettify the cage a bit and to make is easier to install, but we will most likely re-use this system for upcoming conferences.
In this demo we aimed at keeping a Crazyflie in the air at every moment, to do so we had a computer connected to all 8 Crazyflies sending to one of them the signal to start flying if no other where actually in the air flying a trajectory. The flight was completly autonomous as we explained in our previous blog post. We setup the Crazyflie to fly 2 cycles and then land, which increase the rate of swap and so increased the ‘action’, though it also meant that during the swap two Crazyflies where flying. This drained the batteries a bit more than expected and meant that after about an hour all the Crazyflies where bellow the take-off threshold and we had to wait ~30 seconds between flights. Here is a video of it in action:
The demo was very care-free, we had very few Crashes and we mostly restarted the Crazyflies to swap batteries manually to add a bit of power in the swarm. The last day we decided to spice it up a little bit by adding a chair in the cage and by calibrating the chair position and flight trajectory, we managed to have the Crazyflie partly fly under it. This worked quite well most of the time and showed that the lighthouse positioning is repeatable and works fairly well with short occlusion in the path. Though we also found out that even though a single Crazyflie would always fly the same trajectory, two different Crazyflies will not. We think differences in propeller stiffness and the fact that the our Mellinger position controller has not been calibrated for changing YAW are the main reasons.
If you want to know more about the demo or if you want to reproduce it do not hesitate to visit the ICRA 2019 page that explains it in more details and links to the source code of everything including 3D printed parts for the cage and the landing pads.
Hi, very nice to meet you all! My name is Kimberly McGuire and I would like to introduce myself as the newest member of the Bitcraze team. Although I probably have never written anything bigger than a paragraph about myself before, but I will try my best to get you to know me a little better!
The first thing you should know about me is that I’m Dutch. I grew up in the Netherlands, which is a small little country that has fought for eternity against the sea and still managed to exist. If you do visit and would appreciate some impressive pieces of Civil Engineering, don’t linger around in Amsterdam but visit the “Delta werken” in the province of Zeeland or the ‘Afsluitdijk” in the north. But if you don’t like to take your chances near our oceans, ‘Utrecht’, ‘Groningen’ and ‘Maastricht are really nice to visit too! Probably my last name already gave it away, but I’m also half-American and I visit California almost once a year.
So, let’s talk about hobbies! I have played tennis for almost all my life (started when I was just 6 years old), and I’ve played competitively in tournaments and team-based competitions. You can also find me skiing on some mountains at least once per year. In general, I really love visiting other countries and to experience the culture and, most importantly, the food. During my studies I’ve managed to go on extended stays abroad: I’ve spent a half a year in Santa Barbara, 3 months in Liverpool, a half a year in Tokyo. Talking about the latter: I’m a huge fan of pretty much everything related to Japan. All their food, Ghibli studios and other Japanese productions, the culture and people, and I do admit that I’m quite the karaoke addict. Moreover, I love going to the movies, playing videogames, and enjoying Dutch coziness, a.k.a. “gezelligheid”, with friends.
To show in a slice of my educational background: for my Bachelor studies at the Delft University of Technology, I started out at Industrial Design Engineering. Here I learned everything there is to know about product development, from analyzing market-trends, creating concepts to finally to the full production process. For my Masters I was leaning more towards the technical side. After a bridging course to Mechanical engineering I went to do an M.Sc. in BioMecanical design with a specialization in Bio-Robotics (currently known cognitive robotics). I ended developing a cerebellum-based stabilization system for a binocular robotic head (google “jaguar chicken commercial”:) ). After this, I came across a project at the MAVlab where I was allowed to work with tiny MAVs called pocket-drones, and the first thing I thought was ‘awesome!!’, however, that was before I realized that working with tiny MAVs was not a piece of cake. I’m glad that the inner-geek in me kept me excited for 4 years straight, which is a crucial element or any PhD I believe, or any job!
So now a new chapter will start for me in Sweden. I hope that I will append to Bitcraze’s vision and I’m quite sure that they will teach me how to become a better hardware and software developer. I’m excited to start working with Arnaud, Marcus, Kristoffer and Tobias and develop more things that will make any’s inner-geek jump a little from excitement. At the moment of writing, we will be on ICRA in Montreal, Canada, so jump by booth 101 to say hi!
