We have worked hard last week to get a new fresh release out before the summer months are on our doorstep. Not only that we would like to make sure that important bugs are fixed before some of us go on our holiday, but also to be able to display our new AI deck features! Here is an overview of what has been changed
AI deck over air flashing
As you can probably see in the release notes of both the python libraries and the firmware, most of our changes are focused on making it possible to develop for the AI deck without using a programmer all the time. If the STM and NRF firmware of the Crazyflie is fully updated, and the ESP firmware on the AI deck, it should now be possible to flash an AI deck example binary with a Crazyradio! For older versions of the AI deck 1.X (Rev A to C) it is unfortunately still necessary to use the JTAG programmer one last time to flash a bootloader on the GAP8, but after that it should not be needed anymore.
In the light of the work we have done for the AI deck, we also have started to implement a new, inter MCU protocol called the Crazyflie Packet Exchange. Since with the AI deck, we are adding 2 additional microprocessors to the Crazyflie architecture, it was crucial to handle the communication between all platforms and communication channels properly. Currently the functionality is mostly enabled to tailor Wifi streaming and console printouts for the AI deck, but it is meant to be a generic protocol which in the future, should be able to handle more combinations like for instance, command messages through wifi?
For the last part of the Grand tour trip, we had a hackathon with the IMRC lab of TU Berlin and our close collaborator Wolfgang Hönig, in which we managed to convert the PID controller, Mellinger controller and the motor mixing into python bindings, which can be used in the experimental simulator of the Crazyflie.
There is no Pypi release of these, you will need to pull the latest crazyflie-firmware repo and build the bindings with ‘make bindings_python’
Additional fixes
We have some additional fixes to both the python libraries and firmware. For the STM we have updated the STD peripheral library and solved several build issues. For the cfclient, we fixed a lot of issues that were caused by either the latest version of python, as it was more stricter with type definitions, and some issues QT. Moreover, the LED ring headlight functionality has been restored, and the cfbridge.py script, used for the PX4 crazyflie 2.1 tutorial, is re-added, since it suddenly disappeared a few releases ago.
Update and Feedback
Make sure to update your cfclient with ‘pip install cfclient –upgrade’ and to reflash the new stable firmware. For AI deck users, try out our our new tutorial to try out both CPX, the over air flashing and the wifi example. The new AI deck functionalities has been subjected to some limited testing so if there is anything wrong or unclear, please let us know in the forum! The feedback will help the AI deck to become a more stable product for development, so we would be very grateful if you would be able to help out with that.
Since the pandemic, having a close relationship with our contributors, partners, distributors and generally speaking, users, have been a challenge. We tried to keep in touch as much as possible, by organizing our own conference, visiting labs in Europe, or asking for feedback.
Now that it seems the situation has gone back to almost normal (and I’m crossing all my fingers as I’m writing that, which makes typing difficult), we have exciting plans for the coming months for getting closer to the community. Here are some of the things we are cooking up:
Mini BAM
The closest one is actually next week ! We are hosting a short webinar where 2 of our close collaborators will present what they’ve been working on. Matěj Karásek from Flapper Drones will talk to us about his Bolt-based drone, that is set up with flapping wings. We got to try it out in our lab last week, and it looked amazing: we’re excited you’re getting a look too!
Matej will be followed by Gábor Vásárhelyi from Collmot that will introduce us to Skybrush, its platform for any kind of swarm/fleet/multi-UAV mission control.
We’re really grateful that Flapper Drones and Collmot will join us for our very first Mini Bam to talk about drones in show! Here are the details:
It starts at 15.00 CEST on May 18th.
If you’re interested in joining, please fill out this form, or contact us at contact@bitcraze.io. You’ll get an invitation to join the webinar.
After 2 years of online or hybrid conferences, we’re really excited to join the next one. And it’s a big one: IROS 2022, which will be held 23-27 october in Kyoto, Japan. We’re actually so excited about it that the whole company should be joining, if logistics and Corona let us. The situation in Japan is still uncertain, the country being still closed for tourism, but we are optimistic and hope for a week full of conference, meeting new people, and of course discovering a beautiful city all together. We’re planning on having a booth there, so if you plan also on visiting IROS, be sure to pass by and say hello !
We’re hiring
Of course, all of those plans take time… And we’re a little bit short on that, since (as I maybe mentioned before) we’re a little short handed right now. With only 6 people at Bitcraze, we’re getting frustrated: we have many projects, and too little time to work on them ! That’s why we have begun actively looking for a new Bitcrazer to add to our ranks. A job offer should be posted soon on our page: if you’re interested, keep an eye out for this, and be sure to let us know if you fill the profile (or someone who does!). We know it will be a long process to find the right fit for us, but we’re hopefully we will discover the person that will help us achieving all those plans – and even more!
We recently added improved support for assert information in the client and wanted to take this opportunity to describe some of the features in the console tab of the client that are useful for debugging and profiling.
Example of the console tab
The console tab in the python client is where you can get real time logs from the Crazyflie when connected. Any DEBUG_PRINT() statements in the Crazyflie firmware will popup here and is obviously a simple way of adding debug information to your firmware. The console logs are buffered in the Crazyflie and dumped to the client when you connect, this is why you will see the start up information when connecting to a Crazyflie. If too much information is logged and the buffer is full, you will unfortunately loose some of it but you will be notified by a “<F>” marker in the console window.
On the right side of the console tab window you will find some useful buttons, the first being the “Clear” button that simply clears the console window.
Task dump
The “Task dump” button will print a list with information about the FreeRTOS tasks running in the system, for instance something like this.
The “load” column contains how much of the total time that was spent in each task, since the previous measurement (or boot). To get useful values when performing some task, you probably want to make a dump at the start of your measurement and a second one at the end to get the average during this specific time.
The “Stack left” shows how many bytes of stack that is left for each task, this is the worst recorded number in the period. Stack size is recorded at task switch time which means it is possible that more stack actually was used at some point, but it should give a good indication if a task is running out of stack.
Assert info
Next up is the new “Assert info” button, it will dump assert or crash info to the console. When the STM CPU encounters a hard fault or some other condition that resets the CPU, it will record some basic crash information in a specific part of the RAM. This special RAM is not reset when the STM re-boots and it will automatically be dumped to the console log for investigation during the start up sequence. The “Assert info” button simply dumps the same information again, which may not sound very useful. But in some cases a client may auto-reconnect to a crashed Crazyflie, consume the console log and dispose of it before a human had the opportunity to look at it. In this case you can simply connect the client to the Crazyflie and click the “Assert info” button to get the information again.
Propeller test
The “Propeller test” button runs a automated test of the propellers and measures vibrations in the platform to determine if they are well balanced or not. The result is printed in the console window, like this: (looks like it is time to change one of my propellers!)
The final button is the “Battery test”. It tests if the battery is worn out by spinning the motors and measuring the drop in voltage. A drop in the voltage indicates that the battery probably is bad, but it can also be caused by other sources of extra resistance in the power path, for instance oxide on the battery connector. Use it as an indication only!
Note: Only use this test for the Crazyflie 2.x, not the Bolt or BigQuad.
The result of this test is printed in the console log:
It is possible to add the console log as a tool box at the bottom or one of the sides of the client. In the “View” menu, choose “toolboxes” and click “Console”. A toolbox window with the console log will appear at the bottom of the screen which can be handy as it will be visible even if you switch to another tab.
The Plotter tab with the console as a toolbox
Other debug tools
This post has been focused on the console tab, but there are of course other functionality that is useful when debugging your system. We will end by quickly mention some of them:
If anybody noticed a delay of my response on emails, forum or Github, that might be due to the fact that I was on the road for Bitcraze for the last few weeks! I was invited to give a guest lecture for a course at EPFL, and of recent they have a CO2 reducing policy regarding travel. At Bitcraze we also aim for reducing our environmental impact, so hence the idea came forth to travel to Switzerland and visit our close collaborators that are nearby(ish)… all by train! Internally we dubbed this to be The Grand Tour.
The Itinerary
We kept the itinerary mostly within Switzerland and Germany, although I did pass the Netherlands a few days just to visit family. The full itinerary by train was:
Utrecht (NL) -> Lausanne (SW) -> Zürich (SW) -> Munich (GE) -> Berlin (GE) -> Malmö (SE)
The longest train ride was from Utrecht to Lausanne (9 hours), but all the others were well under 4 hours which was pretty comfortable. The nice thing about being in the train is that it quite easy to work on your laptop (although the wireless network + onboard WiFi was still patchy). Luckily I was able to actually phone in for Bitcraze’s morning meetings so that I wouldn’t miss a thing.
Here are some pictures of the in-between travels, with the views, trains and food. It was all awesome, but if I do have to make a confession… the train rides through Switzerland was the most beautiful of all!
Travelling through Switzerland and Germany
The People
The first two days in Lausanne went quite smoothly. Dario Floreano of the Laboratory of Intelligent Systems (LIS) invited us to give a Crazyflie 101 lecture to the students of the Aerial Robotics course, for which we are very grateful for the opportunity. It was great to do the talk in person this time and visit the EPFL campus, since the last two years I’ve given the same lecture from my own kitchen. I was able to see the students trying to start up the course themselves, and actually got to experience how they would install the Crazyflie framework. Next to my lecture, I was given a very nice tour through the offices, laboratories and work-spaces, where I had the possibility see all the nature inspired drone designs of the LIS-lab. In the meantime I also squeezed in a quick but fun visit with Cyberbotics, the creator of Webots, to discuss our latest efforts for a crazyflie simulator.
After a beautiful train ride towards Zurich, I first met up with the people of the Automatic Control lab (ACL), who made a video about how they handled education with the Crazyflie during the harsher COVID times. Now I got a chance to see the flight room where students are able control their Crazyflie down to the rate attitude controller. Moreover, I was treated to a full workshop, hosted by ETH Zürich’s Integrated Systems Lab (IIS) and Center of Project Based learning (PBL), joined by researchers from ETHZ, University of Bologna and IDSIA (Lugano) working on the PULP platform and/or nano-drones. The workshop consisted of them and us showcasing our current work, future plans and they showed me very impressive demos with both the AIdeck and their own prototypes decks! Complete that with a lunch with one of the best views any campus has to offer, coffee break talks, and you have a very inspiring day.
The third part of the trip took place in Germany! My first stop was near Munich, namely Hochschule Augsburg, where I visited the Cooperative Control Lab lead by Klaus Kefferpütz where we had great discussions about collaborative swarms and state estimators. They showed their lab with demos, and we spoke about positioning systems and how to improve their development experience. They are currently integrating the Bolt with a Raspberry Pi with the latest functionalities we implemented into our firmware, which we can imagine is a very wanted feature by the community! I also had a brief visit at TU Munich as well to visit my friend Sophie Armanini from the eAviation and Sustainable Flight Group, and to my surprise I got to fly with a Crazyflie Bolt fueled Flapper drone!
As my final stop, I visited Wolfgang Hönig from the Intelligent Multi-Robot Coordination Lab (IMRC) at TU Berlin. Here we discussed all about Crazyswarm, simulations and firmware python bindings among many things. Also, we had a successful hackathon where we managed to generate python bindings of the Mellinger & PID controller and the motor mixing. On top of that, we managed to fly with the PID binding in the Webots simulator, which has been on the wish list for a little while now. It was great working together again in person after 1.5 years!
Collection of the tours, the platforms and the people I’ve met!
The Insights
It was great to see all the different ways that our products are used and what matters to the community members were dealing with. I’ve visited labs that tweak the attitude rate controllers, trying to improve the quality of the state estimators, or experiment with the actual mechanics. However, it was clear to see that quite some were controlling the Crazyflies on a higher level of autonomy, either off-board or onboard. This is all spread out over education and research alike, so there is a very wide range of people that are working with the Crazyflie.
There is of course also a huge variety in their approach. Some used our internally development framework with the Cflib and cfclient, and I’ve generated quite some new Github tickets in those respective repositories based on the discussions I had. However, it was interesting to see that many have made their own clients to tailor more to their research and education objectives. Moreover, about half of the users I met used ROS to interact with the Crazyflies. Is it perhaps a sign that we should start to rethink the communication infrastructure and how it all fits together?
There was also quite the difference on how close these users were on our latest changes. It ranged from working on a branch forked 4 years ago to being on the very edge of the commits, which each have their pros and cons. Working on a stable branch that has been proven worthy might be beneficial with education classes, but also makes people miss out on new features like the new lighthouse integration. However, it is not all fine and dandy on the edge of development either, as I have heard of many having issues with the new kbuild intergration, installing the cfclient or our latest efforts of getting the AIdeck out of early access. That is something that these pioneers has to deal every time they merge the new master, so we need to find better ways to make it easier for them as well.
And last but not least, it seems that the simulation we have been working on has generated quite the buzz, as most of whom I spoke to were quite interested in it, or has used a different simulation for their purpose. It was clear that there is not yet a standard simulator for aerial robotics that can fulfill everybody’s requirements in terms of swarming, (vision-based) autonomy or control. Perhaps that is a good reason to promote the simulation work from Fun-Fridays to a regular day project and have some interesting future discussions with the community how to shape this to most of our needs.
The Conclusion
All and all, those were very inspiring 2 weeks of travel for me. Even though physically I was a bit exhausted afterwards, mentally it was very motivating and inspiring! After two of the worst years of the pandemic it was great to talk to people in person and I really feel stronger connections with those I visited than the remote video calls we have done before. It is so important to stay in touch with the community in person, after so long time of absence, as we get a better sense of what the needs are and how people are using the Crazyflie and its ecosystem. The Grand Tour was according to us a great success, and who knows…. perhaps we will do an 2023 edition as well :)
I know a lot of you will be too distracted by chocolate to read this post, so I will make it short.
I am, too, a little distracted by sugar
As I mentioned earlier, we’re a little under-staffed right now. Jonas left us for new adventures, and Arnaud is enjoying some time with his baby (here in Sweden parental leave is thankfully long for dads too). On top of that, Kimberly was away the last two weeks to visit various labs in Europe. She will talk to you about it once she’s back, I’m sure. But with just 4 people at the office, time is a valuable resource. So what are we doing with it?
Well, a lot of that has been dedicated to the AI deck, but that’s not the only thing we’ve been working on. Recently, we had the visit of one expert on dangerous goods shipment. During 2 days, we got to learn about how to properly send the batteries we have, the regulations that are involved and what we have to implement to ship them. It may sound boring… and honestly, it was not the most interesting. But we got a certification out of it, that now allows us to ship as many batteries as we want with your order ! The 2 batteries only restriction that we have on the shop should be lifted – but please be aware that if you exceed 2 batteries per Crazyflie, the shipping cost will be higher, because of the fee Fedex imposes on dangerous goods shipments.
And speaking of Fedex, there are some problems right now on their air routes. Avoiding Ukraine and dealing with some strikes for air traffic operators in Europe has not been easy on their infrastructure, and we have experienced some delays in deliveries unfortunately. It seems to go back to normal gradually, so let’s hope their usual speediness resumes soon.
We’re also working on the Mini BAMs, which is on the 18th of May and will talk about drones for aerial show. Our special guest speakers are from Collmot and Flapper Drones, make sure to answer this survey if you want to participate ! You will get more informations soon.
And if want to play around with the AI deck, you will have an interesting occasion in September. IMAV launched a competition, where the goal is to have the Crazyflie equipped with the AI deck perform vision-based obstacle avoidance at increasing speeds. Deadline for registering are Mid-May, you can find more informations here.
We are now enjoying a long Easter week-end, recharging our batteries with families (and chocolate!), hoping that the Swedish spring finally settles here. I hope you’re enjoying it too !
And after some thoughts, we are glad to announce the Mini BAMs! As the name implies, they are shorter (maximum 3 hours if the discussions get lively), with a simplified platform (to be determined yet), but still with interesting talks, and a lot to discover from speakers and the community. Each Mini BAM will be dedicated to a specific subject, with one or two guest speakers, followed by discussions.
We already have a session programmed, so let’s see what we have in store for our very first Mini BAM!
When? The 18th of May, in the afternoon (CEST)(the exact time will be determined shortly)
What ? Our focus this time is shows in the sky! You surely couldn’t have missed that drones are getting more and more involved in shows and productions. But while aerial entertainment is getting popular, its implementation is not easy. At Bitcraze, we try to accompany artists to help them create a unique experience, but it’s not our main area of expertise. that’s why we’re turning to 2 close partners for those shows in the sky. Which lead me to….
Who ? We will have two distinguished speakers with us this afternoon.
Gábor Vásárhelyi was born in Budapest, Hungary, in 1979. He received his MSc in engineering-physics from the Technical University of Budapest, Hungary, in 2003, and his PhD in technical sciences (info-bionics) from Péter Pázmány Catholic University, Hungary, in 2007. Since 2009 he is with Eötvös University, Department of Biological Physics as leader of the Robotic Lab at Tamas Vicsek’s Research Group on collective motion. Since 2015, he is the CEO of CollMot Robotics Ltd., a spinoff dedicated to multi-drone services. His research fields are connected to the collective motion and collective behavior of animals and robots (drones). He received many awards, for exemple: Junior Prima Award, category of informatics (2007), Magyary Postdoctoral Grant (2013), Bolyai János Research Scholarship (2015), ELTE Innovative Researcher Award (2021).
You may recognize Gabor as the author of this post. For this Mini BAM, he will present us with Skybrush, his very clean platform for any kind of swarm/fleet/multi-UAV mission control.
We will also be joined by Matěj Karásek.
Matěj Karásek studied mechanical engineering and holds a PhD in engineering sciences. He spent 10 years in the academia (ULB Brussels, TU Delft) researching animal flight and developing bioinspired flying robots. He is a founder of Flapper Drones, a startup company developing bird-like robots for research and entertainment applications.
Matej will talk to us about his Bolt-based drone, that is set up with flapping wings!
You will have time to ask them questions, and be sure to stay afterwards for discussions about show drones, the Bolt, and Skybrush!
If you’re interested in joining, follow this link to pre-register:
More informations will of course come soon, stay updated!
Batteries in the shop
And now, for something completely different: you may have noticed that it’s difficult to order batteries with us these past weeks. That’s due to a change in transport regulation for Lithium batteries. Thankfully, we got a certification last week that allows us to ship batteries without the limitations that we had to put in the shop. We’re working on getting everything up to par with the new regulations, and shipping only batteries should soon be possible. Finally, the Swarm bundles will be, for a short time, sold without any chargers as we’re out of stock for those. The prices have been regulated accordingly.
There is a new fresh release of both the firmware and the python library and client! The last release (2022.01) was from 2 months ago but we already added quite some extra functionality so we wanted to make a snapshot of this before continuing on other priorities.
Kbuild on CF firmware
One of the biggest changes that you will notice, is that there is now a new way to configure your Crazyflie firmware before building it. The old config.mk is gone and you will now need to either automatically generate a config file or generate one with the menuconfig, of which kbuild is most known for. For more information, please read the blogpost about this latest change, for the exception that we do prefer the users to use ‘make cf2_config’ as instructed in the 2022.03 version of the repo documentation.
Platform support for Bolt
We now defined the Bolt as a different platform. That means that for each release, there should now also be a bolt flavor zip file, next to the cf2 and tag zips, as you can see in the release page. Moreover, if you want to build the firmware to be Bolt compatible, you would first need to do ‘make bolt_defconfig’ to generate the needed configs with kbuild. For more information of how to add your own custom platform, please check out these instructions.
2+ Lighthouse base stations (experimental)
For those that feel constrained by the max 2 lighthouse base station support in the firmware and client, this functionality is now part of the release. This blogpost will explain more about this, and it is still experimental in nature, as you would need to reconfigure the firmware with… you guessed it: Kbuild! Also the geometry estimation needs to be done as a separate python script as well all from the Crazyflie python library. No worries, if you still prefer using the cfclient, it still uses the old way of estimating if you click the button, but just remember that you would need to do something extra in order to get 2+ base station support.
New VM release
We were also made aware of a pretty big error in the bitcraze VM, namely that we still used the old git:// type url for github repositories. IN the new release of the bitcraze VM this should be fixed, so please download the new one, or fix it yourself in your current VM by changing the remote URLs of the github repos you are working on to https://.
There has been some background work going on related to the Lighthouse system, as mentioned in a previous blogpost. The solution has been improved since that blog post and we believe the functionality is now on a level where it works pretty well and can add value to most Lighthouse users.
How to use it?
We have added a brief documentation to get you started. Though the solution has been stabilized, it is still a bit experimental and it has not been fully integrated into the client yet. The base station geometry estimator still has to be run as a python script from the command line, and a reconfigured version of the Crazyflie firmware has to be built and flashed.
We have added some improvements to the client thought to enable it to display base station status for 2+ base stations. This was the final part of the client UI that did not support 2+ base stations, and now remains only the possibility to run the new geometry estimation from the client.
Benefits
What kind of improvements does it bring?
First of all, the functionality to use more than 2 base stations and the possibility to cover a larger flight space. It also makes it possible to set up multi-room systems to support flight from one room to another.
Secondly an improved estimation of the base station geometry (also when using 2 base stations) that generally reduces the errors and improves the position estimation of the Crazyflie when flying. “Jumping” of the estimated position when one base station is occluded should be reduced. When following a trajectory that is straight line through space, the Crazyflie should now actually fly on a fairly straight line, previously the flown path might be a bit curved.
The new solution has a better match to the physical world and hopefully the estimated Z will be closer to zero when the Crazyflie is on the floor, with the “old” method, the solution sometimes is slightly tilted with a Z != 0 in some areas.
Problems
Most of the Lighthouse system works just like before, the new functionality is related to base station geometry estimation. The “standard” geometry estimation is still available in the client and if you continue to use this nothing is changed, the following list is for the new estimation method.
The new geometry estimation is a bit clunky to use and the user still has to rebuild the firmware and run a python script.
Lighthouse 1 is not fully supported
The new geometry estimation does not work with one base station.
We hope to address the above problems in future releases.
Release
Talking about releases, we are working on a new official release. If no unforeseen obstacles are found, we plan to make a new release within a week or two.
The functionality discussed in this blog post is still only in source code, on master or possibly in some pull requests. If you wait for the release all repositories should be syncronized and make it a bit easier to try out.
Feedback
As the environment of the system has an impact on this type of functionality, we would love to get feedback from you if you try it out. We’d love to hear how it works for you!
In December we had a blogpost where we gave an overview of existing simulation models that were out there. In the mean time, I have done some work during my Fun Fridays to get this to work even further. Currently I moved the efforts from my personal Github repo to the Bitcraze organization github called crazyflie-simulation. It is all still very much work in progress but in this blogpost I will explain the content of the repository and what these elements can already do.
Low Poly CAD model
The first thing that you will need to have for any simulation, is a 3D model of the Crazyflie. There is of course already great models available from the CrazyS project, the sim_cf project and the multi_uav_simulator, which are completely fine to use as well. But since we have direct access to the exact geometries of the real crazyflie itself, I wanted to see if I could abstract the shapes myself. And also I would like to improve my Blender skills, so this seemed to be a nice project to work with! Moreover, it might be handy to have a central place if anybody is looking for a 3D simulation model of the Crazyflie.
For simulations with only one or a few Crazyflie, the higher resolution models from the other repository are absolutely sufficient, especially if you are not using a very complicated physics geometry model (because that is where most of the computation is). But if you would like to simulate very big swarms, then the polygon count will have more influences on the speed of the simulation. So I managed to make it to 1970 vertices with the below Crazyflie model, which is not too bad! I am sure that we can make it even with lesser polygons but this is perhaps a good place to start out with for now.
In the crazyflie-simulation, you can find the Blender, stl files and collada files under the folder ‘meshes’.
Webots model
We implemented the above model in a Webots simulator, which was much easier to implement than I thought! The tutorials they provide are great so I was able to get the model flying within a day or two. By combining the propeller node and rotational motor, and adjusting the thrust and drag coefficient to be a bit more ‘Crazyflie like’, it was able to take off. It would be nice to perhaps base these coefficients on the system identification of the Crazyflie, like what was done for this bachelor thesis, but for now our goal is just to make it fly!
It would then be possible to control the pitch and roll with the arrow keys of your keyboard while it is maintaining a current height of 1 meter. This is current state of the code as of commit 79640a.
Ignition Gazebo model
Ignition will be the replacement for Gazebo Classic, which is already a well known simulator for many of you. Writing controllers and plugins is slightly more challenging as it is only in C++ but it is such a landmark in the world of simulation, it only makes sense that we will try to make a Gazebo model of the Crazyflie as well! In the previous blogpost I mentioned that I already experimented a bit with Ignition Gazebo, as it has the nice multicopter motor model plugin standard within the framework now. Then I tried to make it controllable with the intergrated multicopter velocity control plugin but I wasn’t super successful, probably because I didn’t have the right coefficients and gains! I will rekindle these efforts another time, but if anybody would like to try that out, please do so!
First I made my own controller plugin for the gazebo model, which can be found in the repository in a different branch under /gazebo-ignition/. This controller plugin needs to be built first and it’s bin file added to the path IGN_GAZEBO_SYSTEM_PLUGIN_PATH, and the Crazyflie model in IGN_GAZEBO_RESOURCE_PATH , but then if you try to fly the model with the following:
It will take off and hover nicely. Unfortunately, if you try out the key publisher widget with the arrow keys, you see that the Crazyflie immediately crashes. So there is still something fishy there! Please check out the issue list of the repo to check the state on that.
Controllers
So the reason why I made my own controller plugins for the above mentioned simulation models, is that I want to experiment with a way that we can separate the crazyflie firmware controllers, make a code wrapper for them, and use those controllers directly in the simulator. So this way it will become a hybrid software in the loop without having to compile the entire firmware that contains all kinds of extra things that the simulation probably does not need. We can’t do this hybrid SITL yet, but at least it would be nice to have the elements in place to make it possible.
Currently I’m only experimenting with a simple fixed height and attitude PID controller written in C, and some extra files to make it possible to make a python wrapper for those. The C-controller itself you can try out in Webots as of this commit 79640a, but hopefully we will have the python version of it working too.
What is next?
As you probably noticed, the simulation work are still very much work in process and there is still a lot enhancements to add or fix. Currently this is only done on available Fridays so the progress is not super fast unfortunately, but at least there is one model flying.
Some other elements that we would like to work on:
Velocity controller, so that the models are able to react on twist messages.
Crazyflie firmware bindings of controllers
Better system variables (at least so that the ign gazebo model and the webots model are more similar)
I might turn a couple of these into topics that would be good for contribution, so that any community members can help out with. Please keep an eye on the issue list, and we are communicating on the Crazyswarm2 Discussion page about simulations if you want to share your thoughts on this as well.
During the last couple of months we’ve been working on getting the AI-deck out of early-access. One of the things needed for this to happen is an improved infrastructure for the AI-deck, like bootloading and how the deck fits into the rest of the eco-system. For this there’s two new repositories:
With the addition of two new MCUs (ESP32 and GAP8) as well as the possibility to connect via the WiFi, we quickly run into the issue of how to communicate between the targets. Even more so since there’s no direct access between some of these (like the Crazyflie<->WiFi, Crazyflie<->GAP8, GAP8<->WiFi).
What we needed was a protocol that …
… could be routed though intermediaries to reach it’s destination
… could handle high transfer rates with large amounts of data as well as small messages
… could handle different memory budgets
… doesn’t drop data along the way if some parts of the system is loaded
We decided to design and implement a new protocol, which we’ve named CPX (Crazyflie Packet eXchange). The protocol solves the issues above by:
Each packet has a source and destination ID, so it can be routed to (and from) the target of the packet
Each link between targets can have it’s own MTU, which allows each target to optimize memory usage. In order to handle this, intermediaries are allowed to split packages along the way, so data can be transferred in smaller pieces.
Instead of dropping packages if targets become overloaded, congestion in created in the system, where the sender will not be able to send more data until the receiver has been able to handle it.
Currently the new protocol is used for the GAP8 bootloader, for setting up the WiFi on the ESP32 and in the WiFi streamer example. But we’re hoping to expand it in the future to include more functionality, like logging and other plumbing that could be used in user applications.
WiFi configuration changes
With CPX it’s now possible to set up the WiFi from either the Crazyflie, the GAP8 or from the ESP32 itself. For doing this from the Crazyflie we’ve added the option of configuring this using KConfig, where we’ve added the following options in the expansion decks menu for the AI-deck:
Do not set-up the WiFi: Should be used if another target is setting up the WiFi, like the GAP8
Act as an access point: This will make it possible to connect to the AI-deck as an access point
Connect to an access point: This will connect the AI-deck to an access point using SSID/PASSWD entered in the menuconfig
GAP 8 bootloader
To make things easier for the user we want to remove the requirement of using a JTAG dongle to program the GAP8. In order to achieve this we’ve implemented a bootloader for the GAP8 which uses CPX, which means it can be used either from the Crazyflie or over the WiFi. We still haven’t had time to implement the Crazyflie part, where this will fit nicely together with the cload and client deck firmware upgrade, but it’s currently working via the WiFi. So until the implementation is done via the Crazyflie Python library, this script can be used to bootload and start your custom GAP8 firmware. Note though, that you will first have to flash the GAP8 bootloader and set-up the WiFi.
What’s next?
We’re continuing working towards getting the AI-deck out of early access. For CPX and the GAP8 bootloader there’s still a few bugs to iron out and examples to be updated as well as improved support for building using our toolbelt.
