For a long time issue #270 has been bugging us. It caused the µSD-card logging to fail in combination when using either the flow or loco deck, or actually any deck that uses the deck SPI bus. Several attempts has been made to fix this issue over time and recently we decided to really dig in to it. There has been some workaround to move the µSD-card to a different SPI bus but that was tedious and required patching the deck. So it was time to fix this for good, or at least know why it doesn’t work. A SPI bus is designed to be a multi-bus so it should be possible… Timing problems is still tricky but that is another story.
The problem
The SPI driver is protecting the bus with a mutex to prevent several clients to access it at the same time. After some digging we found that the FatFs integration layer was bugged and that SPI bus handling wasn’t well done. After comparing this to some other open implementations we found that this needed to be rewritten.
The solution
After rewriting part of the integration layer to have clear path of when the SPI bus was taken, and when it was released, we immediately got some good results. µSD-card logging with flow and loco deck worked, hooray! There is of course a limit to this and as we mentioned earlier the bus is a shared resource and if it is to congested, things will slow down, or stop working. This is currently the case when LPS is put in TWR mode. The TWR is very chatty and causes around 15k transactions per seconds on the SPI bus, and since it has higher priority than the µSD-card logging, the µSD-card write task starves, causing the logging to fail.
µSD and LPS SPI bus captured with a logic analyzer, over 50msµSD and LPS SPI bus captured with a logic analyzer, over 6ms
So if you stay away from LPS in TWR mode µSD-card logging should now work fine. I’m pretty sure there is a workaround for the TWR mode as well. First guess is that you would need to slow down the TWR update rate which is now at its maximum.
It has almost been 2.5 years since we last made a compilation video about what has been done with the crazyflie 2.0 (see this blogpost). During this time we released several new products and many of you were able to achieve very cool and awesome applications so we thought it was time for a new research compilation video!
We have seen quite a lot of projects with swarms of Crazyflies, ranging from close proximity flight to autonomous exploration in a building. Some research groups have also been experimenting with controlling the Crazyflie with our own hands, either to control its position or to reach another state of mind entirely. Others have created their own deck in order to add their own sensors or cameras necessary for their application. One of those even led to the new AI-deck that we introduced in early release before the summer! Last but not least: we were shown that the low level control can be further improved and multiple crazyflies can be linked together and still fly!
We were overwhelmed by all the awesome things that the community showed us of what possible with the Crazyflie and this will inspire others to think of new things to do as well. We hope that we can continue with helping you to make your ideas fly, so that we are soon to be forced to make another completion video ;)
Here is a list of all the research that has been included in the movie:
Close proximity flight of sixteen quadrotor drones, CalTech: B. Rivière, W. Hoenig, Y. Yue, and S.-J. Chung (video, paper)
Pointing gestures, IDSIA: B. Gromov, J, Guzzi, L. M. Gambardella, A. Giusti (video, project)
Yaw actuation, Modlab UPenn: B. Gabrich G. LiM. Yim (video, paper)
Learning to seek, Harvard University: B. P. Duisterhof , S. Krishnan, J. J. Cruz, C. R. Banbury, W. Fu, A. Faust, G. C. H. E. de Croon, V. Janapa Reddi (video, paper)
Drone Chi, Exertion Labs and RMIT: J. La Delfa, M. Baytas, E. Luke, B. Koder, F. Mueller (video, project)
Generalization through simulation, Berkeley AI Research (BAIR): K. Kang, S. Belkhale, G. Kahn, P. Abbeel, S. Levine (video, paper)
Swarm exploration, TU Delft: K.N. McGuire, C. De Wagter, K. Tuyls, H. Kappen, G.C.H.E. de Croon (video, paper)
PULP-based autonomous drone, ETH Zürich: D. Palossi, F. Conti, and L. Benini (video, paper)
Networked Autonomous Aerial Vehicles, University of Klagenfurt, Austria: Research by Karl Popper Kolleg (video)
GLAS for Multi-Robot Motion Planning with End-to-End Learning, CalTech: B. Rivière, W. Hoenig, Y. Yue, and S.-J. Chung (video, paper)
Resilience by reconfiguration, USC: R. K. Ramachandran, J. A. Preiss, G. S. Sukhatme (video, paper)
Following firmware releases we have now released a new version for the Crazyflie client and python lib (cflib). It took a bit more time to test and fix various last minute bugs but we now have released Crazyflie client 2020.09 as well as Crazyflie lib 0.12.1.
Crazyflie python lib 0.12.1
The main new funcitonalities of the lib are:
Python 2.x support is now dropped. Python 2 official support has ended beginning of this year and it is not installed by default in Ubuntu 20.04, it was time to stop supporting it in cflib
Some documentation work
Capabilities to abort a bootloading operation
Crazyflie client 2020.09
There has been a brunch of cosmetic and functional changes in the client. Some themes have been added so that the client can now be used with a dark blue or even green-on black hacker theme. The used Qt theme has also been forced to be drawn by Qt on all platforms: this means that the client will not look like a Windows or Mac app on Windows and Mac, but the styling will be consistent on all platform. This will simplify development and make documentation consistent with all platform.
The bootloader has been changed to automatically download releases of the firmware from Github by default. This is a great quality of life feature made by victor this summer that makes it very easy to run Crazyflies with a clean release build.
New bootloader window
There are also a brunch of bugfixes, the full changelog can be read on the release page.
Future plans
Semantic versioning for the lib
We have been thinking of using semantic versioning for the lib and bumping the version to 1.0. This will allow us to communicate the state of the lib more accurately: it is not perfect but it is perfectly usable. As well giving more freedom to break compatibility. A lot of things could be made better but we are always very careful not breaking backwards compatibility. Proper semantic versioning would allow us to make a Crazyflie client lib 2.0 making it clear that if you update from 1.0 to 2.0 you might have to make changes to your scripts.
Client binary release for more platform
So far, the Crazyflie client has had a binary release for Windows and some work to make one for MacOS. By Binary release we mean releasing the client in a form that does not require installing python, and then the crazyflie client pip package, on Windows it is an installer and on Mac it would be an app bundle.
Last week we have also been working on Linux releases, after all most of us uses Linux at Bitcraze so we might as well show it some love. Today we have released a snap of Crazyflie client. This means that you can install Crazyflie client from the Ubuntu software application on Ubuntu, or directly via the snap install –edge cfclient command on any Linux system with snap installed. There is still some rough edges, and a stable version will only be available for next release, but this should make it much easier to get started with the Crazyflie.
We are happy to annouce that we have released a new version of the Crazyflie firmware, version 2020.09. It is available for download from Github.
The new firmware solves an old compatibility issue when using the LPS and Flow deck at the same time and also improves stability. A list of all the issues that have been fixed can be found on the release page.
For users that have a LPS system, we have also made some improvements to the LPS node firmware and are releasing version 2020.09.
If you are building the Crazyflie or LPS firmware from source, remember to update the libdw1000 git submodule using
git submodule update
We are working on a release of the python client as well, but still have a few issues to fix so stay tuned.
It’s been more than 6 months now that I’ve joined Bitcraze and we are currently looking for more passionate people to join our team. So what is it like to work at Bitcraze? Here is my story.
First weeks
My first day of work was actually during one of our quarterly meetings, which means it was during a conference, in a good hotel with a nice spa and dinner, well needed after many hours of retrospective, brainstorming and planning. It was the perfect way to enter the Bitcraze world, and get to know my colleagues: it included serious talks, but also massages and board games. Did I get used to the good life? Well, I discovered that it was not all champagnes and jaccuzi: my first actual day at the office, I cut my finger pretty badly, spreading blood all over the kitchen. That’s fine, now everyone knows I’m not to be trusted with a knife! And I have a nice “Bitcraze” scar to show.
The on boarding itself included some education from our process guru, Kristoffer. I was excited and very curious to discover how a self-organizing company functioned, and I learned a lot during those sessions. I discovered a new way of working. It got some getting used to, but I got to really analyze and question my working habits and reflexes, which is always healthy. I am now an adept of lean and agile processes, and love being involved in the innerworking of the company and its processes.
Daily habits
As the days went along, I took my marks. I am everyday happy to get up and go to work. I especially love Mondays, that usually involve a nice morning chat, sitting on the sofa, discussing how the weekend was or the latest Netflix documentary, before beginning our weekly meeting. I discovered that Bitcraze is all about habits and routines, that I sometimes had to adapt to my non-geeky role. Tuesday for examples is usually dedicated to coding and programming: for me, it meant that’s the day I dig into the accounting!
We also have a tradition of “fun friday” that I really enjoy. The concept is simple: Fridays are dedicated to something that we love and have fun with. It allowed me to play around with my Crazyflie and its various decks, but also to work on my photographic skills or think about a more dedicated marketing strategy. It helps that usually, Fridays end with a nice chat around a beer and some VR games.
I love that I’ve got an independence to decide how my day is going to look like. My daily tasks include a lot of different things and areas. It’s a real luxury to me to be able to choose what I feel like tackling at any point. If I don’t feel like crunching numbers, I can deal with the shipments. Maybe today I’ll order those office supplies we need, or look into our social media statistics. When I first got recruited, the word “passion” came back a lot, and it didn’t disappoint: everything we do is driven by passion. I get to do and learn a lot of different things, and rarely get bored.
Global pandemic
Unfortunately, just as I begun to be comfortable on my new everyday routine, the world was hit by a global pandemic. Our habits were completely changed as we closed the door on the office and worked from home for 3 months.
I am actually really proud of how we handled it. Sure, the process and work flow changed drastically, but we kept on going, having faith in each other and in our capability in handling it. We kept the communication channels open, and produced the AI deck while working remotely.
For me, those times were though. I still needed the everyday guidance of my colleagues, which is trickier when they’re not sitting next to you. But it also gave me the opportunity to do more by myself, which ultimately led to learn things a lot quicker, I think. The hardest, though, was when everybody got to get back to the office, and I couldn’t: I belong in a risk group for Covid. I miss the fika with my colleagues, and working remotely seem pretty lonely.
Working as a non-tech
The trickiest part for everyone when I joined Bitcraze was to fit in the more technical aspects of the company. I only have a little programming and tech background, so including me in the geek discussions without using too much jargon was not easy for the guys. I learned a lot, in a short time. I still bug them with my questions and have a long list of terms and concepts I need to read about. But that’s ok, because my “cluelessness” actually provided good insights on the work we still have to do on documentation. And the work to understanding each other better actually flowed both ways: I had also sometimes to include my colleagues in more administrative aspects that they don’t know, or don’t care about. It’s interesting to try to adapt the Bitcraze process just because I’m here: it’s not only about developing tech anymore, we have to think about a way to involve administrative tasks to our methods.
All in all, working at Bitcraze is everything I thought it will be, and more: I love spending time with my colleagues. Each morning, I feel lucky to have joined a passionate and exciting company. I didn’t think I’ll be someone that happily turns her computer on a Sunday night to check what Monday will have to offer, but that’s what I end up doing most of the weeks.
That’s why my feelings today are mixed: I’m actually leaving the office to enjoy my generous Swedish maternity leave. Being pregnant and welcoming a new life is exciting, and I’m really happy to extend my family, but not working at Bitcraze will feel weird and I know I will miss it. Nevertheless, I know the guys will do fine without me, and I’ll be back in 2021 for more exciting news!
And if you’re interested in working at Bitcraze too, you’ll find more infos here !
I am back from parental leave and during this time I tried not to think too much about Crazyflie-related things to get a little break. However, over time, while geeking around, I eventually ended-up back to Crazyflie and Crazyradio designing a new channel-hopping communication protocol. This will likely be the subject of a future blog post but for the time being I thought I could write a bit about how the current Crazyflie radio communication is working.
Protocol layers
Like Many protocols, the Crazyflie communication protocol is layered. This allows to plug different elements at each level. When it comes to a Crazyflie client talking to a Crazyflie over the radio, the layering looks as follow:
Services are high-level functionalities like log that allows to get values of Crazyflie variables at regular interval. At this level there is essencially an API with commands like addLogBlock.
CRTP is a protocol that encapsulates the commands for each sevices. It multiplexes packets on the link using port numbers, this is very similar to TCP/UDP port on a network, each service is listening and sending packet on a pre-specified port.
Finally the radio link only deals with raw packets. The role of the radio link is to deliver packets from the PC to the Crazyflie and vice-versa. At this level, we have many link implementations, the most used are the radio and the USB link but there also is a Serial link that uses the Crazyflie serial port.
Radio link
The radio link is currently implemented by the Crazyradio (PA) on the PC side and the Crazyflie on the other side. The Crazyradio uses a nordic semiconductor nRF24LU1 USB/Radio chip and the Crazyflie a nRF51822 MCU/Radio. This is importance since, while the nRF51 has a quite flexible radio, the nRF24 does use a standalone SPI radio that has most of the packet handling hard-coded to a protocol that nordic call Enhanced Shockburst (ESB).
The ESB protocol handles sending packet and receiving acknowledgement automatically. A packet is sent on a radio channel, using a 5 bytes address, and when this packet is received on the other side an acknowledgement is sent back using the same address on the same channel. Both the original packet and the acknowledgement can contain a payload.
To implement a bi-directional radio link, the crazyradio is the one sending packets and the Crazyflies continuously listens and, when receiving a packet, sends back an ack. We do use the payload capabilities of both packet we send and of the ack to implement an uplink (PC->Crazyflie) and downlink (Crazyflie->PC) data link.
Of course, one problem with this setup is that while the PC can decide to send a packet at any moment, the Crazyflie needs to wait for the PC to send a packet to have a chance to send one back in an ACK. To make sure the Crazyflie has enough opportunity to send packets back, we are sending packets regular interval to the Crazyflie even if there is no packet to be sent. This polling allows to implement a continuous downlink.
The most important to see here is that the radio link gives to the upper layer, the CRTP layer, the illusion of a full duplex link. On the radio side this is implemented by polling regularly for downlink packets.
Communicating with multiple Crazyflies
In order to communicate with multiple Crazyflie, we just send packet to each Crazyflies one after each-other. This way we give equal chance for each Crazyflie to send back packets and doing so we divide the available bandwidth between them.
The main advantage of the polling protocol versus a more traditional P2P protocol where the Crazyflies would send when they want, is that when using polling the Crazyradio is the master and we can guarantee that we are not introducing any packet collision when we communicate.
Limitation and future
One major limitation of the current protocol is that it communicates on a single channel and requires the user to set manually channel and address for each Crazyflies. This means that the user has to tinker with parameters to find a good channel and has to manually handle all addressing.
Another limitation is that the polling is done over USB by python or, in case of ROS/Crazyswarm, in C++. This adds the USB latency to the equation and complexifies the client implementation.
I have been working on defining a new protocol that would be implemented efficiently in a Crazyradio and that would implement addressing and channel hopping. The idea is to get closer to a connection style more like bluetooth low energy where you do not have to care about channels and setting address, you just connect your device. Unlike BLE though, this protocol will be optimized for low latency. Stay tuned, we will likely talk about that more in future posts :-).
Now that we are all back from our summer holiday, we are back on what we were set on doing a while ago already: fixing issues and stabilizing code. In the last two weeks we have been focusing on fixing existing issues of the Flowdeck and LPS positioning system. It is still work in progress and even though we fixed some problems, we still have some way to go! At least we can give you an update of our work of the last few weeks.
Flow-deck Kalman Improvements
When we started working on the motion commander tutorials (see this blogpost), which are mostly based on flying with the flowdeck, we were also hit by the following error that probably many of you know: the Crazyflie flies over a low texture area, wobbles, flips and crashes. This won’t happen as long as you are flying of high texture areas (like a children’s play mat for instance), but the occasional situation that it is not, it should not crash like it does now. The expected behavior of the Crazyflie should be that it glides away until it flies over something with sufficient texture again (That is the behavior that you see if when you are flying manually with a controller, and you just let the controls go). So we decided to investigate this further.
First we thought that it might had something to do with the rotation compensation by the gyroscopes, which is part of the measurement model of the flowdeck, since maybe it was overcompensating or something like that. But if you remove that parts, it starts wobbling right away, even with high texture areas… so that was not it for sure… Even though we still think that it causes the actual wobbling itself (compensating flow that is not detected) but we still had to dig a bit deeper into the issue.
Eventually we did a couple of measurements. We let the Crazyflie fly over a low and high texture area while flying an 8 shape and log a couple of important values. These were the detected flow, the ground truth position, and a couple of quality measurements that the Pixart’s PMW3901 flow sensor provided themselves, namely the amount of features (motion.squal) and the automatic shutter time (motion.shutter). With the ground truth position we can transform that to the ground truth flow that the flowdeck is supposed to measure. With that we can see what the standard deviation of the measurement vs groundtruth flow is supposed to be, and see if we can find a relation the error’s STD and the quality values, which resulted in these couple of nice graphs:
Three major improvements were added to the code based on these results:
The standard deviation is the flow measurement is increased from 0.25 to 2.0 pixels, since this is actually a more accurate depiction of the measurement noise to be expected by the Kalman filter
An adaptive std based on the motion.shutter has been implemented (since there is a stronger correlation there than with motion.squal), which can activated putting the parameter motion.adaptive to True or 1. Its put by default on False or 0 since the heightened STD of the first improvement already increased the quality of flight significantly.
If the flow sensor indicates there is no motion detected (log motion.motion), it will now prevent to send any measurement value to the Kalman filter. Also it will adjust the difference in time (dt) between samples based on the last measurement received.
Now when the Crazyflie flies over low texture areas with the Flowdeck alone, it will not flip anymore but simply glide away! Check out this closed issue to know more about the exact implementation and it should be part of the next release.
The LPS and Flowdeck
Kalman filter conflicts
The previous fix of the flow deck also took care of this issue, which caused the Crazyflie to also flip in the LPS system if it does not detect any flow.. This happened because the Kalman filter trusted the Flow measurement much more than the UWB distance measurement in the previous firmware version, but not anymore! If the Flowdeck is out of range or can’t detect motion, the state estimation will trust the LPS system more. However, once the Flowdeck is detecting motion, it will help out with the accuracy of the positioning estimate.
Moreover, now it is possible to make the Crazyflie fly in and out of the LPS system area with the Flowdeck! however, be sure that it flies using velocity commands, since there are situations where the position estimate can skip:
1- LPS system is off 2- take off Crazyflie with only Flowdeck, 3 – turn on the LPS nodes
1- Take off in LPS, 2- fly out of LPS system’s reach for a while (position estimate will drift a bit) 3- Fly back into the LPS system with position estimation drift due to Flowdeck.
As long as your are flying with velocity commands, like with the assist modes with the controller in the CFclient, this should not be a problem.
Deck compatibility problems
The previous fixes only work with the LPS methods TDOA2 and TDOA3. Unfortunately, there is still some work to be done with the Deck incompatibility with the TWR method and the Flowdeck. The deck stops working quickly after the Crazyflie is turned on and this seems to be related to the SPI bus that is shared by the LPS deck and the flowdeck. Reading the flow sensor takes some time, which blocks the TWR algorithm for a while, making it miss an event. Since the TWR algorithm relies on a continues stream of events from the DWM1000 chip, it simply stops working if it does not … or at least that is our current theory …
Please check out this issue to follow the ongoing discussion. If you have maybe an idea of what is going on, drop a comment and see if we can work together to iron out this issue once and for all!
Hello everyone, this is Victor and I’ve spent another internship here at Bitcraze. You can read my blogpost from last year here https://www.bitcraze.io/2019/08/summer-internship/. I have learned a lot since last year so it has been fun to put my skills to test!
This summer I have spent my time on improving the cf-client. I’ve fixed a few bugs but mostly it has been about making small changes that improves overall functionality.
Some of the improvements that I’ve worked on:
Flight-control tab: Added logging of x and y-axis and changed the columns to more suitable groups. Also improved UI for assist mode.
Flashing dialog: Added support to flash both of the MCUs individually as well as choosing which one to flash (previously you could only flash the stm32 or both). Created an automatic firmware-release-downloader, so that you don’t have to download the files manually.
Log-config: Added grouping of log-configurations, that allows you to group the configs into categories. Also added small functionalities like double-click to add, remove configs etc.
Added sort-support for all list/tables.
Removed traces from Crazyflie 1.0 and support for x-mode, since it is no longer supported by the client.
Removed traces from python 2.
I hope that the functionalities will help you and make your experience with the client better. If you have any tips for further improvements, you’re more than welcome to leave a comment or contribute yourself. This is my last week for this summer, but I hope to see you all again and until then, fly safe!
As you probably already know we have been wondering how to best handle our documentation and how to provide information to new Crazyflie starters as easy as possible, as you can read in our blogpost of two weeks ago. In the mean time, we also had a chance to think about the results of a poll we had when we discussed about new ways on how to meet our users. We had about 30 responses, but it became clear that many of you are in the need of getting some more knowledge about working with the Crazyflie. The majority voted for online tutorials, and although it might be difficult to do those during the summer holidays, we already started to make step-by-step guides of various parts of the Crazyflie Eco-system.
Poll result of alternative events.
Python Library Tutorials
Currently we have started with step-by-step tutorials of the CFLIB (the python library of the crazyflie). Usually we refer to the example pages of the CFLIB, however we feel that many users copy paste parts of these scripts for their own purposes, without understanding what is actually going on. Therefore, in order to move Crazyflie beginners to the starting developer phase, we have made these guides in order to teach exactly what is going on in each module, step-by-step.
These tutorials can be found in the python library documentation. The first tutorial focuses on connecting, logging and parameters, which guides you through the process of connecting the Crazyflie through a python script, starting up logging configurations in two ways (asynchronous and synchronous) and how to read and set parameters.
The second tutorial is about the motion commander and is a logical continuation of the first. A nice thing is that we also show how to build in some protection in your script as well. If the Flowdeck is not attached, you can check that and prevent the Crazyflie from taking off altogether if it does not detect the Flowdeck. This will be a life saver in your future endeavors, and trust me I know from experience ;). Afterwards it will go into how to take off – fly forward and go back to the initial position. The application of the end of the motion commander tutorial, is where we also use the logging functionality to get the actual estimated position of the Crazyflie. With this information, we show how to write an application that create a virtual bounding box where the Crazyflie can bounce around in (like the old windows screensaver).
The results of the motion commander step by step guide.
We are planning to finish this step-by-step guide by adding the multi-ranger to the mix, continuing on the bouncing ball example. After that we will probably start some tutorials on how to use the swarming functionality before moving on to the firmware or the client.
Work in Progress
The tutorials are still work in progress. So let us know on the forum, python library github repository or as a comment on this blogpost if you see anything wrong or if something is not very clear. This will improve the quality further so that other users can benefit as well. Also once the these step-by-step tutorials are finished we can start working on video based tutorials as well.
Remember, it is possible to contribute your own fixes (or tutorials) to our repositories if you want to. It’s an open source project after all ;)
Modular robotics implies in general flexibility and versatility to robots. In theory, you could design a modular robot basically on the way you would want it to be, by simply adding or removing modules from the already existing robot. Changing the robot configuration by adding more individuals, generally increases the system redundancy, meaning that now, there are probably many different ways to achieve a specific goal. From a naive standard point of view, more modules could imply in practice more robustness due to this redundancy. In fact, it does get more robust by the cost of becoming more complex, and probably harder to control. Added to that, other issues may arise when you take into account that your modular robot is flying, and how physical properties and actuation scales as the number of modules grow.
In the GRASP Laboratory at the University of Pennsylvania, one of our focuses is to allow robots to achieve a specific task. In this work, we present ModQuad-DoF, which is a modular flying platform that enlarges the configuration space of modular flying structures based on quadrotors (crazyflies), by applying a new yaw actuation method that relies on the desired roll angles of each flying vehicle. This research project is coordinated by Professor Mark Yim , and led by Bruno Gabrich (PhD candidate).
Scaling Modular Robots
Scaling modular robots is a very challenging problem that usually limits the benefits of modularity. The sum of the performance metrics (speed, torque, precision etc.) from each module usually does not scale at the same rate as the conglomerate physical properties. In particular, for ModQuad, saturation from individual motors would increase as the structures became larger leading to failure and instability. When conglomerate systems scale up in the number of modules, the moment of inertia of the conglomerate often grows faster than the increase in thrust capability for each module. For example, the increase in the moment of inertia for a fifth module added to four modules in a line can be approximated by the mass of the module times half the distance to the center squared. This quadratic increase gives us the intuition that the required yaw actuation grows faster than the actuation authority.
Yaw Actuation
An inherit characteristic of quadrotors is to have their yaw controlled by the drag moments from each propeller. For ModQuad as more modules are docked together, a decreased controllability in yaw is noticed as the structure becomes larger. In a line configuration the structure’s inertia grows quadratically with the distance of each module to the structure center of mass. On the other hand the drag moments produced scales linearly with the number of modules.
The new yaw actuation method relies on the fact that each quadrotor is capable to generate an individual roll enabled by our new cage design. By working in coordinated manner, each crazyflie can then generate structure moments from moment arms provided by the propellers given its roll and its distance from the structure’s center of mass.
Cage Design
The Crazyflie 2.0 is the chosen platform to enable thrust and attitude to the individual modules. The flying vehicle measures 92×92×29 mm and weights 27 g while its battery lasts around 4 minutes for the novel design proposed. In this work the cage performs as pendulum relative to the flying vehicle. The quadrotor is joined to the cage through a one DOF joint. The cages are made of light-weight materials: ABS for the 3-D printed connectors and joints, and carbon fiber for the rods.
Although the flying vehicle does not necessarily share same orientation as the cage, the multiple connected cages do preserve same orientation relative to each other. With the purpose of allowing such behavior, we used Neodymium Iron Boron (NdFeB) magnets as passive actuators to enable rigid cage connections. Docking is only allowed at the back and front face of the modules, and each one of these faces contains four magnets. Those passive actuators have dimensions of 6.35 × 6.35 × 0.79 mm with a bonding force of 1 kg.
Structure Flying Performance
Conclusions
ModQuad-DoF is a flying modular robotic structure whose yaw actuation scales with increased numbers of modules. ModQuad-DoF has a one DOF jointed cage design and a novel control method for the flying structure. Our new yaw actuation method was validated conducting experiments for hovering conditions. We were able to perform two, four and, six modules cooperatively flying in a line with yaw controllability and reduced loss in thrust. In future work we aim to explore the structure controllability with more robots in a line configuration, and exploring different solutions for the desired roll angles. Possibly, with more modules in the structure, only a few would be required to roll in order to maintain a desired structure yaw. Given that, we could explore the control allocation for each module in a specific structure configuration, and dependent on its desired behavior. Further, structures that are not constrained to a line will also be tested using the basis of the controller proposed in this work.
